Global Catalog وLDAP: ليش تلقى المستخدم على 3268 لكن بعض خصائصه ما تظهر؟

تبحث عن مستخدم في Active Directory، وتلقى اسمه وDN، لكن الخاصية اللي يحتاجها تقريرك غائبة. تغيّر الحساب وتعيد الاستعلام وتظل النتيجة ناقصة. قبل ما تسميها مشكلة صلاحية، اسأل: هل تستعلم من Global Catalog، وهل الخاصية موجودة أصلًا ضمن البيانات التي يوفرها هذا النوع من البحث؟
GC يوسع البحث في كائنات الغابة، لكنه لا يحول كل خصائص كل دومين إلى نتيجة كاملة في طلب واحد. بنفهم هنا الفرق بين العثور على الكائن وجلب تفاصيله، وبين منفذ الاتصال وقاعدة البحث والفلتر. الأمثلة قراءة في مختبر مصرح، بدون توسيع التصريح إلى دومينات إضافية أو تعديل Schema.

وش يعطيك Global Catalog فعلًا؟

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

389 و636 و3268 و3269: المنفذ جزء من نوع القراءة

جدول Microsoft للمنافذ يميز LDAP على 389، وLDAP SSL على 636، وLDAP GC على 3268، وLDAP GC SSL على 3269. هذا يوضح أن تبديل المنفذ قد يغير نوع الخدمة المقصودة أو طريقة النقل. لا تنظر للأربعة كأرقام متكافئة تؤدي نفس البحث بمجرد تغييرها في أمر محفوظ.
كذلك فتح 3268 لا يثبت أن استعلامك الفعلي ناجح أو أن كل خصائصك متاحة. اختبار اتصال TCP يجيب سؤال الوصول إلى المنفذ فقط. تحتاج بعده قراءة LDAP صحيحة ومصادقة مناسبة وقاعدة وفلتر وخصائص مطلوبة. والمنفذ المشفر يحتاج تحققًا من شهادة الطرف المقابل ضمن الإعداد المعتمد، وليس إلغاء التحقق لتجاوز رسالة.
إذا كان نفس الخادم يقدم LDAP وGC، اكتب endpoint كاملًا في ملاحظاتك مع المنفذ. تسجيل dc01 فقط قد يخفي الفرق بين تجربتين. وعندما تقارن نتيجتين، ثبت بقية العوامل قدر الإمكان: الهوية، وقاعدة البحث، والفلتر، والخصائص، والوقت. وإلا يصعب معرفة هل الاختلاف من نوع الوجهة أو من تغيير آخر.
لا تضف كل المنافذ إلى قاعدة جدار ناري لأن جدول المرجع يسردها. التصميم والسيناريو يحددان التدفق المطلوب، وبعض البيئات لا تحتاج جميع المسارات. في هذا المقال نحن نفسر قراءة، ولا نبني سياسة شبكة عامة. إذا كان الاتصال غير متاح، راجعه مع صاحب المختبر بدل توسيع الوصول تلقائيًا.

قاعدة البحث تحدد أين تبحث حتى لو تستخدم GC

Base DN وSearch Scope ما زالا مهمين. الاتصال بـGC لا يجعل كل استعلام بحثًا صحيحًا على الغابة كاملة. إذا اخترت قاعدة ضيقة تحت OU معينة، قد تراجع تلك الشجرة فقط وفق طلبك. وإذا كانت القاعدة خاطئة، قد تحصل على خطأ كائن غير موجود أو نتيجة لا تخص السؤال.
قبل التنفيذ اكتب مسار البحث المقصود من قراءة موثوقة، لا من تخمين تنظيم الدليل. الاسم الذي تراه في رسم أو لقطة قد لا يعكس DN الحالي بعد نقل كائن. وإذا كان السؤال عن مستخدم محدد، لا تبدأ من قاعدة واسعة ثم تعتمد على اسم عرض غير فريد عندما يمكنك استخدام هوية أدق.
في المختبر، اجعل أول مقارنة بسيطة: نفس حساب التدريب ونفس DN المعروف ونفس الحقول الأساسية من مصدرين مناسبين. لا تبدأ بفلتر طويل يضم عدة شروط؛ إذا رجع فارغًا، يصعب معرفة أي شرط أو نطاق تسبب في ذلك. أضف شروطًا عندما تعرف ما الذي تضيفه للسؤال.
سجل نوع scope أيضًا. بحث base على كائن محدد يختلف عن subtree تحت حاوية. يمكن أن يكون اتصالك صحيحًا وحسابك مخولًا، لكن النتيجة فارغة لأن نوع البحث لا يشمل المكان الذي تتوقعه. هذه فروق تجعل تفسير ldapsearch أو أي عميل LDAP أدق من تكرار محاولة المصادقة بلا سبب.

الفلتر والخصائص المطلوبة: مشكلتان مختلفتان

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

Partial Attribute Set: راجع تعريف الخاصية، لا اسمها

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

Referral: نتيجة إرشاد لمصدر آخر، وليست دائمًا رفضًا

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

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

في مختبرك اختَر مستخدم تدريب معروفًا، واحصل على DN وهويته الأساسية من مصدر موثوق. اكتب الحقول التي تريد مقارنتها، وتحقق من تعريفها في بيئة التدريب. الهدف أن تختبر حدود عرض GC، لا أن تختار حقلًا حساسًا أو تحاول تجاوز حقوق القراءة.
اقرأ الحقول الأساسية من GC بالعميل المجهز وفق مصادقة ونقل معتمدين. احفظ endpoint وقاعدة البحث والفلتر والوقت والنتيجة. إذا لم تصل قراءة صالحة، توقف عند تشخيص الاتصال أو الهوية؛ لا تعتبر الفشل دليلًا أن GC لا يحمل المستخدم. مقارنة البيانات تبدأ بعد نجاح الاستعلام.
بعد العثور، اقرأ الحقول الإضافية من وحدة تحكم مناسبة للدومين الذي يحمل الكائن، بنفس الهوية المخولة عندما يمكن ذلك. قارن الهوية الثابتة قبل مقارنة القيم. إذا ظهرت خاصية في القراءة الثانية وغابت في الأولى، راجع PAS وصلاحية القراءة وفرق الوقت قبل تسمية السبب.
اكتب نتيجة التجربة: «عُثر على الكائن في GC، واحتاج حقل محدد قراءة من المصدر المناسب وفق الحالة المثبتة». هذه صياغة عملية تفيد تصميم تقرير أو تطبيق. لا تقول إن GC سيئ أو LDAP أفضل دائمًا؛ كل مسار له وظيفة وحدود، والمقارنة تعلمك اختيار المصدر بدل محاربته.

أربع حالات لا تجمعها تحت نتيجة فارغة

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

اكتب توصية تختار مصدرًا، بدل تغيير البيئة بلا حاجة

إذا كان تطبيقك يحتاج بحثًا واسعًا وحقولًا أساسية، راجع هل GC يحقق هذه الحاجة. وإذا يحتاج تفاصيل محددة بعد العثور، صمم القراءة الثانية مع صاحب التطبيق وفق الهوية والنطاق والأداء المناسب. لا تنقل قرارًا من تمرين بسيط إلى منتج كبير دون اختبار اعتمادياته.
اختبر الحقول الفعلية التي يحتاجها التقرير، ومصادرها، وسلوك فشلها. هل التطبيق يميز حقلًا غير متاح عن قيمة فارغة؟ وهل يسجل مصدر القراءة كي يفسر الاختلاف لاحقًا؟ هذه أسئلة تصميم وتشخيص تفيدك حتى لو لم تغير أي إعداد في AD.
معيار الإغلاق يذكر أن القراءة المقصودة تعيد البيانات المطلوبة من المصدر المناسب، وأن النطاق والهوية لم يتوسعا بلا حاجة، وأن سبب النقص موثق. إذا بقيت خاصية خارج التغطية، سجلها بوضوح. لا ترفع الثقة في النتيجة لأنك غيرت المنفذ وظهر جدول أكبر فقط.
المراجع: البحث في GC https://learn.microsoft.com/en-us/windows/win32/ad/searching-global-catalog-contents وتعريف PAS https://learn.microsoft.com/en-us/windows/win32/adschema/a-ismemberofpartialattributeset والإحالات https://learn.microsoft.com/en-us/windows/win32/adsi/referrals وجدول المنافذ https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/config-firewall-for-ad-domains-and-trusts . الدرس العملي: اعرف من أين جاءت المعلومة، وما الذي يمكن أن يعيده المصدر، ثم فسر الغياب ضمن ذلك النطاق.