ออฟไลน์หนึ่งเดือนแล้วความเชื่อถือของโดเมนหลุด? ตรวจสอบก่อน
เวิร์กสเตชันสมาชิกอาจอยู่ออฟไลน์นานเกินช่วงรหัสผ่านของเครื่องโดยไม่สูญเสียความเชื่อถือ พิสูจน์ช่องทางที่ปลอดภัยก่อนรีเซ็ตบัญชี
แล็ปท็อปเครื่องหนึ่งอยู่นอก VPN หกสัปดาห์ กลับมา แล้วผู้ใช้ลงชื่อเข้าใช้ด้วยบัญชีโดเมนไม่ได้ ข้อผิดพลาดกล่าวถึงความสัมพันธ์ความเชื่อถือ จึงมีคนรีเซ็ตบัญชีคอมพิวเตอร์ หรือบังคับให้ผู้ใช้ใช้ทันเนลเต็มรูปแบบ และปัญหาก็ดูเหมือนหายไป ไม่มีมาตรการใดพิสูจน์ว่าอะไรเสีย สมาชิก Windows สามารถอยู่ออฟไลน์นานเกินช่วงรหัสผ่านของเครื่องตามปกติโดยไม่สูญเสียความเชื่อถือโดยอัตโนมัติ งานแรกจึงเป็นการแยกความล้มเหลวในการเข้าถึงออกจากความไม่ตรงกันของความลับจริง
ข้อผิดพลาดดูเหมือนความเชื่อถือ แต่สามสถานะคล้ายกัน
ผู้ใช้อาจ ลงชื่อเข้าใช้ด้วยข้อมูลโดเมนที่แคชไว้ หรือเวิร์กสเตชันอาจหาโดเมนคอนโทรลเลอร์ไม่พบ หรือสมาชิกกับโดเมนอาจไม่เห็นตรงกันจริง ๆ เกี่ยวกับบัญชีคอมพิวเตอร์ เฉพาะกรณีที่สามเท่านั้นที่เป็นความสัมพันธ์ความเชื่อถือที่แตกในความหมายเข้มงวด
สุขภาพการจำลอง AD เป็นการสังเกตที่สี่ และไม่เกี่ยวกับเวิร์กสเตชันนี้เลย มันอธิบายความสอดคล้องระหว่างโดเมนคอนโทรลเลอร์ และแดชบอร์ดการจำลองที่ดีไม่ได้พิสูจน์ว่าความลับภายในเครื่องนี้ตรงกับบัญชีคอมพิวเตอร์ของมัน
ค่าเริ่มต้น 30 วันที่คุ้นเคยเป็นนโยบายการเปลี่ยนแปลง ไม่ใช่กำหนดหมดอายุออฟไลน์ คำอธิบายของ Microsoft เกี่ยวกับรหัสผ่านบัญชีเครื่อง อธิบายกระบวนการเปลี่ยนแปลงที่ประสานกัน และองค์กรสามารถกำหนดช่วงเวลาอื่นได้
ไอคอน VPN ไม่ได้พิสูจน์อะไรเกี่ยวกับช่องทางที่ปลอดภัย
การเชื่อมต่อต้องดีพอที่จะไปถึงบริการโดเมนก่อนการทดสอบใด ๆ จะมีความหมาย นั่นหมายถึงตัวแปลง DNS ของโดเมนที่ตั้งใจ คอนโทรลเลอร์ที่ค้นหาได้ บริการตรวจสอบสิทธิ์ที่เข้าถึงได้ และนาฬิกาที่ใกล้พอสำหรับ Kerberos
ทันเนลเต็มรูปแบบอาจเป็นการออกแบบที่ถูกต้องสมบูรณ์ที่นี่ การเปลี่ยนไปทันเนลแยกไม่ใช่เงื่อนไขเบื้องต้นของความสัมพันธ์โดเมนที่ดี และการปฏิบัติเช่นนั้นทำให้การวินิจฉัยกลายเป็นการเปลี่ยนสถาปัตยกรรม ตรวจสอบว่าคอนโทรลเลอร์ใดที่เวิร์กสเตชันเลือกจริง และเก็บชื่อนั้นไว้กับข้อผิดพลาด
nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verboseบันทึกเซิร์ฟเวอร์ DNS คอนโทรลเลอร์ที่แก้ไขได้ และข้อความข้อผิดพลาดที่แน่นอน ไคลเอนต์ VPN ที่รายงานว่าเชื่อมต่อบอกคุณว่าทันเนลมีอยู่ ไม่ใช่ว่าเส้นทางโดเมนทำงาน คอนโทรลเลอร์ที่ตอบบนพอร์ต Kerberos แต่ไม่ตอบบนพอร์ตไดเรกทอรีเป็นสิ่งที่พบจากไฟร์วอลล์ ไม่ใช่สิ่งที่พบจากความเชื่อถือ
ทดสอบสมาชิกก่อนซ่อม
บนสมาชิกโดเมน Windows ที่ได้รับอนุญาต Test-ComputerSecureChannel -Verbose เป็นการตรวจสอบแบบอ่านอย่างเดียวของช่องทางระหว่างเครื่องกับโดเมน เรียกใช้ในบริบทของเครื่องที่คุณกำลังตรวจสอบ ไม่ใช่จากโดเมนคอนโทรลเลอร์ซึ่งมีบทบาทและกฎการกู้คืนต่างกัน บันทึกเอาต์พุตและสถานะออก ไม่ใช่คำว่าผ่านหรือล้มเหลว หากไม่มี cmdlet ในบิลด์นั้น โมดูลเป็นปัญหาแยก
ผลลัพธ์ยังต้องมีบริบท หากเครื่องไปถึงหรือตรวจสอบสิทธิ์กับคอนโทรลเลอร์ที่เลือกไม่ได้ การทดสอบที่ล้มเหลวไม่ใช่หลักฐานอิสระว่ารหัสผ่านออฟไลน์หมดอายุ เก็บข้อผิดพลาดจริงและคอนโทรลเลอร์ที่ใช้ และทำการทดสอบซ้ำเมื่อเส้นทางเป็นที่ทราบว่าดี
เชื่อมโยงเหตุการณ์ Netlogon บนสมาชิกและบนคอนโทรลเลอร์ที่เกี่ยวข้องรอบเหตุการณ์ เก็บชื่อเครื่อง ที่อยู่ต้นทาง เวลา และหลักฐานการเปลี่ยนแปลงบัญชีใด ๆ การลงชื่อเข้าใช้สำเร็จของผู้ใช้อื่น หรือแดชบอร์ดคอนโทรลเลอร์ที่ดี ไม่สามารถแทนที่การแลกเปลี่ยนของเครื่องนี้
ซ่อมเฉพาะความสัมพันธ์ที่คุณพิสูจน์แล้ว
เมื่อการเชื่อมต่อเสถียรและผู้ดูแลระบบยืนยันว่าการซ่อมเหมาะสม โหมด -Repair ของ cmdlet พร้อมข้อมูลรับรองที่ได้รับอนุญาตเป็นการดำเนินการที่รองรับหนึ่งรายการสำหรับเวิร์กสเตชันสมาชิก มันเปลี่ยนความสัมพันธ์ และไม่ใช่การทดสอบแบบอ่านอย่างเดียวอีกครั้ง
เตรียมบัญชีกู้คืนภายในที่ได้รับอนุมัติและเส้นทางการจัดการให้พร้อมก่อนการเปลี่ยนแปลง โดเมนคอนโทรลเลอร์มีบทบาทการกู้คืนต่างกัน และขั้นตอนนี้ต้องไม่ถือว่าพวกมันเป็นเวิร์กสเตชันธรรมดา ใช้เวิร์กโฟลว์การกู้คืนขององค์กรแทนการเรียกใช้เครื่องมือรีเซ็ตหลายตัวตามลำดับและหวังว่าตัวใดตัวหนึ่งจะถูก
หลังการซ่อม ให้ตรวจสอบการทดสอบช่องทางที่ปลอดภัยครั้งใหม่และการดำเนินการโดเมนเดิม รักษาโปรไฟล์ผู้ใช้และสถานะแอปพลิเคชัน และอย่าทำให้การถอดและเข้าร่วมใหม่เป็นการกระทำแรกที่อธิบายไม่ได้
สิ่งที่ต้องตรวจสอบเมื่อความล้มเหลวกลับมา
หากความล้มเหลวกลับมา ให้ดูการย้อนกลับ ตัวตนซ้ำ และเวลาของการเปลี่ยนแปลงบัญชี แทนการรีเซ็ตบัญชีเดิมอีกครั้ง อิมเมจที่กู้คืน สแนปช็อต ตัวตนเครื่องที่โคลน หรือการรีเซ็ตบัญชีคอมพิวเตอร์ที่ทำที่อื่น ล้วนควรได้รับการสืบสวน
การรีเซ็ตที่สำเร็จชั่วคราวเป็นหลักฐานการกู้คืนที่มีประโยชน์ แต่ไม่ใช่หลักฐานว่า VPN ที่เป็นช่วง ๆ ทำให้เกิดความไม่ตรงกันเดิม การเกิดครั้งถัดไปคือสิ่งที่บอกคุณว่าสาเหตุถูกกำจัดออกไปหรือไม่
เขียนคอนโทรลเลอร์ เซิร์ฟเวอร์ DNS และเอาต์พุตการทดสอบลงในตั๋ว บันทึกนั้นคือสิ่งที่แยกความล้มเหลวของความเชื่อถือจริงออกจากแล็ปท็อปที่หาโดเมนไม่พบเฉย ๆ