En bærbar pc, en fungerende konto og et hotelnetværk giver tilsammen en loginløkke, som ingen mængde genforsøg bryder. Kontoen ligger i Protected Users, hvilket forhindrer Windows i at gemme den verifikator, der ville være nødvendig for at autentificere brugeren offline. Enhver plan af formen »log ind først, tilslut tunnelen bagefter« har den omvendte rækkefølge, og beskyttelsen gør præcis det, den lover. Det følgende forudsætter en traditionel Active Directory-konto på en understøttet Windows-vært.

Hvad beskyttelsen faktisk fjerner

Windows cacher normalt en verifikator, så en domænekonto kan logge ind, mens en domænecontroller er utilgængelig. Protected Users blokerer det for kontoen, hvilket fjerner offline domænelogin som mulighed i stedet for at gøre det upålideligt.

Det er ikke det sædvanlige problem med forældet cache, og de sædvanlige midler gælder ikke. Gentagen onlinelogin, endnu en adgangskodeændring eller en højere grænse for cachede logins genskaber ikke evnen, fordi ingen af disse handlinger skaber den verifikator, som politikken nægter at gemme. Kontoen opfører sig som designet, og designet forudsætter, at netværket er til stede, når Windows spørger. At behandle symptomet som en cachefejl er måden, hvorpå teams genopbygger en profil, der aldrig var i stykker.

Hvorfor tunnelen skal findes før skrivebordet

Enheden skal nå domæneautentificering i det øjeblik, Windows beder om det, hvilket er før nogen brugersession findes. En VPN-klient, der først starter, når skrivebordet vises, efterlader et nyt login, der venter på en vej, som aldrig kommer. Afhængigheden hører til maskinen, ikke til en bruger, der endnu ikke er logget ind.

Brug en understøttet ordning for login før login, aftalt med ejerne af endpoint og identitet. En Always On VPN-enhedstunnel autentificeret med et computercertifikat kvalificerer, når den administrerede enhed opfylder forudsætningerne for den udrulning. En leverandørs understøttede integration på loginskærmen er en anden. En almindelig brugerprofil med en automatisk udløser er ingen af delene, uanset hvor ens den ser ud i klientgrænsefladen.

Den vej har brug for navneopløsning til domænet, en tilgængelig domænecontroller og de autentificeringsprotokoller, kontoen må bruge, og ingen indikator for »forbundet« giver nogen af dem. Dens ruter og filtre skal bære identitetstjenesterne og intet andet, der ikke er nødvendigt, fordi den præfikseliste er den flade, en stjålet bærbar pc får, før nogen logger ind. Beslutninger om split tunnel, der er taget for brugertunnelen, overføres ikke til enhedstunnelen, så gennemgå de to hver for sig.

Tilgængelighed er ikke autentificeringskompatibilitet

En tunnel kan transportere pakker perfekt, mens domæneautentificering fejler, fordi den mekanisme, der forsøges, er en, kontoen ikke må bruge. I et domæne, der håndhæver gruppens begrænsninger, er NTLM utilgængelig for medlemmer, og Kerberos kræver en AES-kompatibel konto og konfiguration. En pakkevej kan ikke reparere nogen af delene. Derfor er en ren ping til en domænecontroller ikke bevis for, at login vil virke.

Der kan også være to legitimationssystemer i spil. VPN kan autentificere mod en identitetsudbyder, mens Windows separat har brug for et domænelogin, og den førstes accept siger intet om den anden. »VPN’en er forbundet« og »brugeren er logget ind« er separate observationer, og at rette den ene indebærer ikke den anden.

Læs autentificeringsbeviserne

Indsaml hændelser fra klienten og fra en domænecontroller for det samme forsøg i stedet for kun fra den ene side. Protected Users-logfilerne ligger under Applications and Services Logs\Microsoft\Windows\Authentication, og en administrator skal måske slå en log til, før den registrerer noget. Korrelér tidsstemplerne med tunnelens egen forbindelseslog, fordi en fejl i rækkefølgen ligner en legitimationsfejl fra begge sider.

Den første kommando nedenfor viser alle de autentificeringslogfiler, enheden stiller til rådighed, så du læser den, der findes, i stedet for den, et blogindlæg nævnte. Den anden læser de seneste poster, når du kender navnet. Se efter autentificeringspakken, kontoen og fejltypen, fordi en manglende netværksvej og en afvist mekanisme efterlader forskellige beviser, og kun én af dem er et VPN-problem. Hvis tunnelen kom op efter forsøget, var rækkefølgen forkert, uanset hvad posterne siger.

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

Bevis grænsen fra en kold opstart

Kør testen fra en logget-ud eller netop opstartet tilstand med en begrænset konto, og hold en godkendt gendannelsesvej åben, før du ændrer noget for privilegerede brugere. En test på et skrivebord, der allerede kører, udøver ingen del af den kodesti, der betyder noget, og det forklarer de fleste rapporter om en rettelse, der holdt til den næste genstart. Arbejd derefter gennem de fire trin i denne rækkefølge.

  1. Bekræft, at enheden kan finde en domænecontroller, før nogen logger ind, med nltest /dsgetdc:corp.example.com.
  2. Forsøg domænelogin, og spørg derefter, om der overhovedet blev hentet en billet, med klist.
  3. Læs den autentificeringslog, enheden registrerer, med de to kommandoer ovenfor, og notér pakken og fejltypen.
  4. Bekræft, at den godkendte gendannelseslegitimation stadig virker fra loginskærmen, fordi det er den eneste vej tilbage, hvis grænsetesten fejler.

At åbne en filshare med medsendte legitimationsoplysninger skaber heller ikke et offline interaktivt login, så det erstatter ikke noget trin ovenfor. Hvis organisationen virkelig har brug for login uden forbindelse, er svaret et kompatibelt konto- og endpointdesign, der er valgt bevidst. At fjerne kontoen fra gruppen eller holde et ubegrænset nødlogin på hver bærbar pc er en identitetspolitisk beslutning, som en VPN-ændring ikke kan træffe for jer.

Dokumentationen for Protected Users beskriver både verifikatorens adfærd og de domænebegrænsninger, dette design afhænger af. Planlæg gendannelsesprocessen, før nogen rejser, fordi kold-opstarts-testen er det eneste sted, den bliver udøvet.

Relaterede artikler