You have probably had to reset the password on your account or someone else’s account. Although at first glance such a change seems trivial, in reality it involves some kind of risk and is… a huge waste of time. Today, I’m going to give you some reasons to implement Self-Service Password Reset (SSPR), a solution that can streamline the password change process in your organization. I’ll also show you how to configure it so that everyone is happy :winking_face:
What is Self-Service Password Reset (SSPR)?
Self-Service Password Reset (SSPR), is a feature of Entra ID that allows you to reset your password in case you have lost or forgotten it. If you’re an introvert like me, you probably hate calling people. With SSPR, you can reset your password without having to call IT. A really handy feature! Were you hoping for a longer description? I am sorry to disappoint you, but Self-Service Password Reset does exactly what its name implies.
Why should I enable SSPR?
So, Mr. Damian, why should I enable Self-Service Password Reset? Look, I have two good arguments for you that will make you like SSPR:
Save money and reduce unnecessary IT overhead
Every time an employee’s password is changed by the IT department, it is time consuming. Depending on the number of employees, the cost of this change can be truly frightening. On the other hand, changing the password of the same employee for the nth time is not an activity we like to do. So by implementing SSPR, we can solve two problems at once 🙂
It’s really worth it to open Excel and sum up the number of password change tickets. Then you can see how serious the problem is.
Enhance security
How can something as simple as allowing employees to reset their own passwords affect an organization’s security?
Reason #1
Let’s start with the fact that password change is a process that is highly vulnerable to social engineering. How do you securely confirm the identity of a person who has just lost access to his/her company account and is calling you on the phone? After all, the person responsible for resetting passwords doesn’t know the voice of every employee in the company. What’s more, tools such as Microsoft’s VALL-E are capable of imitating other people’s voices with just a few seconds of a recording of victim’s conversation. Other questions arise: in what form should the temporary password be handed over?, how can we make sure that our employee will change the password as soon as he receives the temporary one? These are just a few of the many issues associated with the password reset process. A poorly designed process can lead to disaster, and it should also be noted that often such this process simply doesn’t exist or is not written down anywhere…
Reason #2
Not everyone who handles support requests should be able to change user account passwords. By implementing SSPR, we can reduce redundant permissions and minimize the risk of bribing our support staff (you can also pay them more 🙃).
Reason #3
Because it’s a Microsoft recommendation, for which we get points in Secure Score. It’s like loyalty points, everyone likes to collect them.
Secure Score is a tool that lists actions and recommendations to improve the security of your services such as Microsoft 365 or Entra ID. The progress of these recommendations is automatically measured and scored so you can monitor your organization’s security posture and respond to anomalies like users without MFA or SSPR enabled.
Congratulations, you’ve just acquired another security measurement tool to your collection. Keep in mind, the more Microsoft products you use, the more recommendations you’ll find in Secure Score!
Reason #4
Deploying other Microsoft security products is much easier. For example, Microsoft’s portfolio includes the Entra ID Protection service, which works with Conditional Access to force a user to change their password if their actions or login parameters (such as using the TOR browser) are classified as a risk. This forced password change is treated by the service as a risk-reducing factor for the compromised account. If the SSPR is not in place, the employee will see a sorry message saying that the account has been locked and the only option left is to call a friend (the IT department).
You’ll find more information about Entra ID Protection in this post.
Why worry about SSPR?
If SSPR didn’t have any flaws, most companies would have already implemented it. Here are some typical “objections” to SSPR that I have heard in the past, along with my comments.
Objection #1
SSPR requires users to provide a private email address or security questions. These methods seem risky, especially for “not so smart” employees.
Answer: We are not required to use the above methods. It is up to us to decide which SSPR methods our employees can use. If you are concerned about using poorly secured private email addresses that are completely out of your control, then either opt out or require two different authentication methods during password resets. For example, require the use of Microsoft Authenticator and security questions or email.
Objection #2
Some of our employees don’t have Microsoft Authenticator app, so implementing SSPR will be cumbersome.
Answer: In this case, you may want to consider having only one mandatory authentication method required for password reset, and allowing the employee to choose it from the options you currently use.
Objection #3
The SSPR registration process is complicated…
Answer: The SSPR registration process is the same as the MFA configuration. But you still use MFA, don’t you?
Objection #4
I have a hybrid environment and SSPR doesn’t work there!
Answer: That’s not true, it actually works very well! Hybrid, although it sounds scary, only requires a few extra clicks, as you will read later in this article.
If your question wasn’t on my list, then you’ll have to convince your “safety guy”, management, or supervisor on your own. I’m keeping my fingers crossed for you 🤞
SSPR technical requirements
Two factors: the licenses you have and whether you are running identity synchronization with your local AD, determine your deployment requirements.
Licenses
I guess it won’t surprise you that Microsoft makes us pay 💲 for a convenient password reset process. What licenses do we need?
| Feature | Entra ID Free | Microsoft 365 Business Standard | Microsoft 365 Business Premium | Entra ID P1 or P2 |
|---|---|---|---|---|
| Cloud-only user password change | ● | ● | ● | ● |
| Cloud-only user password reset | ● | ● | ● | |
| Hybrid user password change or reset with on-prem writeback | ● | ● |
So, if you have a local domain, then you must have a Azure AD Premium Entra ID P1 or P2 license to run SSPR. Fortunately, it’s not so bad, because the cheaper P1 license is enough. If you are 100% cloud-first, then Microsoft 365 Business Standard will be enough to run SSPR.
It could always be better, but considering that we also have Conditional Access in Entra ID P1, I assume that most companies meet the above requirements.
Cloud-only environment
If you don’t have a local domain and only work with cloud-only accounts, then you generally only need to enable SSPR in the Microsoft Entra admin center portal. Of course, be sure to review the default configuration before enabling it!
Hybrid environment
By default Entra ID users’ passwords are always synchronized “from below” i.e. from Active Directory. Therefore, we need to change this behavior using the password writeback option provided by the Entra Connect tool. When password writeback is enabled, password changes from the cloud will be synchronized “from above (cloud)” to our local domain. In addition, the configuration may require you to extend the Entra Connect service account privileges.
Do this before SSPR activation
Configuring Self-Service Password Reset is not just about the options in the Admin Center. It is also about the people who will use them. Before rolling out SSPR it’s a good idea to send out “company propaganda” i.e. information about the new password reset options, and to update any procedures and instructions.
Don’t have an idea for your own advertising campaign? Use Microsoft SSPR rollout materials!
Configuration - How to enable SSPR?
Self-Service Password Reset settings panel is located in the Microsoft Entra admin center.
Look for the blade: Protection -> Password reset
Lets have a look at the options that are available to us in each tab.
Authentication methods
In the Authentication methods section, we set the available methods for validating the employee’s identity during a password reset, as well as their required number (1 or 2 of them).
The authentication methods available in the portal:
- Mobile app notification - During the password change process, employee will receive an alert in the Microsoft Authenticator app. The employee will be prompted to accept or reject the alert. This option is not available if only one authentication method is used.
- Mobile app code - The employee must enter a “one-time password code” from the Microsoft Authenticator app (or another app if you don’t like Microsoft’s) to make a password change. The code in the application changes every 30 seconds.
- Email - When resetting the password, the user will be asked to enter a one-time code that will be sent to the private email address previously registered with SSPR.
- Mobile Phone - Authentication via a one-time code from an SMS message or a phone call. In the case of a phone call, you will receive a call from a Microsoft robot asking you to press the specified key on the keypad (or screen, if your phone doesn’t have a physical keyboard :mobile_phone:).
- Office Phone - Same as Mobile Phone, but without the SMS feature.
- Security Questions - The employee will be asked to answer the security questions that he/she has previously set up individually. The number of questions depends on the SSPR configuration. We can create our own list of questions for the employee to answer, but we have no control over the content of the answers.
My comments on authentication methods:
Personally, I try to avoid the Security Questions and Office Phone options. For the former, security is guaranteed by our employee not typing in brainless answers to security questions, which can’t be guaranteed and brings some risk. As for the Office Phone option, I don’t like the ability to have someone “impulsively” approve a password change. This method is often used by employees who don’t have a home or work phone, and the office phone number is controlled by someone other than the person doing the password reset. It’s also worth mentioning that the machine doesn’t specify the name of the account for which the reset is being performed. So we blindly accept the change :face_with_diagonal_mouth:
If you are considering the Email option, I recommend setting up two mandatory authentication methods to protect against the potential compromise of the private email account.
Registration
In the Registration section, we can configure a notification message to prompt employees to register missing authentication methods for SSPR. This message will appear the next time they log in to the account. If we don’t enable it, an employee may be surprised when he/she tries to reset the password and finds that the feature is not available (no password reset methods configured).
In addition, we can force a recurring periodic check to see if the configured authentication methods have accidentally become outdated. The maximum time we can set is 730 days. If we don’t want our employees to be bombarded with such notifications (and in my opinion it’s worth it), we can disable the notifications by entering 0 as the value of this setting.
Notifications
The next section is Notifications, where we can configure the notifications sent by SSPR after a password change is made.
There are two types of notifications available:
for user (Notify users on password resets?) - user will receive a notification at his email address when someone changes the password on his/her account.
for admin accounts (Notify all admins when other admins reset their password?) - any user with the Azure administrator role will receive a notification when another Azure administrator changes his/her password. An admin forgetting password is a rare phenomenon, so it’s always a good idea to ask your colleague if he/she is definitely the one who performed the reset :smiling_face_with_halo:
Which Azure administrators will receive the notification? The setting description doesn’t specify this, but most likely it will be everyone covered by Default SSPR policy for administrators.
Customization
As for SSPR’s customization options, under the Customization section we have the option to add our own custom helpdesk link or email address. Naturally, if we feel the need to do so. It will be displayed during password reset to an employee.
Properties
Finally, it’s time for the first, last, and most important section, which is Properties. Here we enable Self-Service Password Reset (SSPR).
If you want full control, you can enable SSPR only for a selected group of users. This is also a good idea if you plan to pilot the service. For technical reasons, we cannot select only one group, but we can use “groups within groups” known as nested groups.
As a result, our cloud security group will include both cloud-only accounts and a local Active Directory group that contains hybrid AD users.
Done. In a few minutes, SSPR should be available to your employees.
Configuration - How to enable SSPR for hybrid environments?
To run SSPR for users from the local Active Directory (AD), we will need three things:
- enable the password writeback option in Entra Connect,
- assign additional privileges for the Entra Connect service account,
- Enable SSPR on-premises integration with the local AD in Microsoft Entra admin center.
Of course, you can try to ignore the first two items on the list, but Microsoft Entra admin center won’t let you go any further and will display a nice message No agents that are capable of performing password writeback have been detected.
Enabling password writeback
To activate password writeback, connect to your AD Connect server (Entra Connect), run the Azure AD Connect wizard, and then click Configure.
From Additional tasks select Customize synchronization options and click Next.
Log in to the Global Administrator account and confirm MFA.
Make sure you’re changing the settings for a good Active Directory forest and click Next.
Make sure synchronization range (Domain and OU filtering) is correct and click Next.
Finally, select the Password writeback feature and click Next.
Confirm your changes and click Next. The wizard will take some time to reconfigure the synchronization settings.
Done! Close the wizard with the Exit button. After a few minutes, the On-premises integration section in Microsoft Entra admin center should be fully unlocked!
Verification of password reset privileges for Entra Connect
What permissions does the AD Connect Entra Connect account need to reset passwords? The list looks as follows:
- Reset password
- Change password
- Write permissions on lockoutTime
- Write permissions on pwdLastSet
- Extended rights for “Unexpire Password” on the root object of each domain in that forest, if not already set.
If you are using the default service account that was created when you first set up AD Connect, I have good news for you - you don’t need to take any additional action. This account should automatically have the correct permissions.
How do I check which AD Connect account I’m using?
Open the AD Connect wizard again and this time select View or export current configuration from the Additional tasks list.
Your service account should appear under Synchronized Directories:
After you have found it, don’t forget to close the wizard!
How to check the permissions for an object?
Now that we know the name of our service account, we can verify that it has all the necessary permissions.
Open the Active Directory Users and Computers tool, select your test user, then click Properties and go to the Security tab.
The list should include your AD Connect service account. However, this view is too simplified, so select Advanced and go to the Effective Access tab.
Now you can select your service account and verify that all the permissions in the above list are present.
If your service account doesn’t have all the permissions granted, be sure to check:
- whether the object being checked has permission inheritance enabled,
- whether permissions are granted for an OU/domain higher in the Active Directory hierarchy.
You can find a guide on how to assign permissions in Microsoft docs.
Now we can go back to Microsoft Entra admin center!
Enabling SSPR integration with local AD
Let’s log back into the Microsoft Entra admin center and go to the Self-Service Password Reset settings. This time select the On-premises integration section.
As you can see, there is no trace of our earlier error! From the available options check Write back passwords with Azure AD Connect cloud sync, which will allow you to write back passwords from Entra ID to the local Active Directory.
After saving the changes, we can add our test/target employees to the previous cloud security group and start testing!
Tests - What does the SSPR registration look like?
Currently, the SSPR registration process is no different than the MFA setup process. The only noticeable difference is that if the SSPR service is enabled and requires two authentication methods, the wizard requires two registration steps instead of one.
Sample SSPR registration
We have two ways to register authentication methods for SSPR. We can go directly to: https://aka.ms/ssprsetup or simply log into test account as we previously forced users to register methods for SSPR in the Registration section.
Let’s test the notification we configured earlier. During the test login, we will be greeted with a message:
The Next button will take us to a typical MFA registration window. The difference is subtle - instead of a single MFA registration, this time we have to configure additionally a phone number as a second component of the SSPR.
Following the message, let’s configure the Microsoft Authenticator app first…
…and the second method for SSPR - the phone number.
Done! From now on, we can reset passwords as much as we want!
Tests - What does the password reset look like?
We can start the password reset process by following the link: https://aka.ms/sspr or while logging in using the Forgot my password option.
The next step will be to make sure that we are not part of a robot army that is fighting to take over the world 🤖
Now it’s time to use the authentication methods we registered earlier. In the first step, I selected the option to send a notification to my Microsoft Authenticator application.
As the option to use the app disappeared, I was forced to enter the one-time code from an SMS message.
After successful double verification, I can proceed to set a new password.
And that’s it. The password has been changed and written back to the local domain, thanks to password writeback.
Everything without contacting the IT department :smiling_face_with_sunglasses:
Default SSPR policy for administrators
You may have noticed during your journey through the Microsoft Entra admin center that admin accounts have predefined SSPR policies by default. This is indeed true, and what’s more, these policies are enabled by default, even if you haven’t made any changes.
Doesn’t sound good? Having said that, I would also like to add that all authentication methods are available to them and there is no way to change them….
Which accounts are covered by the policy?
All users with the following roles are covered by the policy:
- Application administrator
- Application proxy service administrator
- Authentication administrator
- Azure AD Joined Device Local Administrator
- Billing administrator
- Compliance administrator
- Device administrators
- Directory synchronization accounts
- Directory writers
- Dynamics 365 administrator
- Exchange administrator
- Global administrator or company administrator
- Helpdesk administrator
- Intune administrator
- Mailbox Administrator
- Partner Tier1 Support
- Partner Tier2 Support
- Password administrator
- Power BI service administrator
- Privileged Authentication administrator
- Privileged role administrator
- Security administrator
- Service support administrator
- SharePoint administrator
- Skype for Business administrator
- User administrator
For the latest list of roles, see the link: Administrator reset policy differences
How to disable the built-in administrator policy?
We can disable the built-in administrator policy with the Update-MgPolicyAuthorizationPolicy command. However, Microsoft did not give us the option to disable it only for specific accounts, so changing this setting will disable SSPR for all administrators. It is worth knowing this before you decide to tweak the settings 🙂
Instruction
To use the Update-MgPolicyAuthorizationPolicy command, we must first install the Microsoft.Graph PowerShell module.
| |
Then we connect to our Microsoft 365 tenant using Microsoft Graph:
| |
Just to make sure that Microsoft didn’t accidentally forget to update the documentation, let’s see if the policy is actually enabled:
| |
Looks like we are missing some permissions :face_with_diagonal_mouth: We need to fix this.
| |
Permissions have been fixed, but the formatting leaves much to be desired… Let’s try to display our policy as a list.
| |
Much better. The AllowedToUseSspr name and value match the documentation. Now we can disable SSPR for admin:
| |
Done. Now all we have to do is wait for our policy to take effect. According to the documentation, this can take up to 60 minutes.
Tests after change
The setting has been changed, so it’s time to see if our administrator policy has actually been disabled. Let’s start by quick verification in Microsoft Entra admin center.
Great, our change is shown in the portal. Now let’s try to do a password reset for some admin account.
Despite the configured authentication methods, we cannot reset the password. Let’s see what the SSPR_009 error means.
SSPR for Administrators isn’t enabled on the tenant. SSPR for Administrators (SSPR-A) was the first implementation of SSPR. After SSPR for Users (SSPR-U) was introduced, users could have two separate configurations.
I think we can consider our tests complete 🙃
Congratulations! You have successfully disabled the built-in SSPR administrator policy.
What if…
You’re probably wondering what would happen if you add an administrator account to a group that you previously configured for regular users. Would it work? Let’s find out!
Let’s add the user to our group:
And after some time, let’s try to change the password…
Well, at least you don’t have to test it yourself because you already know it won’t work :grinning_face:
Conclusion
In this post, I explained why you should use Self-Service Password Reset (SSPR) and how to configure it. I also explained how SSPR works in practice and what kind of messages you or your colleagues might get. I hope my long-winded monologue wasn’t too boring and that at least some of what I wrote resonated with you.
On the other hand, if you came here just to look at memes, now you can see how many things your admin has to analyze and test in order to deploy a super-simple option like Self-Service Password Reset :grinning_face_with_sweat:
Additional resources
- Microsoft Docs - Tutorial: Enable users to unlock their account or reset passwords using Azure Active Directory self-service password reset
- Microsoft Docs - Tutorial: Enable Azure Active Directory self-service password reset writeback to an on-premises environment
- Microsoft Docs - Licensing requirements for Azure Active Directory self-service password reset
- Microsoft Docs - Update-MgPolicyAuthorizationPolicy
- Microsoft Docs - Troubleshoot error SSPR_009
- Microsoft Download Center - SSPR rollout materials
- Practical 365 - Connecting to the Microsoft Graph Using the PowerShell SDK