سياسة كلمات المرور في Active Directory: افحص السياسة الفعلية للحساب قبل ما تحكم على الدومين

تفتح إعدادات الدومين وتشوف حدًا أدنى لكلمة المرور، ثم تجد حسابًا له سياسة مختلفة. هل النظام يتجاهل الإعدادات؟ غالبًا السؤال يحتاج ترتيب قبل الحكم. داخل Active Directory يمكن وجود سياسة افتراضية للدومين وسياسات أدق لبعض المستخدمين والمجموعات. عشان كذا صورة واحدة من شاشة الإعدادات ما تكفي لتقول إن جميع الحسابات محمية بنفس الطريقة. هنا نراجع Password Policy وFine-Grained Password Policy بأوامر قراءة، ونفهم الفرق بين إعداد معلن وسياسة ناتجة لحساب محدد. التدريب على دومين lab.test تملكه أو تملك تصريحًا لمراجعته؛ لا نحتاج محاولة تسجيل دخول فاشلة واحدة، ولا تغيير كلمة مرور أي مستخدم.

وش السؤال الذي تريد تجاوب عليه؟

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

في مثالنا هناك مستخدم تجريبي trainee01 وحساب إدارة تجريبي lab-admin01. يريد الفريق التأكد أن السياسة المخصصة للإدارة تنطبق على الثاني فعلًا، وأن الحساب الأول بقي تحت السياسة المقصودة له. مجرد وجود سياسة اسمها AdminsPSO لا يثبت أنها تحكم حساب الإدارة. الاسم يساعدك تتعرف عليها، بينما التطبيق يحتاج قراءة السياسة الناتجة.

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

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

اقرأ السياسة الافتراضية من دومين واضح

من جهاز إدارة تتوفر عليه وحدة ActiveDirectory، ابدأ باستعلام قراءة مباشر:

Get-ADDefaultDomainPasswordPolicy -Identity lab.test -Server dc01.lab.test

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

احفظ أسماء الحقول وقيمها كما ظهرت، ثم اكتب تفسيرك في مساحة منفصلة. من الحقول التي تهم المراجعة MinPasswordLength وComplexityEnabled وPasswordHistoryCount، وإعدادات القفل مثل LockoutThreshold وLockoutDuration وLockoutObservationWindow. لا تحول القيمة إلى حكم قبل تحديد الحساب الذي يفترض أن تنطبق عليه.

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

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

Fine-Grained Password Policy ليست مجرد GPO باسم مختلف

Fine-Grained Password Policies تسمح بتطبيق سياسات مختلفة داخل الدومين على مستخدمين أو Global Security Groups. تسمى الكائنات المرتبطة بها Password Settings Objects، أو PSOs. النقطة العملية أنك قد ترى أكثر من إعداد مشروع في نفس البيئة، فلا تبدأ بافتراض أن الاختلاف دليل على عطل.

راجع سياسة تجريبية محددة بالاسم:

Get-ADFineGrainedPasswordPolicy -Identity LabAdminsPSO -Server dc01.lab.test

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

لا تتعامل مع OU وكأنها الطرف الذي ترتبط به FGPP مباشرة. التصميم الموثق لهذه السياسات يستخدم المستخدمين والمجموعات الأمنية العالمية. إذا قال المسؤول «كل من في OU الإدارة له السياسة الخاصة»، اسأله عن الآلية التي تربط هؤلاء المستخدمين بالمجموعة أو السياسة، ثم تحقق من النتيجة. قد تكون هناك عملية إدارة تؤدي هذا الربط، لكن وجود الحساب في مكان داخل الشجرة ليس الدليل الذي تبحث عنه.

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

اعرف السياسة الناتجة لحساب محدد

للحساب التجريبي الذي تراجعه، شغّل:

Get-ADUserResultantPasswordPolicy -Identity lab-admin01 -Server dc01.lab.test

هذا الأمر يقرأ كائن السياسة الناتجة المرتبط بالمستخدم، وفق حساب السياسة في Active Directory. قد يكون المستخدم مرتبطًا بأكثر من PSO، لكن المطلوب معرفة الذي يحكم الحالة الناتجة. لذلك قراءة أسماء السياسات الموجودة فقط لا تجيب عن سؤال التطبيق.

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

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

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

الطول والتعقيد يصفان شروطًا، مو جودة كل كلمة مرور

MinPasswordLength يخبرك بالحد الأدنى في السياسة التي تقرأها. وComplexityEnabled يخبرك بحالة قواعد التعقيد. لا تساوي بين تفعيل التعقيد وبين وجود كلمة مرور يصعب توقعها فعليًا. قد يختار المستخدم نمطًا متكررًا يحقق شروط الشكل؛ قراءة السياسة وحدها لا تكشف هذا النمط ولا تحتاج أن تجمع كلمات المرور لمعرفة أن الضمان مختلف.

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

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

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

إعدادات Lockout ثلاثة أسئلة مختلفة

LockoutThreshold يحدد الحد المرتبط بمحاولات تسجيل الدخول الفاشلة قبل قفل الحساب. LockoutDuration يتعلق بمدة القفل، وLockoutObservationWindow يرتبط بالفترة اللازمة لإعادة عداد المحاولات الفاشلة. قراءة حقل واحد وترك البقية قد تعطي تصورًا ناقصًا عن سلوك السياسة.

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

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

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

ليش الحساب انقفل رغم أن المختبر جرب مرة واحدة؟

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

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

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

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

تمرين مقارنة: السياسة موجودة، لكن من يستخدمها؟

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

الحالة الأولى: سياسة LabAdminsPSO موجودة، لكن الحساب lab-admin01 تظهر له سياسة أخرى. النتيجة المؤكدة هي اختلاف التطبيق عن التوقع. الخطوة التالية مراجعة الربط والأولوية، لا إعلان أن Active Directory معطّل. إذا اتضح أن السياسة الأخرى مرتبطة مباشرة بالحساب، تصبح لديك علاقة تفسر النتيجة.

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

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

اكتب توصية يمكن التحقق منها بعد المعالجة

النتيجة الجيدة تسمي الحساب أو العينة والسياسة التي قُرئت والاختلاف الذي ثبت. مثال: الحساب الإداري التجريبي لا يستخدم السياسة التي اتفق الفريق أنها مخصصة له، وفق قراءة السياسة الناتجة من dc01.lab.test في وقت المراجعة. هذا وصف قابل للتحقق، بينما «سياسة كلمات المرور ضعيفة» وحدها تترك المسؤول يبحث عن المقصود.

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

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

إذا تبغى تستفيد من الدرس أثناء دراسة CRTP أو مراجعة Active Directory، اسأل دائمًا: هل الأداة عرضت السياسة الافتراضية أم السياسة الناتجة للمستخدم؟ هذا السؤال وحده يمنع كثيرًا من الاستنتاجات المتسرعة.

مراجع الأوامر والسياسات من Microsoft:
https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addefaultdomainpasswordpolicy
https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adfinegrainedpasswordpolicy
https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduserresultantpasswordpolicy
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/fine-grained-password-policies
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/account-lockout-threshold
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after
https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements