شرح ldapsearch مع Active Directory: ابحث من لينكس وافهم ليش النتيجة ناقصة أو فاضية

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

وش تسوي الأداة فعلًا؟

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

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

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

جهّز اللاب قبل ما تدخل كلمة المرور

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

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

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

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

أول استعلام: ستة أجزاء، وكل جزء له وظيفة

الأمر التالي مثال لقراءة أسماء المستخدمين وأسماء العرض داخل OU التدريب، عبر اتصال LDAPS مجهز وموثوق:

ldapsearch -LLL -x -H ldaps://dc01.lab.test -D 'CN=Student,OU=Training,DC=lab,DC=test' -W -b 'OU=Training,DC=lab,DC=test' -s sub '(&(objectCategory=person)(objectClass=user))' sAMAccountName displayName

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

-x يختار المصادقة البسيطة بدل SASL، ولذلك ربطناه هنا بقناة TLS صحيحة. هذا اختيار تعليمي محدد، وليس توصية بتغيير أسلوب المصادقة الذي تعتمد عليه مؤسستك. قد يكون المطلوب عندكم أسلوبًا آخر، وعندها ارجع لإعداد العميل والسياسة المعتمدة بدل تعديل حماية الخادم لتناسب أمرًا من الإنترنت.

-b يحدد نقطة بداية البحث، و-s sub يشمل هذه النقطة وما تحتها. الفلتر داخل الأقواس يحدد نوع الكائنات التي نريدها. وفي آخر الأمر سمّينا خاصيتين نحتاج قراءتهما. -LLL يقلل التعليقات وبعض تفاصيل تنسيق الإخراج، لكنه ما يغير صلاحيات الحساب ولا يحول البحث إلى اختبار ثغرة.

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

الفرق بين عنوان الخادم وBind DN وSearch Base

هذي ثلاثة أشياء مختلفة وغالبًا تنخلط. dc01.lab.test عنوان الخادم الذي نتصل به. CN=Student,OU=Training,DC=lab,DC=test يصف موقع كائن الحساب الذي نصادق به. OU=Training,DC=lab,DC=test يصف المكان الذي نبدأ البحث داخله. ما يشترط أن يكون حساب المصادقة في المكان نفسه الذي تقرأ منه، بشرط أن تغطي الصلاحيات والتصريح هذه القراءة.

DN اختصار Distinguished Name، أي الاسم المميز للكائن في الدليل. المثال يقرأ من الجزء الأقرب للكائن باتجاه أجزاء الدومين. واسم CN مو لازم يساوي sAMAccountName حرفيًا. ممكن يكون اسم تسجيل الدخول student.lab بينما اسم الكائن Student Lab. وقتها نسخ اسم الدخول مكان CN قد يعطيك اسمًا غير صحيح، رغم أنك تعرف الحساب وكلمة مروره.

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

ونقطة مهمة: OU اسم لنوع من الحاويات التنظيمية، لكن مو كل حاوية اسمها Users أو Computers تبدأ بـ OU. بعض الحاويات تستخدم CN. تعامل مع DN الفعلي، ولا تحول كل اسم مجلد تشوفه في الواجهة إلى OU من عندك. هذا خطأ صغير في الكتابة، لكنه كفيل بأن يخليك تبحث في مكان غير موجود ثم تتهم الأداة.

base أو one أو sub؟ المثال اللي يوضح الفرق

تخيل أن Training تحتوي حسابًا تجريبيًا مباشرًا اسمه Saleh، وتحتها OU فرعية اسمها Students فيها حساب Noura. إذا بدأت من Training واخترت one، تبحث في مستوى الأبناء المباشرين؛ تتوقع رؤية Saleh، وقد ترى كائن الحاوية بحسب الفلتر، لكنك ما تبحث داخل Students عن Noura. أما sub فيشمل الشجرة تحت نقطة البداية، ولذلك يمكن أن يشمل الحسابين.

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

جرب في اللاب تبديل -s sub إلى -s one فقط، وخلك محافظًا على بقية الأمر. سجل الفرق قبل الانتقال لأي تغيير آخر. بعده اختبر base على DN حساب تدريبي معروف، مع فلتر يناسبه. بهالطريقة تتعلم النطاق من تجربة قابلة للتفسير، بدل تغيير خمسة خيارات ثم عدم معرفة أي واحد حل المشكلة.

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

فلتر المستخدمين: ليش جمعنا شرطين؟

الجزء (&(objectCategory=person)(objectClass=user)) يجمع شرطين باستخدام AND. في Active Directory، الاكتفاء بفئة user يمكن يدخل كائنات غير التي يقصدها القارئ بكلمة «مستخدم»، ومنها كائنات الكمبيوتر بسبب العلاقة بين الفئات. إضافة شرط person تضيق المثال إلى كائنات المستخدمين المقصودة هنا. هذا ما يثبت أن كل كائن يمثل موظفًا؛ حساب الخدمة قد يكون من النوع نفسه.

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

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

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

اقرأ الناتج كبيانات، مو كسطر نجاح

قد يظهر الناتج التجريبي بهذا الشكل:

dn: CN=Noura,OU=Students,OU=Training,DC=lab,DC=test
sAMAccountName: noura.lab
displayName: Noura Training

سطر dn يحدد الكائن الذي تخصه الخصائص التالية. sAMAccountName اسم الحساب ضمن هذا المثال، وdisplayName اسم العرض. وجود اسم العرض ما يعني أنه هو معرف تسجيل الدخول، ووجود الاسم ضمن الدليل ما يثبت أن الحساب يستطيع فتح تطبيق معين. هذي أسئلة ثانية تحتاج أدلة ثانية.

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

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

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

النتيجة فاضية: راجع السؤال قبل اتهام الحساب

ابدأ بفحص هل الاتصال والمصادقة اكتملتا أصلًا، أو أن الطرفية عرضت خطأ. ما فيه داعي تناقش الفلتر إذا TLS لم يبدأ، ولا تبحث عن مستخدم ناقص إذا الحساب لم يُقبل. فصل المراحل يوفر وقتًا ويمنعك من تكرار كلمة المرور في كل محاولة بدون سبب.

إذا نجحت المراحل الأولى، راجع Search Base وScope والفلتر والخصائص. خلنا نفترض أن Noura موجودة في Students، وأنت تبحث one من Training. النتيجة الناقصة متوقعة. غيّر النطاق وحده إلى sub وأعد القراءة المحدودة. لو ظهر الحساب بعدها، وثّق سبب الفرق؛ لا تقل إن الأداة كانت غير مستقرة ثم اشتغلت.

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

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

إذا رفض الاتصال: لا تعالج كل شيء بإلغاء الحماية

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

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

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

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

حدود النتائج والتوثيق: متى تقول إن القراءة مكتملة؟

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

للعميل خيارات للحد من عدد النتائج ومدة البحث، لكن قيم العميل ما تلغي حدود الخادم. في تمرين صغير، جهز عددًا معلومًا من الحسابات داخل OU التدريب وقارن التوقع بالمخرجات. إذا صارت الحاجة لجرد كبير، راجع سلوك الصفحات والقيود مع المسؤول ووثائق إصدارك؛ ما نحتاج نجمع كل هذا التعقيد في أول استعلام لفهم حسابين.

في ملاحظات الاختبار اكتب أن القراءة تمت بحساب Student، ومن dc01.lab.test، وداخل Training، بالنطاق sub، مع الفلتر والخصائص المذكورة. بعده اكتب النتيجة الفعلية والقيود التي لاحظتها. عبارة «تم استخراج مستخدمي الدومين» أوسع بكثير من هذا الدليل، وقد توحي بتغطية لم تحصل أصلًا.

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

تمرين يخليك تستفيد من الأداة بعد إغلاق المقال

جهز داخل لابك حسابين مباشرين في Training وحسابًا ثالثًا داخل OU فرعية، بتنسيق من مسؤول التدريب. ابدأ بقراءة خاصيتين فقط، ثم توقع ناتج one وsub قبل تشغيلهما. بعد ذلك ابحث عن حساب واحد باسمه، وراجع DN الذي رجع لك. لا تغير بيانات حسابات إنتاج لأجل تنفيذ التمرين؛ بياناته كلها وهمية ومخصصة للتعلم.

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

للمقارنة من ويندوز، اقرأ شرح Get-ADUser الموجود في المجتمع:
https://courses.cyberpts.com/community/63/shrh-get-aduser-abhth-an-mstkhdmy-aldwmyn-wafhm-alkhsays-walntayj-alfarghh

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

المراجع الفنية التي ترجع لها عند الحاجة:
دليل ldapsearch الصادر عن مشروع OpenLDAP، معروض على man7:
https://man7.org/linux/man-pages/man1/ldapsearch.1.html
صيغة فلاتر البحث في وثائق Microsoft:
https://learn.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax
متطلبات LDAP signing في وثائق Microsoft:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server

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