فشل ثقة النطاق بعد شهر دون اتصال؟ افحص أولاً

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

الخطأ يبدو كخطأ ثقة، لكن ثلاث حالات تتشابه

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

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

الافتراضي المألوف البالغ 30 يوماً سياسة تغيير، لا موعداً نهائياً للانتهاء أثناء عدم الاتصال. ويصف شرح Microsoft لكلمة مرور حساب الجهاز عملية تغيير منسقة، ويمكن للمؤسسة تكوين فاصل مختلف.

أيقونة VPN لا تثبت شيئاً عن القناة الآمنة

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

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

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

سجّل خادم DNS، ووحدة التحكم التي تم تحليلها، ونص الخطأ الدقيق. عميل VPN يقول إنه متصل يخبرك أن النفق موجود، لا أن مسار النطاق يعمل. وحدة تحكم تستجيب على منفذ Kerberos ولكن ليس على منفذ الدليل هي نتيجة جدار حماية، لا نتيجة ثقة.

اختبر العضو قبل إصلاحه

على عضو نطاق Windows مصرّح به، يُعد Test-ComputerSecureChannel -Verbose فحصاً للقراءة فقط للقناة بين الجهاز والنطاق. شغّله في سياق الجهاز الذي تفحصه، لا من وحدة تحكم نطاق، لأن لها دوراً مختلفاً وقواعد استرداد مختلفة. التقط المخرجات وحالة الخروج بدلاً من كلمة نجاح أو فشل. وإذا كان الأمر مفقوداً في ذلك الإصدار، فالوحدة مشكلة منفصلة.

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

اربط أحداث Netlogon على العضو وعلى وحدة التحكم المعنية حول الحادث. احفظ اسم الجهاز وعنوان المصدر والوقت وأي دليل على تغيير الحساب. نجاح مستخدم آخر في تسجيل الدخول، أو لوحة تحكم سليمة، لا يمكن أن يحل محل تبادل هذا الجهاز.

أصلح فقط العلاقة التي أثبتها

بمجرد أن يصبح الاتصال مستقراً ويؤكد مسؤول أن الإصلاح مناسب، فإن وضع -Repair في الأمر مع بيانات اعتماد مصرّح بها هو عملية مدعومة واحدة لمحطة عمل عضو. فهو يغيّر العلاقة، وليس اختباراً آخر للقراءة فقط.

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

بعد الإصلاح، تحقق من اختبار جديد للقناة الآمنة ومن عملية النطاق الأصلية. حافظ على ملفات تعريف المستخدمين وحالة التطبيقات، ولا تجعل الإزالة وإعادة الانضمام أول إجراء غير مفسر.

ما يجب فحصه عندما يعود الفشل

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

إعادة التعيين الناجحة المؤقتة دليل استرداد مفيد، لكنها ليست دليلاً على أن شبكة VPN متقطعة تسببت في عدم التطابق الأصلي. الحادثة التالية هي التي تخبرك ما إذا كان السبب قد أُزيل فعلاً.

اكتب وحدة التحكم وخادم DNS ومخرجات الاختبار في التذكرة. فهذا السجل هو ما يميز فشل ثقة حقيقياً عن حاسوب محمول لم يستطع ببساطة العثور على النطاق.