Conditional Access Templates vs Custom Policies in Entra ID | تمبلت Conditional Access الجاهزة ولا تبنيها بإيدك؟ القصة كاملة

تمبلت Conditional Access الجاهزة ولا تبنيها بإيدك؟ القصة كاملة

تجربة عملية مع Microsoft's baseline templates في Entra admin center، وإمتى تسيبها وتعمل policy مخصصة من الصفر.

---

المقدمة

لما بتفتح Conditional Access في Entra admin center دلوقتي، هتلاقي Microsoft ضايفة قسم "Templates" فيه policies جاهزة زي Require MFA for admins و Block legacy authentication. الفكرة إن أي حد داخل جديد على identity security يقدر يفعّل baseline policies في دقايق من غير ما يفهم كل تفصيلة. المشكلة إني شخصياً اتعاملت مع عميل استخدم الـ templates زي ما هي من غير تعديل، وبعد شهر لقى نفسه محتاج exclusions لحسابات service accounts ومحتاج session controls مش موجودة في التمبلت الأساسي. يعني السؤال مش "التمبلت كويس ولا لأ"، السؤال هو "امتى تستخدمه كما هو وامتى تاخده كنقطة بداية بس".

💡 المتطلبات:

• Microsoft Entra ID P1 على الأقل (P2 لو هتستخدم Sign-in risk أو User risk conditions)
• رول Conditional Access Administrator أو Security Administrator
• Microsoft Graph PowerShell SDK لو هتشتغل بالـ automation
• Break-glass account مستثنى من كل الـ policies قبل ما تبدأ أي تجربة

إيه اللي موجود في Microsoft's baseline templates

لما تدخل على Entra admin center > Protection > Conditional Access > Create new policy from templates، هتلاقي التمبلتات متقسمة تحت تصنيفات زي Secure foundation و Zero Trust و Remote work و Protect administrators. أشهر التمبلتات اللي بتستخدمها فعلياً في أي بيئة:

اسم التمبلت	الوظيفة
Require multifactor authentication for admins	MFA إجباري لأي حد له admin role
Block legacy authentication	قفل بروتوكولات قديمة زي POP و IMAP اللي بتتجاوز MFA
Require compliant or hybrid joined device for admins	الأدمن لازم يستخدم جهاز compliant أو hybrid joined
Securing security info registration	حماية عملية تسجيل الـ MFA methods نفسها

✅ الميزة الحقيقية هنا إن التمبلتات دي مبنية على best practices متوثقة من Microsoft، يعني مش هتقلق إنك ناسي condition أو grant control مهم.

إمتى التمبلت مش كفاية وتحتاج Custom Policy

التمبلت بيديك structure عام، لكن فيه حاجات كتير محتاج تعدلها بإيدك قبل ما تفعّل الـ policy فعلياً:

1. الـ Exclusions

كل تمبلت بيتقفل فيه include كـ "All users"، لكن لازم تضيف break-glass accounts و service accounts يدوياً. التمبلت مبيعملهاش تلقائي.

2. Session Controls

لو محتاج Sign-in frequency أو Persistent browser session أو Use app enforced restrictions، دي مش موجودة في أغلب baseline templates وهتحتاج تضيفها يدوي بعد الإنشاء.

3. Named Locations و Risk-Based Conditions

لو عندك P2 وعايز تستخدم Sign-in risk level أو User risk level، دي مش هتلاقيها جاهزة في التمبلت الافتراضي، لازم تبنيها Custom من الأول.

4. Naming Convention

التمبلت بيديك اسم عام زي "Require multifactor authentication for admins"، وده مش هيفرق بين policies كتير لما يكبر العدد. أنا شخصياً بستخدم convention زي:

CA[Number]-[Persona]-[Control]-[Platform]
مثال: CA001-Admins-RequireMFA-AllApps

إنشاء Custom Policy عن طريق Microsoft Graph PowerShell

لو عايز تبني policy مخصصة من الصفر بدل التمبلت، وتحطها في report-only أول ما تعملها، ده مثال عملي:

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$params = @{
    displayName = "CA001-Admins-RequireMFA-AllApps"
    state       = "enabledForReportingButNotEnforced"
    conditions  = @{
        users = @{
            includeRoles = @("62e90394-69f5-4237-9190-012177145e10") # Global Administrator
            excludeUsers = @("")
        }
        applications = @{
            includeApplications = @("All")
        }
        clientAppTypes = @("all")
    }
    grantControls = @{
        operator        = "OR"
        builtInControls = @("mfa")
    }
    sessionControls = @{
        signInFrequency = @{
            value         = 4
            type          = "hours"
            isEnabled     = $true
        }
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

⚠️ لاحظ إن أي policy جديد لازم يبدأ بـ state = "enabledForReportingButNotEnforced". متفعّلش policy على enabled من غير ما تشوف تأثيره في Sign-in logs الأول، خصوصاً لو الـ include بتاعك "All users".

تتبع تأثير الـ Policy بـ KQL

بعد ما تحط الـ policy في report-only، تقدر تراجع تأثيرها من Log Analytics لو عامل export للـ Sign-in logs:

SigninLogs
| where TimeGenerated > ago(7d)
| mv-expand ConditionalAccessPolicies
| where tostring(ConditionalAccessPolicies.displayName) == "CA001-Admins-RequireMFA-AllApps"
| summarize Count = count() by Result = tostring(ConditionalAccessPolicies.result)
| order by Count desc

ده بيوريك إذا كان الـ policy هيعمل "reportOnlySuccess" أو "reportOnlyFailure" لو اتفعل فعلياً، قبل ما تاخد القرار.

مقارنة سريعة: Template vs Custom

المعيار	Baseline Template	Custom Policy
سرعة الإعداد	دقايق	يحتاج تخطيط وتوثيق
التحكم في Exclusions	لازم تعدلها يدوياً بعد الإنشاء	مدمجة من الأول في التصميم
Risk-Based Conditions	غير موجودة غالباً	متاحة كاملة مع P2
مناسب لـ	بيئات جديدة أو Quick wins	بيئات ناضجة بمتطلبات compliance محددة

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

المشكلة	الحل
فعّلت تمبلت "Require MFA for admins" وقفلت نفسك بره	تأكد إن الـ break-glass account مستثنى قبل التفعيل، وابدأ دايماً بـ report-only
التمبلت الجاهز بيشمل apps مش محتاجها في الـ scope	عدّل الـ conditions بعد الإنشاء مباشرة وحدد Applications بدقة بدل "All"
Service accounts بتفشل بسبب MFA policy	استخدم Workload Identity Federation أو استثنيها في group منفصلة بدل استثناء فردي
صعوبة تتبع أي policy مسؤول عن أي block	استخدم What If tool في Entra admin center قبل أي تعديل جوهري

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

• خلي دايماً على الأقل two break-glass accounts مستثنيين من كل الـ Conditional Access policies، وراقبهم بـ alert منفصل في Defender XDR.
• استخدم Named Locations للـ trusted IPs بدل ما تفتح الـ scope لكل الـ locations من غير قيد.
• راجع الـ report-only policies أسبوعياً على الأقل قبل ما تحولها لـ enabled، حتى لو التمبلت جاهز من Microsoft.
• وثّق كل policy custom عملتها في مكان منفصل (naming convention + السبب) عشان أي حد يجي بعدك يفهم القرار.
• لو بتستخدم Sign-in risk أو User risk، تأكد إن Identity Protection مفعّل صح وعامل sync مع الـ policy.

الخلاصة

Baseline templates في Entra ID مش بديل عن التخطيط، هي نقطة بداية سريعة وآمنة نسبياً لأي حد بادئ. لكن أي بيئة فيها complexity حقيقية (service accounts، compliance requirements، risk-based access) هتحتاج آجلاً أو عاجلاً Custom policies مبنية على فهم دقيق لاحتياجاتك.

1. استخدم التمبلت كـ quick win في البداية، بس متسيبهوش زي ما هو من غير مراجعة exclusions.
2. ابني أي policy جديدة في report-only الأول، وراقب تأثيرها بـ KQL قبل التفعيل.
3. لو محتاج session controls أو risk-based conditions، اعتبر التمبلت مجرد نقطة انطلاق مش الحل النهائي.
4. وثّق واستخدم naming convention ثابت من أول policy، هيوفرلك وقت كبير لما العدد يكبر.

إنت بتستخدم التمبلتات الجاهزة ولا بتبني كل حاجة Custom من الأول؟ شاركني تجربتك في التعليقات.