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

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 Corporate network and not connected in the VPN Network, they can’t change their passwords/reset their passwords. It is always big challenge for the IT team. To come across this issue, IT team should setup 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.

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.
    1. 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. 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

Security Concerns?

  1. Password Write back is Tenant-Specific Service Buss 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
  • Any end-user self-service voluntary change password operation
  • 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
  • Any administrator self-service voluntary change password operation
  • Any administrator self-service force change password operation, for example, password expiration
  • Any administrator self-service password reset that originates from the password reset portal
  • Any administrator-initiated end-user password reset from the Azure portal

From <https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback#password-writeback-encryption-details>

Unsupported writeback operations

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

  • Unsupported end-user operations
  • Any end user resetting their own password by using PowerShell version 1, version 2, or the Azure AD Graph API
  • Unsupported administrator operations
  • Any administrator-initiated end-user password reset from PowerShell version 1, version 2, or the Azure AD Graph API
  • Any administrator-initiated end-user password reset from the Microsoft 365 admin center

From <https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback#password-writeback-encryption-details>

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.

 From <https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-writeback#password-writeback-encryption-details>

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

Select the 5 Security questions

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

Registration

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

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

Notifications

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

Notify users on password resets- Yes to intimate users when the reset the passwords

Notify all admins when other admins reset their password – Yes to intimate users when other administrators reset password.

 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

On-premises integration

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

Enabling SSPR for Pilot Users

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

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

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

Select Selected and Select the Group Created.

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, User need to set up at least 2 of the options below

Now user has successfully completed the SSPR Setup

Resetting Password Using SSPR

To reset password Login to,

https://aka.ms/sspr or https://passwordreset.microsoftonline.com/

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

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

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

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

How to Successfully deploy SSPR

Communications plan

  • Microsoft Provides Complete Rollout Mailers / Posters / Stickers
  • 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,

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.

  For more details — https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-deployment#testing-plan

Implementation

Implementation occurs in three stages:

  • Configure users and licenses
  • Configure Azure AD SSPR for registration and self-service
  • 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 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

For More Details from Microsoft SSPR https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-deployment#configure-sspr

4 thoughts on “How to Implement Self-Service Password Rest (SSPR) – A Complete Walk-through”

  1. So let’s say a user’s phone number is no longer valid because they got a new cell phone. They want to go in and change that information. I am unable to find a place in the current Office 365 setup without going to https://aka.ms/ssprsetup to make that change. Is there a place within the portal to be able to easily click and reset or re-verify this information?

    1. As an administrator, You can update the new phone number for the users or You can simply reset all the MFA options for the user, so when user login again in the Office 365, User will be asked to register from the scratch.. It makes simple and efficient for the users.

Leave a Reply

Your email address will not be published. Required fields are marked *