Passwordless Authentication in Entra ID: Passkeys, Windows Hello, and FIDO2 Rollout | وداعًا للباسورد: دليل تفعيل Passkeys و Windows Hello و FIDO2 في Entra ID

وداعًا للباسورد: دليل تفعيل Passkeys و Windows Hello و FIDO2 في Entra ID

تجربة عملية من واقع رول أوت حقيقي لعميل عايز يقفل الباب على الـ password spray وIRT tickets بتاعة "نسيت الباسورد".

المقدمة

لو انت شغال Identity Engineer أو حتى IT Support، بالتأكيد جالك تذاكر من نوع "نسيت الباسورد" أو "الحساب اتقفل بسبب محاولات دخول غلط". المشكلة إن الباسورد نفسه هو أضعف حلقة في السلسلة، مهما وضعنا عليه Conditional Access أو MFA. في مشروع اشتغلت فيه مؤخرًا، العميل كان عنده تذاكر Password Reset بشكل يومي، وده كان الدافع الأساسي إننا نبدأ رحلة Passwordless بجدية، مش كخيار اختياري في Authentication Methods policy وبس.

في البوست ده هنتكلم عن الفرق بين Windows Hello for Business وFIDO2 security keys وPasskeys (اللي هي التطور الطبيعي لـ FIDO2)، وهنعمل رول أوت فعلي خطوة بخطوة باستخدام PowerShell وGraph API، مع التركيز على الـ gotchas اللي ممكن تقابلك في بيئة Hybrid.

💡 المتطلبات:

• Entra ID P1 على الأقل (P2 مفيد لو هتستخدم PIM أو Identity Protection مع الـ policy)
• صلاحية Authentication Policy Administrator أو Global Administrator
• أجهزة Windows 10/11 محدثة لو هتفعّل Windows Hello for Business
• FIDO2 security keys متوافقة مع WebAuthn (زي YubiKey أو Feitian)
• Microsoft Graph PowerShell SDK لو هتدير الـ policies برمجيًا

الفرق بين الطرق الثلاثة

قبل ما تبدأ الرول أوت، لازم تفهم كل طريقة تناسب إيه، لأن ده اللي هيحدد سياسة الـ deployment بتاعتك.

الطريقة	تستخدم فين	تحتاج جهاز مشترك؟	Sync عبر الأجهزة
Windows Hello for Business	أجهزة Windows مسجلة (Hybrid/Azure AD Joined)	لا، مرتبط بالجهاز نفسه	لا
FIDO2 Security Key (Hardware)	شير كيوسك، بيئات بدون موبايل، Privileged accounts	نعم، الكي نفسه محمول	لا
Passkeys (Device-bound / Synced)	موظفين عاديين، سيناريو BYOD، تسجيل دخول من موبايل	يعتمد (device-bound لا، synced نعم عبر iCloud/Google)	نعم لو Synced Passkey

الفكرة إن Passkeys دلوقتي بقت المسمى العام اللي بتستخدمه Microsoft وGoogle وApple لطريقة FIDO2/WebAuthn، وممكن تكون Device-bound (زي الـ FIDO2 key نفسه أو Windows Hello) أو Synced (متخزنة في password manager أو cloud keychain). Entra ID بقى يدعم الاتنين تحت authentication method واحد اسمه "Passkey (FIDO2)".

الخطوة الأولى: تفعيل Authentication Methods Policy

1. تفعيل FIDO2 عبر Graph API

أول حاجة، لازم تفعّل الـ method نفسه من Authentication Methods Policy. أنا بفضل أعمل ده عبر Graph API عشان أقدر أتحكم في الـ scope بدقة (Group معين مثلًا، مش All Users من أول يوم).

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

$params = @{
    isAttestationEnforced = $true
    keyRestrictions = @{
        isEnforced = $false
        enforcementType = "block"
        aaGuids = @()
    }
    includeTargets = @(
        @{
            targetType = "group"
            id = "00000000-0000-0000-0000-000000000000"  # Group ID بتاع الـ pilot
            isRegistrationRequired = $false
        }
    )
    state = "enabled"
}

Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "Fido2" `
    -BodyParameter $params

⚠️ ملحوظة مهمة: لو ضبطت isAttestationEnforced = $true، لازم تتأكد إن الكيهات اللي هتشتريها متسجلة في FIDO2 Metadata Service (MDS)، وإلا الـ registration هيفضل يفضل. كتير ناس بتقابل المشكلة دي أول مرة وتفتكر إن الـ policy عاطلة.

2. تفعيل Windows Hello for Business

لو عندك أجهزة Hybrid Joined، الأسهل إنك تديره عبر Intune Configuration Profile أو Group Policy، لكن لو عايز تتأكد من حالة الـ policy على مستوى Tenant:

Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "WindowsHelloForBusiness" |
    Select-Object Id, State

3. متابعة تسجيل المستخدمين عبر Sign-in logs بـ KQL

بعد ما تفتح الـ pilot، أنا بحب أعمل query على Sign-in Logs في Log Analytics عشان أشوف نسبة استخدام الطرق الجديدة فعليًا، مش بس عدد اللي "سجّلوا".

SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationRequirement == "singleFactorAuthentication" or AuthenticationRequirement == "multiFactorAuthentication"
| mv-expand AuthenticationDetails = parse_json(AuthenticationDetails)
| extend AuthMethod = tostring(AuthenticationDetails.authenticationMethod)
| where AuthMethod in ("FIDO2 security key", "Windows Hello for Business", "Passkey")
| summarize Count = count() by AuthMethod, bin(TimeGenerated, 1d)
| render timechart

✅ لو الـ chart بدأ يطلع فيه نشاط تصاعدي على الطرق دي بعد إعلان الـ pilot، ده معناه إن الرول أوت شغال فعليًا، مش بس معمول له policy على الورق.

فرض الـ Passwordless عبر Conditional Access

التفعيل مش كفاية، لازم تدفع المستخدمين يستخدموا الطريقة الجديدة فعليًا. هنا بييجي دور Authentication Strengths مع Conditional Access. تقدر تعمل policy تفرض "Passwordless MFA" فقط على مجموعة معينة (زي Admins أو IT Staff) وتستبعد الباسورد تمامًا.

New-MgIdentityConditionalAccessPolicy -BodyParameter @{
    displayName = "Require Passwordless Auth Strength - IT Admins"
    state = "enabledForReportingButNotEnforced"  # ابدأ بـ Report-only دايمًا
    conditions = @{
        users = @{ includeGroups = @("") }
        applications = @{ includeApplications = @("All") }
    }
    grantControls = @{
        operator = "OR"
        authenticationStrength = @{
            id = "00000000-0000-0000-0000-000000000004"  # Passwordless MFA strength
        }
    }
}

⚠️ ابدأ دايمًا بـ Report-only قبل ما تحوّل الـ state لـ enabled. المرة اللي هتنسى فيها الخطوة دي، هتقفل على نفسك أو على مستخدم مهم مش مسجّل الطريقة بعد.

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

المشكلة	الحل
المستخدم مش شايف خيار "Add a sign-in method" في MySecurityInfo	اتأكد إن الـ authentication method مفعّل للـ group بتاعته في Authentication Methods Policy، مش فقط بتفعيل Security Defaults
تسجيل FIDO2 key بيفضل، رسالة "attestation failed"	الكي غير متسجل في FIDO2 MDS، أو الـ AAGUID مش ضمن الـ allow list. جرب تعطّل attestation enforcement مؤقتًا للتشخيص
Windows Hello for Business مش بيتفعل على أجهزة Hybrid Joined	اتأكد من Sync بين AD وEntra Connect، وإن الجهاز فعلاً Hybrid Azure AD Joined لا Domain Joined بس
Passkey متسجل على الموبايل بس مش شغال على الـ Desktop	لو Synced Passkey، اتأكد إن iCloud Keychain أو Google Password Manager متفعّل ومتزامن على الجهازين
Legacy Authentication (POP/IMAP/Basic Auth) بيتخطى الـ Conditional Access	لازم تقفل Legacy Authentication نفسه أولًا، وإلا هيفضل باب مفتوح حتى لو Passwordless مفروض على المستخدم

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

• فعّل isAttestationEnforced على الأقل لحسابات الـ Admins عشان تضمن إن الكيهات المستخدمة معتمدة رسميًا
• استخدم Authentication Strengths مش Conditional Access grant controls العادية، لأنها بتفرق فعليًا بين Phishing-resistant MFA والباقي
• ابدأ الرول أوت بمجموعة Pilot صغيرة (IT + Security Team) قبل ما توسّع على باقي التنظيم
• راقب Sign-in Logs بانتظام باستخدام KQL عشان تكتشف لو حد لسه بيستخدم الباسورد بعد فترة الـ enforcement
• لا تلغي الباسورد كـ fallback method نهائيًا إلا بعد ما تتأكد إن نسبة استخدام Passwordless وصلت لمرحلة مطمّنة، وده بيتحدد بالمتابعة الفعلية مش بتاريخ محدد مسبقًا

الخلاصة

الانتقال لـ Passwordless مش قرار تقني بس، ده تغيير في سلوك المستخدمين، ولازم يتم على مراحل واضحة مع متابعة مستمرة. الفايدة الحقيقية مش إنك "تفعّل feature"، الفايدة إنك تقفل باب كامل من أبواب الهجوم زي Phishing وPassword Spray.

1. افهم الفرق بين Windows Hello، FIDO2 Keys، وPasskeys قبل ما تختار الطريقة المناسبة لكل شريحة مستخدمين
2. فعّل الـ Authentication Methods Policy بـ scope محدود أولًا عبر Graph API أو PowerShell
3. افرض الاستخدام تدريجيًا عبر Conditional Access مع Authentication Strengths، وابدأ دايمًا بـ Report-only
4. راقب النتيجة فعليًا بـ KQL على Sign-in Logs، مش بس بتقارير التفعيل

إنت جربت رول أوت لـ Passwordless في بيئتك؟ شاركنا التجربة أو أي مشكلة واجهتك في الكومنتات تحت 👇