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، فتوقف عن النظر إلى هذا الإعداد تمامًا. وإذا كان جهازًا قديمًا لا يستطيع فعل أفضل حقًا، فوثّق ذلك الاستثناء وحدّد نطاقه، لأن البديل هو خط أساس مُضعَّف بهدوء لا يتذكر أحد موافقته عليه.