شرح Get-ADGroupMember: ليش المستخدم يوصل للمجموعة واسمه مو ظاهر بين أعضائها؟

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

حالة بسيطة تشرح المشكلة من أولها

تخيل عندنا مجموعة اسمها LabAppReaders. تحتوي مباشرة على الحساب sara وعلى مجموعة اسمها LabFinance. المجموعة الثانية تحتوي على الحساب omar وعلى مجموعة ثالثة اسمها LabInterns، وهذه الأخيرة تضم الحساب nour. جميع الأسماء تدريبية داخل دومين lab.test.
إذا سألت عن الأعضاء المباشرين في LabAppReaders، تتوقع sara وLabFinance. وإذا سألت عن المستخدمين الذين يصلون من خلال التداخل في هذه الحالة المبسطة، تتوقع sara وomar وnour. ظهور nour في القائمة الثانية لا يعني أن حسابها أُضيف مباشرة إلى المجموعة الرئيسية.
ليش يهمك هذا الفرق؟ لأن إزالة عضوية مباشرة غير موجودة أصلًا لن تعالج المشكلة. وقد يوصي شخص بحذف مجموعة LabFinance بالكامل من المورد، مع أن معظم أعضائها يحتاجون الوصول، بينما سبب الوصول الزائد موجود داخل LabInterns. التشخيص الصحيح يوفر تعديلًا أضيق وأقل إرباكًا للعمل.
قبل تشغيل أي أمر، اكتب التوقعين السابقين في ملاحظاتك. هذه ليست خطوة شكلية؛ هي طريقة تكشف لك أنك فهمت التداخل قبل أن تعتمد على الأداة. بعد التجربة، إذا اختلف الناتج، يصير عندك سؤال واضح: أي مستوى من مستويات العضوية لم يظهر كما توقعت؟

تأكد أنك تسأل عن المجموعة الصحيحة

ابدأ بقراءة هوية المجموعة وخصائصها الأساسية:
Get-ADGroup -Identity LabAppReaders -Server dc01.lab.test | Select-Object Name,SamAccountName,GroupCategory,GroupScope,DistinguishedName,SID
الخادم والاسم في المثال للاب تملكه أو مصرح لك بمراجعته. إذا لم تكن وحدة ActiveDirectory متوفرة، جهّز أدوات الإدارة المعتمدة قبل تنفيذ المثال. لا تغيّر اسم الأمر إلى دالة من أداة أخرى وتفترض أن الناتج سيحمل نفس المعنى.
راجع الاسم المميز والمعرف ونوع المجموعة ونطاقها. الاسم الذي يظهر في واجهة إدارية قد يكون متشابهًا مع اسم مجموعة في دومين آخر، أو اسم قديم تتذكره من وثيقة سابقة. تثبيت الهوية يمنعك تبني سلسلة عضويات صحيحة لمجموعة غير المقصودة.
المجموعات الأمنية ومجموعات التوزيع ليستا الشيء نفسه في استخدامات التحكم بالوصول. ونطاق المجموعة يؤثر في قواعد العضويات والاستخدام بين الدومينات. لذلك لا تفترض أن أي تداخل رسمته على الورق مسموح بأي نوع من المجموعات؛ اضبط إعداد اللاب مع المسؤول وفق الأنواع المناسبة.
في ملاحظاتك، افصل الاسم القابل للقراءة عن المعرف. الاسم يخدم التواصل، والمعرف يساعد في التأكد أنك تراجع الكائن نفسه عند المقارنة. لا تحتاج تنسخ كل خاصية في كل تقرير، لكن تحتاج تعرف أي مجموعة بنيت عليها الحكم.

اعرض الأعضاء المباشرين واقرأ نوع كل عضو

شغّل الاستعلام المباشر:
Get-ADGroupMember -Identity LabAppReaders -Server dc01.lab.test | Select-Object Name,SamAccountName,ObjectClass,DistinguishedName
في الحالة الافتراضية السابقة، راجع وجود sara وLabFinance. انتبه إلى ObjectClass؛ الأعضاء قد يكونون مستخدمين أو مجموعات أو أجهزة، فلا تعتبر كل صف موظفًا. عدد الصفوف ليس بالضرورة عدد الأشخاص الذين يستفيدون من المجموعة.
إذا ظهر عضو من نوع group، فهذا ليس سطرًا زائدًا يمكنك حذفه من العرض لمجرد أنك تبحث عن الناس. هو نقطة تحتاج متابعة إذا كان سؤالك عن العضوية المتداخلة. إخفاؤه قبل فهمه قد يزيل الجزء الذي يفسر وصول الحساب الذي تبحث عنه.
احتفظ بالناتج المباشر حتى لو كنت ناوي تستخدم البحث المتداخل بعده. هذا الناتج يثبت المستوى الأول من العلاقة ويحدد أين تبدأ التوسعة. أما الاكتفاء بالنتيجة النهائية فقد يعطيك أسماء صحيحة لكنه يترك سبب ظهورها مجهولًا.
وإذا القائمة المباشرة فارغة أو الاستعلام أخطأ، افصل الحالتين. راجع هوية المجموعة والخادم والاتصال والصلاحية كما تفعل مع أي استعلام إداري. لا تبدأ بإضافة Recursive على أساس أنه يصلح كل نقص؛ هذا المعامل يغير السؤال، ولا يعالج اسمًا خاطئًا أو مشكلة وصول.

وش يسوي Recursive، ووش ما يعطيك؟

جرب الآن:
Get-ADGroupMember -Identity LabAppReaders -Recursive -Server dc01.lab.test | Select-Object Name,SamAccountName,ObjectClass
في المثال، تتوقع ظهور المستخدمين عبر مستويات التداخل. توثيق Microsoft يوضح أن الاستعلام المتداخل يرجع الأعضاء النهائيين في التسلسل بدل إبقاء المجموعات الوسيطة التي تحتوي أعضاء. لذلك قد تحصل على قائمة مفيدة للحصر، لكنها لا تحفظ لك كل خطوة من الطريق إلى كل اسم.
هنا يقع اللبس: تشوف nour في الناتج فتكتب أنها عضو مباشر في LabAppReaders. هذا استنتاج أوسع من الدليل. الصحيح أنها ظهرت ضمن نتيجة مراجعة العضوية المتداخلة في تلك اللحظة، ثم تحتاج تتبع المسار إذا كان هذا هو سؤال المهمة.
قارن استخدامين مختلفين. مسؤول يريد قائمة بالحسابات التي تستحق مراجعة دورية قد يستفيد من الناتج النهائي. ومختبر يريد تفسير سبب وصول حساب قديم يحتاج العلاقات الوسيطة أيضًا. نفس الأداة تخدم الاثنين، لكن الناتج الذي يكفي للأول قد لا يكفي للثاني.
ولا تعتبر الاستعلام المتداخل تقريرًا شاملًا عن كل وصول فعلي للموارد. هو يراجع العضويات المرتبطة بالمجموعة، بينما الوصول إلى تطبيق أو ملف يتطلب معرفة أين تُستخدم المجموعة وما القيود المحيطة. اربط كل نتيجة بسؤالها حتى ما تحمل القائمة أكثر مما تقول.

تتبع حسابًا واحدًا بدل التوسع بلا نهاية

نريد الآن تفسير ظهور nour. ارجع إلى الأعضاء المباشرين للمجموعة الرئيسية، وحدد المجموعة الوسيطة التي راجعتها. ثم اعرض أعضاء تلك المجموعة:
Get-ADGroupMember -Identity LabFinance -Server dc01.lab.test | Select-Object Name,SamAccountName,ObjectClass
في إعدادنا التدريبي ستجد omar وLabInterns. راجع المجموعة الأخيرة بنفس الطريقة:
Get-ADGroupMember -Identity LabInterns -Server dc01.lab.test | Select-Object Name,SamAccountName,ObjectClass
الآن تقدر تكتب المسار بالكلمات: nour عضو في LabInterns، وهذه عضو في LabFinance، والأخيرة عضو في LabAppReaders. كل وصلة في الجملة لها نتيجة مباشرة تراجعها، وليست مجرد تفسير تخميني لقائمة نهائية.
هذا التتبع اليدوي مناسب لفهم حالة صغيرة أو التحقق من مسار محدد. لا يلزم تحول مراجعة بيئة كبيرة إلى مئات الأوامر اليدوية؛ يمكن استخدام أدوات تحليل مناسبة بعد تحديد النطاق، لكن فهم المستوى الواحد يبقى ضروريًا لمراجعة ما تعرضه.
إذا واجهت مجموعة سبق أن زرتها، لا تستمر في توسعة عمياء. سجّل أنك عدت إلى كائن معروف وراجع بنية التداخل. وفي العمل البرمجي، تحتاج معالجة الدورات والتكرار وحدود النطاق، وليس مجرد دالة تستدعي نفسها إلى أن تتوقف من تلقاء نفسها. بساطة اللاب فرصة تفهم هالمشكلة قبل التعامل مع بيانات أكبر.

المستخدم قد يصل من أكثر من طريق

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

العضوية لا تخبرك وحدها بما يستطيع الحساب فعله

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

احفظ العضويات كعلاقات، مو أسماء مبعثرة

للمراجعة الصغيرة، يمكن حفظ الأعضاء المباشرين في متغير:
$directMembers = Get-ADGroupMember -Identity LabAppReaders -Server dc01.lab.test
ثم إضافة اسم المجموعة المستهدفة إلى كل صف عند التصدير:
$directMembers | Select-Object @{Name='ParentGroup';Expression={'LabAppReaders'}},SamAccountName,ObjectClass,DistinguishedName | Export-Csv -Path 'labappreaders-direct.csv' -NoTypeInformation -Encoding UTF8
هذا يجعل معنى الصف واضحًا عند فتح الملف لاحقًا. بدون اسم المجموعة الأم قد تجمع عدة ملفات ثم تنسى إلى أي مجموعة ينتمي كل عضو. راجع وجود ملف سابق قبل التصدير، واستخدم اسمًا جديدًا إذا كنت تحتاج الاحتفاظ بالجولة الماضية.
للمجموعات الوسيطة، احتفظ بنتائجها المباشرة مع نفس السياق. لا تضع قائمة المستخدمين النهائية وقائمة العلاقات في نفس العمود وتسميهما «الأعضاء» فقط. في ملف المراجعة، يحتاج القارئ يعرف هل الصف يمثل علاقة مباشرة أو اسمًا خرج من توسعة متداخلة.
أضف وقت الاستعلام والخادم في سجل العمل المصاحب، وراجع الأحرف العربية والتنسيق إذا ستشارك الملف. لا يلزم أن يكون كل شيء داخل جدول واحد ضخم. المهم أن يقدر المراجع إعادة بناء الدليل من الملفات والملاحظات، وأن تكون البيانات محفوظة في المكان المصرح به.

لما تظهر أسماء غريبة أو تفشل التوسعة

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

تمرين إصلاح يختبر فهمك للمسار

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

مراجع تساعدك تكمل المراجعة

مرجع Microsoft للأعضاء المباشرين والمتداخلين وحدود الأمر:
https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adgroupmember
مرجع قراءة هوية المجموعة وخصائصها:
https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adgroup
شرح المجموعات الأمنية ونطاقاتها:
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups
إذا احتجت قراءة خصائص حساب ظهر ضمن الأعضاء، ارجع لشرح Get-ADUser في المجتمع:
https://courses.cyberpts.com/community/63/shrh-get-aduser-abhth-an-mstkhdmy-aldwmyn-wafhm-alkhsays-walntayj-alfarghh
في المراجعة القادمة، لا تسأل «هل الاسم موجود؟» فقط. اسأل كيف وصل إلى المجموعة، وهل توجد طرق أخرى، وما المورد الذي يعتمد عليها. الأداة تعطيك أجزاء مهمة من الإجابة، ودورك تربطها بأدلة واضحة وتعرف متى تحتاج معلومة إضافية من مالك النظام.