شرح Get-ADTrust واتجاه الثقة: أي دومين يثق بالثاني، ومن يقدر يدخل الموارد؟

تشوف بين دومينين علاقة ثقة، وتقول ممتاز، حسابي بيشتغل هناك. تحاول تفتح موردًا ويرفض. هل العلاقة معطلة؟ يمكن، لكن الرفض قد يكون صحيحًا تمامًا: قبول الهوية لا يعني أن صاحبها مُنح إذنًا على المورد.
هذا الموضوع يبان بسيطًا إلى أن تتداخل كلمات trusted وtrusting وinbound وoutbound. بنرتبه بحالة تدريبية واضحة، ثم نقرأ ناتج Get-ADTrust من منظور محدد ونحوّله إلى أسئلة تحقق عملية. الأمثلة ضمن بيئة تملكها أو نطاق اختبار مصرح، ولا تشمل إنشاء علاقات جديدة أو تغيير حمايتها. وهي مفيدة لمن يدرس لابات متعددة الدومينات، بما فيها المهارات المرتبطة بمسارات مثل CRTE، من دون الادعاء أنها وصف لسؤال أو تجربة اختبار فعلية.

ابدأ بالهويات والموارد، ثم فكّر في السهم

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

اقرأ العلاقة من خادم معلوم

على جهاز إداري مجهز بوحدة ActiveDirectory، اقرأ كائنات الثقة من خادم مصرح بمراجعته:
Get-ADTrust -Filter * -Server dc01.resources.test
ثم اختر حقولًا تساعدك على فهم العلاقة:
Get-ADTrust -Filter * -Server dc01.resources.test | Select-Object Source,Target,Direction,TrustType
هذا استعلام قراءة لكائنات الثقة في المصدر الذي راجعته. لا تتعامل مع ظهور صف على أنه اختبار شامل لسلامة العلاقة أو إثبات أن موردًا معينًا يسمح لحسابك بالدخول. أنت بدأت بجرد الإعداد الموجود في الدليل.
راجع Source وTarget مع اسم الخادم الذي حددته، ثم اكتب المنظور الذي ستفسر منه Direction. لا تنسخ قيمة Outbound إلى التقرير وحدها؛ القارئ يحتاج يعرف من أي جانب جاءت القراءة. كلمة الاتجاه بدون مرجع تشبه قولك «يمين» لشخص واقف أمامك من الجهة المقابلة.
إذا كانت المهمة عن شريك واحد معروف، تقدر تستخدم استعلامًا محددًا بعد التأكد من الاسم:
Get-ADTrust -Identity staff.test -Server dc01.resources.test
الهدف تضييق المراجعة إلى العلاقة المقصودة، لا اعتبار أن اسم دومين ظهر في القائمة صار تلقائيًا جزءًا من نطاق اختبارك. في بيئة عمل، قد توجد علاقات مع جهات أو نطاقات إدارية لا يشملها التكليف. سجّل وجود العلاقة وحدود ما راجعته، واترك أي توسعة اختبار للقرار المعتمد.

فهم Inbound وOutbound بدون حفظ متعب

اتجاه الثقة نسبي للجانب الذي تنظر منه. وفق تعريف البروتوكول، Outbound يعني أن الدومين المحلي في تلك القراءة يثق بالدومين الشريك. وInbound يعني أن الشريك يثق بالدومين المحلي. أما Bidirectional فيصف ثقة في الاتجاهين.
في مثالنا، عندما نقرأ من جانب resources.test ونريد أن يثق بدومين الموظفين، فالاتجاه المقابل لهذا المعنى هو Outbound من منظور دومين الموارد. إذا راجعت العلاقة المقابلة من جانب staff.test، يتغير وصف الاتجاه لأن نقطة النظر تغيرت، وليس لأن التصميم قلب نفسه أثناء استعلامك.
أفضل تمرين أنك تغطي أسماء الاتجاهات مؤقتًا وتكتب المعنى المطلوب بالعربية. بعدها طابقه بالتعريف الموثق من منظور المصدر. هذه الطريقة أبطأ بعشر ثوانٍ في البداية، لكنها تمنع خطأ يضيع عليك وقتًا طويلًا في لاب متعدد الدومينات.
إذا لم يتطابق ما تعرضه الأدوات مع توقعك، راجع أولًا هل تصف نفس العلاقة من نفس الجانب. ثم راجع نوع الأداة وتعريف الحقول التي تستخدمها. لا تفترض أن كل رسم أو تقرير يسمي السهم بالطريقة نفسها، خصوصًا إذا كان يوضح تدفق مصادقة بدل كائن الثقة نفسه.
وفي الملاحظات النهائية، اكتب الاتجاه والمعنى معًا: «قراءة من دومين الموارد؛ الدومين يثق بالشريك المحدد». هذا يجعل التقرير مفهومًا حتى لمن لا يحفظ المصطلحات، ويقلل فرصة أن يفهم مسؤول آخر الجملة بعكس ما قصدته.

الثقة تفتح مسارًا للمصادقة، وليست إذنًا بكل شيء

افترض أن حساب student موجود في staff.test، وأن علاقة الثقة مناسبة للمثال. هذا لا يمنح الحساب تلقائيًا قراءة كل مشاركة ملفات في resources.test. ما زال المورد يحتاج أذونات مناسبة، وقد توجد شروط أخرى تضبط نطاق المصادقة أو الوصول.
للتوضيح، جهّز مسؤول اللاب موردين تجريبيين: واحدًا سمح لحساب التدريب باستخدامه، والثاني لم يمنحه هذا الحق. إذا نجحت تجربة المورد الأول ورُفض الثاني، فقد يكون هذا بالضبط السلوك المطلوب. الرفض ليس عطلًا لمجرد أن العلاقة موجودة.
فرق في التقرير بين التعرف على الهوية، ونجاح المصادقة، والسماح بالعملية المحددة. رسالة رفض واحدة قد تحتاج مزيدًا من المعلومات لتحديد المرحلة التي توقفت فيها. لا تخمن السبب من كلمة عامة أو من صورة مسار في أداة تحليل.
كذلك وجود ثقة ثنائية لا يعني تماثل الأذونات. يمكن أن يكون في الاتجاهين قبول للهويات، بينما تمنح الموارد في كل طرف صلاحيات مختلفة لمجموعات مختلفة. التناظر في علاقة الثقة لا يفرض تناظرًا في تصميم التطبيقات والملفات والمهام.
ومن منظور المراجعة الأمنية، السؤال المفيد ليس «هل توجد ثقة؟» فقط، بل «أي هويات تدخل ضمنها، وما الموارد التي تعتمد عليها، وما الصلاحيات الممنوحة، وهل الحاجة ما زالت قائمة؟». بهذا تنتقل من اكتشاف مكون طبيعي في بنية المؤسسة إلى تقييم استخدامه وحدوده فعليًا.

الانتقالية لا تعني أن كل الغابات صارت شبكة ثقة واحدة

مصطلح Transitive يحتاج تفسيرًا ضمن نوع العلاقة وحدودها. لا تستنتج من وجود علاقة بين بيئتين، وعلاقة أخرى مع طرف ثالث، أن كل الأطراف أصبحت تثق ببعضها تلقائيًا. خصوصًا في علاقات الغابات، لا تختصر الموضوع إلى سلسلة أسهم تمتد بلا حدود.
خلنا نضيف بيئة ثالثة اسمها partner.test. افترض أن عندنا معلومات عن علاقة بينها وبين أحد الطرفين. قبل توقع أي وصول من الطرف الثالث، راجع نوع العلاقة واتجاهها وحدود الانتقالية المطلوبة. وجود الاسم في رسم شامل لا يثبت أن حسابًا منه يمكنه المرور إلى كل مورد في الرسم.
الفكرة العملية أن كل خطوة في المسار تحتاج تفسيرًا. إذا عجزت عن شرح سبب قبول الهوية في انتقال معين، فلا تبنِ بقية الخطة على أنه مفروغ منه. ارجع إلى تصميم اللاب أو توثيق نوع العلاقة أو مسؤول الهوية، وحدد المعلومة الناقصة.
لا يلزم أن تحفظ كل أنواع الثقة قبل أول تجربة. ابدأ بنوع معلوم في اللاب، وافهم حدوده، ثم قارن بنوع ثانٍ بسؤال واضح. التوسع التدريجي أفضل من جمع تعريفات كثيرة ثم تطبيق قاعدة واحدة عليها كلها.
وعند استخدام مرجع خاص بخدمة مُدارة مثل Microsoft Entra Domain Services، فرّق بين المفاهيم العامة وبين القيود والميزات الخاصة بتلك الخدمة. لا تنقل شرط دعم أو قيد تشغيل من منتج مُدار إلى كل بيئات AD DS التقليدية. التشابه في المصطلح لا يلغي اختلاف المنتج والسياق.

كيف تتأكد من مثال وصول بدون تغيير العلاقة؟

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

قراءة النتيجة كمدقق أو مختبر اختراق

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

تمرين اتجاهات: جاوب قبل ما تشوف الناتج

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

المراجع التي تحسم معنى الاتجاه

مرجع قراءة كائنات الثقة:
https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adtrust
تعريف trustDirection في مواصفة Microsoft:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/5026a939-44ba-47b2-99cf-386a9e674b04
شرح العلاقة بين المصادقة والتفويض والثقة:
https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/windows-authentication-concepts
شرح علاقات الغابات، مع الانتباه للسياق الخاص بالخدمة المذكورة فيه:
https://learn.microsoft.com/en-us/entra/identity/domain-services/concepts-forest-trust
في أي مراجعة جديدة، ارجع للأدوار الثلاثة: مصدر الهوية، والطرف الذي يقبلها، والمورد الذي يقرر السماح. بعدها اقرأ الاتجاه من منظور معلوم. بهذه الطريقة تظل المصطلحات أدوات توضيح، بدل أن تتحول إلى كلمات تحفظها وتعيد تفسيرها من الصفر كلما ظهر دومين جديد.