Cisco Secure Client blockerar VPN från en RDP-session

Inloggningen lyckas och tunneln kommer ändå inte upp. Kombinationen förvirrar eftersom den läses som ett autentiseringsproblem, och sedan går en eftermiddag åt till att återställa inloggningsuppgifter som aldrig var problemet. En Cisco Secure Client kan vägra att upprätta en VPN just för att försöket kom från en Remote Desktop-session, och det beslutet fattas av policy på klientsidan.

Var detta dyker upp i anslutningsflödet

Gå igenom klienten uppifrån. Profilen laddas, inloggningsuppgifter samlas in och autentiseringen slutförs. Sedan, innan någon tunnel byggs, utvärderar klienten sina session- och upprättandeinställningar mot den miljö den befinner sig i.

Skriv ned tre saker i det ögonblicket: det exakta meddelandet, klientversionen och profilnamnet som visas i klienten. De tre förvandlar ett vagt klagomål till en supportbegäran som någon kan agera på. Ta en skärmbild av dialogrutan, eftersom långa meddelanden trunkeras i loggen. Notera också tiden, så att administratören kan jämföra den med headenden.

Inställningen som faktiskt avgör

Policyn Windows VPN Establishment är den relevanta kontrollen och har två dokumenterade värden: endast lokala användare och tillåt fjärranvändare. Den andra tillåter att en tunnel upprättas från en Remote Desktop-session i en konfiguration som stöds. Den första är standardhållningen i många företagsprofiler.

Blanda inte ihop den med Windows Logon Enforcement, som profilguiden dokumenterar som en separat policy om inloggningssessioner. Den ena styr vilken session som får bygga tunneln, den andra styr samtidigt beteende eller beteende före inloggning. Att ändra den felaktiga ger ingen synlig effekt.

Läs den profil som faktiskt tillämpas

I en hanterad distribution får klienten sin profil från headenden eller en hanterad plats, och en kopia som redigerats på disken är ofta inte den som gäller. Därför kan en lokal XML-ändring se korrekt ut och inte ändra något.

Fråga administratören vilken profil och vilken grupprincip enheten tar emot, i stället för vilken fil som finns på laptopen. De två stämmer ofta inte överens efter en versionsuppgradering. En föråldrad kopia i den lokala mappen öppnas fortfarande i redigeraren och ser fortfarande korrekt ut. Den är bara inte det klienten använde.

RDP-vägen efter att tunneln kommit upp

Att tillåta fjärrupprättande garanterar inte att din Remote Desktop-session överlever. När tunneln ändrar rutter eller lokala åtkomstregler kan sessionen som tog in dig förlora den väg som håller den vid liv.

Planera en återställningskanal före ändringen: konsolåtkomst, en out-of-band-hanteringsväg eller en dokumenterad återanslutningsprocedur. Att besluta det i efterhand innebär oftast en resa till maskinen.

Använd inte trick för att stjäla sessioner, alternativa fjärrstyrningsverktyg eller ett lösenord skrivet i ett skript för att kringgå policyn. Om organisationen inte auktoriserar detta arbetsflöde är rätt steg den administrationsväg den stöder.

Vad du ska skicka till administratören

Ge dem meddelandetexten, klientversionen, namnet på den aktiva profilen, sessionstypen du anslöt över och om ett försök från den lokala konsolen beter sig annorlunda. Lägg till tidsstämpeln.

Just den sista jämförelsen sparar tid, eftersom den skiljer en avvisning enligt sessionspolicy från ett fel på hela enheten.

Verifiera efter en godkänd ändring

När profilen har uppdaterats, upprätta en ny RDP-session och anslut igen, och gå sedan medvetet igenom frånkopplingssekvensen. Bekräfta att tunneln kommer upp, att hanteringsvägen överlever och att ditt konto fortfarande kan logga in på skrivbordet.

VPN-inträde, sessionens livslängd och Windows-inloggningsbehörighet är tre separata kontroller. Att klara en säger inget om de andra två.