Bakit tinatanggap ng domain laptop ang lumang password habang offline

Ang pagbabago ng password ay dumarating sa lahat ng lugar nang sabay, maliban sa isang laptop na isang linggong offline. Tinatanggap ng webmail ang bagong password, tinatanggap din ito ng desktop sa opisina, at ang remote na makina ay pumapasok pa rin gamit ang luma kapag nakababa ang VPN. Hindi ito pangalawang password at hindi ito bug sa pag-sync ng direktoryo. Ito ang naka-cache na verifier ng pag-log on na ginagawa ang dapat nitong gawin, at ang solusyon ay isang pagkakasunod-sunod, hindi isang reset.

Sinusuri ng laptop ang isang naka-cache na verifier

Ang Windows na kaanib ng domain ay nagtatago ng lokal na verifier para sa mga kamakailang matagumpay na interactive na pag-log on, upang makapag-boot ang makina kapag walang domain controller na sumasagot. Ang verifier na iyon ay hinango sa password noong panahon ng pag-log on na iyon. Kapag binago ang password sa ibang lugar, ang direktoryo ang naa-update, hindi ang kopya sa laptop na hindi na nakipag-usap dito mula noon.

Kaya ang lumang password ay nakakabukas pa rin ng lokal na session kahit na hindi ito wasto para sa anumang bagong domain authentication. Dalawang magkaibang obserbasyon ito, at ang paghahalo sa kanila ay humahantong sa paulit-ulit na reset.

Tiyakin kung aling kredensyal ang talagang ginagamit bago magbago ng anumang iba. Ang PIN ng Windows Hello, pag-log on gamit ang Entra ID, at tradisyonal na domain password ay magkakahiwalay na mekanismo, at ang PIN lalo na ay hindi ang domain password kahit na ina-unlock nito ang parehong desktop.

Ang network authentication ay hindi interactive na pag-log on

Ang pagbukas ng file share gamit ang bagong password ay nagpapatunay na gumagana ang network path. Hindi nito nire-refresh ang cache ng interactive na pag-log on, dahil itinuturing ng Windows ang network at interactive na authentication bilang magkahiwalay na operasyon na may magkahiwalay na estado.

Nire-refresh lamang ang verifier kapag ang isang interactive na pag-log on ay aktwal na nakikipag-ugnayan sa isang domain controller; ang naka-map na drive o prompt ng Outlook ay hindi gumagawa nito.

Ipinapaliwanag ng pagkakaibang iyon ang karaniwang ulat: nakakabasa ng mail at nakakabukas ng intranet ang user, ngunit hinihingi pa rin ng lock screen ang lumang password. Ipinapaliwanag din nito kung bakit ang VPN na sinimulan pagkatapos ng pag-log on ay hindi makakatulong sa unang pag-log on, dahil dumarating ang tunnel pagkatapos na magawa ang desisyon nang lokal.

Kumuha ng isang online na pag-log on sa tamang sandali

Nire-refresh ang cache kapag nag-log on nang interactive ang user habang naaabot ang domain. Para sa remote na makina, nangangahulugan itong kailangang umiiral ang tunnel bago suriin ang kredensyal, hindi pagkatapos lumitaw ang desktop.

Tingnan kung sinusuportahan ng deployment ang koneksyon bago mag-log on o isang device tunnel. Dinisenyo ang mga ito para sa sandaling ito, at hindi kapalit ng mga ito ang user tunnel:

nltest /dsgetdc:corp.example
klist

Kung walang landas bago mag-log on ang endpoint, gamitin ang sinusuportahang proseso ng pagbawi na dokumentado ng organisasyon. May mga environment na gumagamit ng pagkakasunod-sunod na kumonekta, i-lock, at i-unlock habang bukas ang tunnel sa lock screen; may iba namang nagpapadala ng device sa pinamamahalaang hakbang ng pagbawi. Sundin ang umaayon sa client, at bago umasa rito, tiyakin na nakakalampas ang tunnel sa lock screen.

Protektahan ang daan pabalik

Bago mag-sign out sa isang remote na makina, magpasya kung paano maaabot ng susunod na pag-log on ang domain. Ang user tunnel na bumabagsak kasabay ng session ay maaaring mag-alis ng nag-iisang daan na inaasahan mo, at hindi ka na mapapalusot ng luma o bagong password sa lock screen. Panatilihin ang lokal na administrative account o out-of-band console bilang reserba. Isulat ang hakbang ng pagbawi sa lugar na maaabot ng user nang hindi nag-log on.

Para sa suporta, kolektahin ang apat na katotohanan: saan binago ang password, aling kredensyal ang gumagana pa rin offline, naaabot ba ang domain controller sa pamamagitan ng tunnel, at aling paraan ng pag-log on ang ginagamit ng laptop.

Ang apat na ito ay naghihiwalay ng lumang verifier mula sa account lockout o tinanggihang pag-log on sa VPN, na magkamukha sa isang ticket at may magkaibang lunas. Tatanggihan din ng naka-lock na account ang bagong password online, kaya subukan iyon bago sisihin ang cache.

Isara ang loop gamit ang isang online na pag-log on

Ang layunin ay isang sinusuportahang interactive na pag-log on habang naaabot ang domain, na sinusundan ng kilalang offline na estado. Ang nag-iisang pangyayaring iyon ay nagre-refresh ng verifier at nagtatapos sa paikot na pagbabago ng password sa bawat device.

Tiyakin ang estado pagkatapos gamit ang bilang ng naka-cache na pag-log on at paghahanap ng domain controller:

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

Kung zero ang bilang, hindi pinagana ng patakaran ang naka-cache na pag-log on at hindi magbabago ang gawi kapag offline, gaano man kadalas i-reset ang password. Ito ay desisyon sa patakaran na dapat iharap sa may-ari, hindi isang paraan ng pag-iwas na ilalapat nang lokal.