Lab: test a safe SSPR rollout

Outcome

Enable self-service password reset for one training group, register methods as a non-administrator test user, complete a real password reset in a private browser window, then remove the scope. You will deliberately test an excluded user and diagnose the scope/registration result without weakening emergency-access controls.

Before you begin

Use a non-production Entra tenant with the required SSPR entitlement. You need an Authentication Policy Administrator, a cloud-only non-administrator test user whose password you know, and two training groups: SSPR-Included-<suffix> and SSPR-Excluded-<suffix>. Do not use an emergency-access administrator as the reset subject; protect those accounts under your organization’s separate resilience process.

Do

  1. Add the non-administrator test user to SSPR-Included-<suffix>. Keep a second test user in SSPR-Excluded-<suffix>.
  2. In Microsoft Entra admin center, go to Entra ID > Password reset > Properties. Set Self service password reset enabled to Selected, choose SSPR-Included-<suffix>, and save. The current portal supports one selected Entra group for this setting; record its name and scope.
  3. In the Authentication methods policy, allow only the methods that the training exercise requires. Set the required number of reset methods deliberately. Do not modify deprecated legacy method-management policies.
  4. In an InPrivate/incognito window, sign in as the included non-administrator user at https://aka.ms/ssprsetup. Register the approved methods, then close the window.
  5. Open another InPrivate/incognito window at https://aka.ms/sspr. Complete the reset with the training user, set a new training password, and sign in to a training application. Record the registration state, chosen methods, reset timestamp, and successful sign-in.

Verify

Capture the SSPR scope, included group membership, Authentication methods policy, registration evidence, reset confirmation, and successful post-reset sign-in. You should now understand: SSPR scope allows the flow; registered methods prove the user’s control of the account; password reset is an identity operation, not an Azure RBAC permission.

Break and fix

  1. Use the excluded test user at https://aka.ms/sspr. Capture the scoped-access error. Add that user to the selected training group, wait for processing, register methods, then retest. Remove the user from the group during cleanup.
  2. With an included but unregistered test user, start the reset flow. Capture the registration/method requirement, register only the permitted methods, and retry. Do not lower the required number of methods just to pass the test.
  3. Review an emergency-access account without attempting its reset. Confirm it is excluded from this training scope and has a documented, separately tested resilience procedure. Do not treat SSPR as the sole recovery path for privileged access.

Scenario practice

  1. Configure: A pilot needs a reversible SSPR rollout. Why use one selected group before enabling all users, and what evidence lets you expand safely?
  2. Diagnose: An included user gets “not enabled” at the reset portal. Which scope, license, group-processing, registration, and source-of-authority facts do you inspect?
  3. Distinguish: Contrast SSPR, an administrator password reset, MFA registration, and password writeback. Which changes a cloud password, which proves a method, and which can update on-premises AD?

Clean up

Set SSPR back to its documented pre-lab scope, remove training users from the selected group, remove registered training methods where policy permits, rotate or delete the training account, and delete the temporary groups. Do not remove production users or alter emergency-access accounts as cleanup.

Sources and re-audit

Re-audit when SSPR entitlement, scope limits, authentication methods, or administrator reset policy changes.

Self-service password reset · Multifactor authentication · Conditional Access · Authentication module · All labs