top of page
Writer's pictureRadhakrishnan Govindan

How to Implement Self-Service Password Reset (SSPR) – A Complete Walk-through

Updated: Dec 27, 2023

What is SSPR?

SSPR is the Self-Service Password Rest Portal for the Office 365 Users. It enables users to reset the accounts and enables users to unblock their accounts without reaching IT Team. It helps to increase the productivity.

In the past, On-premise closed environment, If user accounts locked, they need to reach their IT team to unlock their account. It is time-consuming process and if users are sitting outside the Corporate network and not connected to the VPN Network, they can’t change their passwords/reset their passwords. It is always a big challenge for the IT team. To come across this issue, the IT team should setup an internet-facing Password resetting portal for the end users. Again, there are multiple challenges.

Why do we need SSPR?

SSPR is Azure Based Portal Solution and it is easy to setup and users can reset their passwords without any issues or reaching Supporting Teams.

Prerequisites for the SSPR?

License Requirement

  1. Cloud-only users Password reset/unlock/change required

Azure AD Basic, Premium P1 or P2, or Microsoft 365 Business.

  1. Hybrid Users enabled with Write Back users want Password reset/unlock/change required Azure AD Premium P1 or P2, or Microsoft 365 Business.

  2. Standalone Office 365 licensing plans don’t support “Self-Service Password Reset/Change/Unlock with on-premises writeback” and require a plan that includes Azure AD Premium P1, Premium P2, or Microsoft 365 Business for this functionality to work.

  3. Licensing requirements for password writeback, https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback#licensing-requirements-for-password-writeback

  4. More information on License requirements, https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-licensing

Hybrid Environment Requirements

  1. If infra is Hybrid Environment using Federated Authentication / Password Hash Sync / Pass-Through Authentication, We need to enable Password Writeback in AAD Connect and Azure AD Level.

  2. How Password Writeback Works, https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback#how-password-writeback-works

Things to know before enabling SSPR?

  1. User accounts that are in Protected Groups of On-premises accounts cannot use SSPR for the password reset. For more details about Protected On-premises users, Please check https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c–protected-accounts-and-groups-in-active-directory

  2. If the user’s password hash is synchronized to Azure AD by using password hash synchronization, there is a chance that the on-premises password policy is weaker than the cloud password policy. In this case, the on-premises policy is enforced. This policy ensures that your on-premises policy is enforced in the cloud, no matter if you use password hash synchronization or federation to provide single sign-on.

Changing/Resetting passwords of administrators

  1. On-premises enterprise administrators or domain administrators cannot reset their password through SSPR. They can only change their password in their on-premises environment. Thus, we recommend not syncing on-prem AD admin accounts to Azure AD.

  2. An administrator cannot use secret Questions and answers as a method to reset passwords.

  3. The two-gate policy requires two pieces of authentication data, such as an email address, an authenticator app, or a phone number.

  4. For more information about Two-gate Policy, https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy#administrator-reset-policy-differences

Security Concerns?

  1. Password Writeback is Tenant-Specific Service Bus Relay. Hence only the tenant AAD Connect Agent is access for the Password writeback process.

  2. After the service bus relay is created, a strong symmetric key is created that is used to encrypt the password as it comes over the wire

  3. All the transactions are taken with TLS Communication using Microsoft TLS Certificates.

  4. More About Security information, https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback#password-writeback-security

  5. Encryption Details, https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback#password-writeback-encryption-details

Supported writeback operations

Passwords are written back in all the following situations:

Supported end-user operations

  1. Any end-user self-service voluntary change password operation

  2. Any end-user self-service force change password operation, for example, password expiration

Any end-user self-service password reset that originates from the password reset portal

Supported administrator operations

  1. Any administrator self-service voluntary change password operation

  2. Any administrator self-service force change password operation, for example, password expiration

  3. Any administrator self-service password reset that originates from the password reset portal

  4. Any administrator-initiated end-user password reset from the Azure portal

Passwords are not written back in any of the following situations:

Unsupported end-user operations

  1. Any end user resetting their own password by using PowerShell version 1, version 2, or the Azure AD Graph API

  2. Any administrator-initiated end-user password reset from PowerShell version 1, version 2, or the Azure AD Graph API

  3. Any administrator-initiated end-user password reset from the Microsoft 365 admin center

Must Not DO?

  1. Use of the checkbox “User must change password at next logon” in on-premises Active Directory administrative tools like Active Directory Users and Computers or the Active Directory Administrative Center is not supported. When changing a password on-premises do not check this option.

Enabling SSPR

Pre-Register Authentication Data for SSPR

Before we begin to enable SSPR, we need to consider setting up few mandatory requirements for the SSPR

  1. Authentication methods

  2. Registration

  3. Notifications

  4. Customization

  5. On-premises integration

Authentication methods

Login to https://Portal.azure.com –>Azure Active Directory–>Users –>Password reset – Authentication methods Select the Number of methods required to reset

Methods available to users, Number of Questions required to register

Number of questions required to reset

SSPR

SSPR

SSPR

Select the 5 Security Questions

Select Predefined Questions or create custom questions based on the organization recommendations

SSPR

SSPR
SQL
SQL

Registration

Login to https://Portal.azure.com –>Azure Active Directory–>Users–> Password reset –>Registration

This is the reconfirm the user authentication requirements select anything between 90-180 Days

SQL

Notifications

Login to https://Portal.azure.com –>Azure Active Directory –>Notifications

Notify users on password resets- Yes to inform users when they reset the Password Notify all admins when other admins reset their password – Yes to inform users when other administrators reset passwords.

SSPR

Customization

Login to https://Portal.azure.com –>Azure Active Directory –>Users –>Password reset –>Customization

Set the helpdesk Support URL for the support in case any issues.

SQL

On-premises integration

Login to https://Portal.azure.com –> Azure Active Directory –>Users –>Password reset–> On-Premises integration

SQL

Enabling SSPR for Pilot Users

It is always good to test it with a small set of people before enabling for the complete users. It will help us to validate each option carefully.

  1. During the Pilot, Create Azure Based Security group and add pilot Users

SQL

Once the Security group is created and pilot users are added, Login to https://Portal.azure.com –> Azure Active Directory –>Users –>Password reset Properties

Select Selected and Select the Group Created.

SQL

SQL
SQL

Testing SSPR

Registering for SSPR

  1. User should register their Accounts for Password reset using the URL: https://aka.ms/ssprsetup

  2. Post user logged in, the User need to set up at least 2 of the options below

SSPR

SSPR

SSPR

Now user has successfully completed the SSPR Setup

Resetting Password Using SSPR

Enter the User ID and characters displayed to begin the password reset,

SSPR

The user has to verify two options to reset the password, it is up to the users to select any of the two options allowed by administrators


SSPR

SSPR

SSPR
SSPR

SSPR

The user has verified 2 options, now user can enter new password to reset


SSPR

It will validate the Password policies defined tenant level. Post verified enter a new password. The user will get a notification

SSPR

How to Successfully Deploy SSPR Communications plan

  1. Microsoft Provides Complete Rollout Mailers / Posters / Stickers

  2. Communication is critical to the success of any new service. Proactively communicate with your users how to use the service and what they can do to get help if something doesn’t work as expected. Review the Self-service password reset rollout materials on the Microsoft download center for ideas on how to plan your end-user communication strategy.

Sample Mailer,

SSPR

Testing plan

To ensure that your deployment works as expected, you should plan out a set of test cases you will use to validate the implementation. The following table includes some useful test scenarios you can use to document your organizations expected results based on your policies.

Implementation

Implementation occurs in three stages:

  1. Configure users and licenses

  2. Configure Azure AD SSPR for registration and self-service

  3. Configure Azure AD Connect for password writeback

Communicate the change

Begin implementation of the communications plan that you developed in the planning phase

Ensure groups are created and populated

Reference the Planning password authentication methods section and ensure the group(s) for the pilot or production implementation are available, and all appropriate users are added to the groups.

Apply for licenses

The groups you are going to implement must have the Azure AD premium license assigned to them. You can assign licenses directly to the group, or you can use existing license policies such as through PowerShell or Group-Based Licensing.

Configure SSPR

222 views2 comments
bottom of page