Security Filtering وWMI Filtering في GPO: ليش السياسة تنطبق على جهاز وتتجاوز الثاني؟

عندك جهازان في لاب Active Directory، وكلاهما داخل OU نفسها. تفتح إعدادًا أمنيًا فتلقاه مطبقًا على الأول، والثاني ما تغير فيه شيء. أول تفسير يجي في البال: «السياسات علّقت، خلنا نشغّل gpupdate». أحيانًا المشكلة فعلًا في المعالجة، لكن تكرار التحديث ما يحل شرطًا يمنع السياسة من الأساس.

المفيد هنا أن تفصل بين ثلاث أسئلة: هل الجهاز أو المستخدم داخل نطاق ارتباط السياسة؟ هل الهوية مسموح لها بتطبيقها؟ وهل الجهاز يحقق الشرط التقني الموجود في WMI Filter؟ هذه أسئلة مختلفة، حتى لو ظهرت لك في صفحة واحدة داخل Group Policy Management. بنمشي على حالة تدريبية ونشوف كيف تبني تشخيصًا تقدر تدافع عنه، بدل تغيير مجموعة أذونات وانتظار الحظ. الصورة أدناه من توثيق Microsoft الأصلي، وتوضح مكان الفلترين في Scope؛ أسماء الدومين فيها تخص مثال Microsoft، وليست نتيجة فحص لشبكة حقيقية عندنا.

ابدأ من الإعداد المطلوب، مب من اسم السياسة

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

خلنا نفترض سياسة اسمها Lab-Desktop-Restrictions يفترض أنها تغير خيارًا في سطح مكتب مستخدمي مجموعة Lab-Students. المستخدم الأول يرى الخيار الجديد، والثاني لا يراه. لو بدأت بفحص مجموعة أجهزة الكمبيوتر فقط، قد تقضي ساعة في المكان الخطأ؛ الإعداد هنا تابع للمستخدم. وبالمقابل، وجود المستخدم في المجموعة المطلوبة ما يفسر بمفرده إعدادًا داخل Computer Configuration، لأن حساب الجهاز له دوره الخاص.

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

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

الارتباط يحدد المرشحين، والفلتر يضيّقهم

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

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

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

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

Security Filtering يسأل: أي هوية يحق لها التطبيق؟

Security Filtering يعتمد على أذونات السياسة والهوية التي تُقيّم، مثل مستخدم أو جهاز وعضوياتهما في مجموعات الأمان. القاعدة الأساسية لتطبيق السياسة هي وجود Read وApply Group Policy للهوية المعنية. لكن واجهة Scope تختصر العرض، لذلك تحتاج أحيانًا إلى Delegation وAdvanced لفهم الأذونات الفعلية، خصوصًا حين تختلف القراءة عن التطبيق.

وش المقصود هنا؟ أن القدرة على قراءة تعريف سياسة ليست هي السماح بتطبيقها. ممكن تمنح حسابًا Read حتى يستطيع جلب المعلومات المطلوبة، من غير أن تمنحه Apply Group Policy. وممكن تكون المجموعة التي تريد استهدافها لديها الإذنان، بينما حساب آخر يحتاج القراءة لدوره في المعالجة فقط. لهذا لا تعتمد على أن كل اسم ظاهر في Delegation يعني أنه ضمن جمهور السياسة.

في الحالة التدريبية، راجع عضوية sara في Lab-Students من مصدر الدومين، ثم راجع سياق الجلسة الحالية بشكل منفصل. ما تقرؤه الآن من الدليل وما تحمله جلسة بدأت قبل تعديل العضوية ليسا دائمًا قياسًا واحدًا. سجّل وقت التغيير ووقت تسجيل الدخول، ولا تعالج اختلافًا زمنيًا بمنح أذونات أوسع.

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

WMI Filtering يسأل عن الجهاز الذي يعالج السياسة

أما WMI Filter فهو شرط تقني يُقيّم على الجهاز أثناء معالجة Group Policy. قد يستهدف نوع نظام أو خاصية نظام مناسبة للتصميم. إذن نحن أمام سؤال عن حالة الجهاز، وليس مجرد سؤال عن عضوية المستخدم. يمكن للمستخدم نفسه أن يجد السياسة مطبقة على جهاز وتُستبعد على جهاز آخر لأن شروط الجهازين مختلفة.

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

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

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

حالة Read المفقودة: لماذا قد يتعطل إعداد مستخدم؟

هناك تفصيلة تستحق الوقوف عندها لأنها تربك كثيرًا من المتعلمين: استهداف إعدادات المستخدم لا يلغي احتياج حساب الكمبيوتر إلى قراءة السياسة. توثيق Microsoft يشرح أن جلب سياسات المستخدم يستخدم السياق الأمني للكمبيوتر منذ التغيير المرتبط بتحديث MS16-072. لذلك إزالة Authenticated Users من Security Filtering قد تزيل معه صلاحيات قراءة كانت الأجهزة تعتمد عليها.

المعالجة الصحيحة ليست افتراض أن الحل دائمًا إعادة Authenticated Users بكل صلاحياتها السابقة. المطلوب فهم من يحتاج Read ومن يحتاج Apply، ثم مراجعة تصميم المؤسسة مع المسؤول. توثيق Microsoft يعرض منح القراءة لهويات الكمبيوتر المناسبة مع الاحتفاظ باستهداف التطبيق المطلوب. هذه نقطة أذونات محددة، وليست دعوة لمنح مجموعات واسعة Full Control.

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

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

اجمع النتيجة من العميل ثم ارجع إلى التصميم

أداة gpresult مفيدة لأنها تقرأ نتيجة Group Policy على الجهاز وفي السياق الذي تختبره، بدل الاكتفاء بالتصميم الذي تشاهده من وحدة الإدارة. في لابك يمكنك إخراج تقرير محلي باسم واضح، مثل: gpresult /h lab-pc02-policy.html. هذا يكتب ملف تقرير على جهازك؛ اختر مكانًا مسموحًا ولا ترفعه كما هو إلى مجتمع عام، لأنه قد يحتوي أسماء حسابات وأجهزة وتفاصيل تنظيمية.

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

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

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

تجربة مقارنة تعلّمك أكثر من تحديث متكرر

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

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

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

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

كيف تكتب الملاحظة الأمنية وتربطها بالضابط؟

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

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

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

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

للتوسع والتحقق: توثيق نطاق السياسات: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-scope
معالجة السياسات وWMI: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-processing
مصدر الصورة وتفصيل قراءة سياسات المستخدم: https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/cannot-apply-user-gpo-when-computer-objects-dont-have-read-permissions