استكشاف أخطاء Conditional Access في Entra ID: رموز AADSTS وأداة What If (2026)

آخر تحديث: 9 أغسطس 2026

عندما يُحظر تسجيل دخول مستخدم في Microsoft Entra ID بسبب سياسة وصول مشروط (Conditional Access)، فإن الطريقة الأسرع لتحديد السبب هي فتح سجلات تسجيل الدخول (Sign-in logs)، والانتقال إلى تبويب Conditional Access، ثم قراءة رمز الخطأ AADSTS الظاهر بجانب الطلب الفاشل، وهذا يخبرك بالسياسة والعنصر المحدد (Grant Control أو Session Control) الذي لم يستوفه المستخدم. في هذا الدليل، أستعرض من موقعي كأدمن أنظمة أدواتِ التشخيص التي أعتمد عليها يومياً: What If، Sign-in Diagnostics، استعلامات KQL في Log Analytics، وحسابات الطوارئ (Break-Glass) التي تنقذك عندما تحظر نفسَك بسياسة جديدة.

• رمز الخطأ AADSTS53003 يعني BlockedByConditionalAccess، ويظهر فقط عند الحظر الفعلي، وليس عند طلب MFA الروتيني.
• افتح Entra admin center → Monitoring → Sign-in logs → تبويب Conditional Access لرؤية كل سياسة قُيّمت للطلب ونتيجتها (Success / Failure / Not applied / Report-only).
• أداة What If تحاكي تسجيل الدخول بلا حاجة إلى فشل فعلي: تختار المستخدم والتطبيق والموقع وحالة الجهاز، فتخبرك بالسياسات التي ستُطبَّق.
• وضع Report-only يقيّم السياسة ويسجّل النتيجة بدون فرضها. استخدمه دائماً قبل تفعيل أي سياسة جديدة لمدة 7 أيام على الأقل.
• احتفظ بحسابَي Break-Glass مستثنيَين من جميع سياسات CA، مع تنبيهات على أي تسجيل دخول لهما، وامتحن سيناريو الاسترداد كل 90 يوماً.
• سجلات تسجيل الدخول تُحفظ 30 يوماً افتراضياً، لذا فعّل التصدير إلى Log Analytics أو Storage Account للاحتفاظ الأطول والتحليل بلغة KQL.

كيف تحدد سياسة الوصول المشروط التي حظرت المستخدم؟

الخطوة الأولى في أي تذكرة "لا أستطيع تسجيل الدخول" هي التوجّه إلى Microsoft Entra admin center بصلاحيات Reports Reader على الأقل، ثم Identity → Monitoring & health → Sign-in logs. سجّل الدخول الفاشل يظهر عادةً خلال ثوانٍ، وقد يستغرق حتى دقيقتين في بعض التوترات. لتضييق النطاق بسرعة، أستخدم دائماً هذه المرشحات: Username يساوي بريد المستخدم، Status = Failure، والنطاق الزمني آخر ساعة.

بعد فتح السجل، انتقل إلى تبويب Conditional Access. هنا ستجد كل سياسة قُيّمت لهذا الطلب، مع نتيجة كل واحدة:

• Success: طُبِّقت السياسة والمستخدم استوفى شروطها.
• Failure: طُبِّقت السياسة والمستخدم لم يستوفِها (هذا هو المذنب في أغلب الحالات).
• Not applied: لم تنطبق الشروط (Assignment) على هذا الطلب أصلاً.
• Report-only: Success / Failure: السياسة في وضع تقرير فقط، ولم تُفرض فعلياً.

اضغط على السياسة ذات نتيجة Failure لترى تفصيل Grant controls وSession controls، والعنصر المحدد الذي لم يستوفَ (مثلاً Require multifactor authentication، أو Require compliant device). هذا التفصيل موجود في وثائق Microsoft الرسمية لاستكشاف أخطاء Conditional Access، وهو المرجع الأول قبل أي تشخيص أعمق.

إذا كان المستخدم قد اتصل بك تلفونياً، اطلب منه Correlation ID من صفحة الخطأ ذاتها (يظهر عادةً أسفل رسالة "حدث خطأ"). هذا المعرّف يتيح لك العثور على الطلب المحدد في ثوانٍ بدلاً من التقليب بين مئات السجلات. صراحةً، من قواعدي: لا أبدأ التشخيص أبداً من الاتصال بالمستخدم. أفتح السجل أولاً، أفهم القصة، ثم أهاتفه بحلٍّ جاهز.

رموز أخطاء AADSTS الشائعة في Conditional Access ومعانيها

رموز AADSTS هي لغة تشخيصية دقيقة؛ كل رقم يعني شيئاً محدداً، وحفظ أهمها يوفر ساعات من البحث. في تجربتي، خمسة رموز تغطي نحو 80% من تذاكر Conditional Access. الجدول أدناه يلخصها كمرجع سريع، ثم أشرح كل واحد تفصيلياً:

الرمز	الاسم التقني	المعنى بالعربية	الإجراء الأول
AADSTS53003	BlockedByConditionalAccess	حظر مباشر بواسطة سياسة CA	افتح تبويب Conditional Access في السجل
AADSTS50076	UserStrongAuthClientAuthNRequired	مطلوب MFA (وليس فشلاً)	تحقق أن المستخدم أكمل تسجيل طرق المصادقة
AADSTS50158	ExternalSecurityChallengeNotSatisfied	تحدٍّ خارجي لم يُستوفَ (غالباً Terms of Use)	راجع سياسة Terms of Use أو مزود MFA خارجي
AADSTS700003	DeviceObjectNotFound	كائن الجهاز محذوف من التنانت	أعد تسجيل الجهاز أو راجع Audit log للحذف
AADSTS70043	TokenExpired (SignInFrequency)	انتهت مدة Sign-in Frequency	مصادقة تفاعلية مطلوبة، وهو سلوك متوقع

AADSTS53003 والحظر الفعلي

هذا الرمز يعني أن الاعتماديات كانت صحيحة، لكن سياسة CA فرضت Block access. الأسباب الأكثر شيوعاً: تسجيل من موقع خارج Named locations المسموحة، أو جهاز غير متوافق (Non-compliant)، أو استخدام Legacy authentication يُحظره Security Defaults من Microsoft. الحل يبدأ دائماً من تبويب Conditional Access في السجل، لا من تخمين ما قد يكون خاطئاً.

AADSTS50076 وطلب MFA وليس فشلاً

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

AADSTS50158 والتحدي الخارجي

هذا الرمز يظهر غالباً مع سياسات Terms of Use (المستخدم لم يقبل الشروط بعد)، أو مع مزودي MFA خارجيين (Duo, Okta) يعمل CA على تفويض المصادقة إليهم. إذا رأيت هذا الرمز، افتح Identity → Governance → Terms of use وتحقق من قبول المستخدم للنسخة الحالية.

AADSTS700003 وكائن الجهاز المحذوف

يحدث عندما يعتمد CA على سياسة "Require Hybrid Entra joined device" أو "Require compliant device" ثم يُحذف كائن الجهاز من التنانت (يدوياً أو تلقائياً بعد فترة عدم نشاط). راجع Audit logs بتصفية Activity = "Delete device" لمعرفة متى ومن حذفه، ثم أعد تسجيل الجهاز عبر dsregcmd /leave ثم dsregcmd /join.

أداة What If: محاكاة تسجيل الدخول قبل النشر

What If هي أداة المحاكاة الرسمية داخل Entra، وهي منقذة قبل نشر أي سياسة جديدة. توجّه إلى Entra admin center → Protection → Conditional Access → Policies → What If. تختار الحقول التالية لبناء سيناريو تسجيل دخول افتراضي:

1. User or workload identity: المستخدم أو Service principal المستهدف.
2. Cloud apps or actions: التطبيق (مثلاً Office 365، Exchange Online، Intune).
3. IP address: لمحاكاة موقع جغرافي محدد.
4. Device platform: Windows, iOS, Android, macOS.
5. Client apps: Browser, Modern authentication clients, Exchange ActiveSync.
6. Device state: Compliant, Hybrid joined.
7. Sign-in risk: None, Low, Medium, High.

اضغط What If فيعرض قسمَين: Policies that will apply وPolicies that will not apply. لكل سياسة "لن تُطبَّق"، يخبرك السبب الدقيق (مثلاً: المستخدم مستثنى، أو التطبيق ليس ضمن Assignments). هذا يوفّر عليك بناء طلب حقيقي فاشل لاختبار السياسة.

لأتمتة الاختبار عبر عدة مستخدمين، استخدم Microsoft Graph API لـ Conditional Access. يمكنك استعلام endpoint اسمه /identity/conditionalAccess/evaluate ببرمجة بسيطة وتشغيل مصفوفة سيناريوهات دفعة واحدة.

استخدام Sign-in Diagnostics لتحقيق سريع

عندما لا يكون لديك وقت لقراءة كل تفاصيل السجل، توفّر Microsoft Sign-in Diagnostics، وهو معالج تشخيص مؤتمت يحلل السجل ويقدّم تشخيصاً بلغة طبيعية. للوصول: افتح السجل الفاشل ثم اضغط زر Launch the Sign-in Diagnostic في الشريط العلوي.

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

خطوات التشخيص العملية (Runbook)

1. افتح Sign-in logs، ابحث بـ UPN وحدد فترة زمنية ضيقة.
2. افتح آخر طلب فاشل واقرأ Sign-in error code.
3. انتقل إلى تبويب Conditional Access، وسجّل السياسة الفاشلة وGrant control غير المستوفى.
4. شغّل Sign-in Diagnostics على نفس الطلب.
5. إن كان الحل واضحاً، طبّقه. وإن كان غامضاً، انسخ Correlation ID وارفعه إلى دعم Microsoft.
6. وثّق الحل في تذكرة نظام إدارة التذاكر حتى لا يبحث الأدمن التالي مرة أخرى.

تحليل الأنماط بـ KQL في Log Analytics

تبويب Conditional Access في السجل ممتاز لطلب واحد، لكن عندما تريد أن تفهم نمطاً (مثلاً: كم مستخدماً حُظر بالسياسة الجديدة في آخر أسبوع؟) فأنت تحتاج إلى Log Analytics. الشرط أن تكون قد فعّلت Diagnostic settings على Entra لتصدير SignInLogs إلى Workspace.

الاستعلام التالي يعرض السياسات التي تسببت في أكبر عدد من الحظر في آخر 7 أيام:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 53003
| mv-expand ConditionalAccessPolicies
| where tostring(ConditionalAccessPolicies.result) == "failure"
| extend PolicyName = tostring(ConditionalAccessPolicies.displayName)
| summarize BlockedUsers = dcount(UserPrincipalName),
            Attempts = count()
          by PolicyName
| order by BlockedUsers desc

مثال آخر يفيد قبل تعديل سياسة، وهو عرض جميع المستخدمين الذين طُبِّق عليهم CA policy معينة في آخر 30 يوماً، حتى تعرف حجم التأثير قبل التغيير:

SigninLogs
| where TimeGenerated > ago(30d)
| mv-expand ConditionalAccessPolicies
| where tostring(ConditionalAccessPolicies.displayName) == "Require MFA for All Users"
| where tostring(ConditionalAccessPolicies.result) in ("success", "failure")
| summarize Interactions = count() by UserPrincipalName, tostring(ConditionalAccessPolicies.result)
| order by Interactions desc

هذه استعلامات أشغّلها أسبوعياً في مهام صيانة الهوية. أنصح ببنائها في Workbook مخصص في Azure Monitor حتى يفتحه الفريق بنقرة، ويكون أسلوب توثيق حي أفضل من ملف Word ينسى الجميع أنه موجود. لمن يدير هوية مختلطة، راجع أيضاً دليل استكشاف أخطاء Active Directory والهوية المختلطة الذي يغطي مشكلات المزامنة التي قد تظهر كأخطاء CA زائفة.

وضع Report-only: كيف تختبر سياسة قبل تفعيلها؟

القاعدة الذهبية: لا تفعّل سياسة CA جديدة مباشرةً. أبداً. استخدم دائماً وضع Report-only أولاً. النظام يقيّم السياسة على كل طلب حقيقي ويسجل نتيجة "Report-only: Failure" أو "Report-only: Success" في السجلات، بدون فرض السياسة على المستخدم.

خطواتي المعتادة لكل سياسة جديدة:

1. أنشئ السياسة بحالة Report-only.
2. اتركها 7 أيام على الأقل، فهذا يكفي لتغطية دورة عمل أسبوعية كاملة.
3. في Log Analytics، شغّل استعلاماً لعدّ المستخدمين الذين كانوا سيُحظرون:

   SigninLogs
   | where TimeGenerated > ago(7d)
   | mv-expand ConditionalAccessPolicies
   | where tostring(ConditionalAccessPolicies.displayName) == "My New CA Policy"
   | where tostring(ConditionalAccessPolicies.result) == "reportOnlyFailure"
   | summarize dcount(UserPrincipalName)

4. راجع القائمة يدوياً، واستثنِ الحسابات الشرعية (مثل حسابات الخدمة).
5. حوّل السياسة إلى On، ولكن بحدود ضيقة أولاً (مجموعة تجريبية من 20 مستخدماً)، ثم وسّع تدريجياً.

حسابات الطوارئ Break-Glass وأفضل الممارسات

أسوأ سيناريو في Conditional Access: تفعّل سياسة "Require compliant device" على كل المستخدمين وتنسى استثناء نفسك من جهاز غير متوافق. النتيجة: التنانت مقفل، لا يمكن لأحد الدخول ليصلح السياسة. الحل الوقائي: حسابا Break-Glass (اثنان بحد أدنى، حسب توصية Microsoft) مستثنيان من جميع سياسات CA، مع بروتوكول صارم:

• حسابان اثنان بأسماء لا توحي بالوظيفة (مثلاً [email protected])، ولا تجعلها admin@ أو breakglass@.
• استخدم دور Global Administrator دائم (Permanent)، وليس PIM eligible. الهدف تجاوز أي عطل في PIM.
• كلمات مرور طويلة (32 حرفاً+) مخزّنة في خزانة مادية مقسّمة بين مسؤولَين (لا يعرف أحدهما الكلمة كاملة).
• استثنِ الحسابين من كل سياسة CA، وتحقق من ذلك عبر What If شهرياً.
• فعّل تنبيهاً في Log Analytics لأي تسجيل دخول لهذه الحسابات، إذ يجب أن يكون كل استخدام حدثاً استثنائياً.
• امتحن سيناريو الاسترداد الفعلي كل 90 يوماً، ولا تكتفِ بوجود الوثيقة.

هذا موضوع أعمق مما يتّسع له هذا الدليل، وأنصح بمراجعة إدارة مفاتيح استرداد BitLocker في Intune وEntra، إذ يشترك مع Break-Glass في فلسفة "الوصول الطارئ عندما ينهار كل شيء".

Continuous Access Evaluation: عندما يحدث الحظر بعد تسجيل الدخول

تقليدياً، كانت سياسات CA تُقيَّم فقط عند إصدار Token جديد (تسجيل دخول أو تحديث). لكن مع Continuous Access Evaluation (CAE)، أصبحت التطبيقات مثل Exchange Online، SharePoint، وTeams تستقبل إشارات فورية من Entra عند حدوث تغيير حرج (حذف مستخدم، تعطيل حساب، تغيير كلمة مرور، تغيير موقع IP، أو تحديث سياسة CA)، فتُبطل الجلسة القائمة في ثوانٍ بدل انتظار انتهاء صلاحية Token (ساعة عادةً).

هذا يفسّر ظاهرة "المستخدم يقول إنه كان مسجّلاً وفجأة طُرد" حتى بدون إجراء منه. في تبويب Conditional Access ابحث عن حقل continuousAccessEvaluation، فإن كانت قيمته true فهذا ما حدث. الأسباب الشائعة: المستخدم تنقّل من مكتب إلى VPN فتغيّر IP، أو الأدمن حدّث سياسة CA تشمله فطُبِّقت فوراً بدل انتظار الجلسة القادمة.

عندما يصبح CAE مصدر إزعاج

في بعض شبكات الشركات الكبيرة التي تستخدم NAT مع IP متعدد أو Proxy circular، قد يبدو للمستخدم أنه يتنقّل بين مواقع باستمرار فيُطرد كل بضع دقائق. الحل: أضف نطاقات IP الحقيقية للشركة إلى Trusted named locations، وأخبر Entra أن هذه العناوين ثقة عبر Identity → Protection → Conditional Access → Named locations. لمن يدير شبكات معقدة، يفيد الرجوع إلى دليل استكشاف أخطاء VPN وتشخيص الشبكات لفهم كيف يظهر IP الحقيقي للجلسة لدى Entra.

المزالق الشائعة عند إنشاء سياسات جديدة

بعد سنوات من إدارة تنانت متوسط الحجم، هذه أكثر الأخطاء التي رأيتها (وارتكبتها):

1. سياسة "Block All" بلا استثناء لحسابات الطوارئ

مثال حقيقي من مواقف مررت بها: فريق أمن يفعّل "Block legacy authentication" على جميع المستخدمين دون استثناء حساب SMTP relay لخدمة معينة. النتيجة: كل طابعات المكتب تفقد قدرة إرسال البريد الممسوح ضوئياً. الدرس: أي سياسة Block يجب أن يسبقها Report-only لأسبوعين على الأقل، وقائمة استثناءات للخدمات الشرعية.

2. Require compliant device دون خطة تسجيل الأجهزة

تفعيل هذه السياسة قبل أن يكون كل جهاز مسجَّلاً في Intune ومتوافقاً يعني حظر فوري لكل من لم يُسجَّل. راجع دليل استكشاف أخطاء Intune وAutopilot لخطة تسجيل الأجهزة أولاً.

3. تضارب السياسات (Policy conflicts)

عندما تُطبَّق عدة Grant controls على نفس الطلب، فإن Entra يعتمد "AND" لكل الشروط. إذا سياسة تطلب MFA وأخرى تطلب Compliant device، فالمستخدم يحتاج للاثنين. عدد كبير من السياسات المتداخلة يجعل التشخيص كابوساً. قاعدتي: لا تتجاوز 15 سياسة إنتاجية. وإذا اضطررت لأكثر، أعد التصميم بمنطق شرائح (Personas).

4. إهمال Service Principals و Workload identities

CA لا يشمل حسابات الخدمة والتطبيقات إلا مع ترخيص Workload Identities Premium. الكثير من الأدمن يفعّل سياسات صارمة على المستخدمين ثم يترك Service Principals مكشوفة، وهذه في الغالب حسابات "Global Admin" فعلياً. راجع Sign-in logs مع تصفية Service principal sign-ins بشكل منفصل.

5. عدم تصدير نسخة احتياطية من السياسات

لا يوجد زر "استرجاع" رسمي في CA. إن حذف أحد الأدمن سياسة مهمة، تستطيع رؤية الحدث في Audit log لكن ليس استرجاعها بضغطة زر. الحل: صدّر السياسات دورياً بـ PowerShell:

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
    ConvertTo-Json -Depth 10 |
    Out-File "CA-Backup-$(Get-Date -Format 'yyyyMMdd').json"

احفظ الملف في مستودع Git خاص، فتحصل بذلك على نسخ احتياطية وتاريخ تغييرات مع فروقات واضحة. لمن يريد أتمتة أعمق، توفّر أدوات Entra ID PowerToys واجهة رسومية للنسخ الاحتياطي والمقارنة والاستعادة.

الأسئلة الشائعة

ما الفرق بين وضع Report-only والتفعيل الكامل لسياسة الوصول المشروط؟

في وضع Report-only، السياسة تُقيَّم على كل طلب حقيقي ونتيجتها تُسجّل في Sign-in logs، لكن Entra لا يفرضها على المستخدم، أي أن الطلب يمر حتى لو كان "سيُحظر". في التفعيل الكامل (On)، السياسة تُفرض فعلياً. أنصح دائماً بترك أي سياسة جديدة في Report-only أسبوعاً كاملاً على الأقل قبل التفعيل.

كيف يمكنني إلغاء حظر نفسي إذا أخطأت في سياسة CA؟

سجّل الدخول بحساب Break-Glass المستثنى من جميع سياسات CA، أو تواصل مع Microsoft Support (رقم 1-800-865-9408 في الولايات المتحدة)، فلديهم صلاحية إسقاط السياسات في حالات الطوارئ. لهذا السبب بالضبط، وجود حسابَين Break-Glass وامتحان الاسترداد كل 90 يوماً ليس ترفاً بل ضرورة تشغيلية.

هل تعمل سياسات الوصول المشروط على المستخدمين الضيوف (Guest users)؟

نعم، منذ 2023 يمكن استهداف المستخدمين الضيوف في CA بشكل مستقل عبر خيار Guest or external users ضمن Assignments، مع تصنيفات فرعية (B2B collaboration guest, B2B collaboration member, B2B direct connect, Service provider users, Other external users). سياسة شائعة: طلب MFA من كل ضيف عند الوصول إلى SharePoint حتى إن كان تنانته الأصلي لا يفرض MFA.

ما مدة الاحتفاظ الافتراضية بسجلات تسجيل الدخول في Entra ID؟

مع ترخيص Entra ID P1/P2 يُحتفظ بالسجلات 30 يوماً في البوابة. للاحتفاظ الأطول، فعّل Diagnostic settings لتصدير SignInLogs وAuditLogs إلى Log Analytics Workspace (احتفاظ قابل للتخصيص حتى 730 يوماً) أو Azure Storage Account (احتفاظ غير محدود). كثير من متطلبات الامتثال تفرض احتفاظاً لسنة أو أكثر.

هل يمكن تصدير سياسات Conditional Access كنسخة احتياطية؟

نعم، عبر Microsoft Graph API أو Microsoft.Graph PowerShell module. الأمر Get-MgIdentityConditionalAccessPolicy -All | ConvertTo-Json يصدّر كل السياسات كملف JSON قابل للنسخ الاحتياطي في مستودع Git. لا يوجد زر تصدير رسمي في البوابة، لذا الأتمتة عبر PowerShell هي الطريقة العملية الوحيدة.

ماذا يعني رمز الخطأ AADSTS53003 بالضبط؟

يعني BlockedByConditionalAccess، أي أن الاعتماديات كانت صحيحة، لكن سياسة Conditional Access واحدة أو أكثر فرضت Block أو لم تُستوفَ Grant control (مثل MFA أو Compliant device). لتحديد السياسة المسؤولة، افتح السجل في Entra admin center وانتقل إلى تبويب Conditional Access داخل تفاصيل الطلب.