شرح SID في Active Directory: ليش الحساب بنفس الاسم ما يرجع له نفس الوصول؟

رجع موظف إلى الشركة، وأنشأ الفريق حسابًا جديدًا بنفس اسم حسابه القديم. تسجيل الدخول يعمل، لكن المجلد الذي كان يستخدمه يرفض الوصول. وفي مختبر آخر، حساب اسمه Administrator لا يملك الصلاحيات التي توقعها المتدرب. وش الرابط بين الموقفين؟ الاعتماد على اسم الحساب بدل هويته الأمنية. الـSecurity Identifier، أو SID، يساعدك تفهم من هو الطرف الموجود في قائمة الصلاحيات، بينما الاسم مجرد طريقة أسهل لعرضه. هذا المقال يشرح كيف تقرأ SID وتربطه بالحساب والمجموعة والجلسة، وكيف تحول اختلافًا في الوصول إلى سؤال واضح يمكن اختباره. الأمثلة تخص دومين تجريبي تملكه باسم lab.test، ولا تحتاج حذف حسابات أو تغيير عضويات في بيئة عمل حتى تتعلم الفكرة.

ابدأ بالهوية، مو بالاسم الظاهر

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

تعرّف Microsoft الـSID بأنه معرّف أمني يستخدم لتمييز المستخدم أو المجموعة. يظهر داخل عناصر مثل Access Token وAccess Control Entry. شرح الفكرة المختصر: عندما تعرض واجهة الصلاحيات اسم مجموعة LabReaders داخل الدومين، فهي تساعدك تقرأ القائمة، لكن الطرف الأمني الذي يشير إليه السجل له SID. لذلك تغيير الاسم وحده مختلف عن إنشاء طرف جديد.

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

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

اقرأ شكل SID بدون ما تحول آخر رقم إلى رتبة

قد ترى قيمة توضيحية مثل S-1-5-21-111111111-222222222-333333333-1107. الأرقام هنا تعليمية، وليست معرفًا مأخوذًا من شركة. في SID لحساب دومين من هذا الشكل، الجزء الأخير هو Relative Identifier أو RID، وما يسبقه يحدد سياق الدومين الذي أصدر المعرف. الاحتفاظ بالقيمة كاملة أهم من حفظ الرقم الأخير وحده.

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

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

هناك أيضًا Well-known SIDs لبعض الهويات والمجموعات المعروفة. ليست كل القيم التي تراها في جلسة ويندوز حسابات موظفين داخل الدومين. إذا صادفت معرفًا لمجموعة مدمجة، ارجع إلى توثيقه بدل محاولة البحث عنه كمستخدم في Active Directory. أول فرز مفيد هو: حساب دومين، طرف محلي، أم هوية معروفة للنظام؟ وبعد ذلك تختار مصدر الاستعلام المناسب.

whoami: اقرأ سياق الجلسة التي تعمل منها الآن

من نافذة أوامر على جهاز المختبر، ابدأ بأوامر قراءة بسيطة:

whoami
whoami /user
whoami /groups
whoami /priv

الأول يعطيك اسم الحساب في السياق الحالي. الخيار /user يضيف SID الخاص بالمستخدم، و/groups يعرض مجموعات هذا السياق، و/priv يعرض الامتيازات الأمنية. لا تجمع المخرجات لمجرد أنها كثيرة؛ اربط كل أمر بسؤال. هل النافذة تعمل بالحساب المتوقع؟ ما المعرف الذي يجب مطابقته مع قائمة الصلاحيات؟ هل توجد مجموعة مرتبطة بالوصول الذي تراجعه؟

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

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

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

وجود المجموعة في المخرجات يحتاج قراءة Attributes

سطر المجموعة لا يساوي دائمًا تصريحًا فعالًا بكل ما تسمح به تلك المجموعة. لكل SID داخل التوكن خصائص تؤثر في استخدامه أثناء فحص الوصول. من أهم الفروق التعليمية أن SID المعلّم Deny only يمكن استخدامه مع قواعد المنع، بينما لا يستخدم لمنح الوصول من قواعد السماح. لذلك اقرأ خانة Attributes بجانب الاسم والمعرف.

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

كذلك لا تخلط Group Membership مع Privilege. مجموعة تعطي وصولًا عبر قائمة صلاحيات تختلف عن امتياز أمني يظهر في whoami /priv. اقرأ اسم الامتياز وحالته، ولا تجعل كل سطر في النافذة دليلًا على تصعيد صلاحيات. قد تكون الأداة قد كشفت وصفًا للسياق فقط، ولم تثبت أي تجاوز لحدود الحساب.

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

Get-ADUser: طابق الحساب داخل الدليل مع الجلسة

إذا كانت وحدة ActiveDirectory متاحة على جهاز إدارة مصرح، اقرأ حسابًا محددًا بدل جمع جميع المستخدمين:

Get-ADUser -Identity trainee01 -Server dc01.lab.test -Properties SIDHistory | Select-Object SamAccountName,SID,ObjectGUID,DistinguishedName,SIDHistory

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

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

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

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

SID غير محلول في ACL: لا تحذفه قبل ما تعرف قصته

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

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

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

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

SIDHistory: افهم الاعتماد القديم قبل اقتراح إزالته

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

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

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

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

تمرين عملي: ثلاث حالات، وثلاثة استنتاجات مختلفة

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

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

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

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

كيف تكتب النتيجة بحيث يفهمها المسؤول؟

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

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

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

مراجع Microsoft للهوية وأوامر القراءة:
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/whoami
https://learn.microsoft.com/en-us/windows/win32/secauthz/sid-attributes-in-an-access-token
https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduser