Authentication Methods Policy Migration: Retiring Legacy MFA and SSPR Policies | وداعًا لسياسات الـ MFA و SSPR القديمة: دليل Migration لـ Authentication Methods Policy في Entra ID

وداعًا لسياسات الـ MFA و SSPR القديمة: دليل Migration لـ Authentication Methods Policy في Entra ID

حكاية عملية لتينانت لسه شغال بالـ Legacy MFA Service Settings و SSPR Policy القديمة، وإزاي تنقله بأمان لـ Authentication Methods Policy الموحدة من غير ما توقف أي user عن تسجيل الدخول.

المقدمة



لو فتحت تينانت قديم شويه في Entra ID، هتلاقي حاجة غريبة: فيه صفحة "Multi-factor authentication" جوه Active Directory admin center لوحدها، وفيه صفحة "Password reset" لوحدها بتتحكم في SSPR، وفيه Authentication methods policy تالتة جوه Protection بتتحكم في نفس الطرق دي. ده مش تكرار غلط، ده بقايا نظام قديم كانت Microsoft بتديره من قبل ما توحّد كل حاجة في مكان واحد. المشكلة إن الوضع ده بيسبب تعارض فعلي: ممكن تفعّل Microsoft Authenticator من Authentication methods policy وتلاقيه شغال، لكن الـ per-user MFA القديم لسه مفعّل على مستخدمين معينين ومعطلهم من الـ Conditional Access الطبيعي. أنا اتعاملت مع الموضوع ده في تينانت فيه أكتر من ٢٠٠٠ يوزر، وده اللي عملته خطوة بخطوة.

💡 المتطلبات:
  • صلاحية Authentication Policy Administrator أو Global Administrator على الـ tenant
  • Microsoft Graph PowerShell SDK (module: Microsoft.Graph.Identity.SignIns)
  • Scope مطلوب: Policy.ReadWrite.AuthenticationMethod
  • Access لـ Defender XDR Advanced Hunting أو Log Analytics لو عايز تعمل audit قبل التبديل
  • وقت كافي لمرحلة "Migration in progress" (مش قرار يتاخد في نفس اليوم)

ليه أصلاً محتاج تعمل Migration دلوقتي

الـ Legacy MFA (اللي بتتحكم فيه من Service Settings في الـ old MFA portal) والـ Legacy SSPR policy كانوا بيشتغلوا بمنطق منفصل تمامًا عن Conditional Access. النتيجة إن المستخدم ممكن يكون معفى من MFA بسياسة Conditional Access لكن لسه مطلوب منه verification بسبب إعداد قديم في per-user MFA. Microsoft بتوجه كل التينانتات تدريجيًا لتوحيد الإدارة في Authentication methods policy عشان:

  • تدير كل الطرق (Authenticator, FIDO2, SMS, Voice, Email OTP) من مكان واحد
  • تتحكم في الـ registration campaign وتفرض Authenticator بدل SMS
  • تربط الـ SSPR reset methods بنفس تعريف الـ authentication methods بدل إعداد منفصل

⚠️ لو التينانت بتاعك لسه في وضع "Pre-migration"، ده معناه إن أي تعديل تعمله في Authentication methods policy مش بالضرورة هيبقى هو المصدر الفعلي للـ enforcement، لأن الـ Legacy policy ممكن تكون هي اللي شغالة فعليًا خلف الكواليس.

الخطوة الأولى: تقييم الوضع الحالي قبل أي تعديل

1. اتأكد من الـ migration state الحالي

Connect-MgGraph -Scopes "Policy.Read.All"

$policy = Get-MgPolicyAuthenticationMethodPolicy
$policy | Select-Object Id, PolicyMigrationState

القيم الممكنة هنا: preMigration، migrationInProgress، migrationComplete. لو لقيت preMigration يبقى لسه ما عملتش أي خطوة فعلية للتحويل حتى لو فاتح Authenticator من Authentication methods policy.

2. دور على المستخدمين اللي لسه معتمدين على Legacy per-user MFA

الطريقة الأسهل هنا Advanced Hunting في Defender XDR على الـ sign-in logs بدل ما تدور يدوي:

AADSignInEventsBeta
| where Timestamp > ago(30d)
| mv-expand AuthenticationDetails
| where tostring(AuthenticationDetails.authenticationMethod) in ("SMS", "Voice call", "OTP")
| where tostring(AuthenticationDetails.authenticationStepResultDetail) contains "MFA requirement satisfied by legacy"
| summarize LegacyMfaHits = count() by AccountUpn
| order by LegacyMfaHits desc

✅ لو النتيجة رجعت فاضية أو قليلة جدًا، يبقى المستخدمين غالبًا بالفعل بيمروا من Conditional Access وممكن تكمل بأمان أكبر.

خطوات الـ Migration الفعلية

1. تفعيل الطرق المطلوبة داخل Authentication methods policy الأول

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

$params = @{
    "@odata.type" = "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration"
    state = "enabled"
    includeTargets = @(
        @{
            targetType = "group"
            id = "all_users"
        }
    )
}

Update-MgPolicyAuthenticationMethodAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "MicrosoftAuthenticator" `
    -BodyParameter $params

مهم إنك تتأكد إن كل طريقة كانت شغالة في الـ Legacy MFA (زي SMS أو Voice) بقت مفعّلة هنا كمان قبل ما تكمل، عشان محدش يفقد وسيلة الدخول بتاعته فجأة.

2. تحويل الحالة لـ "Migration in progress"

$body = @{
    policyMigrationState = "migrationInProgress"
}

Update-MgPolicyAuthenticationMethodPolicy -BodyParameter $body

في المرحلة دي، الاتنين (Legacy و Authentication methods policy) بيشتغلوا مع بعض، والنظام بيدي الأولوية للإعداد الأكثر تقييدًا. ده الوقت المثالي إنك تسيب المرحلة دي كام يوم أو أسبوع وتراقب سلوك الدخول قبل ما تقفل الباب خالص.

3. مراقبة الـ sign-ins أثناء الـ transition

AADSignInEventsBeta
| where Timestamp > ago(7d)
| where ErrorCode != 0
| where ResultType has "InteractionRequired" or ResultType has "50076" or ResultType has "50079"
| summarize FailedMfaCount = count() by AccountUpn, ResultType
| order by FailedMfaCount desc

لو شفت spike غير طبيعي في failures بعد التفعيل، ارجع خطوة وراجع الـ target groups بتاعتك قبل ما تكمل للمرحلة الأخيرة.

4. إنهاء الـ Migration

$body = @{
    policyMigrationState = "migrationComplete"
}

Update-MgPolicyAuthenticationMethodPolicy -BodyParameter $body

⚠️ بعد ما تعمل migrationComplete، الـ Legacy MFA Service Settings وصفحة Password reset القديمة بيتوقف تأثيرهم الفعلي تمامًا، وأي إعداد فيهم بقى للعرض بس. مفيش رجوع سهل من غير ما تعيد الإعداد يدويًا في Authentication methods policy، فخد وقتك في المرحلة اللي قبل دي.

مقارنة سريعة بين النظامين

النقطة Legacy MFA / SSPR Policy Authentication Methods Policy
مكان الإدارة صفحتين منفصلتين (MFA Service Settings + SSPR) مكان واحد جوه Protection > Authentication methods
Targeting per-user فقط Groups (all users أو groups محددة)
تكامل مع Conditional Access محدود ومربك أحيانًا متكامل بشكل كامل
دعم مستقبلي من Microsoft في طريقه للتقاعد هو المسار الرسمي المستمر

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

المشكلة الحل
مستخدم اتقفل بره حسابه بعد التفعيل لأن الطريقة القديمة اتشالت راجع الـ includeTargets لكل authentication method قبل ما تقفل، وسيب SMS مفعّل مؤقتًا لحد ما الكل يسجل Authenticator
تعديل عملته في Authentication methods policy مش بيظهر تأثيره اتأكد إن الـ PolicyMigrationState مش لسه preMigration، لأن الـ Legacy policy بتفضل هي المصدر
SSPR بقى مش شغال بعد الـ migration complete SSPR دلوقتي بيتحكم فيه من نفس الـ Authentication methods policy عن طريق registrationEnforcement، لازم تعيد ضبطه هناك مش في الصفحة القديمة
Service accounts أو break-glass accounts اتأثروا بالتغيير استثنيهم في target groups بتاعة كل method، ومتنساش تختبر break-glass account بعد كل مرحلة

Comments

Post a Comment

Popular posts from this blog

Entra ID Free vs P1 vs P2: What You Actually Get at Each License Tier | Entra ID Free ولا P1 ولا P2: الفرق الحقيقي بين الباقات

Image
Entra ID Free ولا P1 ولا P2: الفرق الحقيقي بين الباقات دليل عملي لأي حد بيحاول يقنع الإدارة يدفع فلوس زيادة، أو بيحاول يفهم ليه الميزة اللي شافها في الدوكيومنتيشن مش شغالة عنده. المقدمة كل شوية بيجيلي سؤال من حد بيقولي "عملت Conditional Access policy بالظبط زي اللي في الفيديو بس مش لاقيها في التينانت بتاعي"، وبعد شوية بحث بيطلع إن التينانت شغال على Entra ID Free أو إن المستخدم نفسه مش معاه P1 أصلا. الموضوع ده بيسبب لخبطة كبيرة لأن Microsoft بتدي نفس الـ Portal تقريبا لكل الباقات، بس الميزات اللي بتظهر جوه بتختلف بشكل جوهري حسب الـ license اللي أنت أو المستخدم معاك. في البوست ده هوضحلك بالظبط إيه اللي بتاخده في كل tier، وإزاي تتأكد من الـ licensing الفعلي عندك بدل ما تعتمد على الحظ. 💡 المتطلبات: صلاحية Global Reader أو Global Administrator عشان تشوف الـ licenses المفعلة في التينانت وصول لـ Microsoft Entra admin center أو Microsoft Graph PowerShell SDK فكرة مبدئية عن الفرق بين Assigned license للمستخدم والـ features المتاحة في التينانت الفرق الأساسي بين الب...
Read more

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

Image
لما الـ 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 من الأساس لو مفيش عندك E...
Read more

Entra ID Built-in Roles vs Custom Roles for Least Privilege | أدوار مدمجة ولا Custom Roles؟ إزاي تطبق مبدأ الصلاحية الأقل في Entra ID

Image
أدوار مدمجة ولا Custom Roles؟ إزاي تطبق مبدأ الصلاحية الأقل في Entra ID حكاية عملية عن الفرق بين إنك تدي حد صلاحية "تقريبًا كفاية" وإنك تدي حد الصلاحية "بالظبط اللي محتاجها"، ومتى تستخدم إيه من الاتنين. المقدمة حصلت معايا قبل كده موقف كلاسيكي: عضو في فريق الـ Helpdesk طلب صلاحية يعمل reset password لمستخدمين قسم معين بس. أقرب Built-in Role ليها هو Password Administrator أو Helpdesk Administrator، بس المشكلة إن الدور ده بيدي صلاحية على كل المستخدمين في الـ tenant تقريبًا، مش بس القسم المطلوب. يعني عشان أحل مشكلة صغيرة، أنا فتحت باب كبير قوي. المشكلة دي بتتكرر كتير في الشركات اللي بتكبر وتحتاج تفصيل الصلاحيات على مستوى أدق من اللي الأدوار المدمجة بتقدمه، وهنا بالظبط بييجي دور الـ Custom Roles. 💡 المتطلبات: Microsoft Entra ID P1 على الأقل عشان تقدر تعمل Custom Roles (P2 لو هتستخدم PIM مع الأدوار دي). صلاحية Privileged Role Administrator أو Global Administrator عشان تنشئ وتخصص الأدوار. Microsoft Graph PowerShell SDK مثبت (Install-Module Microsoft.Graph...
Read more