تقدم هذه المقالة دليلاً تفصيليًا لاستكشاف أخطاء RDP NLA وإصلاحها. وهي تغطي الأسباب الجذرية مثل عدم تطابق CredSSP ومشكلات DNS، وتقدم 7 حلول تقنية، وتقدم AnyViewer كبديل موثوق بنقرة واحدة لتجاوز تكوينات RDP المعقدة.
عند إدارة خوادم Windows أو الاتصال بمحطة عمل بعيدة، قد تواجه رسالة خطأ محبطة: "يتطلب الكمبيوتر البعيد مصادقة مستوى الشبكة (NLA)." حتى عندما تبدو إعداداتك صحيحة، فإن اكتشاف أن بروتوكول RDP مع NLA لا يعمل رغم تفعيل NLA يمكن أن يوقف إنتاجيتك ويمنع الوصول الحرج.
يستكشف هذا الدليل الأسباب الجذرية لفشل NLA ويقدم حلولًا خطوة بخطوة لاستعادة اتصال سطح المكتب البعيد الخاص بك.
مصادقة مستوى الشبكة (NLA) هي طريقة أمان تُنهي مصادقة المستخدم قبل إنشاء جلسة سطح مكتب بعيد كاملة وظهور شاشة تسجيل الدخول.
يمكن لعدة عوامل أن تسبب فشل الاتصال هذا، تتراوح من تحديثات الأمان إلى إعدادات الشبكة الخاطئة:
إذا كنت تواجه أخطاء في مصادقة مستوى الشبكة (NLA)، فاتبع هذه الإصلاحات بالترتيب. تساعد هذه المنهجيات المنظمة في استعادة الوصول مع الحفاظ على أمان النظام.
أولاً، تأكد من أن كلا الطرفين قادران تقنيًا على التعامل مع NLA.
الخطوة 1. التحقق من إصدار نظام التشغيل: نفّذ الأمر winver على كلا الجهازين للتأكد من أنهما يعملان بنظام Windows Vista / Windows Server 2008 أو إصدار أحدث.
الخطوة 2. تحديث العملاء: تأكد من تثبيت أحدث تحديثات عميل سطح المكتب البعيد عبر Windows Update أو تطبيق Microsoft Remote Desktop الرسمي.
الخطوة 3. التطبيقات الخارجية: إذا كنت تستخدم عملاء RDP غير تابعين لنظام Windows، تحقق من تمكين دعم NLA صراحةً في الإعدادات.
الخطوة 4. خطة الترقية: إذا كان أحد المكونات لا يدعم NLA، خطط للترقية بدلاً من خفض مستوى الأمان بشكل دائم.
بالنسبة للأجهزة المنضمة إلى النطاق، غالبًا ما يتسبب الاتصال المعطّل بـ Active Directory (AD) في فشل NLA.
الخطوة 1. اختبار إمكانية الوصول: استخدم الأمر ping dc01.yourdomain.com للتحقق من المسار الشبكي إلى وحدة تحكم النطاق الخاصة بك.
الخطوة 2. تحديد موقع وحدة التحكم: نفّذ الأمر nltest /dsgetdc:yourdomain.com للتأكد من قدرة العميل على اكتشاف وحدة تحكم.
الخطوة 3. فحص القناة الآمنة: نفّذ PowerShell كمسؤول وأدخل:
الخطوة 4. إصلاح الثقة: إذا كانت النتيجة False، أصلح القناة الآمنة باستخدام:
الخطوة 5. إعادة التشغيل: أعد تشغيل الجهاز بعد الإصلاح إذا طُلب منك ذلك.
عدم تطابق تحديثات CredSSP بين العميل والخادم هو السبب الأكثر شيوعًا لخطأ "معالجة أوراكل التشفير".
الخطوة 1. تثبيت التحديثات: تأكد من تثبيت جميع تحديثات الأمان التراكمية على كلا الطرفين.
الخطوة 2. تكوين سياسة المجموعة: افتح gpedit.msc وانتقل إلى:
الخطوة 3. ضبط المعالجة: انقر نقرًا مزدوجًا على معالجة أوراكل التشفير. عيّنها على ممكّن وللاختبار المؤقت، عيّن مستوى الحماية على عرضة للخطر.
الخطوة 4. الإصلاح طويل الأمد: بمجرد استعادة الاتصال، قم بإعطاء الأولية لتحديث جميع الأنظمة إلى مستوى ثابت وإعادة السياسة إلى "تم التخفيف".
تعتمد مصادقة مستوى الشبكة (NLA) على بروتوكولات أمنية حديثة. إذا كان TLS 1.2 معطلاً، فسيفشل مصافحة الاتصال.
الخطوة 1. التحقق من السجل: انتقل إلى المسار التالي في محرر السجل:
الخطوة 2. تمكين المفتاح: تأكد من ضبط قيمة DWORD المسماة "Enabled" على 1.
الخطوة 3. مفاتيح الخادم: تحقق من إعدادات مماثلة في المفتاح الفرعي "Server" تحت نفس المسار.
الخطوة 4. فحص الشهادة: تأكد من أن شهادة RDP سارية وليست مستخدمة لتوقيعات قديمة. أعد تشغيل خدمة "Remote Desktop Services" في services.msc لتحديث الشهادة.
قد تفرض كائنات نهج المجموعة (GPOs) مصادقة مستوى الشبكة (NLA) بطريقة تتعارض مع بيئتك المحددة.
الخطوة 1. نهج الأمان المحلي: افتح gpedit.msc وانتقل إلى:
الخطوة 2. تدقيق التنفيذ: تحقق من السياسة "تطلب مصادقة المستخدم للاتصالات البعيدة باستخدام مصادقة مستوى الشبكة".
الخطوة 3. التحقق من التشفير: تأكد من أن السياسات المتعلقة بخوارزميات متوافقة مع FIPS لا تمنع الاتصال.
الخطوة 4. مزامنة السياسة: قم بمطابقة مستويات فرض مصادقة مستوى الشبكة (NLA) مع إمكانيات أجهزة العميل المصرح بها لديك.
إذا كانت المشكلة معزولة على جهاز محدد، قم بإجراء إعادة ضبط محلية.
الخطوة 1. مسح الإعدادات المخزنة مؤقتاً: احذف الملف المخفي Default.rdp الموجود في %userprofile%\Documents.
الخطوة 2. إعادة تعيين بيانات الاعتماد: افتح مدير بيانات اعتماد Windows وقم بإزالة أي إدخالات RDP محفوظة.
الخطوة 3. التحقق من جدار الحماية: تأكد من أن منفذ TCP 3389 مفتوح على جدران الحماية المحلية وأجهزة الشبكة الوسيطة.
الخطوة 4. الاختبار المتقاطع: حاول الاتصال من عميل مختلف على نفس الشبكة لتحديد ما إذا كانت المشكلة خاصة بالجهاز.
إذا كنت محجوزًا تمامًا من الوصول إلى خادم حاسم، يمكنك تعطيل NLA مؤقتًا لإجراء الإصلاحات.
الخطوة 1. الطرق: قم بتشغيل النظام في الوضع الآمن مع الشبكة أو استخدم وسائط الاسترداد لتحميل سجل النظام.
الخطوة 2. تعديل السجل: انتقل إلى:
الخطوة 3. تغيير القيمة: عيّن قيمة UserAuthentication إلى 0.
الخطوة 4. تحذير أمني: يعرّض هذا خادمك لهجمات القوة الغاشمة. أصلح السبب الجذري على الفور وأعد تمكين NLA (اضبط القيمة مرة أخرى إلى 1) في أسرع وقت ممكن.
إذا كنت قد سئمت من استكشاف أخطاء NLA وإصلاحها أو تحتاج إلى اتصال عاجل بخادم بعيد دون الخوض في تعديلات السجل أو نهج المجموعة، فإن AnyViewer هو بديل قوي ومستوى احترافي لسطح المكتب البعيد في Windows.
على عكس RDP الذي يعتمد بشكل كبير على بروتوكولات معقدة خاصة بـ Windows مثل CredSSP و NLA، يستخدم AnyViewer تقنية اتصال مُحسّنة خاصة به لتجاوز فشلات المصافحة الشائعة هذه مع الحفاظ على مستوى عالٍ من الأمان.
كيفية إعداد AnyViewer:
الخطوة 1. التنزيل والتثبيت: قم بتثبيت AnyViewer على كل من أجهزة Windows المحلية والبعيدة.
الخطوة 2. إنشاء حساب: سجل للحصول على حساب مجاني وقم بتسجيل الدخول على كلا الجهازين.
الخطوة 3. الاتصال: في علامة التبويب "الجهاز"، ابحث عن الكمبيوتر البعيد وانقر على "التحكم بنقرة واحدة" لإنشاء جلسة وصول عن بُعد غير خاضعة للإشراف.
باستخدام AnyViewer، يمكنك تجاوز أخطاء "RDP NLA Not Working" تمامًا والعودة إلى العمل في دقائق.
يمكن أن يكون التعامل مع أخطاء NLA مهمة معقدة تتضمن تكوينات نظام عميقة. بينما يعد إصلاح السبب الجذري، مثل عدم تطابق CredSSP أو مشكلات DNS، هو المسار الأفضل لصحة الخادم على المدى الطويل، فإن وجود نسخة احتياطية موثوقة مثل AnyViewer يضمن أن خطأ بروتوكول واحد لا يحرمك من الوصول إلى بنيتك التحتية الحرجة.
تذكر دائمًا إعادة تمكين ميزات الأمان بمجرد اكتمال استكشاف الأخطاء وإصلاحها للحفاظ على بيئة شبكتك قوية ومحمية.