Смяната на парола достига навсякъде наведнъж, с изключение на единствения лаптоп, който е бил офлайн цяла седмица. Уеб пощата приема новата парола, настолен компютър в офиса я приема, а отдалечената машина все още влиза със старата, когато VPN е спрян. Това не е втора парола и не е грешка в синхронизацията на директорията. Това е кешираният проверяващ елемент за вход, който прави това, за което е създаден, и решението е последователност, а не нулиране.

Лаптопът проверява кеширан проверяващ елемент

Windows, присъединен към домейн, пази локален проверяващ елемент за последните успешни интерактивни влизания, за да може машината да стартира, когато никой контролер на домейн не отговаря. Този проверяващ елемент се извлича от паролата такава, каквато е била при онова влизане. Смяната на паролата другаде обновява директорията, но не и копието на лаптопа, който оттогава не е говорил с нея.

Затова старата парола все още може да отвори локалната сесия, въпреки че е невалидна за всяко ново удостоверяване в домейна. Това са две различни наблюдения и смесването им води до повтарящи се нулирания.

Преди да промените нещо друго, потвърдете кой идентификатор всъщност се използва. PIN на Windows Hello, вход през Entra ID и традиционна парола за домейн са отделни механизми, като PIN-ът по-специално не е паролата за домейна, дори когато отключва същия работен плот.

Мрежовото удостоверяване не е интерактивно влизане

Отварянето на мрежов дял с новата парола доказва, че мрежовият път работи. То не обновява кеша за интерактивно влизане, защото Windows третира мрежовото и интерактивното удостоверяване като отделни операции с отделно състояние.

Проверяващият елемент се обновява само когато интерактивно влизане действително се свърже с контролер на домейн; свързан диск или подкана на Outlook не прави това.

Това разграничение обяснява обичайния доклад: потребителят може да чете поща и да отваря интранета, но екранът за заключване все още иска старата парола. То обяснява и защо VPN, стартиран след влизането, не може да помогне на първоначалния вход, тъй като тунелът пристига, след като решението вече е взето локално.

Получете едно онлайн влизане в подходящия момент

Кешът се обновява, когато потребителят влезе интерактивно, докато домейнът е достъпен. За отдалечена машина това означава, че тунелът трябва да съществува преди идентификаторът да бъде оценен, а не след като се появи работният плот.

Проверете дали внедряването поддържа свързаност преди влизане или тунел за устройство. Те са създадени точно за такъв момент и потребителският тунел не е заместител:

nltest /dsgetdc:corp.example
klist

Ако крайната точка няма път преди влизане, използвайте поддържания процес за възстановяване, който организацията документира. Някои среди използват последователност от свързване, заключване и отключване с тунел, задържан отворен на екрана за заключване; други изпращат устройството към управлявана стъпка за възстановяване. Следвайте тази, която отговаря на клиента, и преди да разчитате на тунела, потвърдете, че той оцелява след екрана за заключване.

Защитете пътя обратно

Преди да излезете от отдалечена машина, решете как следващото влизане ще достигне до домейна. Потребителски тунел, който пада заедно със сесията, може да премахне единствения път, на който сте разчитали, и тогава нито старата, нито новата парола ще ви преведе през екрана за заключване. Пазете локален административен акаунт или извънлентовидна конзола като резерва. Запишете стъпката за възстановяване там, където потребителят може да я достигне без влизане.

За поддръжка съберете четири факта: къде е сменена паролата, кой идентификатор все още работи офлайн, достъпен ли е контролер на домейн през тунела и кой метод за влизане използва лаптопът.

Тези четири отделят остарелия проверяващ елемент от блокировка на акаунта или отхвърлено влизане през VPN, които изглеждат сходни в тикет и имат различни решения. Блокиран акаунт ще отхвърли новата парола и онлайн, така че проверете това, преди да обвинявате кеша.

Затворете цикъла с едно онлайн влизане

Целта е едно поддържано интерактивно влизане, докато домейнът е достъпен, последвано от известно офлайн състояние. Това единствено събитие обновява проверяващия елемент и прекратява цикъла на смяна на паролата на всяко устройство.

Проверете състоянието след това с броя кеширани влизания и справка за контролер на домейн:

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

Ако броят е нула, кешираното влизане е изключено от политика и офлайн поведението няма да се промени, колкото и пъти да се нулира паролата. Това е политическо решение, което да се повдигне пред собственика, а не заобиколно решение за локално прилагане.

Подобни статии