Authentication Policy Silos: الحساب مرتبط بالسياسة، بس هل المنع مطبّق فعلًا؟ افهم Audit وEnforce

في مراجعة لاب، يقول لك المسؤول إن حساب الإدارة محصور في جهاز الإدارة. تفتح Active Directory Administrative Center وتلقى Authentication Policy وSilo تحمل اسمًا مرتبًا، والحساب ظاهر ضمن الإعدادات. بعدها تكتشف أنه يستطيع بدء مصادقة من جهاز تدريب آخر. هل هذه ثغرة في Windows؟ غالبًا تحتاج أولًا معرفة هل القيود مفروضة، وهل ربط الحساب مكتمل، وما المسار الذي قسته.

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

ما المطلوب تحديدًا: من أين يصادق، أم إلى أي خدمة؟

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

في مشروعنا، الحساب lab-tier-admin ينبغي استخدامه من ADMIN-PC01 لمهام إدارة تدريبية محددة. جهاز STUDENT-PC01 ليس مصدرًا معتمدًا لهذا الاستخدام. والخدمة LAB-MGMT01 ضمن جمهور العمل، بينما LAB-APP01 خارجه. نكتب هذا التصميم قبل النظر في الشاشات، حتى نعرف أي إعداد يخدم أي قيد.

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

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

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

Policy تحدد القيود، وSilo تنظم من تنطبق عليهم

Authentication Policy هي كائن يحمل إعدادات المصادقة وشروطها. Authentication Policy Silo تنظم حسابات تُربط بسياسات مناسبة لأنواعها. وجود اسم Silo في الدليل لا يقول لك تلقائيًا إن كل حساب إداري يدخل فيها، ولا إن Policy التي يشير إليها الاسم تحتوي الشروط التي قصدها مسؤول المشروع.

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

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

لذلك استخدم في سجلك ثلاثة أسطر منفصلة: السياسة وخصائصها، Silo والسياسات المرتبطة بها وحالتها، والحساب وتعيينه الحالي. بعد ذلك اكتب العلاقة التي تثبتها المصادر. اسم جذاب مثل Tier0-Protected لا يمنحك معلومة عن عدد الحسابات أو حالتهم، تمامًا كما اسم GPO أمني لا يثبت وصوله لكل جهاز.

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

Audit يعطيك أثرًا للمراجعة، وEnforce يغيّر القرار

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

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

في مثالنا، قد يظهر lab-tier-admin مربوطًا إلى Silo، لكن السياسة ما زالت للمراقبة. نجاح محاولة من STUDENT-PC01 في هذه المرحلة لا يثبت فشل المنتج. النتيجة الصحيحة هي أن المشروع لم يصل إلى الفرض الذي يتطلبه وصف الضابط، إن كان ذلك هو المتطلب المعتمد. فرق صغير في الصياغة، لكنه يغير التوصية من «عطل في النظام» إلى «اكتمال نشر السياسة يحتاج تحققًا».

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

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

اقرأ الكائنين والحساب من المصدر نفسه

في لاب مصرح ومع وحدة ActiveDirectory، اقرأ Silo محددة: Get-ADAuthenticationPolicySilo -Identity 'Lab-Admin-Silo' -Server 'dc01.lab.test' -Properties * | Format-List. هذا يعرض خصائص الكائن المقصود، ومنها حالة الفرض والتفاصيل المتاحة في النسخة. ما نحتاج جمع كل Silos في غابة لا تدخل نطاق التدريب كي نراجع حالة واحدة.

بعد ذلك اقرأ السياسة باسمها الذي وجدته في تصميم Silo: Get-ADAuthenticationPolicy -Identity 'Lab-Admin-Policy' -Server 'dc01.lab.test' -Properties * | Format-List. راجع الشروط الموجودة فعلًا بدل الاكتفاء بالوصف. وإن كان هناك أكثر من سياسة بحسب نوع الهوية، اجمع ما يتعلق بالحساب الذي ستختبره، ثم وضّح لماذا هو الاختيار المناسب.

وللحساب التدريبي، يمكنك قراءة التعيينات: Get-ADUser -Identity 'lab-tier-admin' -Server 'dc01.lab.test' -Properties msDS-AssignedAuthNPolicy,msDS-AssignedAuthNPolicySilo | Select-Object SamAccountName,DistinguishedName,msDS-AssignedAuthNPolicy,msDS-AssignedAuthNPolicySilo. الحقول تستخدم أسماء LDAP للتعيين، والقراءة من المصدر نفسه تقلل التباس مقارنة نسخ من وحدات تحكم مختلفة في وقت تغيير.

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

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

اختبار أربع حالات أفضل من تسجيل دخول واحد

لدينا مصدران: ADMIN-PC01 المعتمد وSTUDENT-PC01 غير المعتمد، وخدمتان: LAB-MGMT01 المطلوبة وLAB-APP01 الخارجة عن التصميم. لكن لا تختبر كل التركيبات بالطريقة نفسها من غير تحديد المرحلة. أولًا اختر حالات تراجع مصدر المصادقة، ثم حالات تراجع أهلية طلب الخدمة وفق الشروط المعتمدة، ودوّن الفرق بينها في نموذجك.

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

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

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

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

السجل يشرح الشرط، لكنه يحتاج سياقًا

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

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

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

انتبه للحساب الإداري المدمج ذي RID 500: توثيق Microsoft يذكر استثناءه من Authentication Policies حتى عند تعيينه إلى Silo. لذلك لا تستخدمه حالة اختبار عادية ثم تعمم السلوك على الحسابات الأخرى. هذا استثناء لهذه السياسات، وليس عبارة أن الحساب خارج كل ضابط أمني أو أنه مناسب للاستخدام اليومي.

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

نتيجة تقرير تُفهم، وخطة نشر قابلة للتحقق

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

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

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

إذا رجعت من هذا المقال بفكرة واحدة، فهي أن وجود كائن سياسة لا يساوي حماية مفروضة. اقرأ السلسلة كاملة ثم قِس السلوك المناسب لكل شرط. هذه طريقة تفكير تنفعك في لابات CRTE وفي نقاش مسؤول يقول «الإعداد موجود» بينما السؤال الحقيقي هو أين طُبق وعلى من وبأي أثر.

المراجع: المفاهيم والأنواع والأحداث والاستثناءات: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos
قراءة Silo وEnforce: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adauthenticationpolicysilo?view=windowsserver2025-ps
قراءة Policy: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adauthenticationpolicy?view=windowsserver2025-ps
دليل Microsoft للتهيئة والمتطلبات: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/how-to-configure-protected-accounts