Un cambio di password arriva ovunque contemporaneamente, tranne che sull'unico portatile rimasto offline per una settimana. La webmail accetta la nuova password, un desktop in ufficio la accetta, e la macchina remota continua ad accedere con quella vecchia quando la VPN è giù. Non è una seconda password e non è un bug di sincronizzazione della directory. È il verificatore di accesso memorizzato nella cache che fa ciò per cui è progettato, e la soluzione è una sequenza, non un ripristino.

Il portatile controlla un verificatore memorizzato

Windows aggiunto a un dominio conserva un verificatore locale per gli accessi interattivi recenti riusciti, così la macchina può avviarsi quando nessun controller di dominio risponde. Quel verificatore deriva dalla password com'era a quell'accesso. Cambiare la password altrove aggiorna la directory, non la copia su un portatile che da allora non ci ha parlato.

Quindi la vecchia password può ancora aprire la sessione locale pur essendo non valida per qualsiasi nuova autenticazione di dominio. Sono due osservazioni diverse, e mescolarle porta a ripristini ripetuti.

Confermate quale credenziale è davvero in gioco prima di cambiare qualsiasi altra cosa. Un PIN di Windows Hello, un accesso con Entra ID e una password di dominio tradizionale sono meccanismi separati, e il PIN in particolare non è la password del dominio anche quando sblocca lo stesso desktop.

L'autenticazione di rete non è un accesso interattivo

Aprire una condivisione file con la nuova password dimostra che il percorso di rete funziona. Non aggiorna la cache dell'accesso interattivo, perché Windows tratta l'autenticazione di rete e quella interattiva come operazioni separate con stato separato.

Il verificatore si aggiorna solo quando un accesso interattivo contatta davvero un controller di dominio; un'unità mappata o un avviso di Outlook non lo fanno.

Questa distinzione spiega la segnalazione abituale: l'utente può leggere la posta e aprire l'intranet, ma la schermata di blocco chiede ancora la vecchia password. Spiega anche perché una VPN avviata dopo l'accesso non può aiutare l'accesso iniziale, dato che il tunnel arriva dopo che la decisione è già stata presa localmente.

Ottenete un accesso online al momento giusto

La cache si aggiorna quando l'utente accede in modo interattivo mentre il dominio è raggiungibile. Per una macchina remota questo significa che il tunnel deve esistere prima che la credenziale venga valutata, non dopo che compare il desktop.

Verificate se l'implementazione supporta la connettività pre-accesso o un tunnel del dispositivo. Sono progettati per questo momento, e un tunnel utente non li sostituisce:

nltest /dsgetdc:corp.example
klist

Se l'endpoint non ha un percorso pre-accesso, usate il processo di ripristino supportato che l'organizzazione documenta. Alcuni ambienti usano una sequenza di connessione, blocco e sblocco con il tunnel tenuto aperto sulla schermata di blocco; altri inviano il dispositivo a un passaggio di ripristino gestito. Seguite quello che corrisponde al client e, prima di contarci, confermate che il tunnel sopravviva alla schermata di blocco.

Proteggete la via del ritorno

Prima di disconnettervi da una macchina remota, decidete come il prossimo accesso raggiungerà il dominio. Un tunnel utente che cade con la sessione può rimuovere l'unico percorso su cui contavate, e allora né la vecchia né la nuova password vi faranno superare la schermata di blocco. Tenete un account amministrativo locale o una console fuori banda come ripiego. Scrivete il passaggio di ripristino dove l'utente può raggiungerlo senza accedere.

Per l'assistenza, raccogliete quattro fatti: dove è stata cambiata la password, quale credenziale funziona ancora offline, se un controller di dominio è raggiungibile tramite il tunnel e quale metodo di accesso usa il portatile.

Quei quattro separano un verificatore obsoleto da un blocco dell'account o da un accesso VPN rifiutato, che in un ticket sembrano uguali e hanno soluzioni diverse. Un account bloccato rifiuterà la nuova password anche online, quindi provatelo prima di dare la colpa alla cache.

Chiudete il cerchio con un accesso online

L'obiettivo è un accesso interattivo supportato mentre il dominio è raggiungibile, seguito da uno stato offline noto. Quell'unico evento aggiorna il verificatore e chiude il ciclo di cambiare la password su ogni dispositivo.

Verificate poi lo stato con il conteggio degli accessi memorizzati e una ricerca del controller di dominio:

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

Se il conteggio è zero, l'accesso memorizzato è disattivato dai criteri e il comportamento offline non cambierà, per quante volte si reimposti la password. È una decisione di criterio da sollevare con il proprietario, non una scorciatoia da applicare localmente.

Articoli correlati