Protected Users في Active Directory: وش تحمي فعلًا، وليش يفشل الدخول بعد إضافة الحساب؟

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

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

ابدأ بسبب حماية الحساب، وليس برغبة إضافة الجميع

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

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

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

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

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

القيود التي تفسر أكثر حالات الفشل

بحسب متطلبات البيئة الموضحة في توثيق Microsoft، تمنع حماية المجموعة استخدام NTLM لأعضائها، وتقيّد Kerberos إلى AES بدل DES وRC4 في السياق المعني، وتمنع التفويض غير المقيد والمقيد، وتقيد تجديد TGT بعد عمره الأولي الذي يوصف بأربع ساعات. وعلى العميل، تتغير أنواع من التخزين المؤقت، ولا يُنشأ verifier للدخول دون اتصال بالطريقة المعتادة.

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

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

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

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

منع التفويض في الصورة لا يساوي كل حماية المجموعة

الصورة المرفقة تعرض خيار Account is sensitive and cannot be delegated داخل إعدادات الحساب. الخيار مهم لمراجعة التفويض، لكنه لا يعني أن الحساب عضو في Protected Users، ولا يثبت قيود NTLM والتخزين المؤقت وعمر التذاكر المرتبطة بالمجموعة. وفي المقابل، حماية عضو المجموعة من التفويض لا تعتمد على أن هذا المربع ظاهر ومحدد في لقطة الشاشة نفسها.

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

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

كذلك لا تخلط هذه الفكرة مع AdminSDHolder وadminCount. حماية أذونات كائن إداري في الدليل سؤال مختلف عن قيود استعمال بيانات اعتماده في المصادقة. التشابه في كلمة Protected في مقالات مختلفة لا يجعلها آلية واحدة. هذا مهم لأن إصلاح وراثة ACL لا يحل عدم توافق تطبيق مع NTLM، والعكس صحيح.

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

قراءة العضوية والسياق قبل تجربة الدخول

يمكن قراءة العضوية المباشرة للمجموعة داخل لاب مصرح باستخدام: Get-ADGroupMember -Identity 'Protected Users' -Server 'dc01.lab.test'. راجع اسم المجموعة الفعلي في بيئتك وهويتها، وحسابات النتيجة. هذا الأمر مفيد لبدء المراجعة، لكن لا تعمم من عرض محدود أو خطأ قراءة على كل الدومين، واذكر إن كان فحصك اقتصر على قائمة معينة.

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

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

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

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

خطة لاب تقارن طريقة العمل قبل الحماية وبعدها

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

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

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

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

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

إذا فشل التطبيق، شخّص الاعتماد بدل إزالة الحماية

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

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

وللسجلات، توجد قنوات متعلقة بـProtected Users تحت Microsoft ثم Windows ثم Authentication في Event Viewer، ويشرح توثيق Microsoft متطلبات ظهورها ومعاني الأحداث. اقرأ نص الحدث والهوية والجهاز والزمن، لا الرقم فقط. غياب سجل في قناة غير مفعلة أو نافذة لا تشمل المحاولة لا يثبت نجاح الحماية أو غياب محاولة المصادقة.

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

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

كيف تقيس نجاح التطبيق وتكتب الملاحظة؟

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

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

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

وتذكر الفرق الذي توضحه الصورة: منع التفويض خاصية، وProtected Users مجموعة بقيود أخرى، وAdminSDHolder حماية أذونات كائنات محمية. عندما تسمي كل آلية باسمها وتعرف ما تقيسه، يصير شرح حالة فشل الدخول أقرب للتشخيص المهني من تجربة مجموعات حتى يفتح البرنامج.

المراجع: المتطلبات والقيود الحالية للمجموعة: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
مصدر الصورة وتفصيل التوافق والفرق عن خيار التفويض: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/how-to-configure-protected-accounts
حماية سياسات المصادقة وأنواع الهويات: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos