دليل استكشاف الأخطاء وإصلاحها الشامل لعدم عمل RDP NLA

عند إدارة خوادم Windows أو الاتصال بمحطة عمل بعيدة، قد تواجه رسالة خطأ محبطة: "يتطلب الكمبيوتر البعيد مصادقة مستوى الشبكة (NLA)." حتى عندما تبدو إعداداتك صحيحة، فإن اكتشاف أن بروتوكول RDP مع NLA لا يعمل رغم تفعيل NLA يمكن أن يوقف إنتاجيتك ويمنع الوصول الحرج.

يستكشف هذا الدليل الأسباب الجذرية لفشل NLA ويقدم حلولًا خطوة بخطوة لاستعادة اتصال سطح المكتب البعيد الخاص بك.

ما هي مصادقة مستوى الشبكة (NLA)؟

مصادقة مستوى الشبكة (NLA) هي طريقة أمان تُنهي مصادقة المستخدم قبل إنشاء جلسة سطح مكتب بعيد كاملة وظهور شاشة تسجيل الدخول.

• الأمان: تحمي الكمبيوتر البعيد من هجمات حجب الخدمة (DoS) وتقلل من خطر الوصول غير المصرح به.
• الكفاءة: تستخدم موارد أقل من خلال مصادقة المستخدم قبل إنشاء جلسة كاملة.
• التعارض: رغم أنها آمنة للغاية، إلا أنها تتطلب أن يكون لدى كل من العميل والخادم بروتوكولات أمان متطابقة (تحديدًا CredSSP).

الأسباب الشائعة لـ "عدم عمل RDP مع NLA"

يمكن لعدة عوامل أن تسبب فشل الاتصال هذا، تتراوح من تحديثات الأمان إلى إعدادات الشبكة الخاطئة:

• عدم تطابق بروتوكول CredSSP: غالبًا ما يسببه تحديث الأمان "Encryption Oracle Remediation" (CVE-2018-0886).
• اتصال وحدة تحكم المجال: لا يستطيع العميل أو الخادم الوصول إلى Active Directory للتحقق من بيانات الاعتماد.
• شهادات RDP التالفة: انتهت صلاحية الشهادة الموقعة ذاتيًا التي يستخدمها خدمة سطح المكتب البعيد أو بها خلل.
• إعدادات نهج المجموعة غير الصحيحة: قد يتم فرض NLA على الخادم، لكن لا يتم دعمها أو تمكينها على العميل.
• مشكلات DNS: فشل في حل اسم المضيف بشكل صحيح مما يمنع عملية مصافحة المصادقة.

كيفية إصلاح عدم عمل RDP مع NLA [7 حلول]

إذا كنت تواجه أخطاء في مصادقة مستوى الشبكة (NLA)، فاتبع هذه الإصلاحات بالترتيب. تساعد هذه المنهجيات المنظمة في استعادة الوصول مع الحفاظ على أمان النظام.

الإصلاح 1: تأكيد دعم NLA على العميل والخادم

أولاً، تأكد من أن كلا الطرفين قادران تقنيًا على التعامل مع NLA.

الخطوة 1. التحقق من إصدار نظام التشغيل: نفّذ الأمر winver على كلا الجهازين للتأكد من أنهما يعملان بنظام Windows Vista / Windows Server 2008 أو إصدار أحدث.

الخطوة 2. تحديث العملاء: تأكد من تثبيت أحدث تحديثات عميل سطح المكتب البعيد عبر Windows Update أو تطبيق Microsoft Remote Desktop الرسمي.

الخطوة 3. التطبيقات الخارجية: إذا كنت تستخدم عملاء RDP غير تابعين لنظام Windows، تحقق من تمكين دعم NLA صراحةً في الإعدادات.

الخطوة 4. خطة الترقية: إذا كان أحد المكونات لا يدعم NLA، خطط للترقية بدلاً من خفض مستوى الأمان بشكل دائم.

الإصلاح 2: التحقق من الاتصال بوحدة تحكم النطاق

بالنسبة للأجهزة المنضمة إلى النطاق، غالبًا ما يتسبب الاتصال المعطّل بـ Active Directory (AD) في فشل NLA.

الخطوة 1. اختبار إمكانية الوصول: استخدم الأمر ping dc01.yourdomain.com للتحقق من المسار الشبكي إلى وحدة تحكم النطاق الخاصة بك.

الخطوة 2. تحديد موقع وحدة التحكم: نفّذ الأمر nltest /dsgetdc:yourdomain.com للتأكد من قدرة العميل على اكتشاف وحدة تحكم.

الخطوة 3. فحص القناة الآمنة: نفّذ PowerShell كمسؤول وأدخل:

• Test-ComputerSecureChannel

الخطوة 4. إصلاح الثقة: إذا كانت النتيجة False، أصلح القناة الآمنة باستخدام:

• Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

الخطوة 5. إعادة التشغيل: أعد تشغيل الجهاز بعد الإصلاح إذا طُلب منك ذلك.

الإصلاح 3: محاذاة مستويات تحديثات CredSSP والسياسات

عدم تطابق تحديثات CredSSP بين العميل والخادم هو السبب الأكثر شيوعًا لخطأ "معالجة أوراكل التشفير".

الخطوة 1. تثبيت التحديثات: تأكد من تثبيت جميع تحديثات الأمان التراكمية على كلا الطرفين.

الخطوة 2. تكوين سياسة المجموعة: افتح gpedit.msc وانتقل إلى:

• تكوين الكمبيوتر > القوالب الإدارية > النظام > تفويض بيانات الاعتماد.

الخطوة 3. ضبط المعالجة: انقر نقرًا مزدوجًا على معالجة أوراكل التشفير. عيّنها على ممكّن وللاختبار المؤقت، عيّن مستوى الحماية على عرضة للخطر.

الخطوة 4. الإصلاح طويل الأمد: بمجرد استعادة الاتصال، قم بإعطاء الأولية لتحديث جميع الأنظمة إلى مستوى ثابت وإعادة السياسة إلى "تم التخفيف".

الإصلاح 4: تمكين والتحقق من بروتوكولات TLS المطلوبة

تعتمد مصادقة مستوى الشبكة (NLA) على بروتوكولات أمنية حديثة. إذا كان TLS 1.2 معطلاً، فسيفشل مصافحة الاتصال.

الخطوة 1. التحقق من السجل: انتقل إلى المسار التالي في محرر السجل:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

الخطوة 2. تمكين المفتاح: تأكد من ضبط قيمة DWORD المسماة "Enabled" على 1.

الخطوة 3. مفاتيح الخادم: تحقق من إعدادات مماثلة في المفتاح الفرعي "Server" تحت نفس المسار.

الخطوة 4. فحص الشهادة: تأكد من أن شهادة RDP سارية وليست مستخدمة لتوقيعات قديمة. أعد تشغيل خدمة "Remote Desktop Services" في services.msc لتحديث الشهادة.

الإصلاح 5: مراجعة وتعديل إعدادات نهج المجموعة

قد تفرض كائنات نهج المجموعة (GPOs) مصادقة مستوى الشبكة (NLA) بطريقة تتعارض مع بيئتك المحددة.

الخطوة 1. نهج الأمان المحلي: افتح gpedit.msc وانتقل إلى:

• تكوين الكمبيوتر > إعدادات Windows > إعدادات الأمان > السياسات المحلية > خيارات الأمان.

الخطوة 2. تدقيق التنفيذ: تحقق من السياسة "تطلب مصادقة المستخدم للاتصالات البعيدة باستخدام مصادقة مستوى الشبكة".

الخطوة 3. التحقق من التشفير: تأكد من أن السياسات المتعلقة بخوارزميات متوافقة مع FIPS لا تمنع الاتصال.

الخطوة 4. مزامنة السياسة: قم بمطابقة مستويات فرض مصادقة مستوى الشبكة (NLA) مع إمكانيات أجهزة العميل المصرح بها لديك.

الإصلاح 6: إعادة ضبط تكوين عميل RDP والشبكة

إذا كانت المشكلة معزولة على جهاز محدد، قم بإجراء إعادة ضبط محلية.

الخطوة 1. مسح الإعدادات المخزنة مؤقتاً: احذف الملف المخفي Default.rdp الموجود في %userprofile%\Documents.

الخطوة 2. إعادة تعيين بيانات الاعتماد: افتح مدير بيانات اعتماد Windows وقم بإزالة أي إدخالات RDP محفوظة.

الخطوة 3. التحقق من جدار الحماية: تأكد من أن منفذ TCP 3389 مفتوح على جدران الحماية المحلية وأجهزة الشبكة الوسيطة.

الخطوة 4. الاختبار المتقاطع: حاول الاتصال من عميل مختلف على نفس الشبكة لتحديد ما إذا كانت المشكلة خاصة بالجهاز.

الإصلاح 7: تعطيل NLA مؤقتًا لاستعادة الوصول

إذا كنت محجوزًا تمامًا من الوصول إلى خادم حاسم، يمكنك تعطيل NLA مؤقتًا لإجراء الإصلاحات.

الخطوة 1. الطرق: قم بتشغيل النظام في الوضع الآمن مع الشبكة أو استخدم وسائط الاسترداد لتحميل سجل النظام.

الخطوة 2. تعديل السجل: انتقل إلى:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

الخطوة 3. تغيير القيمة: عيّن قيمة UserAuthentication إلى 0.

الخطوة 4. تحذير أمني: يعرّض هذا خادمك لهجمات القوة الغاشمة. أصلح السبب الجذري على الفور وأعد تمكين NLA (اضبط القيمة مرة أخرى إلى 1) في أسرع وقت ممكن.

نصيحة إضافية: استخدم AnyViewer كبديل موثوق لـ RDP

إذا كنت قد سئمت من استكشاف أخطاء NLA وإصلاحها أو تحتاج إلى اتصال عاجل بخادم بعيد دون الخوض في تعديلات السجل أو نهج المجموعة، فإن AnyViewer هو بديل قوي ومستوى احترافي لسطح المكتب البعيد في Windows.

على عكس RDP الذي يعتمد بشكل كبير على بروتوكولات معقدة خاصة بـ Windows مثل CredSSP و NLA، يستخدم AnyViewer تقنية اتصال مُحسّنة خاصة به لتجاوز فشلات المصافحة الشائعة هذه مع الحفاظ على مستوى عالٍ من الأمان.

• سبب نجاحه: لا يتطلب AnyViewer تكوين NLA على الجهاز المضيف. يستخدم تشفير منحنى إهليلجي (ECC) لحماية بياناتك من طرف إلى طرف، مما يضمن الأمان دون متاعب تكوين RDP.
• سهولة الاستخدام: يعمل عبر شبكات مختلفة (بما في ذلك عبر الإنترنت) دون الحاجة إلى إعادة توجيه المنافذ أو شبكات VPN.
• الأداء: يوفر نقل ملفات عالي السرعة وتحكمًا عن بُعد منخفض الكمون، مما يجعله مثاليًا لكل من دعم تقنية المعلومات والعمل عن بُعد.

كيفية إعداد AnyViewer:

الخطوة 1. التنزيل والتثبيت: قم بتثبيت AnyViewer على كل من أجهزة Windows المحلية والبعيدة.

الخطوة 2. إنشاء حساب: سجل للحصول على حساب مجاني وقم بتسجيل الدخول على كلا الجهازين.

الخطوة 3. الاتصال: في علامة التبويب "الجهاز"، ابحث عن الكمبيوتر البعيد وانقر على "التحكم بنقرة واحدة" لإنشاء جلسة وصول عن بُعد غير خاضعة للإشراف.

باستخدام AnyViewer، يمكنك تجاوز أخطاء "RDP NLA Not Working" تمامًا والعودة إلى العمل في دقائق.

الخلاصة

يمكن أن يكون التعامل مع أخطاء NLA مهمة معقدة تتضمن تكوينات نظام عميقة. بينما يعد إصلاح السبب الجذري، مثل عدم تطابق CredSSP أو مشكلات DNS، هو المسار الأفضل لصحة الخادم على المدى الطويل، فإن وجود نسخة احتياطية موثوقة مثل AnyViewer يضمن أن خطأ بروتوكول واحد لا يحرمك من الوصول إلى بنيتك التحتية الحرجة.

تذكر دائمًا إعادة تمكين ميزات الأمان بمجرد اكتمال استكشاف الأخطاء وإصلاحها للحفاظ على بيئة شبكتك قوية ومحمية.

الأسئلة الشائعة