Kvifor ei domenemaskin godtek det gamle passordet fråkopla

Ei passordendring landar overalt samstundes, bortsett frå den eine berbare maskina som har vore fråkopla i ei veke. Webmail tek imot det nye passordet, ein stasjonær maskin på kontoret tek imot det, og den eksterne maskina loggar framleis på med det gamle når VPN-en er nede. Dette er ikkje eit andre passord og ikkje ein synkroniseringsfeil i katalogen. Det er den bufra påloggingsverifiseraren som gjer det han er laga for, og løysinga er ein sekvens, ikkje ein tilbakestilling.

Maskina sjekkar ein bufra verifiserar

Domenetilknytt Windows held ein lokal verifiserar for nylege vellukka interaktive påloggingar, slik at maskina kan starte når ingen domenekontrollar svarar. Den verifiseraren er utleidd frå passordet slik det var ved den pålogginga. Vert passordet endra andre stader, vert katalogen oppdatert, men ikkje kopien på ei maskin som ikkje har snakka med han sidan.

Så det gamle passordet kan framleis opne den lokale økta sjølv om det er ugyldig for kvar ny domeneautentisering. Det er to ulike observasjonar, og å blande dei fører til gjentekne tilbakestillingar.

Stadfest kva legitimasjon som faktisk er i spel før du endrar noko anna. Ein Windows Hello-PIN, ei pålogging med Entra ID og eit tradisjonelt domenepassord er separate mekanismar, og PIN-en er særleg ikkje domenepassordet sjølv når han låser opp same skrivebordet.

Nettverksautentisering er ikkje interaktiv pålogging

Å opne ein filressurs med det nye passordet beviser at nettverksvegen verkar. Det oppdaterer ikkje hurtigbufferen for interaktiv pålogging, fordi Windows handsamar nettverks- og interaktiv autentisering som separate operasjonar med separat tilstand.

Verifiseraren vert oppdatert berre når ei interaktiv pålogging faktisk kontaktar ein domenekontrollar; ein tilkopla stasjon eller ei Outlook-førespurnad gjer det ikkje.

Den skilnaden forklarar den vanlege rapporten: brukaren kan lese e-post og opne intranettet, men låseskjermen vil framleis ha det gamle passordet. Han forklarar òg kvifor ein VPN som startar etter pålogging ikkje kan hjelpe den første pålogginga, sidan tunnelen kjem etter at avgjerda alt er teken lokalt.

Få éi nettpålogging på rett tidspunkt

Hurtigbufferen vert oppdatert når brukaren loggar på interaktivt medan domenet er tilgjengeleg. For ei ekstern maskin tyder det at tunnelen må finnast før legitimasjonen vert vurdert, ikkje etter at skrivebordet kjem fram.

Sjekk om utrullinga støttar tilkopling før pålogging eller ein einingstunnel. Dei er laga for nettopp dette tidspunktet, og ein brukartunnel er ikkje ei erstatning:

nltest /dsgetdc:corp.example
klist

Har endepunktet ingen veg før pålogging, bruk den støtta gjenopprettingsprosessen organisasjonen dokumenterer. Nokre miljø brukar ein sekvens med kople til, låse og låse opp med tunnelen halden open på låseskjermen; andre sender eininga til eit styrt gjenopprettingstrinn. Følg den som passar klienten, og stadfest før du reknar med han at tunnelen overlever låseskjermen.

Vern vegen tilbake

Før du loggar av ei ekstern maskin, må du avgjere korleis neste pålogging skal nå domenet. Ein brukartunnel som fell med økta kan fjerne den einaste vegen du rekna med, og då kjem korkje det gamle eller det nye passordet deg forbi låseskjermen. Hald ein lokal administratorkonto eller ein konsoll utanfor bandet som reserve. Skriv ned gjenopprettingstrinnet der brukaren kan nå det utan å logge på.

For støtte, samle fire fakta: kvar passordet vart endra, kva legitimasjon som framleis verkar fråkopla, om ein domenekontrollar er tilgjengeleg gjennom tunnelen, og kva påloggingsmetode maskina brukar.

Desse fire skil ein utdatert verifiserar frå ei kontolåsing eller ei avvist VPN-pålogging, som ser like ut i ei sak og har ulike løysingar. Ei låst konto vil avvise det nye passordet òg på nettet, så test det før du klandrar hurtigbufferen.

Lukk sirkelen med éi nettpålogging

Målet er éi støtta interaktiv pålogging medan domenet er tilgjengeleg, etterfølgd av ein kjend fråkopla tilstand. Den eine hendinga oppdaterer verifiseraren og avsluttar syklusen med å endre passordet på kvar eining.

Kontroller tilstanden etterpå med talet på bufra påloggingar og eit oppslag mot domenekontrollaren:

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

Er talet null, er bufra pålogging deaktivert av policy, og fråkopla åtferd vert ikkje endra uansett kor mange gonger passordet vert tilbakestilt. Det er eit policyval som må takast opp med eigaren, ikkje ein omveg som vert brukt lokalt.