Cisco Secure Client blokkerer VPN frå ein RDP-økt
Klienten godtar passordet og nektar deretter å byggje tunnelen fordi økta kom over RDP. Det er profilpolicy, ikkje ein autentiseringsfeil.
Pålogginga lukkast, og tunnelen kjem likevel ikkje opp. Kombinasjonen forvirrar folk fordi han blir lesen som eit autentiseringsproblem, og deretter går ein ettermiddag med til å nullstille påloggingsinformasjon som aldri var problemet. Ein Cisco Secure Client kan nekte å etablere ein VPN nettopp fordi forsøket kom frå ei Remote Desktop-økt, og den avgjerda blir teken av policy på klientsida.
Kvar dette viser seg i tilkoplingsforløpet
Gå gjennom klienten ovanfrå. Profilen blir lasta, påloggingsinformasjon blir samla inn, og autentiseringa blir fullført. Deretter, før nokon tunnel blir bygd, vurderer klienten økt- og etableringsinnstillingane mot miljøet han er i.
Skriv ned tre ting i det augeblikket: den nøyaktige meldinga, klientversjonen og profilnamnet som blir vist i klienten. Desse tre gjer ei vag klage om til ein støtteførespurnad nokon kan handle på. Ta skjermbilde av dialogen, fordi lange meldingar blir korta ned i loggen. Noter også tidspunktet, slik at administratoren kan samanhalde det med hovudenden.
Innstillinga som faktisk avgjer
Policyen Windows VPN Establishment er den relevante kontrollen, og han har to dokumenterte verdiar: berre lokale brukarar, og tillat eksterne brukarar. Den andre tillèt å etablere ein tunnel frå ei Remote Desktop-økt i ein støtta konfigurasjon. Den første er standardhaldninga i mange bedriftsprofilar.
Ikkje forveksle han med Windows Logon Enforcement, som profilrettleiinga dokumenterer som ein eigen policy om påloggingsøkter. Den eine styrer kva økt som kan byggje tunnelen, den andre styrer samtidig åtferd eller åtferd før pålogging. Å endre den gale gir ingen synleg effekt.
Les profilen som faktisk blir brukt
I ein administrert utrulling får klienten profilen sin frå hovudenden eller ein administrert stad, og ein kopi som er redigert på disken er ofte ikkje den som gjeld. Difor kan ei lokal XML-endring sjå riktig ut og ikkje endre noko.
Spør administratoren kva profil og kva gruppepolicy eininga får, i staden for kva fil som ligg på laptoppen. Dei to er ofte usamde etter ein versjonsoppgradering. Ein utdatert kopi i den lokale mappa opnar framleis i editoren og ser framleis riktig ut. Han er berre ikkje det klienten brukte.
RDP-vegen etter at tunnelen kjem opp
Å tillate ekstern etablering garanterer ikkje at Remote Desktop-økta di overlever. Når tunnelen endrar ruter eller lokale tilgangsreglar, kan økta som førte deg inn miste vegen som held henne oppe.
Planlegg ein attopprettingskanal før endringa: konsolltilgang, ein out-of-band-administrasjonsveg eller ein dokumentert gjenoppkoplingsprosedyre. Å avgjere dette i etterkant tyder vanlegvis ein tur til maskina.
Ikkje bruk triks for å stele økter, alternative fjernstyringsverktøy eller eit passord skrive inn i eit skript for å omgå policyen. Viss organisasjonen ikkje autoriserer denne arbeidsflyten, er det rette trekket administrasjonsvegen han støttar.
Kva du bør sende administratoren
Gi dei meldingsteksten, klientversjonen, namnet på den aktive profilen, økttypen du kopla til over, og om eit forsøk frå den lokale konsollen oppfører seg annleis. Legg til tidsstempelet.
Nettopp den siste samanlikninga sparer tid, fordi ho skil ei avvising etter øktpolicy frå ein feil på heile eininga.
Stadfest etter ei godkjend endring
Når profilen er oppdatert, etabler ei ny RDP-økt og kople til igjen, og gjennomfør deretter fråkoplingsekvensen med vilje. Stadfest at tunnelen kjem opp, at administrasjonsvegen overlever, og at kontoen din framleis kan logge på skrivebordet.
VPN-tilgang, levetida til økta og Windows-påloggingstillating er tre separate kontrollar. Å klare éin seier ingenting om dei to andre.