adminCount=1 ما يعني أن الحساب Domain Admin: افهم AdminSDHolder قبل ما تكتب نتيجة أو تصلح الوراثة

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

هذا الموضوع يفيدك إذا تذاكر Active Directory أو تتعامل مع نتائج أدوات المراجعة في لاب CRTP وCRTE. ويفيدك كذلك لو أنت مسؤول دعم، والمفوض له إدارة OU يقدر يعدل أغلب حساباتها إلا حسابًا واحدًا. بنفصل بين حماية الحسابات الإدارية، وتعطيل الوراثة، وبقايا حالة قديمة؛ ثم نبني فحص قراءة واضحًا من غير تعديل قالب حساس أو فتح صلاحيات على مستوى الدومين.

المشكلة التي يحاول AdminSDHolder حلها

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

في كل دومين يوجد كائن AdminSDHolder داخل System، ويُستخدم قالبًا لأذونات الحسابات والمجموعات المحمية. تشرح Microsoft أن مراجعة أذونات هذه الكائنات تجري افتراضيًا كل ستين دقيقة على وحدة التحكم الحاملة لدور PDC Emulator، وتعيد الأذونات وفق القالب عندما تختلف عنه. كذلك تكون وراثة الأذونات معطلة على الكائنات المحمية، فلا يكفي نقلها بين OU لتغيير الأذونات الموروثة عليها.

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

في المراجعة المهنية، اسأل أولًا: ما الحساب أو المجموعة التي تفحصها، وما العضوية التي تجعلها ضمن مجموعة الحماية في هذا الدومين؟ لا تبدأ بسؤال «كيف أعطل الحماية؟» لأن الفشل في تعديل حساب إداري من حساب دعم قد يكون السلوك السليم الذي صُمم التفويض لتحقيقه.

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

فرّق بين العضوية الحالية وadminCount وحالة ACL

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

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

خلنا نقارن حالتين: حساب train-admin ما زال عضوًا في مجموعة محمية، وحساب old-operator أزيلت عضويته الإدارية لكن بقيت الخاصية وحالة الوراثة. البحث البسيط عن adminCount قد يعرض الاثنين في الصف نفسه. لكن تفسيرهما وتوصية التعامل معهما مختلفان. الأول قد يعمل وفق التصميم الحالي، والثاني يحتاج مراجعة آثار انتقال الدور، وربما أذونات قديمة أو تفويض لا يصل إليه.

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

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

فحص حساب واحد أفضل من تنظيف قائمة كاملة

ابدأ بحساب تدريبي محدد على وحدة تحكم معروفة. باستخدام وحدة ActiveDirectory في PowerShell، يمكن قراءة مثال مثل: Get-ADUser -Identity 'old-operator' -Server 'dc01.lab.test' -Properties adminCount,memberOf | Select-Object SamAccountName,DistinguishedName,adminCount,memberOf. الأمر يطلب خصائص ويعرضها؛ لا يغيّر الحساب، ولا يمنحك وحده كل العضويات المتداخلة أو صلاحياته على الموارد.

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

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

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

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

سيناريو دعم: الحساب داخل OU لكن التفويض ما يوصل إليه

عند فريق الدعم تفويض لإدارة خاصية محددة في OU اسمها Training-Users. الموظف التجريبي nasser موجود داخلها، وبقية حسابات التدريب تستجيب للعملية المسموح بها. حساب nasser وحده يرفضها. هنا البداية ليست توسيع التفويض إلى Full Control، بل مقارنة وصول الإذن إلى الكائنين المتشابهين.

راجع ACL لحساب تدريبي يعمل كما هو متوقع ولحساب nasser، ثم راجع adminCount والعضويات ذات العلاقة. إذا كانت الوراثة معطلة على nasser، فقد يفسر ذلك لماذا لا يحمل إذن OU الذي يحمله الآخر. لكن يبقى سؤال السبب: هل الحساب محمي حاليًا، أم توجد حالة حماية قديمة، أم أن الوراثة عطلت لغرض مختلف؟ المقارنة تثبت الفارق ولا تثبت تاريخ حدوثه وحدها.

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

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

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

لا تعتبر تعطيل الوراثة ثغرة، ولا تعتبره ضمان أمان

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

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

وفي تقييم AdminSDHolder نفسه، لا تفترض أن كل Read يعني سيطرة، ولا تساوي بين قراءة خصائص وبين تعديل ACL. ركز على العملية المحددة التي تسمح بها كل ACE، والهوية المستفيدة، وما إذا كان الإذن يمتد إلى كائنات حساسة عبر الآلية. هذا يختلف عن عدّ الأسماء أو البحث عن كلمة Allow فقط.

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

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

متى تكون النتيجة تشغيلية، ومتى تصبح أمنية؟

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

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

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

وبالنسبة للتوصية، لا تستخدم «امسح كل adminCount=1» كمعالجة جماعية. الحسابات المحمية الحالية قد تعتمد على التصميم الذي تحاول محوه، والحسابات القديمة قد تحمل تفاصيل مختلفة. المطلوب فرز الحالة وتحديد دور كل حساب، ثم مراجعة الأذونات المتوقعة وتصحيح الكائنات التي ثبتت حاجتها بطريقة يديرها المسؤول.

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

تمرين لاب: ثلاثة حسابات وثلاثة استنتاجات مختلفة

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

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

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

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

المراجع الأساسية: شرح Microsoft للحسابات المحمية وAdminSDHolder: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory
تفصيل بقاء الخاصية وتعطيل الوراثة بعد خروج الحساب من مجموعة محمية: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/reducing-the-active-directory-attack-surface
مراجعة المفاهيم الشائعة حول الآلية: https://techcommunity.microsoft.com/blog/askds/five-common-questions-about-adminsdholder-and-sdprop/396293