LmCompatibilityLevel เป็นนโยบายของ Windows ไม่ใช่การแก้ไข VPN

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

การอ่านระดับที่มีการบันทึกไว้คือหนทางเร็วที่สุดที่จะเลิกมองค่าของนโยบายเป็นตัวเลขวิเศษ

สามระดับ สามคำสัญญาที่ต่างกัน

ระดับ 1 ทำให้ไคลเอนต์ส่งคำตอบ LM และ NTLM โดยใช้ความปลอดภัยของเซสชัน NTLMv2 เมื่อการเจรจาอนุญาต ระดับ 3 ทำให้ไคลเอนต์ส่งเฉพาะคำตอบ NTLMv2 ซึ่งไม่เหมือนกับการปฏิเสธคำตอบเก่าทุกคำตอบที่ฝั่งผู้รับ ระดับ 5 ทำให้ไคลเอนต์อยู่ที่ NTLMv2 และเพิ่มการปฏิเสธ LM และ NTLMv1 โดยโดเมนคอนโทรลเลอร์ตามที่มีการบันทึกไว้ สามตัวเลข และช่องว่างระหว่างกันคือการตัดสินใจเชิงนโยบายไม่ใช่ความชอบ

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

อ่านนโยบายที่มีผลจริง ไม่ใช่ค่าในรีจิสทรีค่าเดียว

การดูค่าภายในเครื่องแบบอ่านอย่างเดียวเป็นจุดเริ่มต้นที่สมเหตุสมผล: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel การไม่มีค่าไม่ได้หมายความว่านโยบายที่มีผลเป็นศูนย์ เพราะนโยบายโดเมนหรือนโยบายความปลอดภัยภายในเครื่องอาจกำหนดค่าไว้ที่อื่น และบทบาทของเครื่องเปลี่ยนสิ่งที่เครื่องทำกับตัวเลขนั้น

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

ระบุว่าการตรวจสอบสิทธิ์ใดล้มเหลวจริง

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

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

การสนับสนุนโปรโตคอลบางอย่างกู้คืนไม่ได้

Windows 11 24H2 และ Windows Server 2025 ไม่มีการตรวจสอบสิทธิ์เครือข่าย NTLMv1 เลยอีกต่อไป ไม่มีตัวเลขความเข้ากันได้ใดนำโปรโตคอลที่บิลด์ไม่ได้ใช้งานแล้วกลับมา ดังนั้นการดาวน์เกรดที่ดูเหมือนช่วยได้บนรุ่นเก่าจะล้มเหลวบนรุ่นใหม่ Microsoft บันทึกการถอดออกนั้นแยกจากค่าตั้งนโยบาย และการนำสองอย่างมาปนกันทำให้เกิดคำแนะนำที่ใช้ไม่ได้

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

เปลี่ยนผ่านเจ้าของนโยบาย แล้วทดสอบทั้งสองทิศทาง

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

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