شرح Dsacls بالعربي: كيف تقرأ أذونات كائنات Active Directory وتعرف مصدر التفويض؟

في BloodHound ظهرت علاقة تحكم، لكنك تبي ترجع للدليل الذي وراءها. أو عندك مجموعة دعم تستطيع تعديل حسابات قسم كامل، وتبي تعرف هل التفويض مباشر أم جاء من OU أعلى. هنا تفيد Dsacls: أداة تعرض أذونات كائنات Active Directory بصيغة نصية، فتقدر تربط الحق بالهوية والكائن بدل الاكتفاء بسهم في الرسم.
الأداة تستطيع التعديل أيضًا، لذلك أمثلة هذا المقال تقتصر على عرض كائن محدد بدون خيارات تغيير. بنستخدم حسابات ومجموعات وهمية في lab.test، ونركز على تفسير الأذونات وحدودها. الهدف مب حفظ اختصارات كثيرة؛ الهدف أن تعرف أي سؤال يجاوب عنه كل جزء من النتيجة.

أولًا: أذونات كائن الدليل غير أذونات ملف على الخادم

حساب مستخدم في AD كائن داخل الدليل. ملف على خادم كائن في نظام الملفات. كلاهما يمكن أن يملك أذونات، لكن الصلاحيات والعمليات ليست متطابقة. إذا كانت مجموعة تستطيع تعديل خاصية مستخدم في الدليل، لا يعني ذلك تلقائيًا أنها تستطيع قراءة ملفات ذلك المستخدم على كل الأجهزة.
Dsacls هنا تخص كائنات AD DS وفق توثيق Microsoft. لا تعامل ناتجها كفحص شامل لصلاحيات Windows المحلية أو صلاحيات المشاركة أو قاعدة البيانات. إذا كان هدفك معرفة من يستطيع إدارة عضوية مجموعة في الدليل، فهي قراءة مناسبة. وإذا كان السؤال عن وصول ملف، تحتاج دليلًا من طبقة الملف والمشاركة.
خلنا نفترض أن فريق Helpdesk يستطيع تحديث رقم هاتف موظف. هذا تفويض محدود على خاصية، وليس نفس إدارة حسابه بالكامل. وقد يملك فريق آخر القدرة على تغيير عضوية مجموعة مؤثرة. السؤال التقني يجب أن يحدد العملية قبل قراءة ACL، لأن عبارة «عنده Write» بدون كائن وخاصية لا تعطي معنى كافيًا.
ابدأ ورقة العمل بثلاثة عناصر: الكائن المستهدف، العملية التي تراجعها، والهوية المحتمل استفادتها. ثم اقرأ ما يربطها. هذه البداية تمنعك من جمع كل أذونات الدليل ثم البحث عن أي كلمة تبدو خطرة. كلما كان السؤال محددًا، صار الدليل أقل وأوضح، وصارت التوصية قابلة للتطبيق.

حدد الكائن بالاسم المميز قبل تشغيل الاستعلام

Distinguished Name أو DN يحدد موضع الكائن في بنية الدليل. الاسم القصير وحده قد يتكرر أو يشير إلى كائن مختلف عن الذي تقصده. تستطيع قراءة DN لحساب تدريبي معروف مثل: Get-ADUser -Identity trainee01 -Server dc01.lab.test | Select-Object SamAccountName,SID,DistinguishedName. احتفظ بالقيمة التي رجعت بدل تركيبها من تخمين أسماء OU.
لو عُرض DN مثل CN=trainee01,OU=TrainingUsers,DC=lab,DC=test، فهو مثال لحساب في حاوية محددة. لا تفترض أن كل المستخدمين تحت CN=Users، ولا تكتب مسارًا ثابتًا من شرح ثم تستنتج أن الحساب غير موجود عندما يختلف تنظيم مختبرك. نقل الحساب قد يغير DN بينما تبقى هويته؛ لذلك يفيد الاحتفاظ بـSID أيضًا عند المقارنة.
بعد تحديد كائن المختبر، صيغة قراءة بسيطة هي dsacls "CN=trainee01,OU=TrainingUsers,DC=lab,DC=test". يوضح المرجع أن تحديد الكائن بدون معاملات إضافية يعرض ACEs في ACL. لا تضف خيارات رأيتها في قسم أمثلة التعديل بهدف «عرض أكثر»؛ بعض الخيارات تغير الأذونات أو الوراثة.
وثق حساب التنفيذ والوقت ومصدر القراءة. إذا كانت الأداة غير موجودة على جهازك، راجع توفر أدوات الإدارة المعتمدة بدل تنزيل نسخة مجهولة من مكان عشوائي. والمرجع المتاح للأداة ضمن صفحات Windows السابقة؛ طابق المساعدة المحلية مع النسخة الموجودة، ولا تعتبر وصف التوفر القديم دليلًا على أنها مثبتة في كل Windows حديث.

اقرأ كل ACE كسؤال: من، يقدر يسوي وش، وعلى أي جزء؟

ACE مدخل في قائمة التحكم بالوصول. بدل المرور على الناتج بسرعة، حوّل كل مدخل ذي صلة إلى جملة مفهومة: هذه الهوية مسموح لها بعملية محددة على هذا الكائن أو هذه الخاصية ضمن شروط التطبيق المعروضة. إذا لم تستطع تكوين الجملة، تحتاج تتوقف عند تفاصيل المدخل قبل الحكم.
مرجع Dsacls يشرح اختصارات مثل RP لقراءة خاصية، وWP لكتابتها، وWD لتغيير معلومات الأمان، وWO لتغيير معلومات المالك. هذه حقوق مختلفة. القدرة على قراءة خاصية ليست قدرة على تغيير ACL، وتغيير ACL ليس نفس تعديل قيمة تلك الخاصية الآن. لا تختصرها جميعًا تحت «إدارة الحساب» دون توضيح.
يمكن أن تكون ACE مرتبطة بنوع كائن أو خاصية محددة. لذلك ابحث عن القيد المرتبط بالحق، وليس الحق وحده. تفويض كتابة خاصية اتصال لمجموعة دعم مثال مختلف عن تفويض كتابة خصائص أوسع. وإذا ظهرت هوية لا تُحل إلى اسم واضح، احتفظ بمعرفها واطلب مطابقة مناسبة؛ عدم ظهور الاسم لا يبرر تجاهلها أو وصفها بأنها مهاجم.
استخدم ثلاث خانات في الملاحظة: نص الدليل المختصر، تفسيره، وحدود التفسير. مثلًا «كتابة خاصية محددة» ثم «تستطيع جهة الدعم تحديث هذا الحقل» ثم «لا يثبت هذا إدارة كلمة المرور أو المجموعة». هذا الأسلوب يحميك من الاستنتاجات المبالغ فيها، ويساعد قارئ التقرير الذي لا يعرف اختصارات الأداة.

الوراثة: مكان ظهور الحق قد لا يكون مكان إنشائه

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

Allow وDeny: لا تختصر التقييم إلى شعار واحد

نظام الوصول يتعامل مع ACEs وتسلسلها والحقوق المطلوبة. توثيق Microsoft يوضح أن ترتيب المداخل مؤثر، ويميز المداخل الصريحة عن الموروثة في الترتيب المفضل. لذلك عبارة «Deny يفوز دائمًا» بدون شروط قد تضللك عند تفسير حالة مركبة. اقرأ النوع والترتيب والسياق بدل الاعتماد على قاعدة محفوظة وحدها.
كذلك عدم وجود اسم المستخدم مباشرة في ACL لا يعني عدم استفادته؛ قد يستفيد عبر مجموعة. وفي المقابل، اسم مجموعة واسع في المدخل لا يثبت أن المستخدم الذي تختبره عضو فيها حاليًا. تحتاج ربط العضوية والهوية بالحق، ثم تحديد العملية التي تتكلم عنها.
الوثائق تفرق أيضًا بين DACL غير موجودة وDACL فارغة؛ ليستا نفس الحالة. لكن لا تستنتج واحدة منهما من مخرجات ناقصة أو فشل قراءة. رسالة رفض الوصول إلى الأذونات لا تعني أن القائمة فارغة. إذا لم تحصل على عرض صالح، سجل تعذر القراءة كقيد، ولا تحوله إلى حكم على تصميم الوصول.
في حالة تعارض ظاهري بين الأذونات وسلوك اختبار مصرح، راجع الهوية والعملية والطبقة أولًا. ربما تختبر وصول ملف بينما تقرأ كائن AD، أو تقارن جلسة بهوية مختلفة، أو تعتمد على عضوية تغيرت مؤخرًا. لا تبدأ بإضافة Allow أو Deny جديد كي تجعل النتيجة توافق توقعك؛ حل التفسير قبل أي طلب تغيير.

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

إذا ظهر LABTrainingHelpdesk مستفيدًا من حق محدد، اقرأ أعضاء المجموعة ضمن النطاق المسموح. مثال: Get-ADGroupMember -Identity TrainingHelpdesk -Server dc01.lab.test | Select-Object Name,ObjectClass,DistinguishedName. هذا عرض للمستوى المقروء، وليس برهانًا على كل العضويات المتداخلة أو كل من يستطيع التحكم بالمجموعة.
عندما يوجد عضو group، تابع المسار الذي يهم نتيجة الفحص. قد تكون مجموعة فرعية لفريق معين أو تجميعًا تاريخيًا توسع بلا مراجعة. سجل كيف وصلت الهوية للحق، ولا تجمع أسماء من مجموعات مختلفة وتعرضها كأنها أعضاء مباشرين. المسار جزء من الدليل لأنه يحدد نقطة المعالجة.
بعد الأعضاء، اسأل من يستطيع تغيير المجموعة. ACL على المجموعة نفسها قد تكشف تفويضًا آخر. إذا كان فريق غير مقصود يستطيع تعديل العضوية، فهو قادر على التأثير في الجهات المستفيدة من الحق الأول. لكن القدرة على تعديل العضوية ليست نفس الاستفادة الحالية، ويجب أن تظهر بهذه الصياغة في التقرير.
لا تخلط مالك عمل المجموعة مع Owner التقني للكائن. قد يكون قائد فريق مسؤولًا إداريًا عن الطلبات دون أن يكون مالكًا في Security Descriptor، وقد يظهر Owner تقني لا يمثل جهة الموافقة اليومية. كلاهما مفيد، لكن كل واحد يجيب سؤالًا مختلفًا. توثيق الإدارة الجيد يربط الحاجة والملكية وآلية التغيير، ولا يعتمد على خانة واحدة.

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

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

كيف تستخدم المخرجات في تقرير وإعادة فحص؟

اختَر الجزء الذي يثبت الاستنتاج: الكائن والهوية ونوع الحق والقيد ومصدره إن كان موروثًا. أرفقه مع وقت وطريقة قراءة، ثم اشرح الأثر على العملية المحددة. لا يحتاج القارئ كل سطر من ACL كي يفهم سبب النتيجة، لكنه يحتاج معلومات تكفي للتحقق منها دون الرجوع لتخمينك.
إذا قارنت تصديرين، انتبه لتغير الأسماء وترتيب العرض ولغة النظام. اختلاف سطر نصي لا يعني تغير حق، وتشابه اسم لا يعني نفس SID. طابق الهويات والعمليات وقيود التطبيق. أدوات الفروقات النصية تساعدك تلاحظ مواضع، لكنها لا تفسر المعنى الأمني نيابة عنك.
معيار الإغلاق يذكر الحق الذي أزيل أو ضُيق والحاجة التي بقيت. مثلًا يستمر فريق الدعم بتحديث حقول الموظفين المقصودين، لكنه لا يستفيد من حق غير لازم على حساب خدمة. إذا كان يوجد طريق عضوية آخر لنفس الحق، راجعه أيضًا أو اذكره جزءًا مفتوحًا. اختفاء مدخل واحد لا يساوي زوال كل وصول مؤثر.
تعلم Dsacls يضيف لك طريقة للرجوع من ملخص الأداة إلى أذونات الكائن. استخدمها كقراءة محددة، وافهم الفرق بين الخاصية والكائن والوراثة والعضوية، ثم قرر ما الذي يثبت. مب كل حرف W سيطرة كاملة، ومب كل قائمة نظيفة دليل أن الوصول محدود؛ التفسير يأتي من جمع التفاصيل التي تخص السؤال.
المراجع: Dsacls https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc771151(v=ws.11) وDACLs وACEs https://learn.microsoft.com/en-us/windows/win32/secauthz/dacls-and-aces وترتيب ACEs https://learn.microsoft.com/en-us/windows/win32/secauthz/order-of-aces-in-a-dacl . راجع المساعدة المحلية عند اختلاف النسخة؛ المقال لا يقدم معاملات لتغيير أذونات أو إعادة ضبطها.
وإذا أعطاك فريق الهوية تصديرًا بدل القراءة المباشرة، اطلب بيان مصدره وتاريخه والكائنات التي شملها. ملف قديم لا يثبت حالة اليوم، وتصدير الحسابات فقط لا يكشف بالضرورة مصدر التفويض على الحاويات. احتفظ بهذا القيد في التقرير حتى لا يقرأه المراجع كفحص شامل. عند تعذر مطابقة اسم إلى هوية، اجعلها مهمة متابعة محددة، لا تحذف السطر من النتيجة. يمكن أن يكون الحساب من دومين مختلف أو أن العرض لم يحل الاسم، لكن تفسيره يحتاج بيانات إضافية. كل معلومة غير محسومة يجب أن تبقى واضحة لمن يقرر المعالجة، بدل إخفائها داخل لقطة صغيرة يصعب قراءتها.