Windows LAPS في Active Directory: كيف تتأكد أنه يعمل ومن يقدر يسترجع كلمات المرور؟

«عندنا LAPS» إجابة تسمعها كثير عندما تسأل عن حسابات المسؤول المحلية. لكنها بداية المراجعة، مو نهايتها. هل السياسة وصلت للجهاز؟ أي حساب تديره؟ هل حدثت عملية حفظ ناجحة؟ ومن يملك الوصول إلى البيانات المحفوظة؟ إذا ما فرقت بين هذه الأسئلة، قد تعتبر وجود قالب سياسة دليلًا على حماية كل الأجهزة. هنا نراجع Windows Local Administrator Password Solution داخل Active Directory من زاوية عملية: السياسة، التنفيذ، وصلاحيات الاسترجاع. الأمثلة على أجهزة مختبر تملكها داخل lab.test. سنقرأ إعدادات وحقوقًا وسجلات، ولن نعرض كلمة مرور جهاز أو نغيرها لمجرد إثبات أن الميزة موجودة.

حدد المنتج والحساب والجهاز قبل فتح الأدوات

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

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

في سيناريو هذا المقال، نراجع WS01 وWS02 داخل OU تجريبية اسمها LabWorkstations. اتفق الفريق أن كلمات المرور تحفظ في Active Directory، وأن مجموعة دعم محددة تملك الحاجة التشغيلية لاسترجاعها. هذه معلومات تصميم نحتاج مطابقتها مع الأدلة، وليست حقائق نستنتجها من اسم المجموعة.

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

جهة الحفظ جزء من النتيجة، وليست تفصيلًا شكليًا

يسمح Windows LAPS بحفظ كلمة المرور وفق حالة انضمام الجهاز وتصميم الإدارة، ومنها Active Directory أو Microsoft Entra ID في السيناريوهات المناسبة. لهذا السؤال عن جهة الحفظ يسبق اختيار أداة المراجعة. استعلام حقوق على OU داخل الدومين لا يعطيك تقريرًا عن صلاحيات الاسترجاع من جهة سحابية.

في الإعداد BackupDirectory، تذكر Microsoft القيم: صفر لتعطيل الحفظ وفق الميزة، وواحد للحفظ في Microsoft Entra، واثنان للحفظ في Windows Server Active Directory. راجع القيمة الفعلية في سياق الجهاز الذي تفحصه، لا في صورة عامة للسياسة يحتفظ بها الفريق منذ بدء المشروع.

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

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

وجود GPO لا يثبت السياسة التي اختارها الجهاز

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

في المراجعة، اسأل عن المصدر المقصود: Group Policy أم آلية إدارة أخرى؟ ثم راجع الدليل من الجهاز نفسه. يمكنك استخدام تقرير سياسة مناسب من مسؤول المختبر، لكن اربطه بسجلات Windows LAPS التي تصف دورة المعالجة ومصدر السياسة. ليست كل شاشة داخل محرر الإدارة نتيجة تطبيق فعلي.

افترض أن فريقًا عدل PasswordAgeDays في GPO، لكنه ما زال يرى وقت انتهاء قديمًا. تغيير هذا الإعداد وحده لا يعني أن كلمة المرور الحالية دُورت فورًا أو أن وقت انتهائها تغير مباشرة؛ هذه نقطة موثقة في إعدادات Windows LAPS. لا ترفع بلاغًا عن فشل الميزة من هذا الفرق وحده.

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

اقرأ سجل LAPS كسلسلة أحداث، مو رقمًا منفردًا

المسار الموثق في Event Viewer هو Applications and Services Logs ثم Microsoft ثم Windows ثم LAPS ثم Operational. افتحه على جهاز المختبر الذي تراجعه، أو اطلب نسخة محددة منه من المسؤول. اختر فترة زمنية مرتبطة بالسؤال بدل تصدير تاريخ الجهاز بالكامل.

الأحداث 10003 و10004 و10005 تساعدك تميز بداية دورة معالجة السياسة ونهايتها بنجاح أو فشل. الحدث 10021 يصف السياسة عندما تكون جهة الحفظ Active Directory. هذه الأرقام مفاتيح للقراءة، لكنها لا تغني عن نص الحدث وتوقيته والجهاز الذي أصدره.

للتحديث في Active Directory، تذكر Microsoft الحدث 10018 عند نجاح تحديث الدليل بكلمة المرور الجديدة، والحدث 10020 عند نجاح تحديث الحساب المحلي. الفرق بين الدليل والحساب المحلي مهم عندما تبني تسلسلًا زمنيًا. لا تجمع حدثًا من WS01 وآخر من WS02 ثم تصفهما كعملية واحدة ناجحة.

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

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

Find-LapsADExtendedRights يراجع الحقوق، ولا يقرأ السر

من جهاز إدارة مصرح تتوفر عليه وحدة LAPS، استخدم OU تجريبية ذات اسم واضح:

Find-LapsADExtendedRights -Identity LabWorkstations -DomainController dc01.lab.test

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

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

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

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

قراءة الخاصية وفك التشفير طبقتان مختلفتان

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

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

توثيق Windows LAPS يربط تشفير الحفظ في Active Directory بمستوى وظيفة دومين 2016 أو أحدث. لا تخلط Domain Functional Level مع مجرد وجود خادم جديد في البيئة. السؤال يحتاج الخاصية المناسبة وسياق التصميم، وليس اسم إصدار أحد الأجهزة الذي رأيته في قائمة.

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

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

ثلاث حالات تعطيك ثلاثة أحكام مختلفة

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

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

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

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

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

كيف تكتب التقرير وتعيد الاختبار بدون جمع كلمات المرور؟

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

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

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

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

المراجع الرسمية:
https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview
https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-policy-settings
https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-event-log
https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-concepts-overview
https://learn.microsoft.com/en-us/powershell/module/laps/find-lapsadextendedrights?view=windowsserver2025-ps

السؤال الذي يفرق في العمل هو: هل عندنا دليل مناسب لكل طبقة؟ إذا عرفت تجيب عنه، تقدر تراجع LAPS بهدوء وتحدد فجواته بدون ما تجمع أسرار الأجهزة.

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