Cisco Secure Client blokuje VPN z sesji RDP

Logowanie się udaje, a tunel mimo to nie wstaje. Ta kombinacja myli ludzi, bo czytają ją jako problem z uwierzytelnianiem, a potem spędzają popołudnie na resetowaniu poświadczeń, które nigdy nie były przyczyną. Cisco Secure Client może odmówić zestawienia VPN właśnie dlatego, że próba przyszła z sesji Remote Desktop, i tę decyzję podejmuje polityka po stronie klienta.

Gdzie to widać w przebiegu połączenia

Przejdź klienta od góry. Profil się ładuje, poświadczenia są zbierane, uwierzytelnianie się kończy. Potem, zanim zostanie zbudowany jakikolwiek tunel, klient ocenia ustawienia sesji i zestawiania wobec środowiska, w którym się znajduje.

Zapisz w tym momencie trzy rzeczy: dokładny komunikat, wersję klienta i nazwę profilu pokazywaną w kliencie. Te trzy zamieniają mgliste zgłoszenie w prośbę o wsparcie, z którą ktoś może coś zrobić. Zrób zrzut ekranu okna, bo długie komunikaty są ucinane w logu. Zanotuj też godzinę, aby administrator mógł ją porównać z koncentratorem.

Ustawienie, które naprawdę decyduje

Polityka Windows VPN Establishment jest właściwą kontrolą i ma dwie udokumentowane wartości: tylko użytkownicy lokalni oraz zezwalaj użytkownikom zdalnym. Druga pozwala zestawić tunel z sesji Remote Desktop w obsługiwanej konfiguracji. Pierwsza jest domyślną postawą w wielu profilach firmowych.

Nie myl jej z Windows Logon Enforcement, którą przewodnik po profilu dokumentuje jako osobną politykę dotyczącą sesji logowania. Jedna rządzi tym, która sesja może zbudować tunel, druga zachowaniem równoczesnym lub przed logowaniem. Zmiana niewłaściwej nie daje widocznego efektu.

Czytaj profil, który jest faktycznie stosowany

W zarządzanym wdrożeniu klient otrzymuje profil z koncentratora lub z zarządzanej lokalizacji, a kopia edytowana na dysku często nie jest tą obowiązującą. Dlatego lokalna zmiana XML może wyglądać poprawnie i niczego nie zmienić.

Zapytaj administratora, jaki profil i jakie zasady grupy otrzymuje urządzenie, a nie jaki plik leży na laptopie. Te dwie rzeczy często się nie zgadzają po aktualizacji wersji. Nieaktualna kopia w lokalnym folderze wciąż otwiera się w edytorze i wciąż wygląda poprawnie. Po prostu nie jest tym, co zastosował klient.

Ścieżka RDP po podniesieniu tunelu

Zezwolenie na zestawianie zdalne nie gwarantuje, że twoja sesja Remote Desktop przetrwa. Gdy tunel zmienia trasy lub lokalne reguły dostępu, sesja, która cię wprowadziła, może utracić ścieżkę, która ją utrzymuje.

Zaplanuj kanał odzyskiwania przed zmianą: dostęp do konsoli, ścieżkę zarządzania poza pasmem lub udokumentowaną procedurę ponownego połączenia. Decyzja podjęta po fakcie zwykle oznacza podróż do maszyny.

Nie używaj sztuczek z przejmowaniem sesji, alternatywnych narzędzi zdalnego sterowania ani hasła wpisanego w skrypt, aby obejść politykę. Jeśli organizacja nie autoryzuje tego przepływu pracy, właściwym krokiem jest ścieżka administracyjna, którą obsługuje.

Co wysłać administratorowi

Podaj mu treść komunikatu, wersję klienta, nazwę aktywnego profilu, typ sesji, przez którą się łączyłeś, oraz czy próba z lokalnej konsoli zachowuje się inaczej. Dodaj znacznik czasu.

Właśnie to ostatnie porównanie oszczędza czas, bo oddziela odmowę wynikającą z polityki sesji od awarii całego urządzenia.

Sprawdź po zatwierdzonej zmianie

Po zaktualizowaniu profilu zestaw nową sesję RDP i połącz się ponownie, a następnie świadomie przejdź sekwencję rozłączenia. Potwierdź, że tunel wstaje, ścieżka zarządzania przetrwa, a twoje konto nadal może zalogować się na pulpit.

Dopuszczenie do VPN, przetrwanie sesji i uprawnienie do logowania w Windows to trzy osobne kontrole. Zdanie jednej nic nie mówi o pozostałych dwóch.