Hvorfor en Protected Users-bærbar PC trenger VPN før pålogging

En bærbar PC, en fungerende konto og et hotellnettverk gir til sammen en påloggingsløkke som ingen mengde nye forsøk bryter. Kontoen ligger i Protected Users, noe som hindrer Windows i å lagre verifisereren den ville trengt for å autentisere brukeren frakoblet. Enhver plan av formen «logg på først, koble til tunnelen etterpå» har omvendt rekkefølge, og beskyttelsen gjør nøyaktig det den lover. Det følgende forutsetter en tradisjonell Active Directory-konto på en støttet Windows-vert.

Hva beskyttelsen faktisk fjerner

Windows cacher vanligvis en verifiserer slik at en domenekonto kan logge på mens en domenekontroller er utilgjengelig. Protected Users blokkerer dette for kontoen, noe som fjerner frakoblet domenepålogging som mulighet i stedet for å gjøre den upålitelig.

Dette er ikke det vanlige problemet med en utdatert cache, og de vanlige midlene gjelder ikke. Gjentatt pålogging på nett, nok et passordbytte eller økt grense for cachede pålogginger gjenoppretter ikke evnen, fordi ingen av disse handlingene lager verifisereren som policyen nekter å lagre. Kontoen oppfører seg som designet, og designet forutsetter at nettverket er til stede når Windows spør. Å behandle symptomet som en cachefeil er måten team ender med å bygge opp igjen en profil som aldri var ødelagt.

Hvorfor tunnelen må finnes før skrivebordet

Enheten må nå domenautentisering i det øyeblikket Windows ber om det, og det er før noen brukerøkt eksisterer. En VPN-klient som først starter etter at skrivebordet vises, lar en ny pålogging vente på en vei som aldri kommer. Avhengigheten hører til maskinen, ikke til en bruker som ennå ikke har logget på.

Bruk en støttet ordning for pålogging på forhånd, avtalt med eierne av endepunkter og identitet. En Always On VPN-enhetstunnel autentisert med et datamaskinsertifikat kvalifiserer når den administrerte enheten oppfyller forutsetningene for den utrullingen. En leverandørs støttede integrasjon på påloggingsskjermen er et annet alternativ. En vanlig brukerprofil med en automatisk utløser er ingen av delene, uansett hvor likt det ser ut i klientgrensesnittet.

Den veien trenger navneoppslag for domenet, en tilgjengelig domenekontroller og de autentiseringsprotokollene kontoen kan bruke, og ingen indikator for «tilkoblet» gir noe av dette. Rutene og filtrene bør bære identitetstjenestene og ingenting annet som ikke er nødvendig, fordi den prefikslisten er flaten en stjålet bærbar PC får før noen logger på. Beslutninger om splittet tunnel tatt for brukertunnelen gjelder ikke for enhetstunnelen, så gjennomgå de to hver for seg.

Tilgjengelighet er ikke autentiseringskompatibilitet

En tunnel kan frakte pakker perfekt mens domenautentisering mislykkes, fordi mekanismen som forsøkes er en kontoen ikke kan bruke. I et domene som håndhever gruppens begrensninger, er NTLM utilgjengelig for medlemmer, og Kerberos krever en AES-kompatibel konto og konfigurasjon. En pakkevei kan ikke reparere noen av dem. Derfor er en ren ping til en domenekontroller ikke bevis for at påloggingen vil virke.

Det kan også være to legitimasjonssystemer i spill. VPN kan autentisere mot en identitetsleverandør mens Windows separat trenger en domenepålogging, og den førstes aksept sier ingenting om den andre. «VPN-en er tilkoblet» og «brukeren er logget på» er separate observasjoner, og å rette den ene innebærer ikke den andre.

Les autentiseringsbevisene

Samle hendelser fra klienten og fra en domenekontroller for det samme forsøket, ikke bare fra én side. Protected Users-loggene ligger under Applications and Services Logs\Microsoft\Windows\Authentication, og en administrator må kanskje slå på en logg før den registrerer noe. Korrelér tidsstemplene med tunnelens egen tilkoblingslogg, fordi en rekkefølgefeil ser ut som en legitimasjonsfeil fra begge sider.

Den første kommandoen nedenfor lister alle autentiseringslogger enheten eksponerer, slik at du leser den som finnes i stedet for den et blogginnlegg navnga. Den andre leser nylige oppføringer når du kjenner navnet. Se etter autentiseringspakken, kontoen og feilbetingelsen, fordi en manglende nettverksvei og en avvist mekanisme etterlater forskjellige bevis, og bare én av dem er et VPN-problem. Hvis tunnelen kom opp etter forsøket, var rekkefølgen feil uansett hva disse oppføringene sier.

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

Bevis grensen fra en kaldstart

Kjør testen fra en utlogget eller nettopp startet tilstand med en begrenset konto, og hold en godkjent gjenopprettingsvei åpen før du endrer noe for privilegerte brukere. En test på et skrivebord som allerede kjører, utøver ingen del av kodeveien som betyr noe, og det forklarer de fleste rapportene om en rettelse som holdt til neste omstart. Arbeid deg deretter gjennom de fire trinnene i denne rekkefølgen.

1. Bekreft at enheten kan finne en domenekontroller før noen logger på, med nltest /dsgetdc:corp.example.com.
2. Forsøk domenepåloggingen, og spør deretter om det ble hentet en billett i det hele tatt, med klist.
3. Les autentiseringsloggen enheten registrerer, med de to kommandoene ovenfor, og noter pakken og feilbetingelsen.
4. Bekreft at den godkjente gjenopprettingslegitimasjonen fortsatt virker fra påloggingsskjermen, fordi det er den eneste veien tilbake hvis grensetesten mislykkes.

Å åpne en filutveksling med medsendte legitimasjoner lager heller ikke en frakoblet interaktiv pålogging, så det erstatter ikke noe trinn ovenfor. Hvis organisasjonen virkelig trenger pålogging uten forbindelse, er svaret et kompatibelt design for konto og endepunkt som er valgt bevisst. Å ta kontoen ut av gruppen, eller å beholde én ubegrenset nødinnlogging på hver bærbar PC, er en identitetspolitisk beslutning som en VPN-endring ikke kan ta for dere.

Dokumentasjonen for Protected Users beskriver både verifisererens oppførsel og domenebegrensningene dette designet avhenger av. Planlegg gjenopprettingsprosessen før noen reiser, fordi kaldstartstesten er det eneste stedet den blir utøvd.