I understand that you are receiving an SSPR error even though the password is getting changed locally. I've seen this particular error caused by a few different variables before and suggest the following steps to resolve it. Please bear with me as it's a somewhat longer troubleshooting list, though the steps should be relatively straightforward:
- Make sure that you are using an FQDN format, instead of the NETBIOS name in your AD-Connect configuration. To do so, you need to confirm that your account is a member of ADSyncAdmins and make sure that you are added to this group. For more details, see SSPR problem. Open the Synchronization Service Manager > Connectors > open the Active Directory Domain Services window > Configure Directory Partitions > and under “Domain controller connection settings” click configure and you will see the list of DCs that ADConnect connects to and in which order. Make sure that your DC’s are formatted in a Fully Qualified Domain Name like “DC01.domain.com“
- In general, when you are troubleshooting password writeback, make sure to get the UPN of one of the affected users, check the audit logs for failed attempts at SSPR, and collect the time stamp. Then check the event viewer for that user around that timestamp. That will shed more light regarding the issue. Note that even if the ADCS has the right set of permissions for Password Writeback, it is possible that the targeted accounts could have inheritance disabled.
- Verify that the user's password is not blocked by an on-prem password policy a. From on-prem domain controller, check the default password policy using cmd Get-ADDefaultDomainPasswordPolicy If you have a minimum password age (MinPasswordAge) and have recently changed the password within that window of time, you're not able to change the password again until it reaches the specified age in your domain. For testing purposes, the minimum age should be set to 0. If you have password history requirements (PasswordHistoryCount) enabled, then you must select a password that has not been used in the last N times, where N is the password history setting. If you do select a password that has been used in the last N times, then you see a failure in this case. For testing purposes, the password history should be set to 0. If you have password complexity requirements (ComplexityEnabled) , all of them are enforced when the user attempts to change or reset a password.
- Check a particular user's password age with cmd : net user username /domain
- If the above domain password policies are conflicting, update the domain default password policy to our recommended config for testing SSPR which is to have MinPasswordAge=0
- If the above steps do not resolve the error, verify that the user's password is not blocked by Global Banned Password \ AAD Password Protection feature. This could be the case if it's getting changed on prem like you mentioned. See the Password Protection documentation for more information.
Let me know if these steps resolve the issue. If you still face the error after trying them there are a few other possibilities I can think of and we can troubleshoot those. I'm also happy to discuss this over email if you continue to run into this issue. (AzCommunity@microsoft.com "Attn: Marilee Turscak").
If the information helped, please Accept the answer. This will help us as well as others in the community who might be facing similar issues.