Varför en domändator accepterar det gamla lösenordet offline

En lösenordsändring når överallt samtidigt, utom på den där enda bärbara datorn som har varit offline i en vecka. Webbmailen tar emot det nya lösenordet, en stationär dator på kontoret tar också emot det, och fjärrmaskinen loggar fortfarande in med det gamla när VPN:en ligger nere. Det är inte ett andra lösenord och inte en synkroniseringsbugg i katalogen. Det är den cachelagrade inloggningsverifieraren som gör det den är byggd för, och lösningen är en sekvens, inte en återställning.

Datorn kontrollerar en cachelagrad verifierare

Domänansluten Windows håller en lokal verifierare för de senaste lyckade interaktiva inloggningarna, så att datorn kan starta när ingen domänkontrollant svarar. Verifieraren härleds från lösenordet så som det var vid den inloggningen. Ändras lösenordet någon annanstans uppdateras katalogen, men inte kopian på en dator som inte har talat med den sedan dess.

Så det gamla lösenordet kan fortfarande öppna den lokala sessionen trots att det är ogiltigt för varje ny domänautentisering. Det är två olika observationer, och att blanda dem leder till upprepade återställningar.

Bekräfta vilken autentiseringsuppgift som faktiskt används innan du ändrar något annat. En Windows Hello-PIN, en inloggning med Entra ID och ett traditionellt domänlösenord är separata mekanismer, och just PIN-koden är inte domänlösenordet även när den låser upp samma skrivbord.

Nätverksautentisering är inte interaktiv inloggning

Att öppna en filresurs med det nya lösenordet bevisar att nätverksvägen fungerar. Det uppdaterar inte cachen för interaktiv inloggning, eftersom Windows behandlar nätverks- och interaktiv autentisering som separata operationer med separat tillstånd.

Verifieraren uppdateras bara när en interaktiv inloggning faktiskt kontaktar en domänkontrollant; en mappad enhet eller en Outlook-förfrågan gör det inte.

Den skillnaden förklarar den vanliga rapporten: användaren kan läsa mejl och öppna intranätet, men låsskärmen vill fortfarande ha det gamla lösenordet. Den förklarar också varför en VPN som startas efter inloggningen inte kan hjälpa den första inloggningen, eftersom tunneln kommer först efter att beslutet redan fattats lokalt.

Få en online-inloggning vid rätt tillfälle

Cachen uppdateras när användaren loggar in interaktivt medan domänen är nåbar. För en fjärrmaskin innebär det att tunneln måste finnas innan autentiseringsuppgiften utvärderas, inte efter att skrivbordet visas.

Kontrollera om distributionen stöder anslutning före inloggning eller en enhetstunnel. De är byggda för just detta tillfälle, och en användartunnel ersätter dem inte:

nltest /dsgetdc:corp.example
klist

Om slutpunkten saknar väg före inloggning, använd den återställningsprocess som organisationen dokumenterar och som stöds. Vissa miljöer använder en sekvens med anslut, lås och lås upp där tunneln hålls öppen på låsskärmen; andra skickar enheten till ett hanterat återställningssteg. Följ den som passar klienten, och bekräfta innan du förlitar dig på den att tunneln överlever låsskärmen.

Skydda vägen tillbaka

Innan du loggar ut från en fjärrmaskin, bestäm hur nästa inloggning ska nå domänen. En användartunnel som faller med sessionen kan ta bort den enda väg du räknade med, och då tar sig varken det gamla eller det nya lösenordet förbi låsskärmen. Håll ett lokalt administratörskonto eller en konsol utanför bandet som reserv. Skriv ner återställningssteget där användaren kan nå det utan att logga in.

Samla fyra fakta för supporten: var lösenordet ändrades, vilken autentiseringsuppgift som fortfarande fungerar offline, om en domänkontrollant är nåbar via tunneln och vilken inloggningsmetod datorn använder.

Dessa fyra skiljer en föråldrad verifierare från en kontolåsning eller en avvisad VPN-inloggning, som ser likadana ut i ett ärende och har olika åtgärder. Ett låst konto avvisar det nya lösenordet även online, så testa det innan du skyller på cachen.

Slut cirkeln med en online-inloggning

Målet är en stödd interaktiv inloggning medan domänen är nåbar, följd av ett känt offlineläge. Den enda händelsen uppdaterar verifieraren och avslutar cykeln med att byta lösenord på varje enhet.

Kontrollera tillståndet efteråt med antalet cachelagrade inloggningar och en sökning efter domänkontrollanten:

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

Är antalet noll är cachelagrad inloggning avstängd via princip och offlinebeteendet ändras inte, hur många gånger lösenordet än återställs. Det är ett principbeslut att lyfta med ägaren, inte en kringgående lösning att tillämpa lokalt.