ทำไมแล็ปท็อป Protected Users จึงต้องมี VPN ก่อนลงชื่อเข้าใช้

แล็ปท็อป บัญชีที่ใช้งานได้ และเครือข่ายของโรงแรมรวมกันแล้วก่อให้เกิดวงจรการลงชื่อเข้าใช้ที่ไม่มีจำนวนครั้งของการลองใหม่ใดทำให้ขาดได้ บัญชีอยู่ใน Protected Users ซึ่งทำให้ Windows ไม่สามารถเก็บตัวตรวจสอบที่จำเป็นสำหรับตรวจสอบสิทธิ์ผู้ใช้แบบออฟไลน์ได้ แผนใดก็ตามในรูปแบบ «ลงชื่อเข้าใช้ก่อน แล้วค่อยเชื่อมต่ออุโมงค์ทีหลัง» มีลำดับกลับกัน และการป้องกันก็ทำตามที่สัญญาไว้จริง ๆ เนื้อหาต่อไปนี้ถือว่ามีบัญชี Active Directory แบบดั้งเดิมบนโฮสต์ Windows ที่รองรับ

การป้องกันตัดอะไรออกไปจริง ๆ

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

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

ทำไมอุโมงค์ต้องมีอยู่ก่อนเดสก์ท็อป

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

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

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

การเข้าถึงไม่ใช่ความเข้ากันได้ของการตรวจสอบสิทธิ์

อุโมงค์สามารถขนส่งแพ็กเก็ตได้อย่างสมบูรณ์แบบในขณะที่การตรวจสอบสิทธิ์โดเมนล้มเหลว เพราะกลไกที่กำลังลองนั้นเป็นกลไกที่บัญชีใช้ไม่ได้ ในโดเมนที่บังคับใช้ข้อจำกัดของกลุ่ม NTLM ไม่พร้อมใช้สำหรับสมาชิก และ Kerberos ต้องมีบัญชีและการกำหนดค่าที่เข้ากันได้กับ AES เส้นทางแพ็กเก็ตไม่อาจซ่อมแซมสิ่งใดในสองอย่างนั้นได้ นี่คือเหตุผลที่ ping ที่สะอาดไปยังตัวควบคุมโดเมนไม่ใช่หลักฐานว่าการลงชื่อเข้าใช้จะได้ผล

อาจมีระบบข้อมูลรับรองสองระบบทำงานอยู่ด้วย VPN อาจตรวจสอบสิทธิ์กับผู้ให้บริการตัวตนในขณะที่ Windows ต้องการการลงชื่อเข้าใช้โดเมนแยกต่างหาก และการยอมรับจากระบบแรกไม่ได้บอกอะไรเกี่ยวกับระบบที่สอง «VPN เชื่อมต่อแล้ว» และ «ผู้ใช้ลงชื่อเข้าใช้แล้ว» เป็นการสังเกตที่แยกจากกัน และการแก้ไขอย่างหนึ่งไม่ได้หมายถึงอีกอย่างหนึ่ง

อ่านหลักฐานการตรวจสอบสิทธิ์

เก็บเหตุการณ์จากไคลเอนต์และจากตัวควบคุมโดเมนสำหรับความพยายามเดียวกัน ไม่ใช่จากด้านเดียว บันทึกของ Protected Users อยู่ภายใต้ Applications and Services Logs\Microsoft\Windows\Authentication และผู้ดูแลระบบอาจต้องเปิดบันทึกก่อนที่มันจะบันทึกสิ่งใด สหสัมพันธ์เวลากับบันทึกการเชื่อมต่อของอุโมงค์เอง เพราะความผิดพลาดของลำดับดูเหมือนความบกพร่องของข้อมูลรับรองจากทั้งสองด้าน

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

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

พิสูจน์ขอบเขตจากการบูตเย็น

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

1. ยืนยันว่าอุปกรณ์สามารถหาตัวควบคุมโดเมนได้ก่อนที่ใครจะลงชื่อเข้าใช้ ด้วย nltest /dsgetdc:corp.example.com
2. ลองลงชื่อเข้าใช้โดเมน แล้วถามว่าได้รับตั๋วหรือไม่ ด้วย klist
3. อ่านบันทึกการตรวจสอบสิทธิ์ที่อุปกรณ์บันทึก ด้วยสองคำสั่งข้างต้น และบันทึกชุดและเงื่อนไขความล้มเหลว
4. ยืนยันว่าข้อมูลรับรองการกู้คืนที่ได้รับอนุมัติยังใช้ได้จากหน้าจอลงชื่อเข้าใช้ เพราะนั่นคือทางกลับเดียวหากการทดสอบขอบเขตล้มเหลว

การเปิดแชร์ไฟล์ด้วยข้อมูลรับรองที่ให้มาก็ไม่ได้สร้างการลงชื่อเข้าใช้แบบโต้ตอบออฟไลน์เช่นกัน จึงไม่ใช่สิ่งทดแทนขั้นตอนใดข้างต้น หากองค์กรต้องการการลงชื่อเข้าใช้โดยไม่มีการเชื่อมต่อจริง ๆ คำตอบคือการออกแบบบัญชีและปลายทางที่เข้ากันได้ซึ่งเลือกอย่างตั้งใจ การนำบัญชีออกจากกลุ่ม หรือการเก็บบัญชีฉุกเฉินหนึ่งบัญชีที่ไม่จำกัดบนแล็ปท็อปทุกเครื่อง เป็นการตัดสินใจเชิงนโยบายตัวตนที่การเปลี่ยนแปลง VPN ไม่อาจทำแทนคุณได้

เอกสารของ Protected Users อธิบายทั้งพฤติกรรมของตัวตรวจสอบและข้อจำกัดของโดเมนที่การออกแบบนี้อาศัยอยู่ วางแผนกระบวนการกู้คืนก่อนที่ใครจะเดินทาง เพราะการทดสอบบูตเย็นเป็นที่เดียวที่มีการฝึกฝน