الحساب صحيح لكن أدوات Active Directory تفشل: شخّص DNS والمنفذ وADWS وثقة الجهاز بالترتيب

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

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

ابدأ من الأعراض، ولا تجمعها تحت عنوان «الدومين ما يعمل»

اكتب العملية التي فشلت حرفيًا: اسم الأداة، والهدف الذي طلبته، ونوع القراءة، ورسالة الخطأ المنقحة، والحساب ووقت المحاولة. كلمة «يفشل» ما تكفي. أداة لا تتعرف على الأمر تختلف عن أداة تعرفه لكن لا تجد خادمًا، وهذه تختلف عن أداة تتصل بخادم ثم ترفض عملية. كل حالة تبدأ في طبقة مختلفة. لو تجاهلت الفرق، ممكن تعالج شبكة بينما المشكلة أن الوحدة غير متاحة في جلسة PowerShell الحالية.

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

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

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

Resolve-DnsName: هل الاسم يوصلك إلى الهدف المقصود؟

في جهاز اللاب، استخدم Resolve-DnsName dc01.lab.test -Type A لقراءة سجل IPv4 للاسم المحدد. هذه بداية لمعرفة هل الاسم يحل وما العنوان الذي يرجع في السياق الحالي. قارن العنوان بتعريف اللاب، لا بعنوان من شرح خارجي. نجاح القراءة لا يثبت أن الجهاز الذي يرد صحيح من ناحية الهوية أو أن خدمة Active Directory المطلوبة تعمل عليه. لكنه يزيل سؤالًا مبكرًا عن حل الاسم قبل الانتقال إلى الاتصال.

إذا كانت الأداة تحتاج اكتشاف خدمة الدومين، فهناك سؤال آخر عن سجلات SRV، مثل Resolve-DnsName _ldap._tcp.dc._msdcs.lab.test -Type SRV في هذا اللاب. لا تخلط سجل اسم المضيف بقائمة اكتشاف وحدات التحكم. قد تعرف عنوان dc01 مباشرة بينما اكتشاف الدومين في جلسة معينة يحتاج قراءة أخرى. راجع الأسماء التي تعيدها النتيجة وتأكد أنها تتبع البيئة المقصودة، ثم ارجع إلى حل اسم الخادم المختار.

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

Test-NetConnection: الاتصال ليس المصادقة

بعد تثبيت الهدف، راجع منفذًا يناسب الخدمة التي تختبرها. مثال قراءة مصرح بها: Test-NetConnection dc01.lab.test -Port 9389 . مايكروسوفت توثق 9389/TCP لخدمة Active Directory Web Services، وهي مختلفة عن LDAP على 389. فإذا كان سؤالنا عن مسار أداة يعتمد على ADWS، نجاح اختبار 389 وحده لا يجيب عنه. لا تحول كل أسماء الأدوات المتعلقة بالدومين إلى بروتوكول واحد لمجرد أنها تعرض مستخدمين ومجموعات.

في الناتج، ركز على الهدف والعنوان المستخدم وTcpTestSucceeded. إذا رجع True، فهذا يدعم نجاح محاولة الاتصال TCP بذلك العنوان والمنفذ من جهازك، ولا يؤكد أن طلبًا لاحقًا سيُقبل أو أن الحساب يملك حق القراءة. وإذا رجع False، فهناك سؤال اتصال يحتاج تشخيصًا، لكنه لا يخبرك وحده هل السبب خدمة متوقفة أو مسار شبكة أو سياسة منع أو شيء آخر. استخدم سجلات وإعدادات مصرحًا بها لتحديد السبب بدل تسمية أي فشل «Firewall».

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

Get-ADRootDSE: تأكد من الخادم والسياق الذي تقرؤه

إذا وحدة ActiveDirectory متاحة وتملك وصول القراءة المطلوب، يمكن استخدام Get-ADRootDSE -Server dc01.lab.test | Select-Object dnsHostName,defaultNamingContext,configurationNamingContext . هذه قراءة لمعلومات جذر شجرة الدليل على الخادم المحدد، مثل سياقات التسمية واسم المضيف. الأسماء في المثال تخص لابنا؛ لا تتوقع نفس القيم عندك. اقرأ ما عاد فعلًا وقارنه بتعريف بيئتك، خصوصًا إذا كان لديك أكثر من دومين أو أكثر من لاب.

فائدة القراءة أنها تثبت أنك لا تكتفي بعنوان خادم تعرف اسمه، بل تراجع معلومات من خدمة الدليل. نجاحها لا يثبت أن كل استعلام لاحق سيعيد كل كائن، ولا أن كل أنواع الجمع المحلية ستعمل. لكنه يساعدك تحدد سياق البحث الصحيح. لو استعلامك اللاحق يستخدم SearchBase من دومين آخر أو OU غير موجودة في هذا السياق، فقد يفشل أو يعطي نتيجة مختلفة من دون أن تكون كلمة المرور هي المشكلة.

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

klist: راجع ما في الجلسة من دون مسحها أثناء التشخيص

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

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

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

ثقة الجهاز: متى تسأل عنها ومتى ما تستخدم نفس الاختبار؟

على محطة Domain Member، Test-ComputerSecureChannel -Verbose يراجع القناة الآمنة بين الجهاز ودومينه وفق توثيق Windows PowerShell. شغّل القراءة في السياق الإداري المسموح المطلوب لها، وسجل ذلك بوضوح. الأمر له خيار إصلاح، لكننا لا نستخدم -Repair في هذا التمرين. التفريق مهم: اختبار الحالة خطوة تشخيص، بينما إعادة بناء القناة تغيير يحتاج خطة ومعرفة سبب المشكلة ووظيفة الجهاز.

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

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

ثلاث نتائج متشابهة في الشكل، مختلفة في السبب

الحالة الأولى داخل اللاب: حل dc01.lab.test يرجع عنوان VM قديمة بعد تغيير معروف في الإعداد. فشل القراءة اللاحقة هنا يبدأ من الهدف غير المقصود؛ لا نغير كلمة مرور المستخدم. الحالة الثانية: الاسم صحيح، واختبار 389 ينجح، لكن 9389 لا يقبل اتصالًا، والأداة المقصودة تحتاج مسار ADWS. الخطوة التالية مراجعة الخدمة والمسار وفق تصريح اللاب، لا إعلان أن LDAP لا يعمل أو أن الدومين كله متعطل.

الحالة الثالثة: الاتصال والقراءة العامة ينجحان، لكن استعلامًا بقاعدة بحث محددة يرجع فارغًا. نطابق سياق التسمية وSearchBase والكائن المتوقع، ونراجع هل البيانات موجودة أصلًا ضمن النطاق. هذه الحالة تختلف عنرفض مصادقة، وتختلف عن أمر غير معروف. لا تجمعها تحت جملة واحدة لأن نتيجتها كلها «ما طلعت بيانات». وصف الطبقة التي توقفت عندها يعطيك قراءة تالية منطقية، ويمنعك تكرر تحقق كلمة المرور في كل مرحلة.

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

كيف تكتب تشخيصًا يصلح للمراجعة؟

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

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

المراجع: Resolve-DnsName https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname ، وTest-NetConnection https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection ، وGet-ADRootDSE https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adrootdse ، وklist https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist ، وTest-ComputerSecureChannel https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel ، ومتطلبات منافذ AD https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/config-firewall-for-ad-domains-and-trusts . استخدمها لمطابقة دور الجهاز ونسخة الأداة، لا لتحويل كل منفذ مذكور إلى طلب فتح عام.