الشهادة الرقمية صحيحة، لكن تسجيل الدخول يرفضها؟ افهم Certificate Mapping قبل ما تغيّر اللاب

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

أربع نتائج مختلفة غالبًا نجمعها في كلمة «اشتغلت»

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

تخيل أن لديك شهادة لحساب تدريب، وأنها صدرت من CA صحيحة داخل اللاب. تستطيع فتح معلوماتها، لكن التطبيق لا يقبلها. يمكن الشهادة لغرض مختلف، أو أن التطبيق لا يثق بجهة إصدارها، أو أنه يحتاج طريقة تعيين هوية لا تنطبق عليها. ما نعرف السبب من عبارة «Successfully issued» في أداة الإصدار وحدها.

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

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

الشهادة والمفتاح الخاص: امتلاك الملف العام مو كفاية

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

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

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

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

افحص المعلومات العامة أولًا، بدون محاولة مصادقة جديدة

على ويندوز، ومع شهادة عامة تجريبية يوفرها مسؤول اللاب باسم training-user.cer، تقدر تعرض محتواها محليًا:

certutil -dump training-user.cer

راجع المساعدة المحلية إذا إصدار النظام يعرض خيارات مختلفة. المثال يقرأ الملف المحدد، ولا ينشئ شهادة ولا يطلب تسجيل دخول. لا تبدل -dump بخيارات إدارة CA أو تغيير المخازن من شرح آخر؛ certutil برنامج متعدد الوظائف، ونحن نستخدم وظيفة عرض هنا فقط.

ابدأ بـ Subject وIssuer وفترة الصلاحية، ثم راجع Subject Alternative Name وExtended Key Usage إذا كانت موجودة. سجل ما يظهر فعلًا في الشهادة، مو ما كنت تتوقعه من اسم القالب. ممكن قالب تغير بعد إصدارها، والشهادة القديمة ما تعكس الإعداد الجديد تلقائيًا.

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

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

التاريخ: مو بس NotAfter اللي في آخر السطر

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

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

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

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

سلسلة الثقة وحالة الإلغاء: رأي جهازك مو رأي الدومين

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

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

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

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

EKU: شهادة TLS مو بالضرورة شهادة دخول مستخدم

Extended Key Usage يصف أغراض استخدام للشهادة. شهادة صادرة لحماية اتصال خادم ويب ليست تلقائيًا مناسبة لمصادقة حساب مستخدم داخل الدومين. الاسم المكتوب في Subject أو وجود UPN في امتداد ما لا يلغي متطلبات الاستخدام التي يعتمد عليها مسار المصادقة.

المتطلبات تختلف حسب السيناريو: Smart Card Logon، أو PKINIT، أو مصادقة عميل عبر Schannel، أو تطبيق له سياسة خاصة. لا تنقل شرطًا من شرح HTTPS إلى تجربة تسجيل دخول ثم تقول إن الخدمة غير متوافقة. حدد البروتوكول والطرف الذي يفحص الشهادة أولًا، وبعدها اقرأ المتطلبات المناسبة له.

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

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

Certificate Mapping: بأي دليل نربط الشهادة بالحساب؟

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

توضح Microsoft في KB5014754 أن التعيين الضعيف لا يكفي في وضع Full Enforcement، وأن بعض الروابط القوية تعتمد على معرفات مناسبة بدل الاكتفاء بأسماء قابلة لإعادة الاستخدام. لا نحتاج تعديل خصائص هوية لكي نتعلم الفكرة؛ يكفي فهم أن اسم المستخدم ليس دائمًا رابطًا قويًا ثابتًا.

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

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

سجلات KDC تساعدك تحدد سبب الرفض

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

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

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

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

PKINIT وSchannel: المسار مختلف، فلا تبدّل الهدف بدون فهم

PKINIT يستخدم المفاتيح العامة في تبادل المصادقة الأولي لـ Kerberos. أما Schannel فيرتبط بمسارات TLS ومصادقة الشهادات في خدمات تدعمه. مجرد أن أداة تعرض خيارًا لكل منهما ما يجعل الاختبارين مترادفين أو يعطي نجاح أحدهما المعنى نفسه في الآخر.

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

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

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

كيف تكتب نتيجة مفيدة وتعرف أن التشخيص انتهى؟

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

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

لربط هذا الموضوع بجرد القوالب، راجع شرح Certipy find في المجتمع:
https://courses.cyberpts.com/community/74/shrh-certipy-find-aqra-aadadat-ad-cs-wafhm-alntyjh-qbl-ma-tsmyha-thghrh

المراجع الأصلية:
KB5014754 من Microsoft، بما فيه التعيين القوي والأحداث والتحديثات:
https://support.microsoft.com/en-us/servicing/os/windows-server/2022/05/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers
متطلبات شهادات Smart Card ومسار التحقق، ضمن سياقها المحدد:
https://learn.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration
دليل certutil:
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil
وثائق PKINIT الخاصة بتنفيذ ويندوز:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/MS-PKCA/d0cf1763-3541-4008-a75f-a577fa5e8c5b

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