Kerberos Delegation بالعربي: الفرق بين Unconstrained وConstrained وRBCD في عمل التطبيقات

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

ابدأ من الطلب الذي يحتاج هوية المستخدم

خلنا نفترض وجود تطبيق تقارير على WEB01 وبيانات تعليمية على خادم خلفي. المستخدم trainee01 يفتح صفحة التقرير. قد يصمم الفريق التطبيق لقراءة البيانات بهويته الخاصة، أو يحتاج أن تمر العملية بهوية المستخدم حتى يطبق الخادم الخلفي قواعد وصول مرتبطة به. قبل شرح أي Delegation، اسأل أي التصميمين مطلوب.

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

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

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

Unconstrained: ثقة واسعة تحتاج مبررًا أقوى

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

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

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

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

Constrained: التقييد يتعلق بالوجهات المسموح بها

في Kerberos Constrained Delegation التقليدي، تُحدد خدمات خلفية يمكن للخدمة الأمامية التصرف نحوها نيابة عن المستخدم ضمن النموذج. هذا يغير سؤال المراجعة من «هل هناك ثقة واسعة؟» إلى «هل قائمة الوجهات تطابق حاجة التطبيق؟» لا يزال عليك معرفة هوية الأمام والخلف والعميل.

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

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

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

RBCD ينقل قرار الثقة إلى جهة المورد

Resource-Based Constrained Delegation، أو RBCD، يرتبط بضبط الثقة على جهة الخدمة الخلفية أو المورد. بدل أن تبدأ فقط من قائمة وجهات على الطرف الأمامي، تسأل المورد: من تسمح له بالتفويض نحوك؟ هذا فرق في موضع الإعداد والمسؤولية التي تدير حد الثقة.

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

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

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

اقرأ الخصائص من الكائن المناسب

على جهاز إدارة مصرح داخل المختبر، يمكنك قراءة حساب كمبيوتر محدد:

Get-ADComputer -Identity WEB01 -Server dc01.lab.test -Properties TrustedForDelegation,TrustedToAuthForDelegation,msDS-AllowedToDelegateTo | Select-Object Name,TrustedForDelegation,TrustedToAuthForDelegation,msDS-AllowedToDelegateTo

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

إذا كانت الخدمة تعمل بحساب مستخدم أو gMSA، فالقراءة من حساب الكمبيوتر قد لا تكون كل ما تحتاجه. اختر Get-ADUser أو Get-ADServiceAccount حسب نوع الهوية التي أكدها مسؤول التطبيق، وحدد نفس الخادم والسياق. لا تعتمد على أن اسم التطبيق يشبه اسم الكمبيوتر.

لقراءة جهة المورد في مثال RBCD:

Get-ADComputer -Identity APP01 -Server dc01.lab.test -Properties PrincipalsAllowedToDelegateToAccount | Select-Object Name,PrincipalsAllowedToDelegateToAccount

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

هوية المستخدم الحساسة تدخل في المراجعة أيضًا

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

Account is sensitive and cannot be delegated خيار يستحق فهمه ضمن حماية الهويات الحساسة. لا تتعامل معه كزر تعطل به التطبيق فورًا أثناء الفحص. راجع مع مسؤول الهوية أين يجب أن يطبق، وما الاستخدامات التي تعتمد على التفويض، ثم اجعل المعالجة تغييرًا مقصودًا مع تحقق وظيفي.

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

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

المصادقة والتفويض وصلاحية المورد ثلاث مراحل

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

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

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

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

كيف تحدد أثر إعداد التفويض في التقرير؟

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

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

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

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

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

تمرين دراسة يساعدك تفهم بدل حفظ الأسماء

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

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

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

المراجع الرسمية:
https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview
https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/troubleshoot-kerberos-constrained-delegation-issues
https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputer
https://learn.microsoft.com/en-us/powershell/module/activedirectory/set-adcomputer
https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group

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