Entra SSPR Failing–Unexpected Error During A Set Password Operation

On-premises users were unable to use Entra SSPR to reset their passwords. This needs to use the Password Writeback feature, and in this case Entra Connect was used. Nowadays there is also Entra Cloud Sync, but that was not an option for this customer. Users were able to access the SSPR page at https://aka.ms/SSPR and successfully go through all of the steps of the wizard. This included the CAPTCHA, successfully completing a MFA prompt and entering a password that met the on-premises AD DS password policy and Entra ID Password Protection requirements. They received a generic message at the end instructing them that the reset was unsuccessful and that they should contact their administrator.

The full text of the message received was:

"We are unable to reset your password because your account information has changed on-premises. Please contact your administrator for support."

SSPR Background Notes

For details on how SSPR writeback works, please see: How does self-service password reset writeback work in Microsoft Entra ID? and also

Tutorial: Enable Microsoft Entra self-service password reset writeback to an on-premises environment

In many cases SSPR failures are caused by a lack of permissions that are granted for the Entra Connect sync account. That is typically an account called MSOL_************. The twelve characters are replaced by asterisks as the account will be unique to every environment.

The permissions were correct in this case, and no changes were required to resolve the issue. This was a more interesting case! Also it should be noted that none of the below were issues in this case:

User was indeed registered
MFA challenge was completed
Entra Connect server has no connectivity issues
Entra Connect was at latest build
User object synchronised to Entra - mailbox in EXO etc. was all functional
No errors logged regarding password changes being synchronised to Entra ID
User account is enabled and not locked out

Entra Connect Background Notes

Below are some great resources on the Entra Connect product:

Microsoft Entra Connect Sync: Understanding the default configuration

Microsoft Entra Connect Sync: Technical Concepts

Microsoft Entra Connect Sync: Understanding the architecture

Generic SSPR Troubleshooting Article

The general SSPR troubleshooting document is Troubleshoot self-service password reset | Azure Docs and Password Writeback has its own subsection here.

The recommended steps are

Those suggestions were all reviewed.

There were no networking issues. TLS 1.2 was functional and the Password Writeback feature was disabled/enabled to reset the configuration, but the issue persisted.

Entra Connect EventID Errors Present

When a user would use SSPR, two errors were logged on the Entra Connect server.

The EventIDs and full text are shown below.

Error 1 – EventID 6329

An unexpected error has occurred during a password set operation.
"ERR_: MMS(9032): ..\ObjectSearcher.cpp(461): AD Object is not present.
BAIL: MMS(9032): ..\ObjectSearcher.cpp(491): 0x80230405 (The operation failed because the object cannot be found): No password writeback targets found. Make sure that the source object exists and is connected to the target objects via MV and the target object is in scope of password sync rule. AAD anchor = User_966e4393-d730-423c-a3c9-001a3699575fAzure AD Sync 2.5.79.0"

Error 2 – EventID 33002

TrackingId: 62a5da50-8a6b-43a4-8418-82f88522ab34, Reason: Synchronization Engine returned an error hr=80230405, message=The operation failed because the object cannot be found, Context: cloudAnchor: User_966e4393-d730-423c-a3c9-001a3699575f, SourceAnchorValue: AMFLaZcQeEerjEZiNFC+BA==, UserPrincipalName: User-1@Tailspintoys.ca, unblockUser: True, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230405, message=The operation failed because the object cannot be found
at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
at AADPasswordReset.SynchronizationEngineManagedHandle.ResetPassword(String cloudAnchor, String sourceAnchor, String password, Boolean fForcePasswordChangeAtLogon, Boolean fUnlockAccount, Boolean isSelfServiceOperation)
at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ResetUserPassword(String passwordResetXmlRequestString, Boolean unlockUser)

Dissecting The Errors

These errors are interesting as they indicate that the operation failed as the user can not be found. But the user was synchronised from AD DS to Entra ID, and changes are successfully synchronised as well. The user object was visible in the Metaverse Explorer. The above tests were for user-1@tailspintoys.ca and you can see the account is present in the Metaverse:

In the below diagram can see the expected flow from the Connected Directory, to Connector Space, to Metaverse to Connector Space to the destination Connected Directory.

The objects need to be aligned in the Metaverse.

The AD DS user object has a representative Connector Space object in the AD Connector Space, which is connected to a Metaverse object, which is connected to Connector Space object in the AAD connector space, which is a representation of the AAD user object.

All of these objects need to be aligned. If not, then there will be issues. Assuming that the default Entra Connect synchronisation rules were in place, then this is generally not an issue.

It would be expected that there are two Entra Connect sync rules that both have the “Enable Password Sync” option enabled. One rule is inbound, the other is outbound. The relevant user object must be in scope for both of these rules. The “Enable Password Sync” option must be enabled on both the inbound and outbound rule. If this is not the case then there will be issues like this.

Keep in mind there maybe more or different if you have done some customisation for Selective Password Hash Sync.

By default there are two sync rules in Entra Connect that should have the setting “Enable Password Sync” enabled. These are:

“In from AD – User AccountEnabled”
“Out to AAD – User Join”

Note that the naming predates Entra ID. There are also attributes in the Metaverse with onpremise(sic) naming, but we will not go there as that’s not going to realistically change…

Assuming that the default rules have the “Enable Password Sync” option enabled and you want to use SSPR and change password functionality in Entra ID, all you should have to do is fire up the Entra Connect configuration wizard and enable Password Writeback in Entra Connect. That should be it!

But in this case, that clearly was not working.

Eureka

The clue as to what went wrong is really within these portions of the error messages, especially the highlighted portion:

No password writeback targets found.
Make sure that the source object exists and is connected to the target objects via MV and the target object is in scope of password sync rule

If we look at those two rules, what do we see?

Firstly, the "Out to AAD - User Join" sync rule. This is shown below and looks normal.

But note that the "In from AD - User AccountEnabled" sync rule is not OK. It is actually disabled. The status is indicated with the big red arrow.

Excellent that must be it! Well almost, more nuance exists below...

There is an important caveat:

In order to create the correct password sync rule rule the “Enable Password Sync” option must be enabled at the time when password writeback is turned on in the Entra Connect configuration wizard. If not, then the password sync rule will not be created and you will have issues.

To summarise the steps to remediate this issue:

The “In from AD – User AccountEnabled” sync rule was enabled
Using Entra Connect configuration wizard, Password Writeback was disabled. Synchronisation was not enabled at this time
The Entra Connect wizard was immediately re-run to enable Password Write back, and synchronisation was enabled

I also did a full sync for good measure at this point.

Bootnote

At one point Selective Password Hash Sync was enabled for testing purposes, and then removed. Copies of the default sync rules were made for selective PHS and the original rules were meant to have been left as-is and only disabled. The additional rules were removed and the default sync rules were meant to have been re-instated in their original pristine condition.
That was not the case. Only one was re-enabled, the other was left in a disabled state.

The addition issue was that the sync rules had to have the correct configuration when Password Write back was enabled. If that was not the case, then the errors that are illustrated above would occur.

Cheers,
Rhoderick