Hvorfor en domenemaskin godtar det gamle passordet uten nett

En passordendring når frem overalt på samme tid, med unntak av den ene bærbare maskinen som har stått uten nett i en uke. Webmail godtar det nye passordet, en stasjonær maskin på kontoret godtar det, mens den eksterne maskinen fortsatt logger på med det gamle når VPN-forbindelsen er nede. Dette er ikke et ekstra passord, og det er heller ikke en feil i katalogsynkroniseringen. Det er den mellomlagrede påloggingsverifisereren som gjør jobben sin, og løsningen består av flere trinn, ikke av en nullstilling.

Maskinen kontrollerer en mellomlagret verifiserer

Windows som er knyttet til et domene, har en lokal verifiserer for de siste vellykkede interaktive påloggingene, slik at maskinen kan starte når ingen domenekontroller svarer. Verifisereren er utledet fra passordet slik det var på det tidspunktet. Bytter du passordet et annet sted, oppdateres katalogen, men ikke kopien som ligger på en maskin som ikke har vært i kontakt med den siden.

Dermed kan det gamle passordet fortsatt låse opp den lokale økten, selv om det ikke lenger gjelder for noen ny autentisering mot domenet. Dette er to ulike forhold, og når de blandes sammen, ender man opp med å nullstille passordet om og om igjen.

Før du endrer noe annet, må du finne ut hvilken legitimasjon som faktisk brukes. En PIN-kode i Windows Hello, en pålogging med Entra ID og et vanlig domenepassord er tre forskjellige mekanismer, og PIN-koden er ikke domenepassordet selv om den låser opp samme skrivebord.

Autentisering over nett er ikke det samme som interaktiv pålogging

Åpner du en filressurs med det nye passordet, viser det at nettverksveien virker. Det oppdaterer likevel ikke hurtigbufferen for interaktiv pålogging, fordi Windows ser på nettverksautentisering og interaktiv autentisering som to atskilte operasjoner med hver sin tilstand.

Verifisereren oppdateres bare når en interaktiv pålogging faktisk er i kontakt med en domenekontroller. En tilkoblet stasjon eller en forespørsel fra Outlook gjør ingen forskjell.

Denne forskjellen forklarer den vanlige meldingen: brukeren får lest e-post og åpnet intranettet, men låseskjermen krever fortsatt det gamle passordet. Den forklarer også hvorfor en VPN som startes etter pålogging, ikke hjelper den første påloggingen, siden tunnelen først er på plass etter at avgjørelsen er tatt lokalt.

Sørg for én pålogging med nett på riktig tidspunkt

Hurtigbufferen oppdateres når brukeren logger på interaktivt mens domenet er tilgjengelig. På en ekstern maskin betyr det at tunnelen må være oppe før legitimasjonen vurderes, og ikke først når skrivebordet dukker opp.

Undersøk om utrullingen støtter tilkobling før pålogging eller en tunnelløsning for enheten. Disse er laget nettopp for dette tidspunktet, og en vanlig brukertunnel kan ikke erstatte dem:

nltest /dsgetdc:corp.example
klist

Mangler endepunktet en vei inn før pålogging, bruker du den støttede gjenopprettingsprosessen som organisasjonen har dokumentert. Enkelte miljøer bruker en sekvens der man kobler til, låser og låser opp mens tunnelen holdes åpen på låseskjermen. Andre sender enheten videre til et administrert gjenopprettingstrinn. Følg den varianten som passer klienten, og bekreft at tunnelen holder seg gjennom låseskjermen før du baserer deg på den.

Sikre veien tilbake

Før du logger av en ekstern maskin, bør du bestemme hvordan neste pålogging skal nå domenet. En brukertunnel som faller sammen med økten, kan fjerne den eneste veien du hadde regnet med, og da slipper verken det gamle eller det nye passordet deg forbi låseskjermen. Ha en lokal administratorkonto eller en konsoll utenfor det vanlige nettet som reserve. Skriv ned gjenopprettingstrinnet på et sted der brukeren kommer til det uten å logge på.

Til support bør du samle inn fire opplysninger: hvor passordet ble endret, hvilken legitimasjon som fortsatt fungerer uten nett, om en domenekontroller er tilgjengelig gjennom tunnelen, og hvilken påloggingsmetode maskinen benytter.

Disse fire skiller en foreldet verifiserer fra en låst konto eller en avvist VPN-pålogging, som ser like ut i en sak, men har helt forskjellige løsninger. En låst konto vil også avvise det nye passordet på nettet, så det bør testes før du gir hurtigbufferen skylden.

Avslutt med én pålogging med nett

Målet er én støttet interaktiv pålogging mens domenet er tilgjengelig, og deretter en kjent tilstand uten nett. Nettopp denne ene hendelsen oppdaterer verifisereren og stopper den evige runden med å bytte passord på hver enhet.

Etterpå kontrollerer du tilstanden ved hjelp av antallet mellomlagrede pålogginger og et oppslag mot domenekontrolleren:

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

Dersom tallet er null, er mellomlagret pålogging slått av gjennom policy, og oppførselen uten nett vil ikke endre seg uansett hvor mange ganger passordet nullstilles. Dette er et policyvalg som må løftes til eieren, og ikke en omvei du kan bruke lokalt.