SSPR for synced account failed — error: OnPremisesUserNotFound

Hello,

The OnPremisesUserNotFound (hr=80230405) error occurs because SSPR cannot locate the corresponding on-premises AD object. To resolve this:

Verify that each user exists in on-prem AD and is within the sync scope.

Ensure the on-prem UPN matches the Azure AD UPN.

Confirm the ImmutableId (SourceAnchor) is correctly set for each user.

Make sure password writeback is enabled and the sync account has Reset Password and Replicate Directory Changes permissions.

Once these checks are done, perform a full sync in Azure AD Connect. This should resolve the issue.

Let me know if this works for you.

Thanks

Try the following to resolve:

1. Confirm the On-Prem Object Exists

• Open Active Directory Users and Computers (ADUC)
• Verify that the affected user still exists and hasn’t been moved to an OU excluded from sync

2. Check Sync Rules in Entra Connect

• Open the Synchronization Rules Editor
• Ensure that inbound and outbound rules for user objects are correctly configured
• Look for any custom rules that might be filtering out the user

3. Verify Service Account Permissions

• The account used by Entra Connect must have read/write access to the user object
• Specifically, it needs permission to reset passwords and write back changes

4. Restart the Sync Service

• On the Entra Connect server, restart the Microsoft Entra Connect Sync service
• This can clear transient errors and reinitialize connections

5. Disable and Re-enable Password Writeback

• In the Entra admin portal, toggle Password Writeback off and then back on
• This can refresh the configuration and resolve binding issues

6. Check Network Connectivity

• Ensure outbound HTTPS access to:
• *.passwordreset.microsoftonline.com
• *.servicebus.windows.net
• Use PowerShell to test:

Test-NetConnection -ComputerName <namespace>.servicebus.windows.net -Port 443

This error typically indicates that when a user attempts to reset their password in Entra ID (formerly Azure AD), the writeback service cannot find a matching on-premises object in Active Directory, resulting in a failed reset request, despite the sync itself appearing healthy. A few common causes and checks will usually solve it.

First, confirm that password writeback is really enabled in the Entra ID Connect configuration. Open Azure AD Connect and, in the optional features, verify that “Password writeback” is checked. Sometimes, people enable it in the portal but forget that it also needs to be explicitly enabled in the sync tool.

Next, check attribute matching. The writeback lookup depends on the immutableId (which maps to the on-premises objectGUID). If users are soft-matched by UPN or email instead of hard-matched, the cloud account may not have a valid immutable ID linked. You can run Get-MsolUser -UserPrincipalName email address removed for privacy reasons | fl ImmutableId or the equivalent Graph call to confirm the value. If it is blank or does not match the objectGUID in Active Directory, password writeback cannot find the on-premises user and throws OnPremisesUserNotFound.

Also, verify that the service account running Entra ID Connect has reset password rights on the OU where your user objects live. The minimum is “Reset password” and “Write lockoutTime” on descendant user objects. If you only grant read permissions, the sync will succeed, but the writeback will fail.

Check if the accounts in question are in scope of synchronization. If you filtered by OU or attribute in Azure AD Connect, but the users appear in Entra ID because they were created before the filter change, then writeback will not find them in the on-premises directory.

Finally, confirm that users are not cloud-only. SSPR writeback works only for synced users with an on-premises AD object. If you created a cloud account and later attempted to match it to AD, but it never had a proper immutable ID, writeback will fail.

Recommended next steps:

In Entra admin center, check one of the failing users → Identity → Audit immutableId and onPremisesSyncEnabled attributes.
In local AD, confirm the user exists in a synced OU and has the expected objectGUID.
Re-run the AAD Connect wizard and ensure that Password Writeback is enabled and that the account has the correct permissions.
If an immutableId mismatch is found, run Set-MsolUser -UserPrincipalName email address removed for privacy reasons -ImmutableId <correctGUID> or use the Microsoft Graph equivalent to fix the link.

With those checks, you should be able to remove the OnPremisesUserNotFound error and have SSPR successfullay reset passwords back to AD.