SID Filtering وSelective Authentication: وش الفرق في AD Trust، وليش السماح بالمصادقة ما يعطيك صلاحية الملفات؟

شركة تجريبية عندها غابتان في Active Directory: users.lab للهويات وresources.lab لخدمات الملفات. المطلوب أن فريقًا محددًا من الأولى يقرأ مجلد مشروع في الثانية، من غير فتح الوصول لبقية المستخدمين. أثناء المراجعة تسمع عبارتين: «SID Filtering مفعّل» و«Selective Authentication مفعّل». هل هما اسمان لحماية واحدة؟ وهل يكفي تفعيلهما حتى نعرف من يستطيع فتح المجلد؟

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

ابدأ بهوية ومورد وعملية، ثم اقرأ اتجاه الثقة

قول «هناك Trust بين الغابتين» ناقص إذا كان السؤال عن وصول مستخدم إلى مورد. اكتب من يملك الحساب، ومن يملك الخدمة، وما العملية المطلوبة. في مثالنا المستخدم huda موجود في users.lab، والخادم FILE01 موجود في resources.lab، والعملية المطلوبة قراءة ملف تدريبي داخل مشاركة ProjectDocs. هذه ثلاثة عناصر يمكن مراجعتها، بدل سهم على رسم لا أحد يعرف من أي جهة قرأه.

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

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

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

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

SID Filtering يتعلق ببيانات التخويل العابرة للحد

SID Filtering يعالج معرّفات الأمان التي تعبر حدود الثقة ضمن بيانات التخويل. الفكرة أن الجهة المستقبلة لا ينبغي أن تقبل أي ادعاء هوية أو عضوية لمجرد أنه وصل من جهة تثق بمصادقتها. القواعد تختلف بحسب نوع الحد وفئات SID؛ توثيق MS-PAC يشرحها بالتفصيل، ولذلك اختصارها إلى «يحذف كل SIDHistory دائمًا» يضيّع فروقًا مهمة.

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

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

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

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

Selective Authentication يتعلق بأهلية المصادقة

Selective Authentication يضيق الجمهور الذي يستطيع المصادقة على الموارد المعنية عبر الثقة، بدل افتراض قبول المصادقة على نطاق واسع. توثيق Microsoft يشرح مراجعة أهلية المصادقة للخدمة في جهة المورد عند استخدام هذا النمط. في الحالة البسيطة لخادم ملفات يعتمد على حساب الكمبيوتر، راجع Allowed to Authenticate على الكائن المناسب والهويات التي تشملها الأذونات.

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

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

في مثالنا المطلوب أن مجموعة Project-Readers من users.lab تستطيع المصادقة على FILE01 للعمل المصرح، بينما مستخدم خارج المجموعة لا يملك الأهلية المقصودة. هذه صياغة قابلة للاختبار. أما «Selective Authentication مفعّل إذن البيئة مقفلة» فهي عبارة لا تحدد من استُثني أو ما الموارد التي منحت أهلية المصادقة.

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

الأذونات على المورد تجيب سؤال العملية المطلوبة

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

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

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

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

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

قراءة Get-ADTrust من جهة محددة

باستخدام وحدة ActiveDirectory وفي دومين تدريب مصرح، يمكنك قراءة علاقة محددة بدل جمع كل العلاقات دون حاجة: Get-ADTrust -Identity 'users.lab' -Server 'dc01.resources.lab' -Properties * | Select-Object Source,Target,Direction,TrustType,ForestTransitive,IntraForest,SelectiveAuthentication,SIDFilteringForestAware,SIDFilteringQuarantined. تحقق أن اسم الشريك والخادم يناسبان اللاب، وأن المخرجات تحتوي الخصائص المقصودة في نسختك.

فائدة الأمر أنه يجمع صورة عن كائن الثقة من جهة resources.lab. لا يغيّر العلاقة، ولا يثبت بمجرده نجاح الوصول لخدمة معينة. احتفظ بتفسير Source وTarget مع المخرجات، وراجع الخصائص في سياق نوع الثقة. استخدام Properties هنا للقراءة لا يجعل كل خاصية تظهر بمعنى واحد في كل نوع علاقة أو كل أداة تعرضها.

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

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

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

جدول حالات عملي من غير تحويل اللاب إلى هجوم

جهّز مع مسؤول التدريب حسابين: huda ضمن جمهور المشروع، وsaleh خارجه. وجهزهما بهويات تدريب لا تُستخدم في العمل. كذلك جهّز موردًا مطلوبًا FILE01 وموردًا آخر LAB-APP02 ينبغي ألا يدخل التكامل. الهدف أن تراجع حالة السماح وحالة المنع، لأن اختبار الحساب المسموح وحده لا يكشف اتساع الأهلية.

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

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

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

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

اكتب توصية تحافظ على التكامل وحدود الثقة

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

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

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

وش تتذكر من الموضوع؟ SID Filtering يراجع بيانات التخويل التي تعبر الحد، وSelective Authentication يقيّد أهلية المصادقة، وأذونات المورد تحدد العملية المتاحة. فهم كل سؤال على حدة يخليك تقرأ لاب CRTE أو تكامل مؤسسة بصورة أدق من حفظ أعلام True وFalse.

المراجع: قواعد SID Filtering بحسب حدود الثقة: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/55fc19f2-55ba-4251-8a6a-103dd7c66280
قراءة كائن الثقة: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adtrust?view=windowsserver2025-ps
شرح أهلية المصادقة الانتقائية: https://learn.microsoft.com/en-us/dotnet/api/system.directoryservices.activedirectory.forest.getselectiveauthenticationstatus?view=windowsdesktop-9.0
مفاهيم المصادقة وعلاقة الثقة بالتخويل: https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/windows-authentication-concepts