LDAPS يرفض الاتصال رغم أن 636 مفتوح؟ افحص اسم الشهادة وسلسلة الثقة بـOpenSSL

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

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

المنفذ مفتوح، لكن هل العميل عرف الطرف الصحيح؟

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

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

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

ملف CA للثقة مو مفتاحًا خاصًا ولا شهادة مستخدم

سنستخدم lab-ca.pem كملف يحوي شهادات CA عامة اعتمدها مسؤول اللاب للغرض المحدد. لا يحتاج التمرين مفتاح CA الخاص، ولا مفتاح الخادم، ولا حزمة حساب مستخدم. المصدر مهم: لا تأخذ شهادة من اتصال تشك في هويته ثم تثق بها فقط كي يختفي الخطأ. استخدم آلية توزيع ثقة اللاب المعروفة، واحتفظ بالمصدر الذي يشرح لماذا تعتبر هذه الجهة مناسبة للهدف الذي تراجعه.

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

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

أمر فحص واحد يوضح الاسم المتوقع وشروط التحقق

في جهاز اللاب المصرح، استخدم مثالًا محدودًا بعد مراجعة دعم نسختك: openssl s_client -connect dc01.lab.test:636 -servername dc01.lab.test -verify_hostname dc01.lab.test -verify_return_error -CAfile lab-ca.pem -showcerts . الأمر يقصد طرفًا واحدًا وملف ثقة معلومًا. connect يحدد جهة الاتصال، وservername يرسل SNI، بينما verify_hostname يحدد الاسم الذي نتحقق منه. إرسال SNI ليس بديلًا عن فحص مطابقة اسم الشهادة؛ هذان خياران لهما غرضان مختلفان.

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

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

قراءة شهادة عامة محفوظة تساعدك تعزل المشكلة

إذا وفر مسؤول اللاب شهادة الخادم العامة بملف dc01-server.pem، تقدر تقرأ بعض خصائصها محليًا. openssl x509 -in dc01-server.pem -noout -subject -issuer -dates يعرض حقولًا تساعدك تفهم صاحبها والجهة المصدرة والفترة. ولرؤية امتداد الأسماء استخدم openssl x509 -in dc01-server.pem -noout -ext subjectAltName . اسم الملف هنا مثال تعليمي، ولا نفترض أنه موجود تلقائيًا على جهازك أو أنه وحده يثبت الشهادة التي قدمتها الخدمة.

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

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

فرق الاسم وفرق الثقة ما لهم نفس المعالجة

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

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

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

الوقت والتجديد: طابق المادة الحالية بدل الاعتماد على خبر الأمس

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

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

وفي التقرير، فرق بين «قرأنا شهادة بمدة مناسبة في ملف محلي» و«راجعنا الشهادة التي قدمتها الخدمة وقُبل تحققها في السياق المحدد». الجملة الثانية تحتاج دليل اتصال ونتيجة تحقق، لا ملفًا فقط. هذا تمرين دقة يفيدك حتى خارج AD؛ لأن كثيرًا من خدمات TLS لها مصادر ثقة وأسماء وتجديدات متعددة، والقفز من حدث إداري إلى نتيجة فنية من دون مقارنة يترك فجوة في إثبات الإصلاح.

شهادة الخادم وشهادة الحساب: لا تجمع السؤالين تحت كلمة واحدة

شهادة الخادم تساعد العميل يتحقق من الطرف في اتصال TLS. أما استخدام شهادة للمصادقة على حساب AD فله سؤال آخر عن الهوية والربط والسياسات. وجود CA مؤسسية في السياقين لا يجعلهما عملية واحدة. نجاح LDAPS لا يثبت أن شهادة حساب ستُقبل لصاحب هوية معينة، وفشل ربط حساب لا يثبت أن شهادة اتصال الخادم غير مناسبة. عرّف الطرف والغرض قبل تفسير رسالة تقول Certificate.

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

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

StartTLS وLDAPS: اختر الطريقة التي يقصدها العميل

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

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

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

نتيجة قصيرة دقيقة أفضل من لقطة طويلة للشهادة

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

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

المراجع: متطلبات LDAPS في مايكروسوفت https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority ، وتوثيق s_client https://docs.openssl.org/master/man1/openssl-s_client/ ، وx509 https://docs.openssl.org/master/man1/openssl-x509/ ، وTLS في OpenLDAP https://www.openldap.org/doc/admin26/tls.html . وفي المجتمع اقرأ أيضًا مقال أخطاء LDAP ومقال ربط الشهادة بالحساب؛ كل واحد يعالج طبقة مختلفة تكمل هذا التشخيص.