Cisco Secure Client blokuje VPN z relace RDP

Přihlášení uspěje a tunel přesto nevznikne. Tahle kombinace mate lidi, protože ji čtou jako problém s ověřováním, a pak stráví odpoledne resetováním přihlašovacích údajů, které nikdy nebyly příčinou. Cisco Secure Client může odmítnout navázat VPN právě proto, že pokus přišel z relace Remote Desktop, a toto rozhodnutí dělá politika na straně klienta.

Kde se to objevuje v toku připojení

Projděte klienta od začátku. Profil se načte, údaje se shromáždí a ověření se dokončí. Poté, než se vytvoří jakýkoli tunel, klient vyhodnotí nastavení relace a navázání vůči prostředí, ve kterém se nachází.

V tu chvíli si zapište tři věci: přesný text zprávy, verzi klienta a název profilu zobrazený v klientovi. Ty tři promění neurčitou stížnost v požadavek na podporu, se kterým lze něco dělat. Pořiďte snímek obrazovky dialogu, protože dlouhé zprávy se v logu zkracují. Poznamenejte i čas, aby jej správce mohl porovnat s centrálou.

Nastavení, které o tom skutečně rozhoduje

Politika Windows VPN Establishment je příslušný prvek a má dvě dokumentované hodnoty: pouze místní uživatelé a povolit vzdálené uživatele. Druhá umožňuje navázat tunel z relace Remote Desktop v podporované konfiguraci. První je výchozí postoj v mnoha podnikových profilech.

Nezaměňujte ji s průvodcem profilem, který dokumentuje Windows Logon Enforcement jako samostatnou politiku o přihlašovacích relacích. Jedna určuje, která relace smí tunel vytvořit, druhá určuje chování při souběžném přihlášení nebo před přihlášením. Změna té nesprávné nemá viditelný účinek.

Čtěte profil, který je skutečně použit

Ve spravovaném nasazení dostává klient profil z centrály nebo ze spravovaného místa a kopie upravená na disku často není ta platná. Proto může místní změna XML vypadat správně a nic nezměnit.

Ptejte se správce, který profil a které zásady skupiny zařízení dostává, ne který soubor na notebooku existuje. Ty dvě se po upgradu verze často rozcházejí. Zastaralá kopie v místní složce se stále otevírá v editoru a stále vypadá správně. Prostě to není to, co klient použil.

Cesta RDP po navázání tunelu

Povolení vzdáleného navázání nezaručuje, že vaše relace Remote Desktop přežije. Když tunel změní trasy nebo místní pravidla přístupu, relace, která vás přivedla dovnitř, může ztratit cestu, která ji udržuje.

Naplánujte obnovovací kanál před změnou: přístup ke konzoli, mimopásmovou cestu správy nebo zdokumentovaný postup opětovného připojení. Rozhodovat o tom dodatečně obvykle znamená cestu ke stroji.

Nepoužívejte triky s krádeží relací, alternativní nástroje vzdálené správy ani heslo zapsané ve skriptu, abyste politiku obešli. Pokud organizace tento postup nepovoluje, správným krokem je administrativní cesta, kterou podporuje.

Co poslat správci

Dejte mu text zprávy, verzi klienta, název aktivního profilu, typ relace, přes kterou jste se připojovali, a zda se pokus z místní konzole chová jinak. Přidejte časové razítko.

Právě to poslední srovnání šetří čas, protože odděluje odmítnutí politikou relace od závady celého zařízení.

Ověřte po schválené změně

Po aktualizaci profilu naváže novou relaci RDP a připojte se znovu, poté záměrně projděte sekvenci odpojení. Ověřte, že tunel vznikne, že cesta správy přežije a že se váš účet stále může přihlásit k ploše.

Povolení VPN, přežití relace a oprávnění k přihlášení do Windows jsou tři samostatné kontroly. Projít jednou neříká nic o zbývajících dvou.