Cisco Secure Client blochează VPN-ul dintr-o sesiune RDP

Autentificarea reușește și tunelul tot nu apare. Combinația îi încurcă pe oameni pentru că o citesc ca pe o problemă de autentificare, apoi petrec o după-amiază resetând acreditări care nu au fost niciodată cauza. Un Cisco Secure Client poate refuza să stabilească un VPN exact pentru că încercarea a venit dintr-o sesiune Remote Desktop, iar decizia este luată de politică pe partea clientului.

Unde apare acest lucru în fluxul conexiunii

Parcurgeți clientul de sus în jos. Profilul se încarcă, acreditările sunt colectate și autentificarea se încheie. Apoi, înainte de a fi construit orice tunel, clientul își evaluează setările de sesiune și de stabilire față de mediul în care se află.

Notați trei lucruri în acel moment: mesajul exact, versiunea clientului și numele profilului afișat în client. Acestea trei transformă o reclamație vagă într-o cerere de suport pe care cineva poate acționa. Faceți o captură de ecran a dialogului, pentru că mesajele lungi sunt trunchiate în jurnal. Notați și ora, ca administratorul să o poată compara cu capul de rețea.

Setarea care decide de fapt

Politica Windows VPN Establishment este controlul relevant și are două valori documentate: doar utilizatori locali și permite utilizatori la distanță. A doua permite stabilirea unui tunel dintr-o sesiune Remote Desktop într-o configurație acceptată. Prima este poziția implicită în multe profiluri de întreprindere.

Nu o confundați cu Windows Logon Enforcement, pe care ghidul profilului o documentează ca politică separată despre sesiunile de autentificare. Una reglementează ce sesiune poate construi tunelul, cealaltă reglementează comportamentul simultan sau anterior autentificării. Modificarea celei greșite nu produce niciun efect vizibil.

Citiți profilul care este aplicat efectiv

Într-o implementare administrată clientul primește profilul de la capul de rețea sau dintr-o locație administrată, iar o copie editată pe disc nu este adesea cea în vigoare. De aceea o modificare locală XML poate părea corectă și nu schimbă nimic.

Întrebați administratorul ce profil și ce politică de grup primește dispozitivul, nu ce fișier există pe laptop. Cele două nu sunt adesea de acord după o actualizare de versiune. O copie veche din folderul local încă se deschide în editor și încă pare corectă. Pur și simplu nu este ceea ce a aplicat clientul.

Calea RDP după ce tunelul apare

Permiterea stabilirii de la distanță nu garantează că sesiunea Remote Desktop supraviețuiește. Când tunelul schimbă rute sau reguli de acces locale, sesiunea care v-a adus înăuntru poate pierde calea care o susține.

Planificați un canal de recuperare înainte de schimbare: acces la consolă, o cale de administrare în afara benzii sau o procedură documentată de reconectare. A decide acest lucru după fapt înseamnă de obicei o deplasare la mașină.

Nu folosiți trucuri de furt de sesiune, instrumente alternative de control de la distanță sau o parolă scrisă într-un script pentru a ocoli politica. Dacă organizația nu autorizează acest flux de lucru, pasul corect este calea de administrare pe care o susține.

Ce să trimiteți administratorului

Dați-i textul mesajului, versiunea clientului, numele profilului activ, tipul sesiunii prin care v-ați conectat și dacă o încercare de la consola locală se comportă diferit. Adăugați marca de timp.

Exact ultima comparație economisește timp, pentru că separă un refuz din politică de sesiune de o defecțiune a întregului dispozitiv.

Verificați după o modificare aprobată

După ce profilul este actualizat, stabiliți o sesiune RDP nouă și reconectați-vă, apoi parcurgeți deliberat secvența de deconectare. Confirmați că tunelul apare, că calea de administrare supraviețuiește și că contul dumneavoastră se poate încă autentifica pe desktop.

Admiterea în VPN, supraviețuirea sesiunii și permisiunea de autentificare Windows sunt trei verificări separate. Trecerea uneia nu spune nimic despre celelalte două.