Zmiana hasła dociera wszędzie naraz, z wyjątkiem tego jednego laptopa, który był tydzień offline. Webmail przyjmuje nowe hasło, komputer stacjonarny w biurze również, a maszyna zdalna nadal loguje się starym, gdy VPN jest wyłączony. To nie jest drugie hasło ani błąd synchronizacji katalogu. To buforowany weryfikator logowania robi to, do czego został zaprojektowany, a rozwiązaniem jest sekwencja kroków, nie reset.

Laptop sprawdza buforowany weryfikator

Windows przyłączony do domeny przechowuje lokalny weryfikator dla ostatnich udanych logowań interaktywnych, aby maszyna mogła się uruchomić, gdy żaden kontroler domeny nie odpowiada. Ten weryfikator jest wyprowadzany z hasła takiego, jakie było przy tym logowaniu. Zmiana hasła gdzie indziej aktualizuje katalog, a nie kopię na laptopie, który od tego czasu z nim nie rozmawiał.

Stare hasło nadal może więc otworzyć sesję lokalną, choć jest nieważne dla każdego nowego uwierzytelnienia domenowego. To dwie różne obserwacje, a ich mieszanie prowadzi do powtarzanych resetów.

Przed zmianą czegokolwiek innego ustal, które poświadczenie jest rzeczywiście używane. PIN Windows Hello, logowanie przez Entra ID i tradycyjne hasło domenowe to odrębne mechanizmy, a PIN w szczególności nie jest hasłem domenowym, nawet gdy odblokowuje ten sam pulpit.

Uwierzytelnianie sieciowe nie jest logowaniem interaktywnym

Otwarcie udziału sieciowego nowym hasłem dowodzi, że ścieżka sieciowa działa. Nie odświeża jednak pamięci podręcznej logowania interaktywnego, bo Windows traktuje uwierzytelnianie sieciowe i interaktywne jako odrębne operacje z odrębnym stanem.

Weryfikator odświeża się tylko wtedy, gdy logowanie interaktywne naprawdę skontaktuje się z kontrolerem domeny; zmapowany dysk lub monit programu Outlook tego nie robi.

Ta różnica wyjaśnia typowe zgłoszenie: użytkownik może czytać pocztę i otwierać intranet, ale ekran blokady nadal chce starego hasła. Wyjaśnia też, dlaczego VPN uruchomiony po zalogowaniu nie pomoże w początkowym logowaniu, ponieważ tunel pojawia się już po podjęciu decyzji lokalnie.

Uzyskaj jedno logowanie online w odpowiednim momencie

Pamięć podręczna odświeża się, gdy użytkownik zaloguje się interaktywnie, a domena jest osiągalna. W przypadku maszyny zdalnej oznacza to, że tunel musi istnieć przed oceną poświadczenia, a nie po pojawieniu się pulpitu.

Sprawdź, czy wdrożenie obsługuje łączność przed logowaniem lub tunel urządzenia. Są one zaprojektowane właśnie na ten moment, a tunel użytkownika ich nie zastępuje:

nltest /dsgetdc:corp.example
klist

Jeśli punkt końcowy nie ma ścieżki przed logowaniem, użyj obsługiwanego procesu odzyskiwania, który dokumentuje organizacja. Niektóre środowiska stosują sekwencję połącz, zablokuj i odblokuj z tunelem utrzymywanym otwartym na ekranie blokady; inne wysyłają urządzenie do zarządzanego kroku odzyskiwania. Postępuj zgodnie z tym, co pasuje do klienta, i przed poleganiem na nim potwierdź, że tunel przetrwa ekran blokady.

Chroń drogę powrotną

Przed wylogowaniem ze zdalnej maszyny zdecyduj, jak następne logowanie dotrze do domeny. Tunel użytkownika, który pada wraz z sesją, może usunąć jedyną ścieżkę, na której polegałeś, i wtedy ani stare, ani nowe hasło nie przeprowadzi cię przez ekran blokady. Trzymaj lokalne konto administracyjne lub konsolę poza pasmem jako odwód. Zapisz krok odzyskiwania tam, gdzie użytkownik może do niego dotrzeć bez logowania.

Do wsparcia zbierz cztery fakty: gdzie zmieniono hasło, które poświadczenie nadal działa offline, czy kontroler domeny jest osiągalny przez tunel i jakiej metody logowania używa laptop.

Te cztery oddzielają nieaktualny weryfikator od blokady konta lub odrzuconego logowania VPN, które w zgłoszeniu wyglądają podobnie i mają różne rozwiązania. Zablokowane konto odrzuci nowe hasło także online, więc sprawdź to, zanim obwinisz pamięć podręczną.

Zamknij pętlę jednym logowaniem online

Celem jest jedno obsługiwane logowanie interaktywne, gdy domena jest osiągalna, a po nim znany stan offline. To jedno zdarzenie odświeża weryfikator i kończy cykl zmieniania hasła na każdym urządzeniu.

Sprawdź potem stan za pomocą liczby buforowanych logowań i wyszukania kontrolera domeny:

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

Jeśli liczba wynosi zero, buforowane logowanie jest wyłączone przez zasady i zachowanie offline się nie zmieni, niezależnie od liczby resetów hasła. To decyzja dotycząca zasad, którą trzeba podnieść u właściciela, a nie obejście do zastosowania lokalnie.

Powiązane artykuły