Conditional Access Design Mistakes That Lock Admins Out of Microsoft Entra ID | لما الـ Conditional Access يقفل عليك الباب وأنت جوه Tenant

لما الـ Conditional Access يقفل عليك الباب وأنت جوه Tenant

قصة واقعية عن Policy واحدة تعبانة قدرت تقفل كل الأدمنز بره التينانت في نص ساعة


المقدمة


 لو شغال Identity Engineer من فترة، أكيد سمعت أو عملت بنفسك موقف إن حد عمل Conditional Access Policy جديدة الصبح، ضغط Enable على طول من غير Report-only، وبعد شوية بدأ يوصله شكاوى إن الأدمنز مش عارفين يدخلوا الـ Portal. المشكلة إن ده مش سيناريو نظري، ده حاصل فعلاً في شركات كبيرة لدرجة إن Microsoft نفسها عاملة Policy جاهزة اسمها "Emergency access" recommendation بس لسه كتير مش مطبقينها. النهاردة هنتكلم عن أكتر الأغلاط اللي بتحصل في تصميم CA وبتخلي الأدمن نفسه Locked out من غير قصد، وإزاي تتجنبها من الأول.

💡 المتطلبات: صلاحية Conditional Access Administrator أو Security Administrator في Entra ID، Entra ID P1 على الأقل (P2 لو هتستخدم PIM وRisk-based policies)، Access إلى Microsoft Graph PowerShell SDK، وحساب Break-glass جاهز ومُستبعد من كل الـ Policies.

1. الغلطة الأشهر: مفيش Break-Glass Account من الأساس

لو مفيش عندك Emergency Access Account مستبعد من كل CA Policy، فأنت فعليًا بتراهن إن كل الـ Policies اللي عاملها هتفضل شغالة صح 100% للأبد. وده مستحيل، لأي حد بيقولك كده يبقى معملش Production incident قبل كده.

الحساب ده لازم يكون:

  • Cloud-only (مش synced من On-prem، عشان لو AD DS نفسه واقع مش يأثر عليه).
  • Password طويل جدًا ومحفوظ في مكان Physical آمن (مش Key Vault لوحده، لأن لو Key Vault نفسه محتاج MFA عبر نفس الـ CA اللي واقعة، هتقفل على نفسك).
  • مُستبعد Explicitly من كل Policy عن طريق Exclude group مخصص له.
⚠️ تحذير: لو حطيت الحساب ده جوه Group بتستخدمه في أماكن تانية، وبعدين حد عدّل الـ Group أو حذفه بالغلط، هتفضي فجأة من كل الحماية.

خطوات إنشاء Break-Glass Account صحيح

# اتصال بـ Microsoft Graph
Connect-MgGraph -Scopes "User.ReadWrite.All","Group.ReadWrite.All"

# إنشاء الحساب
$params = @{
    accountEnabled = $true
    displayName = "BreakGlass-Emergency-01"
    userPrincipalName = "breakglass01@samironcloud.onmicrosoft.com"
    mailNickname = "breakglass01"
    passwordProfile = @{
        forceChangePasswordNextSignIn = $false
        password = "GENERATE-A-STRONG-32-CHAR-PASSWORD"
    }
}
New-MgUser -BodyParameter $params

# عمل Group مخصص للاستبعاد من CA
New-MgGroup -DisplayName "CA-Exclude-BreakGlass" -MailEnabled:$false `
    -MailNickname "caexcludebg" -SecurityEnabled:$true

2. تفعيل Policy مباشرة من غير Report-Only

دي الغلطة اللي بتحصل غالبًا وقت الضغط أو وقت "بسرعة عايزين نقفل حاجة أمنية". الحل الوحيد اللي مفيش عنه تنازل: أي Policy جديدة أو تعديل على Policy موجودة، لازم يعدي على Report-only مدة كافية (أسبوع على الأقل) وتراجع الـ Sign-in logs قبل ما تحوّلها On. 

// KQL query لمراجعة الـ CA impact في Log Analytics قبل التفعيل
SigninLogs
| where TimeGenerated > ago(7d)
| mv-expand ConditionalAccessPolicies
| where ConditionalAccessPolicies.displayName == "Require MFA for all admins"
| extend Result = tostring(ConditionalAccessPolicies.result)
| summarize Count = count() by Result, UserPrincipalName
| order by Count desc
✅ لو النتيجة "reportOnlySuccess" لكل الأدمنز اللي المفروض يتأثروا، يبقى جاهز تفعّل الـ Policy فعليًا.

3. الخلط بين "All Users" و "All Cloud Apps" من غير استبعاد صحيح

لو عملت Policy على All Users + All Cloud Apps + Block access (لأي شرط، زي Location مثلاً)، وماعملتش Exclude لحساب الـ Break-glass وحساب الأدمن اللي بيدير الـ Policy نفسها، فأنت ممكن تقفل على الـ Azure Portal، Microsoft Graph، وحتى الـ PowerShell session بتاعك في نفس اللحظة.

Scope لو غلط فيه التأثير
All Cloud Apps مش مستبعد Microsoft Graph / Azure Portal Admin مش قادر يدخل حتى يصلّح الـ Policy
All Users مش مستبعد Break-glass Group مفيش Fallback account يدخل بيه
Locations condition Trusted location غير محدثة (IP قديم) حظر من نفس المكتب اللي بتشتغل منه

4. الاعتماد على Policy واحدة "شاملة" بدل Layered Policies

كتير من المصممين بيعملوا Policy عملاقة واحدة فيها كل الشروط (MFA + Device Compliance + Location + Sign-in risk) على كل التينانت. المشكلة إن أي Component فيها لو فشل (زي Compliance state غلط بسبب Intune sync delay) هيبلوك كل حد، بما فيهم الأدمنز. الأفضل تقسيم الـ Policies حسب الـ Persona (Admins / Users / Guests / Service accounts) وتخلي كل Persona ليها Exclude/Include منطقي بدل Policy واحدة تحكم على الكل.

5. نسيان الـ Legacy Authentication و Service Accounts

لو عندك Service accounts أو Legacy protocols (زي POP/IMAP أو Exchange Online older auth) بتستخدم للـ automation، وعملت Policy "Block legacy authentication" شامل من غير استثناء، ممكن تكسر Automation scripts بتستخدم نفس الـ Identity اللي بيدير الـ Conditional Access نفسه (زي Service Principal بيشغّل PowerShell scheduled task لتحديث الـ Policies).

مشاكل شائعة وحلولها

المشكلة الحل
كل الأدمنز قافلين بره التينانت بعد تفعيل Policy جديدة استخدم Break-glass account (المفروض مستبعد أصلاً) عن طريق Azure AD PowerShell أو Graph Explorer من جهاز غير خاضع للـ Policy، وعدّل الـ Policy فورًا بجعلها Report-only
Policy واقفة على "Report-only" ومحدش عمل Review للنتائج استخدم Workbook "Conditional Access Insights and Reporting" في Entra Portal، أو نظّم Alert Rule في Log Analytics يبعتلك تنبيه فوري لو زاد عدد الـ Failures نتيجة Policy معينة.

نصائح الأمان 🔐

  • اعمل Access Review دوري كل 3 شهور على كل Conditional Access Policies عشان تتأكد إن الاستثناءات لسه صحيحة ومحدش ضاف Exception مش لازم.
  • فعّل Sign-in Risk detection مع Identity Protection عشان تلاحظ محاولات دخول غريبة قبل ما توصل لمرحلة Lockout.
  • سجّل كل تعديل على CA Policies من خلال Audit logs، وحدد صلاحية التعديل باستخدام Conditional Access Administrator role بدل Global Administrator الدائم.
  • اعمل Test دوري لحساب الـ Break-glass نفسه، مرة كل شهرين مثلاً، عشان تتأكد إنه لسه شغال ومستبعد صح، مش بس موجود نظريًا.

الخلاصة

تصميم Conditional Access مش مجرد إعداد Policy وتفعيلها، ده قرار بيأثر على كل حد بيدخل على التينانت بما فيهم الأدمنز أنفسهم. الفرق بين Policy آمنة وPolicy بتقفل عليك الباب غالبًا بيكون في تفاصيل صغيرة زي الاستثناءات والـ Report-only testing.

باختصار:

  1. اعمل Break-glass account صحيح ومُستبعد فعليًا من كل Policy.
  2. متفعّلش أي Policy جديدة من غير Report-only كافي ومراجعة النتائج.
  3. افصل الـ Policies حسب الـ Persona بدل Policy واحدة شاملة.
  4. راجع الـ Legacy Authentication وService Accounts قبل أي Block عام.

إنت جربت موقف زي ده قبل كده؟ شاركني قصتك في التعليقات 👇


Comments

Post a Comment