أخطاء LDAP بالعربي: الفرق بين invalidCredentials وinsufficientAccessRights وnoSuchObject

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

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

أول سؤال: الخطأ من العميل ولا نتيجة LDAP من الخادم؟

قبل تفسير الرقم، اقرأ الاسم الكامل للرسالة ومكان ظهورها. خطأ محلي عن مكتبة غير موجودة أو خيار لا يعرفه البرنامج ليس نتيجة LDAP من الدليل. وفشل تحقق الشهادة قد يحدث قبل أن تكمل جلسة محمية وتصل إلى عملية البحث. أما نتيجة LDAP فهي مرتبطة بعملية وخادم وسياق. لا تضع كل الأخطاء التي تظهر في أداة اسمها ldapsearch أو أداة AD تحت عنوان «رفض الدومين الحساب».

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

خلنا نفترض أن برنامجك لم يبدأ بسبب مشكلة Python. الخطوة التالية تجهيز البيئة كما شرحنا في مقال NetExec، وليس مراجعة اسم المستخدم. وفي حالة ثانية، بدأ الاتصال لكن TLS رفض سلسلة الثقة. الخطوة التالية مراجعة الشهادة والاسم والثقة. وفي ثالثة، ظهرت نتيجة LDAP بعد عملية محددة. هنا ننتقل إلى معنى الرمز وحدود ما يثبته. نفس عدم ظهور بيانات يحتاج ثلاثة طرق مختلفة حسب المرحلة التي توقف عندها.

invalidCredentials 49: راجع الهوية المقدمة، مو كل إعداد في الشبكة

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

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

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

insufficientAccessRights 50: المصادقة شيء والحق على العملية شيء

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

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

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

noSuchObject 32: افحص Base DN قبل ما تعلن أن المستخدم محذوف

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

خلنا نفترض أن لابك يستخدم OU=Training,DC=lab,DC=test، لكن الأمر أخذ OU=Trainees من شرح آخر. عندها تغيير الفلتر عشر مرات يظل يدور داخل بداية غير صحيحة. راجع القاعدة المعروفة من مصدر مصرح، مثل قراءة معلومات الدليل التي شرحناها في مقال Get-ADRootDSE، ثم طابق الاسم الفعلي للـOU. لا توسع البحث إلى كل شجرة فقط حتى تحصل على نتائج؛ احرص أن تختار نطاقًا يفيد سؤال التمرين.

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

نجاح البحث مع صفر نتائج مو نفس noSuchObject

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

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

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

حد الوقت والحجم: قد تحصل على جزء وتحتاج تعرف أنه جزء

رمزا timeLimitExceeded 3 وsizeLimitExceeded 4 يرتبطان بتجاوز حدود العملية. عند ظهورهما، لا تتعامل مع ما وصل على أنه قائمة مكتملة من دون مراجعة. قد تكون الأداة عرضت بيانات قبل النتيجة النهائية، لذلك اقرأ نهاية العمل وحدوده. السؤال العملي: هل كان الطلب أكبر من الحاجة، أو هل حددت حدًا لا يناسبه، أو هل تحتاج طريقة موثقة لتجزئة قراءة ضمن نطاق مصرح؟ لا نبدأ من تعطيل حدود الخادم.

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

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

strongerAuthRequired وTLS: لا تحل المتطلب بإلغاء الحماية

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

وفي أخطاء TLS من العميل، راجع اسم الخادم وسلسلة الشهادة والثقة والأوقات وفق الطريقة التي تستخدمها. التوثيق الرسمي لـOpenLDAP يناقش إعدادات الثقة والتحقق. إذا ظهر أن الاسم لا يطابق الشهادة، استبدال عنوان صحيح بعنوان غير مناسب أو استخدام IP بدل الاسم قد يفسر الفرق. لكن لا نحسمه من دون قراءة فعلية. سجل المرحلة والرسالة والمنفذ، وافصل نجاح TCP عن اكتمال TLS وعن نجاح طلب LDAP بعدها.

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

ورقة تشخيص صغيرة تفرق بين ثلاثة أسباب

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

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

المراجع: بروتوكول LDAP ورموز نتائجه في RFC 4511 https://www.rfc-editor.org/rfc/rfc4511 ، وطرق المصادقة في RFC 4513 https://www.rfc-editor.org/rfc/rfc4513 ، وتوثيق TLS في OpenLDAP https://www.openldap.org/doc/admin26/tls.html . وللمراجعة العملية داخل المجتمع، اقرأ مقال ldapsearch ومقال تشخيص DNS وADWS. احتفظ بالقاعدة: الرسالة تصف عملية في سياق، وأفضل خطوة بعدها هي التي تراجع ذلك السياق بدل تخمين سبب واحد لكل الأخطاء.

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