AS-REP Roasting وKerberos Preauthentication: كيف تراجع الحسابات المستثناة وتفهم سبب الاستثناء؟

خيار صغير في حساب Active Directory يقول إن Kerberos Preauthentication غير مطلوبة. قد يمر عليه شخص بسرعة لأنه لا يمنح عضوية إدارية، لكن أثره مختلف: يزيل شرطًا في بداية تدفق مصادقة Kerberos، ويخلق تعرضًا معروفًا يرتبط بـAS-REP Roasting. السؤال المفيد: لماذا فُعّل هذا الاستثناء، وهل ما زال له سبب اليوم؟
نراجع هنا حسابًا تدريبيًا اسمه svc_legacy في lab.test. بنقرأ إعداداته ونربطها بمالك التطبيق وسجلات مصادقة مناسبة، دون طلب بيانات قابلة للتخمين أو استخراج أسرار. الصورة المرفقة من Microsoft تعرض مثالًا قديمًا للحدث 4768 بمصادقة مسبقة من نوع شهادة؛ ليست مثال AS-REP Roasting وليست لقطة من بيئتنا. فائدتها توضيح مواضع الهوية والمصدر ونوع المصادقة المسبقة.

المصادقة المسبقة: وش تحمي في بداية الحوار؟

Kerberos له مراحل، وليس مجرد إرسال اسم مستخدم وكلمة مرور إلى التطبيق. قبل الوصول إلى تذكرة خدمة، توجد مرحلة تتعلق بالحصول على تذكرة مصادقة أولية من KDC. المصادقة المسبقة تضيف شرطًا يقدم فيه العميل دليلًا مناسبًا قبل إتمام هذه العملية وفق الآلية المستخدمة. ليست مساوية للمصادقة الثنائية، وليست نافذة إضافية بالضرورة يراها المستخدم.
تصف Microsoft إعداد DONT_REQUIRE_PREAUTH بأنه يجعل الحساب غير مطالب بمصادقة مسبقة لـKerberos. لا يعني الاسم أن الحساب بلا كلمة مرور أو أن كل طرق دخوله متاحة لأي شخص. لكنه يغير شرطًا مهمًا في التدفق، ولهذا يرتبط بتعرض من نوع مختلف عن محاولة الدخول المباشرة للتطبيق.
AS-REP Roasting يستهدف هذه الحسابات المستثناة، مع محاولة معالجة بيانات استجابة خارج الاتصال المعتاد لاستنتاج سر ضعيف. هذا شرح للمبدأ، وليس خطوات تنفيذ. في مراجعة الإعدادات، يكفي تحديد الحساب المستثنى وفهم الحاجة والأثر كي تبني نتيجة قابلة للنقاش، ولا يلزم جمع مادة حساسة كي يبدو الفحص «عمليًا».
لا تخلطه مع Kerberoasting. هناك التركيز على تذاكر الخدمات وحسابات مرتبطة بها، بينما هنا نقطة البداية استثناء المصادقة المسبقة. قد تتقاطع مشكلات إدارة السر والصلاحيات، لكن شرط كل حالة مختلف. هذا الفرق يساعدك تختار الاستعلام والسؤال الصحيحين بدل استخدام قائمة SPN لمراجعة إعداد لا يتوقف أصلًا على وجود SPN.

القراءة الأولى: حساب واحد، حقول واضحة

في جهاز إدارة مختبر مجهز بـRSAT، ابدأ بحساب معروف: Get-ADUser -Identity svc_legacy -Server dc01.lab.test -Properties DoesNotRequirePreAuth,Enabled,PasswordLastSet,ServicePrincipalNames | Select-Object SamAccountName,Enabled,DoesNotRequirePreAuth,PasswordLastSet,ServicePrincipalNames. هذا أمر قراءة لخصائص إدارية، ولا يطلب كلمة مرور الحساب ولا يحاول تسجيل الدخول به.
إذا كانت DoesNotRequirePreAuth تساوي True، فأنت تقرأ استثناء المصادقة المسبقة. انتبه للاسم المزدوج بالنفي: True هنا لا تعني أن الحماية مفعلة، بل أن عدم طلب المصادقة المسبقة مفعّل. هذه من الأشياء التي تسبب خطأ في التقارير عندما يختصر الكاتب العمود إلى PreAuth ثم ينسى معنى القيمة الأصلية.
اقرأ Enabled بشكل مستقل. حساب معطل ليس نفس حالة حساب نشط يخدم تطبيقًا حاليًا، لكن تعطيله لا يشرح سبب وجود الإعداد ولا يضمن أنه لن يُفعّل لاحقًا. سجل الحالة الحالية وخطة دورة حياة الحساب. لا تمنحه نفس وصف الخطر التشغيلي لحساب مستخدم يوميًا، ولا تتجاهله إذا كان سيعاد تشغيله ضمن مشروع معروف.
أما PasswordLastSet فيعطيك معلومة زمنية، لا حكمًا على جودة السر. وServicePrincipalNames قد تساعد على معرفة دور خدمة، لكنها ليست شرطًا لهذه المراجعة. إذا لم يظهر SPN، لا تستنتج أن إعداد الاستثناء غير مؤثر. الهدف أن تقرأ كل حقل بوظيفته، بدل توقع أن حقلًا واحدًا سيجيب كل أسئلة الهوية.

UserAccountControl: رقم يجمع أعلامًا، مب حالة واحدة

بعض الأدوات تعرض الإعداد بوصف منطقي، وأخرى تعرض userAccountControl كرقم. هذا الرقم يتكون من أعلام بتات تمثل خصائص متعددة. توضح Microsoft أن علم DONT_REQ_PREAUTH قيمته 0x400000، أي 4194304 عشريًا. المهم معرفة وجود هذا البت ضمن القيمة، لا مقارنة الرقم الكامل بهذا العدد على أنه الحالة الوحيدة الممكنة.
لو اجتمع أكثر من علم، تصبح القيمة النهائية مختلفة. لذلك استعلام يبحث عن مساواة userAccountControl لعدد علم واحد قد يفوّت حسابات تحتويه مع أعلام أخرى. عند تفسير تصدير خام، استخدم فهم Bitmask وفق مرجع الأداة، أو اقرأ الخاصية المنطقية عبر وحدة AD إذا كانت متاحة في بيئتك.
لا تخلط هذا العلم مع PASSWD_NOTREQD أو إعداد عدم انتهاء كلمة المرور. الأسماء كلها تخص الحساب، لكنها تمثل سلوكًا مختلفًا. وجود واحد لا يثبت وجود الآخر. وإذا كان تقرير أداة يقول إن عدة إعدادات موجودة، تحقق من كل ادعاء بدل بناء فقرة عامة عن «الحساب بلا حماية».
هذه الدقة تفيد في إعادة الفحص كذلك. ربما عدل الفريق علمًا واحدًا وبقيت القيمة العددية كبيرة بسبب أعلام مشروعة أخرى. الحكم من الرقم وحده قد يعلن أن المعالجة فشلت رغم زوال الاستثناء المقصود. سجل معنى الخاصية التي راجعتها، واحتفظ بالرقم الخام كدليل إضافي، لا بديل عن التفسير.

من صاحب الاستثناء، وما التطبيق الذي يعتمد عليه؟

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

السجلات تعطيك سياقًا، لكنها لا تعوض قراءة الحساب

الحدث 4768 يتعلق بتذكرة المصادقة الأولية TGT على وحدة تحكم الدومين. يعرض بيانات تساعد في ربط الطلب بالهوية والمصدر، ومنها حقل نوع المصادقة المسبقة بحسب نسخة الحدث. وثائق Microsoft تشرح أن إخفاقات محددة تُسجل في 4771 بدلًا من 4768. لذلك لا تتوقع أن حدثًا واحدًا يحتوي كل نجاح وإخفاق وكل تفاصيل الحوار.
الصورة الأصلية المرفقة مثال واجهة قديمة تعرض حسابًا ومصدرًا وPre-Authentication Type بقيمة مرتبطة باستخدام شهادة، مع حقول الشهادة. لا تقرأها كدليل على استثناء المصادقة المسبقة. المقصود تدريب العين على موضع الحقول وفصل هويات المثال عن بيانات مشروعك، لا تقديم لقطة توحي بأن اختبارًا جرى.
عند مراجعة بيئة حديثة، اقرأ XML أو حقول الحدث الفعلية التي توفرها نسختها، وتحقق من المرجع الحالي. تحديثات Windows قد تضيف حقولًا أو تغير عرضًا. إذا كانت صورة توثيق قديمة لا تطابق شاشة خادمك، هذا لا يعني أن سجلك غير صحيح. ابدأ من رقم الحدث والمزود والنسخة وأسماء الحقول الموجودة.
اربط قراءة الحساب مع نافذة أحداث محددة طلبتها من الفريق المسؤول. عدم وجود حدث في هذه النافذة لا يثبت أن الحساب لم يُستخدم في كل حياته، كما أن وجود مصادقة ناجحة لا يثبت أن الإعداد آمن. إعداد الحساب دليل على الحالة المهيأة، والسجل دليل على نشاط مشاهد. الفصل بينهما يمنعك من توسيع معنى أي منهما أكثر مما يحتمل.

سيناريو تحقيق: حساب قديم ظهر في تقرير المراجعة

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

أخطاء تخلي المراجعة تبدو أقوى مما هي

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

تقرير النتيجة وإعادة الاختبار

اكتب العنوان حول إعداد مثبت وحساب ذي وظيفة واضحة. مثال: «حساب خدمة الأرشفة مستثنى من Kerberos Preauthentication دون حاجة موثقة حالية». في التفاصيل ضع مصدر القراءة والوقت والدومين وهوية الحساب وحالته، ثم ما قدمه صاحب التطبيق من تفسير وما بقي يحتاج تحققًا.
اشرح الأثر المرتبط بتعرض AS-REP Roasting دون ادعاء سر استُخرج. حدد حقوق الحساب وانتشاره وجودة عملية إدارة سرّه من الأدلة المتاحة، واذكر القيود. إذا لم تتوفر بيانات استخدام كافية، لا تعوّضها بعبارات واسعة؛ ضع خطوة متابعة واضحة يقدر الفريق ينفذها.
معيار الإغلاق يتضمن زوال الاستثناء غير الضروري في القراءة الحالية، واستمرار وظيفة التطبيق المعتمد، ومعالجة أي حساب منتهي أو حقوق زائدة ضمن النطاق المتفق عليه. إذا كان الاستثناء ما زال مطلوبًا وفق مراجعة موثقة، سجل قرار المخاطر وحدوده وخطة التوافق بدل وضع علامة إصلاح مكتمل.
المفيد في هذا الموضوع أنك تتعلم تربط إعداد حساب صغير بعملية تشغيل كاملة. طالب الشهادة يحتاج يفهم لماذا يتغير تدفق Kerberos، والمختبر يحتاج يعرف كيف يثبت الإعداد دون توسع غير لازم، ومسؤول التطبيق يحتاج خطة تحافظ على الخدمة. لما تكتب بهذه الزاوية، يصير المصطلح قابلًا للفهم والتطبيق بدل أن يبقى اسم هجوم محفوظ.
المراجع: تعريف أعلام الحساب https://learn.microsoft.com/en-US/troubleshoot/windows-server/identity/useraccountcontrol-manipulate-account-properties وتوثيق الخاصية https://learn.microsoft.com/en-us/powershell/module/activedirectory/set-adaccountcontrol ومرجع الصورة والحدث https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768 . أداة التعديل وردت كمرجع لمعنى الخاصية فقط؛ الأمثلة العملية في المقال للاستعلام والتقييم.
إذا اختلفت القراءة بين وحدتي تحكم بعد تغيير حديث، لا تعدل الإعداد مرة ثانية على أساس أن التنفيذ لم ينجح. اطلب من فريق الدليل التحقق من التكرار ووقت التغيير، ثم أعد القراءة من المصدر المتفق عليه. وثق الفرق المؤقت منفصلًا عن الإعداد نفسه؛ قد تكون المسألة وصول بيانات التغيير، لا فشل قرار المعالجة. هذا التفصيل يمنع تكرار تعديلات غير لازمة ويعطي إعادة الاختبار معنى أوضح.