2.1.4. Self-Service Password Reset
💡 First Principle: Password resets are both a top helpdesk cost and a classic social-engineering door. SSPR moves the reset to the user, gated by their own registered proofs — cheaper than the helpdesk and harder to sweet-talk than a human.
Configuration is a short checklist with well-tested corners. Scope: None / Selected group / All — pilot with a group first. Authentication methods: choose which proofs count (Authenticator, email, phone, security questions) and how many are required (one or two) — security questions are the weakest link and can be restricted to registration-only for reset by policy choices. Registration: combined security information registration enrolls MFA and SSPR proofs in one flow; you can require registration at next sign-in and set reconfirmation intervals. Notifications: alert users on their own resets, and alert all admins when any admin resets a password — admin accounts always require two methods and never use security questions.
The hybrid corner is where exams dig: password writeback, enabled via Entra Connect / Cloud Sync, pushes the new password back to on-premises AD so the user's next domain sign-in matches. Writeback requires P1 licensing, and "SSPR works for cloud users but on-prem AD users' new passwords don't work at the office" is the tell that writeback is missing or broken. On-premises integration also surfaces "unlock without reset" — letting users clear an AD lockout separately.
⚠️ Exam Trap: SSPR authorization (who can use it) and SSPR methods (what they must prove) are separate settings — and both are separate from the sign-in MFA policy. A user can be MFA-registered yet unable to reset because they're outside the SSPR-enabled group.
Reflection Question: Why does Microsoft force two authentication methods and ban security questions for administrator SSPR — which attack does each rule close?
