Cisco Secure Client blokerer VPN fra en RDP-session

Login lykkes, og tunnelen kommer stadig ikke op. Kombinationen forvirrer folk, fordi de læser den som et godkendelsesproblem og derefter bruger en eftermiddag på at nulstille legitimationsoplysninger, som aldrig var problemet. En Cisco Secure Client kan nægte at oprette en VPN netop fordi forsøget kom fra en Remote Desktop-session, og den beslutning træffes af politik på klientsiden.

Hvor det viser sig i forbindelsesforløbet

Gå klienten igennem fra toppen. Profilen indlæses, legitimationsoplysninger indsamles, og godkendelsen fuldføres. Derefter, før nogen tunnel bygges, vurderer klienten sine indstillinger for session og oprettelse i forhold til det miljø, den befinder sig i.

Skriv tre ting ned i det øjeblik: den præcise meddelelse, klientversionen og profilnavnet, der vises i klienten. De tre forvandler en vag klage til en supportanmodning, som nogen kan handle på. Tag et skærmbillede af dialogen, fordi lange meddelelser afkortes i loggen. Noter også tidspunktet, så administratoren kan sammenholde det med hovedenden.

Den indstilling, der faktisk afgør det

Politikken Windows VPN Establishment er den relevante kontrol og har to dokumenterede værdier: kun lokale brugere og tillad fjernbrugere. Den anden tillader at oprette en tunnel fra en Remote Desktop-session i en understøttet konfiguration. Den første er standardholdningen i mange virksomhedsprofiler.

Forveksl den ikke med profilvejledningen, som dokumenterer Windows Logon Enforcement som en separat politik om loginsessioner. Den ene styrer, hvilken session der må bygge tunnelen, den anden styrer samtidig adfærd eller adfærd før login. At ændre den forkerte giver ingen synlig effekt.

Læs den profil, der faktisk anvendes

I en administreret udrulning modtager klienten sin profil fra hovedenden eller en administreret placering, og en kopi, der er redigeret på disken, er ofte ikke den, der gælder. Derfor kan en lokal XML-ændring se korrekt ud og ikke ændre noget.

Spørg administratoren, hvilken profil og gruppepolitik enheden modtager, i stedet for hvilken fil der findes på laptop'en. De to er ofte uenige efter en versionsopgradering. En forældet kopi i den lokale mappe åbner stadig i editoren og ser stadig korrekt ud. Den er blot ikke det, klienten anvendte.

RDP-vejen efter tunnelen kommer op

Tilladelse til fjernoprettelse garanterer ikke, at din Remote Desktop-session overlever. Når tunnelen ændrer ruter eller lokale adgangsregler, kan den session, der bragte dig ind, miste den vej, der holder den oppe.

Planlæg en genopretningskanal før ændringen: konsoladgang, en out-of-band-administrationsvej eller en dokumenteret genopkoblingsprocedure. At beslutte det bagefter betyder normalt en tur til maskinen.

Brug ikke trick til at stjæle sessioner, alternative fjernstyringsværktøjer eller en adgangskode skrevet ind i et script for at omgå politikken. Hvis organisationen ikke autoriserer dette arbejdsforløb, er det korrekte skridt den administrationsvej, den understøtter.

Hvad du skal sende til administratoren

Giv dem meddelelsesteksten, klientversionen, navnet på den aktive profil, den sessionstype, du koblede til over, og om et forsøg fra den lokale konsol opfører sig anderledes. Tilføj tidsstemplet.

Netop den sidste sammenligning sparer tid, fordi den adskiller en afvisning efter sessionpolitik fra en fejl på hele enheden.

Verificer efter en godkendt ændring

Når profilen er opdateret, opret en ny RDP-session og forbind igen, og gennemfør derefter afbrydelsesforløbet med vilje. Bekræft, at tunnelen kommer op, at administrationsvejen overlever, og at din konto stadig kan logge på skrivebordet.

VPN-adgang, sessionslevetid og Windows-logonstilladelse er tre separate kontroller. At bestå én siger intet om de to andre.