Cisco Secure Client bloķē VPN no RDP sesijas

Pieteikšanās izdodas, bet tunelis tomēr nepaceļas. Šī kombinācija mulsina, jo to nolasa kā autentifikācijas problēmu, un pēc tam pēcpusdiena tiek pavadīta, atiestatot pieteikšanās datus, kas nekad nebija cēlonis. Cisco Secure Client var atteikties izveidot VPN tieši tāpēc, ka mēģinājums nāca no Remote Desktop sesijas, un šo lēmumu pieņem politika klienta pusē.

Kur tas parādās savienojuma plūsmā

Izstaigājiet klientu no augšas. Profils ielādējas, pieteikšanās dati tiek savākti un autentifikācija pabeidzas. Tad, pirms tiek būvēts jebkurš tunelis, klients izvērtē savus sesijas un izveides iestatījumus pret vidi, kurā tas atrodas.

Tajā brīdī pierakstiet trīs lietas: precīzu ziņojumu, klienta versiju un klientā redzamo profila nosaukumu. Šie trīs pārvērš neskaidru sūdzību atbalsta pieprasījumā, ar ko kāds var kaut ko darīt. Uzņemiet dialoga ekrānuzņēmumu, jo gari ziņojumi žurnālā tiek saīsināti. Atzīmējiet arī laiku, lai administrators varētu to salīdzināt ar galveno serveri.

Iestatījums, kas patiešām izšķir

Politika Windows VPN Establishment ir attiecīgā kontrole, un tai ir divas dokumentētas vērtības: tikai vietējie lietotāji un atļaut attālos lietotājus. Otrā atļauj būvēt tuneli no Remote Desktop sesijas atbalstītā konfigurācijā. Pirmā ir noklusējuma nostāja daudzos uzņēmuma profilos.

Nejauciet to ar Windows Logon Enforcement, ko profila rokasgrāmata dokumentē kā atsevišķu politiku par pieteikšanās sesijām. Viena nosaka, kura sesija drīkst būvēt tuneli, otra nosaka vienlaicīgu vai pirms pieteikšanās uzvedību. Nepareizā maiņa nedod nekādu redzamu efektu.

Lasiet profilu, kas faktiski tiek piemērots

Pārvaldītā izvietošanā klients saņem savu profilu no galvenā servera vai pārvaldītas vietas, un diskā rediģētā kopija bieži nav spēkā esošā. Tāpēc vietēja XML izmaiņa var izskatīties pareiza un neko nemainīt.

Jautājiet administratoram, kādu profilu un kādu grupas politiku ierīce saņem, nevis kāds fails ir klēpjdatorā. Pēc versijas atjauninājuma abi bieži nesaskan. Novecojusi kopija vietējā mapē joprojām atveras redaktorā un joprojām izskatās pareiza. Tā vienkārši nav tā, ko klients piemēroja.

RDP ceļš pēc tam, kad tunelis paceļas

Attālinātas izveides atļaušana negarantē, ka jūsu Remote Desktop sesija izdzīvos. Kad tunelis maina maršrutus vai vietējos piekļuves noteikumus, sesija, kas jūs ieveida, var zaudēt ceļu, kas to uztur.

Pirms izmaiņām ieplānojiet atjaunošanas kanālu: konsoles piekļuvi, ārpusjoslas pārvaldības ceļu vai dokumentētu atkārtotas savienošanas procedūru. Tā izlemšana pēc fakta parasti nozīmē braucienu pie mašīnas.

Neizmantojiet sesiju zagšanas trikus, alternatīvus attālinātās vadības rīkus vai skriptā ierakstītu paroli, lai apietu politiku. Ja organizācija šo darbplūsmu neautorizē, pareizais solis ir administrēšanas ceļš, ko tā atbalsta.

Ko sūtīt administratoram

Dodiet viņam ziņojuma tekstu, klienta versiju, aktīvā profila nosaukumu, sesijas veidu, ar kuru savienojāties, un vai vietējās konsoles mēģinājums uzvedas citādi. Pievienojiet laika zīmogu.

Tieši pēdējais salīdzinājums ietaupa laiku, jo tas atdala atteikumu sesijas politikas dēļ no visas ierīces bojājuma.

Pārbaudiet pēc apstiprinātām izmaiņām

Kad profils ir atjaunināts, izveidojiet jaunu RDP sesiju un savienojieties vēlreiz, pēc tam apzināti izpildiet atvienošanas secību. Pārliecinieties, ka tunelis paceļas, pārvaldības ceļš izdzīvo un jūsu konts joprojām var pierakstīties darbvirsmā.

Uzņemšana VPN, sesijas izdzīvošana un Windows pieteikšanās atļauja ir trīs atsevišķas pārbaudes. Vienas izturēšana neko nepasaka par pārējām divām.