Hvorfor en domenemaskin godtar det gamle passordet frakoblet

En passordendring lander overalt samtidig, bortsett fra på den ene bærbare maskinen som har vært frakoblet i en uke. Webmail tar imot det nye passordet, en stasjonær maskin på kontoret tar imot det, og den eksterne maskinen logger fortsatt på med det gamle når VPN-en er nede. Dette er ikke et andre passord og ikke en synkroniseringsfeil i katalogen. Det er den bufrede påloggingsverifisereren som gjør det den er laget for, og løsningen er en sekvens, ikke en tilbakestilling.

Maskinen sjekker en bufret verifiserer

Domenetilknyttet Windows holder en lokal verifiserer for nylige vellykkede interaktive pålogginger, slik at maskinen kan starte når ingen domenekontroller svarer. Den verifisereren er utledet fra passordet slik det var ved den påloggingen. Endres passordet andre steder, oppdateres katalogen, men ikke kopien på en maskin som ikke har snakket med den siden.

Så det gamle passordet kan fortsatt åpne den lokale økten selv om det er ugyldig for enhver ny domeneautentisering. Det er to forskjellige observasjoner, og å blande dem fører til gjentatte tilbakestillinger.

Bekreft hvilken legitimasjon som faktisk er i spill før du endrer noe annet. En Windows Hello-PIN, en pålogging med Entra ID og et tradisjonelt domenepassord er separate mekanismer, og PIN-en er spesielt ikke domenepassordet selv når den låser opp samme skrivebord.

Nettverksautentisering er ikke interaktiv pålogging

Å åpne en filressurs med det nye passordet beviser at nettverksveien virker. Det oppdaterer ikke hurtigbufferen for interaktiv pålogging, fordi Windows behandler nettverks- og interaktiv autentisering som separate operasjoner med separat tilstand.

Verifisereren oppdateres bare når en interaktiv pålogging faktisk kontakter en domenekontroller; en tilkoblet stasjon eller en Outlook-forespørsel gjør det ikke.

Den forskjellen forklarer den vanlige rapporten: brukeren kan lese e-post og åpne intranettet, men låseskjermen vil fortsatt ha det gamle passordet. Den forklarer også hvorfor en VPN som startes etter pålogging ikke kan hjelpe den første påloggingen, siden tunnelen kommer etter at beslutningen allerede er tatt lokalt.

Få én nettpålogging på riktig tidspunkt

Hurtigbufferen oppdateres når brukeren logger på interaktivt mens domenet er tilgjengelig. For en ekstern maskin betyr det at tunnelen må finnes før legitimasjonen vurderes, ikke etter at skrivebordet vises.

Sjekk om utrullingen støtter tilkobling før pålogging eller en enhetstunnel. De er laget for nettopp dette tidspunktet, og en brukertunnel er ikke en erstatning:

nltest /dsgetdc:corp.example
klist

Hvis endepunktet ikke har en vei før pålogging, bruk den støttede gjenopprettingsprosessen organisasjonen dokumenterer. Noen miljøer bruker en sekvens med koble til, låse og låse opp med tunnelen holdt åpen på låseskjermen; andre sender enheten til et administrert gjenopprettingstrinn. Følg den som passer klienten, og bekreft før du regner med den at tunnelen overlever låseskjermen.

Beskytt veien tilbake

Før du logger av en ekstern maskin, må du bestemme hvordan neste pålogging skal nå domenet. En brukertunnel som faller med økten kan fjerne den eneste veien du regnet med, og da kommer verken det gamle eller det nye passordet deg forbi låseskjermen. Hold en lokal administratorkonto eller en out-of-band-konsoll som reserve. Skriv ned gjenopprettingstrinnet der brukeren kan nå det uten å logge på.

For support, samle fire fakta: hvor passordet ble endret, hvilken legitimasjon som fortsatt virker frakoblet, om en domenekontroller er tilgjengelig gjennom tunnelen, og hvilken påloggingsmetode maskinen bruker.

Disse fire skiller en utdatert verifiserer fra en kontolås eller en avvist VPN-pålogging, som ser like ut i en sak og har ulike løsninger. En låst konto vil avvise det nye passordet også på nettet, så test det før du klandrer hurtigbufferen.

Lukk sirkelen med én nettpålogging

Målet er én støttet interaktiv pålogging mens domenet er tilgjengelig, etterfulgt av en kjent frakoblet tilstand. Den ene hendelsen oppdaterer verifisereren og avslutter syklusen med å endre passordet på hver enhet.

Kontroller tilstanden etterpå med antallet bufrede pålogginger og et oppslag mot domenekontrolleren:

reg query "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" /v CachedLogonsCount
nltest /sc_verify:corp.example

Er tallet null, er bufret pålogging deaktivert av policy, og frakoblet oppførsel endres ikke uansett hvor mange ganger passordet tilbakestilles. Det er en policybeslutning som må tas opp med eieren, ikke en omvei som brukes lokalt.