ทำไมแล็ปท็อปในโดเมนจึงรับรหัสผ่านเดิมขณะออฟไลน์

การเปลี่ยนรหัสผ่านไปถึงทุกที่พร้อมกัน ยกเว้นแล็ปท็อปเครื่องเดียวที่ออฟไลน์มาหนึ่งสัปดาห์ เว็บเมลรับรหัสผ่านใหม่ เดสก์ท็อปในออฟฟิศก็รับ แต่เครื่องระยะไกลยังลงชื่อเข้าใช้ด้วยรหัสเดิมเมื่อ VPN ล่ม นี่ไม่ใช่รหัสผ่านที่สองและไม่ใช่บั๊กการซิงค์ในไดเรกทอรี มันคือตัวตรวจสอบการลงชื่อเข้าใช้ที่แคชไว้กำลังทำหน้าที่ตามที่ออกแบบไว้ และวิธีแก้คือลำดับขั้นตอน ไม่ใช่การรีเซ็ต

แล็ปท็อปกำลังตรวจสอบตัวตรวจสอบที่แคชไว้

Windows ที่ joined โดเมนเก็บตัวตรวจสอบภายในสำหรับการลงชื่อเข้าใช้แบบอินเทอร์แอกทีฟที่สำเร็จล่าสุด เพื่อให้เครื่องบูตได้เมื่อไม่มีโดเมนคอนโทรลเลอร์ตอบสนอง ตัวตรวจสอบนั้นได้มาจากรหัสผ่าน ณ เวลาของการลงชื่อเข้าใช้นั้น การเปลี่ยนรหัสผ่านที่อื่นจะอัปเดตไดเรกทอรี ไม่ใช่สำเนาบนแล็ปท็อปที่ไม่ได้คุยกับมันตั้งแต่นั้น

ดังนั้นรหัสผ่านเดิมยังเปิดเซสชันภายในได้ แม้จะใช้ไม่ได้กับการพิสูจน์ตัวตนโดเมนครั้งใหม่ใด ๆ สิ่งเหล่านี้เป็นการสังเกตที่ต่างกันสองอย่าง และการนำมาปนกันทำให้ต้องรีเซ็ตซ้ำแล้วซ้ำอีก

ยืนยันว่าข้อมูลรับรองใดถูกใช้จริงก่อนเปลี่ยนสิ่งอื่นใด 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

หากจำนวนเป็นศูนย์ การลงชื่อเข้าใช้ที่แคชไว้ถูกปิดโดยนโยบาย และพฤติกรรมออฟไลน์จะไม่เปลี่ยนไม่ว่าจะรีเซ็ตรหัสผ่านกี่ครั้ง นี่คือการตัดสินใจเชิงนโยบายที่ต้องยกให้เจ้าของ ไม่ใช่วิธีเลี่ยงที่นำไปใช้ในเครื่อง