Self-Service Password Reset in Microsoft Entra ID

Fifth in this series on Microsoft Entra ID, focused specifically on self-service password reset (SSPR): who it can be assigned to, how the admin experience differs from the standard user flow, and the hybrid mechanic — password write-back — that makes it work against an on-premises directory.

Self-service password reset (SSPR)

SSPR lets users reset their own passwords without going through IT support, which both reduces support load and improves the user experience — and it does this without weakening security, since users have to verify their identity before a reset is allowed. A quirk worth knowing: SSPR can only be assigned to a group of users or to all users — not to individual users directly. If you don't want the setting applied to everyone in a group, you exclude specific users from that group rather than targeting them individually.

Administrators are a special case: the regular SSPR policy doesn't apply to users in administrative roles (Security Administrator, Billing Administrator, or any other admin role). Admins go through a stricter two-gate policy to reset their password instead, and — notably — they're excluded from using security questions as a verification method, using the enhanced process instead. SSPR is enabled by default for admin roles, and multi-factor authentication is required for SSPR generally, adding a mandatory extra layer of verification on top of whatever identity questions are asked.

On the hybrid side, Microsoft Entra Connect synchronises on-premises Active Directory with Microsoft Entra ID. The feature that lets a cloud-initiated password reset flow back to on-premises AD is specifically password write-back — worth calling out by that name, since the raw note referred to it as "Password Sync (Password Pushback)," which risks confusion with password hash synchronisation (a different, opposite-direction feature: it flows password hashes from on-premises AD up to the cloud, not the other way round — see the hybrid identity post later in this series for how that fits into the broader authentication picture). Write-back is what makes it possible for a user to reset their AD DS password from the Azure portal in the first place.

Licensing for SSPR follows the same familiar pattern: admins are always enabled for SSPR and require MFA, but end users need an appropriate premium licence to use the feature. One easy-to-miss administrative step: before assigning a licence to a user, specify their usage location in the user profile — some Microsoft services aren't available in every location, and this setting is what governs that.

Worked example: enabling SSPR in a hybrid tenant

A Microsoft Entra tenant uses Microsoft Entra Connect to sync with an AD DS domain. Users need to be able to reset their AD DS password from the Azure portal, using two different reset methods. What two actions get this working?

Run the Microsoft Entra Connect wizard to enable password write-back, and configure the authentication methods option to enable the two reset methods required.

This is a good example of where the hybrid model shows its seams: self-service password reset only reaches back into AD DS if write-back is explicitly turned on — it isn't implied by having Connect sync running.

Gotchas and caveats

The SSPR-vs-write-back-vs-hash-sync naming is a real trap — three differently-directioned features with overlapping vocabulary, and getting the direction wrong in a design conversation is an easy way to design something that doesn't do what you think it does. If you only remember one distinction: write-back flows cloud → on-premises (it's what SSPR needs), and hash sync flows on-premises → cloud (it's what lets cloud sign-in use the on-prem password in the first place). They solve different problems and both can be enabled at once.

Sources

(No new external sources beyond what's already covered in this series — see the hybrid identity and Access Reviews/licensing posts for the Microsoft Learn references behind password write-back and licensing generally.)