Cisco Secure Client blokkerer VPN fra en RDP-økt

Påloggingen lykkes, og tunnelen kommer likevel ikke opp. Kombinasjonen forvirrer folk fordi den leses som et autentiseringsproblem, og deretter går en ettermiddag med til å nullstille påloggingsinformasjon som aldri var problemet. En Cisco Secure Client kan nekte å etablere en VPN nettopp fordi forsøket kom fra en Remote Desktop-økt, og den beslutningen tas av policy på klientsiden.

Hvor dette vises i tilkoblingsforløpet

Gå gjennom klienten ovenfra. Profilen lastes, påloggingsinformasjon samles inn, og autentiseringen fullføres. Deretter, før noen tunnel bygges, vurderer klienten økt- og etableringsinnstillingene mot miljøet den befinner seg i.

Skriv ned tre ting i det øyeblikket: den nøyaktige meldingen, klientversjonen og profilnavnet som vises i klienten. Disse tre gjør en vag klage om til en supportforespørsel noen kan handle på. Ta skjermbilde av dialogen, fordi lange meldinger avkortes i loggen. Noter også tidspunktet, slik at administratoren kan sammenholde det med hovedenden.

Innstillingen som faktisk avgjør

Policyen Windows VPN Establishment er den relevante kontrollen, og den har to dokumenterte verdier: bare lokale brukere, og tillat eksterne brukere. Den andre tillater å etablere en tunnel fra en Remote Desktop-økt i en støttet konfigurasjon. Den første er standardholdningen i mange bedriftsprofiler.

Ikke forveksle den med Windows Logon Enforcement, som profilveiledningen dokumenterer som en egen policy om påloggingsøkter. Den ene styrer hvilken økt som kan bygge tunnelen, den andre styrer samtidig atferd eller atferd før pålogging. Å endre den gale gir ingen synlig effekt.

Les profilen som faktisk brukes

I en administrert utrulling mottar klienten profilen sin fra hovedenden eller et administrert sted, og en kopi som er redigert på disken er ofte ikke den som gjelder. Derfor kan en lokal XML-endring se riktig ut og ikke endre noe.

Spør administratoren hvilken profil og gruppepolicy enheten mottar, i stedet for hvilken fil som ligger på laptopen. De to er ofte uenige etter en versjonsoppgradering. En utdatert kopi i den lokale mappen åpnes fortsatt i editoren og ser fortsatt riktig ut. Den er bare ikke det klienten brukte.

RDP-veien etter at tunnelen kommer opp

Å tillate ekstern etablering garanterer ikke at Remote Desktop-økten din overlever. Når tunnelen endrer ruter eller lokale tilgangsregler, kan økten som brakte deg inn miste veien som holder den oppe.

Planlegg en gjenopprettingskanal før endringen: konsolltilgang, en out-of-band-administrasjonsvei eller en dokumentert gjentilkoblingsprosedyre. Å bestemme dette i etterkant betyr vanligvis en tur til maskinen.

Ikke bruk triks for å stjele økter, alternative fjernstyringsverktøy eller et passord skrevet inn i et skript for å omgå policyen. Hvis organisasjonen ikke autoriserer denne arbeidsflyten, er det riktige trekket administrasjonsveien den støtter.

Hva du bør sende administratoren

Gi dem meldingsteksten, klientversjonen, navnet på den aktive profilen, økttypen du koblet til over, og om et forsøk fra den lokale konsollen oppfører seg annerledes. Legg til tidsstempelet.

Nettopp den siste sammenligningen sparer tid, fordi den skiller en avvisning etter øktpolicy fra en feil på hele enheten.

Verifiser etter en godkjent endring

Når profilen er oppdatert, etabler en ny RDP-økt og koble til igjen, og gjennomfør deretter frakoblingssekvensen med vilje. Bekreft at tunnelen kommer opp, at administrasjonsveien overlever, og at kontoen din fortsatt kan logge på skrivebordet.

VPN-adgang, øktens levetid og Windows-påloggingstillatelse er tre separate kontroller. Å bestå én sier ingenting om de to andre.