Active Directory / الأساسي / الدرس 5
LDAP وKerberos وتدفق الدخول
ميّز الوصول للدليل ومصادقة التذاكر واعتماد الوقت واسم الخدمة وقرار المورد بعد الدخول.
في هذه الصفحة
أهداف الدرس
- شرح عمليات LDAP منفصلة عن تذاكر Kerberos.
- تحديد الاكتشاف والوقت وهوية الخدمة والإذن.
- تحليل دليل المصادقة دون التعامل مع اعتماديات دخول.
يحل استعلام الدليل وتذكرة الخدمة مسألتين مختلفتين
يصل LDAP لمعلومات الدليل وعملياته وفق السياسة، وتوفر Kerberos تذاكر بين العميل وKDC بالمتحكم والخدمة. ليست كل عملية دخول LDAP، ولا يثبت بحث ناجح تذكرة أو ملفًا. سمِّ البروتوكول والطريقة الفعلية؛ ويشرح الدرس الأدوار بتسميات اصطناعية دون ربط أو تذكرة أو كلمة مرور أو حركة شبكة.
تشير التذكرة إلى هوية خدمة معينة
تختلف تذكرة المنح من تذكرة الخدمة. تربط SPN الخدمة بحسابها وقد يسبب الغياب أو التكرار أو الاختلاف فشلًا يشبه مشكلة مستخدم. صمّم الأسماء البديلة والموازنة، وراعِ الوقت لفترات الصلاحية ومنع الإعادة. لا تعمم مهلة أو تعد تغيير الساعة آمنًا؛ راجع السياسة والدليل. تختلف كذلك حماية النقل والتوقيع وربط القناة لاحقًا. قد تتطلب الخدمة ذات الاسم البديل أو العقد المتعددة ربطًا منسقًا بهويتها، ولذلك لا يكفي نجاح حل اسم المضيف لإثبات صحة مسار Kerberos كله.
تحديد أول مرحلة نموذجية فاشلة
يفصل النموذج الاكتشاف والوقت والتذكرة والإذن وينسب الفشل للإذن بعد نجاح التذكرة. ليس آلة Kerberos ولا محلل رمز Windows؛ فالترتيب تعليم واعتماد وقد يستخدم الواقع مخزنًا ومسارات أخرى. يمنع خطأ تصفير كلمة المرور لكل وصول. حدّد الفاعل والخدمة والوقت والفئة بالدليل الحقيقي.
stages = [
("discovery", True),
("time_policy", True),
("ticket_issued", True),
("resource_authorization", False),
]
failed = next((name for name, passed in stages if not passed), "none")
print(failed)
resource_authorization
يطبع resource_authorization دون اعتماد أو تذكرة أو اتصال أو سجل حي.
حماية طريقة الوصول مع الحساب
استخدم وصول دليل موثقًا ومحميًا معتمدًا. يوفر توقيع LDAP سلامة بسياق SASL لا سرية عامة، ولـTLS والختم دور آخر ويحتاج الربط البسيط حماية النقل. تختلف الافتراضات حسب الإصدار والتاريخ؛ راجع الواقع. يسمي السجل الأدلة بلا اعتماد أو عميل، ولا تعطل ضبطًا لأجل تطبيق قديم قبل معرفة قدراته وترحيله.
{"client":"workstation-17","domain":"ad.example.test","target_service":"course-files","evidence":["controller_selected","time_context","authentication_stage","resource_decision"],"credentials":"not_collected"}
يفصل السجل الملاحظات ويستبعد جمع الاعتماد ولا يطلب تذاكر أو يصادق.
عقود البحث باستخدام LDAP
يحدد بحث LDAP اسم البداية المميز ونطاق البحث والمرشح والسمات المطلوبة. يغطي base وone-level وsubtree مناطق مختلفة. ينتقي المثال التخطيطي كائن شخص ومستخدم باسم حساب ويطلب displayName وحدها. هرب قيم المرشح الخارجية بقواعد مكتبة العميل الموثقة؛ فتهريب المرشح يختلف عن تهريب DN. حد النتائج وتعامل مع الصفحات والإحالات عمدًا بدل جمع الدليل كله. لا يثبت مرشح صحيح أو سمة مقروءة إذن تعديل الكائن.
{"base_dn":"OU=Learners,DC=ad,DC=example,DC=test","scope":"subtree","filter":"(&(objectCategory=person)(objectClass=user)(sAMAccountName=learner17))","attributes":["displayName"],"mode":"documentation_only"}
يعلن السجل نية الانتقاء فقط ولا يفتح اتصالًا أو يبحث أو يختلق كائنات معادة.
حفظ الفرق بين المصادقة والوصول
تختلف مسؤولية وأدلة الدخول والتذكرة ورفض التطبيق. استخدم سجلات منقحة وسياقًا لا أسرارًا. القفل والتعطيل والانتهاء والاسم والوقت والهوية فرضيات لا أوامر تغيير. لا يثبت بديل NTLM صحة Kerberos، وقد يدل نجاح متحكم آخر على اتساق أو مكان. سمِّ المجهول ولا يولد المقرر مصادقة أو يغير كلمة مرور. يجب أن يظل كل تفسير فرضية مرتبطة بسياقها، لا قائمة تغييرات تُنفذ بالتتابع؛ فالنجاح عبر متحكم آخر لا يحدد وحده سبب الاختلاف.
الأخطاء الشائعة وإصلاحها
تسمية كل فشل كلمة مرور خاطئة.
- لماذا يحدث؟
- دُمجت المراحل والإذن.
- كيف تصلحه؟
- حدّد المرحلة قبل الحساب.
- كيف تتجنب تكراره؟
- سجّل التذكرة والمورد منفصلين.
وصف توقيع LDAP كتشفير.
- لماذا يحدث؟
- خُلطت السلامة بالسرية.
- كيف تصلحه؟
- راجع التوقيع وTLS والختم وربط القناة منفصلة.
- كيف تتجنب تكراره؟
- طابق الضبط بطريقة الربط.
يكسر اسم خدمة بديل Kerberos مع DNS عام سليم.
- لماذا يحدث؟
- عُد حل المضيف هوية خدمة صحيحة.
- كيف تصلحه؟
- راجع ربط الأصل المعتمد ودليله.
- كيف تتجنب تكراره؟
- أدرج البدائل باختبار الهوية.
اختبر فهمك
1. اجعل ticket_issued خاطئة. ما أول فشل ولماذا لا يثبت سببه؟
اعرض الحل المشروح
يطبع النموذج ticket_issued لأن المراحل المعلنة السابقة ما زالت ناجحة. لكنه لا يميز حالة حساب فعلية من مشكلة اسم خدمة أو اختلاف سياسة أو خطأ بروتوكول آخر، لأنه لا يحتوي إلا قيمًا منطقية. يلزم دليل مصرح خاص بالمرحلة لتضييق السبب. النتيجة أداة تصنيف لا إذن بتصفير حساب أو تعديل سياسة مصادقة.
2. يمكن قراءة اتصال LDAP موقع بالنموذج غير TLS. هل فشل التوقيع؟
اعرض الحل المشروح
ليس بالضرورة أن يكون التوقيع معطلًا. فهو يعالج السلامة والأصالة في السياق الذي ينطبق عليه، بينما تحتاج السرية إلى نقل مشفر أو ختم مناسب. راجع طريقة الربط والسياسة والدعم الفعلي لدى العميل والخادم وأثر الهجرة، بدل افتراض أن طبقات الحماية متطابقة. ولا يجيز المثال إضعاف اتصال حقيقي أو تغييره.
أهم ما تعلمته
- لـLDAP وتذاكر Kerberos أدوار مختلفة.
- تحتاج المراحل أدلتها.
- لا تستبدل التشخيص بجمع الاعتماد.