A Cisco Secure Client blokkolja a VPN-t egy RDP-munkamenetből

A bejelentkezés sikerül, az alagút mégsem jön létre. Ez a kombináció összezavarja az embereket, mert hitelesítési problémaként olvassák, majd egy délutánt töltenek olyan hitelesítő adatok visszaállításával, amelyek soha nem voltak a hiba oka. A Cisco Secure Client éppen azért tagadhatja meg a VPN létrehozását, mert a kísérlet egy Remote Desktop-munkamenetből érkezett, és ezt a döntést az ügyféloldali szabályzat hozza.

Hol jelenik ez meg a kapcsolódási folyamatban

Járja végig az ügyfelet felülről. A profil betöltődik, a hitelesítő adatok összegyűlnek, a hitelesítés befejeződik. Ezután, mielőtt bármilyen alagút felépülne, az ügyfél kiértékeli a munkamenet- és létrehozási beállításait a környezethez képest, amelyben találja magát.

Abban a pillanatban írjon fel három dolgot: a pontos üzenetet, az ügyfél verzióját és az ügyfélben látható profilnevet. Ez a három a homályos panaszt olyan támogatási kéréssé alakítja, amelyre valaki tud cselekedni. Készítsen képernyőképet a párbeszédablakról, mert a hosszú üzenetek csonkolódnak a naplóban. Jegyezze fel az időpontot is, hogy az adminisztrátor össze tudja vetni a központi kiszolgálóval.

A beállítás, amely valójában eldönti

A Windows VPN Establishment szabályzat a releváns vezérlő, és két dokumentált értéke van: csak helyi felhasználók, és távoli felhasználók engedélyezése. A második engedélyezi az alagút felépítését Remote Desktop-munkamenetből támogatott konfigurációban. Az első az alapértelmezett álláspont sok vállalati profilban.

Ne keverje össze a Windows Logon Enforcementtel, amelyet a profil útmutató külön szabályzatként dokumentál a bejelentkezési munkamenetekről. Az egyik azt szabályozza, melyik munkamenet építheti fel az alagutat, a másik az egyidejű vagy bejelentkezés előtti viselkedést. A rossz módosítása semmilyen látható hatást nem ad.

Olvassa el a ténylegesen alkalmazott profilt

Felügyelt telepítésben az ügyfél a profilját a központi kiszolgálótól vagy felügyelt helyről kapja, és a lemezen szerkesztett példány gyakran nem az, amely érvényben van. Ezért tűnhet egy helyi XML-módosítás helyesnek, és nem változtat semmit.

Kérdezze meg az adminisztrátortól, milyen profilt és csoportházirendet kap az eszköz, ne azt, milyen fájl van a laptopon. A kettő verziófrissítés után gyakran eltér. A helyi mappában lévő elavult példány még mindig megnyílik a szerkesztőben, és még mindig helyesnek tűnik. Egyszerűen nem az, amit az ügyfél alkalmazott.

Az RDP-útvonal az alagút létrejötte után

A távoli létrehozás engedélyezése nem garantálja, hogy a Remote Desktop-munkamenete túlél. Amikor az alagút útvonalakat vagy helyi hozzáférési szabályokat változtat, a munkamenet, amely behozta Önt, elveszítheti a fenntartó útvonalat.

Tervezzen helyreállítási csatornát a változás előtt: konzolhozzáférést, sávon kívüli felügyeleti útvonalat vagy dokumentált újracsatlakozási eljárást. Ezt utólag eldönteni általában a géphez vezető utat jelenti.

Ne használjon munkamenet-lopási trükköket, alternatív távvezérlő eszközöket vagy szkriptbe írt jelszót a szabályzat megkerülésére. Ha a szervezet nem engedélyezi ezt a munkafolyamatot, a helyes lépés az általa támogatott felügyeleti útvonal.

Mit küldjön az adminisztrátornak

Adja meg neki az üzenet szövegét, az ügyfél verzióját, az aktív profil nevét, a munkamenet típusát, amelyen keresztül csatlakozott, és hogy a helyi konzolról tett kísérlet másképp viselkedik-e. Adja hozzá az időbélyeget.

Éppen az utolsó összehasonlítás takarít meg időt, mert elválasztja a munkamenet-szabályzat szerinti elutasítást az eszköz szintű hibától.

Ellenőrizze jóváhagyott változtatás után

Miután a profil frissült, hozzon létre új RDP-munkamenetet, és csatlakozzon újra, majd szándékosan hajtsa végre a leválasztási sorozatot. Erősítse meg, hogy az alagút létrejön, a felügyeleti útvonal túlél, és fiókja továbbra is be tud jelentkezni az asztalra.

A VPN-be való belépés, a munkamenet túlélése és a Windows bejelentkezési engedély három külön ellenőrzés. Az egyik teljesítése semmit sem mond a másik kettőről.