Self-Service Password Reset (SSPR) in Entra ID: Setup and Troubleshooting Guide | SSPR في Entra ID: ليه اليوزر بيفشل يعمل Reset لباسوورده لوحده؟

SSPR في Entra ID: ليه اليوزر بيفشل يعمل Reset لباسوورده لوحده؟

دليل عملي لإعداد SSPR صح من أول مرة، وحل أكتر المشاكل اللي بتقابل الأدمن يوم بعد يوم.

---

المقدمة

لو انت شغال Helpdesk أو Identity Admin، أكيد جرالك اليوزر يكلمك يقولك "أنا نسيت الباسورد ومش عارف أعمل Reset". وده بالظبط السبب اللي عشانه SSPR اتعمل من الأساس: تقلل الـ ticket load على فريق الدعم الفني وتدي اليوزر القدرة يفك نفسه من غير ما ينتظر حد. المشكلة إن SSPR سهل الإعداد ظاهريًا، بس فيه تفاصيل صغيرة (زي الفرق بين Registration و Authentication methods، أو الـ Combined Registration مع MFA) لو اتنسيت بتخلي اليوزرز يعلقوا في نص العملية ويرجعولك تاني بشكوى إن "الزرار مش شغال". في البوست ده هنعدي على الإعداد، والـ troubleshooting، وأكتر نقط الفشل شيوعًا.

💡 المتطلبات:

• صلاحية Authentication Policy Administrator أو Global Administrator على الـ Entra ID tenant
• Microsoft Entra ID P1 أو P2 (SSPR الأساسي متاح كمان في بعض السيناريوهات مع Free tier لكن بميزات محدودة جدًا)
• Microsoft Graph PowerShell SDK أو صلاحية الوصول لـ Microsoft Graph API
• يوزرز عندهم Authentication methods متسجلة (Phone, Email, Authenticator app)

أولًا: إعداد SSPR من الصفر

1. تفعيل SSPR على مستوى الـ Tenant

تروح على Entra admin center، بعدين Protection، بعدين Password reset. هتلاقي 3 اختيارات: None، Selected، All. عمليًا أنا بنصح دايمًا تبدأ بـ Selected على مجموعة Pilot صغيرة الأول قبل ما تعمم على All.

# تفعيل SSPR على مجموعة معينة عن طريق Microsoft Graph PowerShell
Connect-MgGraph -Scopes "Policy.ReadWrite.Authenticator", "Group.Read.All"

$policy = Get-MgPolicyAuthorizationPolicy

# لازم تستخدم الـ portal أو Graph API endpoint الخاص بـ passwordResetPolicy
# لان الاعداد ده حاليا بيتظبط من الـ UI في أغلب الحالات

Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"

2. تحديد عدد الـ Authentication methods المطلوبة

المفروض تحدد إن اليوزر لازم يسجل على الأقل عدد معين من الطرق (زي Number required to reset = 2). ده بيمنع اليوزر إنه يعتمد على وسيلة واحدة بس، لو ضاعت أو اتغيرت (زي الموبايل رقم قديم).

3. ربط SSPR بالـ Combined Security Info Registration

من الأفضل عمليًا تفعّل الـ Combined Registration Experience، عشان اليوزر لما يسجل بيانات الـ MFA بتسجل نفس البيانات لـ SSPR في نفس الوقت، وده بيقلل الـ friction ويقلل الاتصالات اللي بتيجي "أنا مش فاكر سجلت إيه".

# التأكد من حالة تسجيل الـ Authentication Methods لليوزر
Get-MgUserAuthenticationMethod -UserId "user@contoso.com" | 
  Select-Object Id, AdditionalProperties

ثانيًا: تفعيل الـ Notifications

لازم تفعّل خاصيتين مهمين تحت Notifications: إشعار الأدمنز لما يحصل SSPR، وإشعار اليوزر نفسه على الـ Alternate email لو حصل Reset لباسوورده. الخاصية دي بتساعدك تكتشف أي محاولة غير شرعية بسرعة.

⚠️ تنبيه: لو الأدمن معملش تفعيل لإشعار "notify users on password resets"، مفيش أي طريقة توثق إن اليوزر هو اللي عمل الـ Reset فعلًا غير مراجعة الـ Sign-in logs يدويًا، وده بياخد وقت أطول بكتير وقت الـ Incident Response.

ثالثًا: مقارنة بين Authentication methods المتاحة

الطريقة	مستوى الأمان	ملاحظة عملية
Microsoft Authenticator App	عالي	الأفضل، بس محتاج اليوزر يكون حمّل التطبيق
Phone (SMS/Call)	متوسط	شائع الاستخدام بس عرضة لـ SIM swap
Security Questions	منخفض	غير موصى بيه إطلاقًا في بيئة enterprise
Email (Alternate)	متوسط	لازم يكون بريد خارج نفس الـ tenant

✅ الوضع المثالي: تخلي الـ Authenticator App هو الطريقة الأساسية، وتخلي Phone كـ backup ثاني.

رابعًا: Troubleshooting بالـ Sign-in Logs و KQL

لو عندك Defender XDR أو Sentinel متكامل مع الـ Entra ID logs، تقدر تتبع محاولات الـ SSPR الفاشلة بسهولة عن طريق الـ KQL على جدول AuditLogs.

AuditLogs
| where OperationName == "Reset password (self-service)"
| extend Status = tostring(Result)
| where Status == "failure"
| project TimeGenerated, InitiatedBy, TargetResources, ResultDescription
| order by TimeGenerated desc

لو عايز تتبع كام مرة اليوزر حاول يسجل الـ Authentication methods بتاعته وفشل، استخدم الكويري ده:

AuditLogs
| where OperationName has "Register security info"
| where Result == "failure"
| summarize FailCount = count() by tostring(InitiatedBy.user.userPrincipalName)
| order by FailCount desc

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

المشكلة	الحل
اليوزر مش شايف خيار SSPR في صفحة الـ Login	تأكد إن الـ policy مفعلة "Selected" أو "All" وإن اليوزر داخل النطاق المحدد
اليوزر مسجل Authentication method لكن الـ Reset لسه بيفشل	راجع إن عدد الطرق المسجلة أكبر من أو يساوي الـ "Number of methods required to reset"
اليوزر عنده Conditional Access بيمنع تسجيل الدخول قبل الـ Reset	اعمل Exclusion واضح لـ SSPR flow في الـ CA policy أو استخدم Named Locations لو الوصول من الشبكة الداخلية بس
اليوزر Hybrid identity والباسورد مش بيترجع Sync مع الـ on-prem AD	تأكد إن Password Writeback مفعّل من Azure AD Connect (أو Entra Connect Sync الحالي)
اليوزر بيقول "الرابط مش بيوصلني" على الإيميل البديل	تأكد إن الإيميل البديل اتسجل صح، ومراجعة الـ Spam/Junk، وإن الدومين مش على أي Block list

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

• فعّل دايمًا إشعار الأدمن والمستخدم لما يحصل SSPR، ده بيديك خط دفاع أول ضد الحسابات المخترقة.
• متعتمدش على Security Questions كطريقة أساسية، دي أضعف نقطة ممكن تتستخدم في Social Engineering.
• لو عندك Privileged accounts (زي حسابات فيها PIM roles)، امنعهم من استخدام SSPR خالص، واخليهم يعتمدوا على قنوات تحقق يدوية أقوى.
• راجع الـ AuditLogs بتاعة SSPR بشكل دوري ضمن الـ workflow بتاعك في Defender XDR، مش بس وقت الحادثة.
• خلي الـ Password Writeback مفعّل ومختبر بشكل دوري لو عندك Hybrid environment، عشان تتجنب تضارب بين الـ cloud والـ on-prem password.

الخلاصة

SSPR مش مجرد فيتشر بتفعّله وتسيبه، لازم تتابعه وتراجع سلوكه بشكل دوري زي أي جزء تاني من الـ Identity infrastructure. أكتر حاجة بتوفر وقتك هي إنك تفهم من الأول إزاي الـ Authentication methods بتتربط مع بعض، وإزاي الـ Conditional Access ممكن يعطل الـ flow لو معملتش Exclusion صح.

1. فعّل SSPR على مجموعة Pilot الأول قبل ما تعمم على الكل.
2. اربط الـ SSPR بالـ Combined Registration عشان تقلل الـ friction.
3. فعّل الإشعارات وراقب الـ Logs بانتظام عن طريق KQL.
4. ما تسيبش الحسابات الحساسة (Privileged) تستخدم SSPR أصلًا.

انت جربت SSPR في بيئتك وواجهت مشكلة مش موجودة هنا؟ شاركنا التجربة في الكومنتات.