The trust relationship failed في لاب الدومين؟ افهم Secure Channel قبل ما تفصل الجهاز وتضمه من جديد

تفتح جهاز تدريب كان شغال أمس، وتحاول الدخول بحساب الدومين، فتظهر رسالة أن علاقة الثقة بين الجهاز والدومين فشلت. أول حل تلقاه في كثير من الشروحات: افصل الجهاز من الدومين وأعد ضمه. قد يحل ذلك حالة معينة، لكنه لا يعلمك السبب، وقد يخفي اختلافًا في حالة اللاب أو مشكلة اتصال تحتاج تفهمها أولًا.
خلنا نراجع Secure Channel من زاوية تشخيصية: كيف تفرق حساب الكمبيوتر عن حساب المستخدم، وتستخدم Test-ComputerSecureChannel وقراءة nltest ضمن حدودها، وتوثق نتيجة لها معنى. الأمثلة في مختبر lab.test على جهاز عضو اسمه CLIENT01، ولا تتضمن إعادة ضبط علاقة الثقة أو تغيير كلمة مرور حساب الكمبيوتر.

الجهاز له هوية في الدومين، مب مجرد اسم في قائمة

لما ينضم جهاز إلى الدومين، يوجد له حساب كمبيوتر في الدليل. تسجيله ليس مجرد جرد للأصول؛ هو جزء من هوية الجهاز وعلاقته بالبيئة. لهذا لا يكفي أن ترى CLIENT01 في Get-ADComputer ثم تقول إن الثقة تعمل الآن. وجود الكائن وإمكانية الوصول الشبكي وصحة العلاقة الحالية ثلاث ملاحظات مختلفة.
حساب المستخدم أيضًا مستقل عن حساب الجهاز. قد تكون بيانات المستخدم صحيحة، لكن الجهاز الذي يحاول استخدامها عنده مشكلة في علاقته بالدومين. وفي حالة أخرى، قد تكون علاقة الجهاز سليمة لكن المستخدم معطل أو غير مسموح له بطريقة الدخول. الخلط بينهما يجعل كل رسالة مصادقة تبدو مشكلة كلمة مرور واحدة.
المراجعة تبدأ بسؤال: أي علاقة نحاول اختبارها؟ في هذا المثال نتكلم عن جهاز عضو وعلاقته بدومينه، لا Trust بين دومينين، ولا جلسة تطبيق ولا شهادة خادم. تشابه كلمة Trust في أسماء المواضيع لا يجعلها نفس الإعداد أو نفس الأداة. سجل نوع الجهاز والدومين والعملية التي فشلت قبل اختيار أمر تشخيص.
في لاب متعدد الأجهزة، أضف سؤالًا عن الحالة: هل رجعت Snapshot لجهاز واحد؟ هل استبدلت كائن الكمبيوتر؟ هل تغيرت شبكة اللاب؟ هذه احتمالات تحتاج تحققًا، وليست أسبابًا تثبت من الرسالة وحدها. لا تكتب أن Snapshot هو السبب لأن الفشل ظهر بعده، ما لم تربط التغير بحالة الدليل والجهاز التي يراجعها صاحب المختبر.

ابدأ من الجهاز الحالي ووجهة الدومين

على CLIENT01 سجّل hostname والهوية الحالية وطريقة وصولك للجلسة. إذا كنت داخل جلسة محلية لأغراض تشخيص مصرح، فهذا لا يثبت أن الدخول بالدومين نجح. اكتب ذلك واضحًا بدل أن تعرض لقطة Terminal توحي بأنك داخل نفس سياق المستخدم الذي فشل.
راجع اسم الدومين الذي يفترض أن الجهاز عضو فيه، وخادم DNS المعتمد في شبكة التدريب، وتحليل اسم وحدة التحكم. نجاح الإنترنت لا يثبت أن الجهاز يجد خدمات الدومين. كما أن عنوان IP محفوظًا من جلسة سابقة قد يتغير مع إعدادات شبكة اللاب؛ اعتمد على الجرد والقراءة الحالية.
قراءة مثل Resolve-DnsName dc01.lab.test تساعد في سؤال الاسم، لكنها لا تفحص الثقة. وإذا كان الاسم لا يصل إلى الوجهة الصحيحة، أصلح فهم الاتصال قبل الانتقال لتفسير فشل قناة آمنة. لا تضف حساب مستخدم إلى مجموعة إدارية لمعالجة اسم لا يُحل أو شبكة معزولة عن الدومين.
احتفظ بآخر تغيير معروف من سجل مختبرك: تشغيل أو رجوع حالة أو نقل شبكة أو تغيير إعداد. إذا لم تعرف، اكتب أنك لا تعرف. هذه الصراحة أفضل من قائمة احتمالات طويلة تعرضها كوقائع. هدف المرحلة الأولى بناء سياق تستطيع مقارنة نتائج التشخيص به، وليس الوصول إلى أسرع أمر يعيد تسجيل الدخول.

Test-ComputerSecureChannel: اقرأ True وFalse ضمن نطاقها

توضح Microsoft أن Test-ComputerSecureChannel يفحص قناة الجهاز المحلي مع دومينه، ويعيد True عند عملها وFalse عندما لا تعمل وفق الاختبار. خيار Verbose يعطي تفاصيل إضافية. مثال على جهاز عضو في مختبرك: Test-ComputerSecureChannel -Verbose. اقرأ الرسالة والهوية والوقت مع القيمة، ولا تحفظ True وحدها خارج سياقها.
يمكن تحديد وحدة تحكم مفضلة للاختبار باستخدام -Server، مثل Test-ComputerSecureChannel -Server dc01.lab.test -Verbose. هذا لا يعني أنك تختبر حساب الكمبيوتر DC01 من جهازك؛ المقصود قناة الجهاز المحلي مع الوجهة المختارة. اسم Server في الأمر يحدد الطرف البعيد، بينما الجهاز الذي تنفذ عليه يبقى طرف الفحص المحلي.
القيد المهم في المرجع أن الأداة تعمل على Domain Member computers، وتعيد أخطاء مضللة إذا استخدمت على Domain Controllers. لذلك لا تحول False على DC إلى حكم أن علاقة الدومين كلها مكسورة. اختر أداة وإجراء تشخيص يناسب دور الجهاز، ولا تعمم مثال عميل على وحدة التحكم.
الأمثلة هنا بدون Repair. فحص الحالة والتغيير عمليتان مختلفتان، حتى لو جمعتهما نفس الأداة. إذا قرأت شرحًا يستخدم الإصلاح مباشرة، افهم أثره ومتطلباته ضمن خطة صاحب البيئة قبل تنفيذ أي شيء. خلال مراجعة القراءة، نحن نريد نعرف ما الحالة وما الدليل، لا أن نغيرها ثم نخسر فرصة تفسير أصل الفشل.

nltest: فرق بين اكتشاف DC وقراءة حالة قناة سابقة

قد تجد في الشروحات nltest /dsgetdc:lab.test وnltest /sc_query:lab.test متجاورين، لكنهما لا يجاوبان نفس السؤال. المرجع يصف dsgetdc كبحث عن وحدات التحكم عبر DNS مع اتصال للتحقق، بينما sc_query يقرأ حالة القناة في آخر استخدام لها ويعرض الوحدة المرتبطة. لا تعرض الثاني كاختبار جديد شامل لمجرد أن اسمه Query.
استخدم القراءة الأولى لفهم وجهة اكتشاف الدومين في المختبر، والثانية كسياق لحالة NetLogon المقروءة. إذا كانت المعلومة من استخدام سابق، راعِ وقتها وحدودها. لا تعتبر اسم DC الذي ظهر ضمانًا أن كل اتصالات الجهاز اليوم تمر به أو أن كل خدماته متاحة.
انتبه خصوصًا لخيار يحمل كلمة Verify في بعض الشروحات: توثيق nltest يذكر أن sc_verify يمكن أن يعيد بناء قناة لا تعمل. لهذا لا تختاره كبديل «قراءة فقط» بلا فهم. أسماء الخيارات ليست ضمانًا لطبيعة الأثر، والرجوع للمرجع أهم من الانطباع الذي يتركه الاسم.
إذا تعارضت قراءة nltest مع اختبار PowerShell، لا تبدأ بإعادة الضبط. قارن أولًا ما الذي قاسه كل أمر، وعلى أي جهاز، وضد أي دومين، وفي أي وقت. أداة تعرض حالة سابقة وأداة تختبر حاليًا قد لا تكونان متناقضتين. تفسير حدود النتائج هو الذي يجعل المقارنة مفيدة بدل أن تصبح سببًا لتجربة خيارات إضافية عشوائية.

False ما يشرح السبب كله، وTrue ما يثبت كل التطبيق

نتيجة False تقول إن الاختبار لم ير القناة تعمل كما ينبغي في تلك الحالة، لكنها لا تسمي سببًا واحدًا دائمًا. قد تحتاج مراجعة الاتصال وخدمة مناسبة وحالة الحساب والتغيرات الأخيرة مع فريق الدليل. الرسالة المفصلة ومصدر الفشل يساعدان في ترتيب الفرضيات؛ الرقم وحده لا يكفي.
وبالمقابل، True لا تثبت أن مستخدمًا معينًا مسموح له دخول RDP أو قراءة مشاركة أو فتح قاعدة بيانات. هذه عمليات تحتاج حقوقًا وسياقات مختلفة. إذا كانت القناة سليمة والتطبيق ما زال يرفض، انتقل للطبقة التي تخص التطبيق بدل تكرار فحص الثقة عشر مرات.
خلنا نفترض أن trainee01 لا يدخل عبر RDP إلى APP01، لكن اختبار قناة APP01 ناجح. هنا تحتاج مراجعة إعداد الدخول والعضويات والسياسات المناسبة ضمن تصريحك. لا تكتب أن القناة «نجحت إذن كلمة المرور خاطئة»؛ قد توجد أسباب أخرى. استخدم النجاح لاستبعاد جزء من الاحتمالات، لا لإثبات احتمال وحيد لم تختبره.
الطريقة المهنية في الملاحظات: «اختبار قناة الجهاز العضو ناجح ضد DC01 في الوقت المحدد؛ رفض الدخول البعيد ما زال يحتاج مراجعة مستقلة». أو «الاختبار لم ينجح، والاتصال الأساسي لم يُحسم بعد». هذه صياغة تساعد الخطوة التالية، وتمنعك من عرض قيمة تقنية صغيرة كحكم على كل حالة المصادقة.

سيناريو لاب: رجعت العميل وبقي الدومين في حالة أحدث

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

ليش إعادة الانضمام السريعة قد تخفي معلومات تحتاجها؟

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

تمرين مقارنة بدون إفساد العلاقة

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

ماذا تسلم بعد التشخيص؟

التسليم المختصر يتضمن دور الجهاز، والدومين، ووحدة التحكم المختبرة، وظروف الوصول، ونتيجة القراءة والرسالة المفيدة، وآخر تغير معروف. أرفق جزءًا محدودًا من المخرجات يكفي للمراجعة. لا تحتاج نشر جرد الدومين كاملًا أو تفاصيل حسابات لا تخص CLIENT01.
افصل الاستنتاج عن الفرضية. «اختبار القناة فشل» ملاحظة، و«رجوع حالة غير منسقة هو السبب» تفسير يحتاج دعمًا. إذا لم يُحسم السبب، ضع الخطوة المطلوبة من فريق الدليل بوضوح. نقص الدليل ليس عيبًا يعالج بعبارة واثقة؛ هو حد يجب أن يعرفه من يقرر الإصلاح.
في إعادة الفحص استخدم نفس الظروف الأساسية عندما تستطيع، وسجل أي اختلاف مثل DC آخر أو شبكة مختلفة. إذا كان التغيير متعدد الخطوات، لا تنسب النجاح لخطوة واحدة بلا قياس. وراجع العملية الأصلية التي تهم المستخدم، لا تختبر فقط الأمر الذي صار يعيد True.
هذا الموضوع يفيد طالب CRTP أو CRTE لأنه يدربه على فصل حالة اللاب عن مفهوم الصلاحيات، ويفيد المختبر في العمل لأنه يمنعه من اعتبار كل رفض دخول مشكلة حساب مستخدم. افهم العلاقة المقصودة، اختر قراءة تناسب دور الجهاز، وفسر النتيجة داخل نطاقها قبل أن تفكر في تغيير.
المراجع الرسمية: Test-ComputerSecureChannel https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel?view=powershell-5.1 وnltest https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11) . طابق المساعدة المحلية والمرجع مع إصدار أدواتك؛ الأمثلة هنا لفحص عضو الدومين وقراءة السياق، وليست تعليمات إعادة ضبط أو إصلاح عام.