Issue and Background
Azure AD’s Self-Service Password Reset (SSPR) function (https://aka.ms/sspr) is a great tool for organisations looking to simplify their SSPR capabilities for end-users. AAD SSPR displaces costly third-party tools and reduces calls to the service desk.
It has been known to be somewhat difficult to set up from time-to-time, and one particular issue eluded us for quite a while. Some users were successfully able to use the SSPR solution while others received the error “You can’t reset your own password because password reset isn’t properly set up for your organization.” with error code SSPR_0029 mentioned in the details “SSPR_0029: Your organization hasn’t properly set up the on-premises configuration for password reset.”
Root Cause and Resolution
SSPR_0029 corresponds to missing configurations for in the on-premises AD DS environment as outlined in the Microsoft troubleshooting article.
There are two likely causes.
Potential Cause 1 – Permissions of the Azure AD Connect MSOL Accounts
The first thing to confirm, is the necessary writeback permissions are granted in Azure AD to the Azure AD Connect accounts used within the domain. These start with MSOL_[XXXXXX] and there will be one service account per each Azure AD Connect agent you have installed. Recommended practice is to have two, one active and one left in staging mode that can be manually promoted to active in the event the first Azure AD Connect agent gets pooched.
If you open the AAD Connect agent and view the configurations, you will see the name displayed, and is different for each AAD Connect instance in the environment (active and staging).
In our example case, two accounts need appropriate rights delegation.
The permissions for those MSOL accounts should be configured as per the Enable password writeback to on-premises tutorial inclusive of the specific advanced security permissions including:
- Reset password
- Write permissions on lockoutTime
- Write permissions on pwdLastSet
You may choose to set that at the domain root level or on the specific OUs of users being sync’d to Azure AD.
The “Unexpired Password” setting is to be configured on the domain root’s advanced security properties as well, and this setting is only visible when specifying the rights if the scope is set to “This object and all descendant objects, This object only, or All descendant objects”
Permission sets above should be set for each of the MSOL accounts in use. Otherwise, if you ever failed over to the staging AAD Connect agent, you might find SSPR breaks for all users.
If after setting those parameters (may take some time to propagate to all objects), the SSPR function still fails at the same step, then the root cause is likely related to the next probable cause.
Potential Cause 2 – Inheritance is disabled on specific user accounts
Buried in the SSPR_0029 troubleshooting guide is an interesting reference in “Cause 1”.
Interpretation more or less… if SSPR is failing on specific accounts and they happen to be members of the domain’s Protected Groups (Server Admins, Domain Admins, etc.) then SSPR will not work by design. Side note from a security and isolation standpoint, do not sync privileged accounts to Azure AD period. Bad practice.
But the interesting piece is the underlined bit. If a user was ever part of one of those groups, it will fail. Microsoft does not give any further details as to why that is the case, perhaps on purpose, but this gave us a bit of a smoking gun to work from. The first lead came from Spiceworks and then the second from a Microsoft Learn thread.
To save reading, any user that is a member of a Protected Group automatically has security permissions inheritance disabled. Even if you flip it back on to enable, it may disable again automatically in some time. Typically it is enabled for users not in these groups. This is a security and isolation measure in AD DS to avoid unintended or problematic permissions from applying to members of these groups which may imperil the management of the domain or privileged accounts.
The challenge is, if a user was ever added to a Protected Group and then removed, inheritance is never reverted to enabled. In the case of our trouble users, they evidently were once temporarily made a member of one of those groups, as inheritance was not re-enabled afterward, and thus were not receiving the needed SSPR permissions.
Once we enabled inheritance on the accounts in question again, SSPR worked like a charm.
And we see our password change reflected onto the on-premises account as well.
Hope these potential resolutions help.