Is it normal to see alot of these events after enabling password writeback from Azure? If so does it do this for all user accounts in the domain?
Hi @Jay9x-2286,
Is it normal to see a lot of these events after enabling password writeback from Azure?
Yes, it is normal to see 656 and 657 if you have users changing their passwords. These are informational events that can contain password change requests for up to 50 users per batch. If the number of password change requests from Active Directory exceeds 50 users, multiple 656 and 657 events will be generated. If you are seeing Event ID 657 “Password Change Result: Success” after Event ID 656, that is a good thing and means that your password synchronization is working. If you are seeing a lot of Event ID 657 “Password Change Result: Failed”, that could be an issue.
Here is what the troubleshooting guide says about these:
Event ID 656
Password synchronization indicates that a password change was detected and tries to sync it to Azure AD. It identifies the user or users whose password changed and will be synced. Each batch contains at least one user and at most 50 users.
Event ID 657
Users whose password successfully synced. (Result: Success)
Event ID 657
Users whose password didn't sync. (Result: Failed)
If the password synchronization is not successful, you can follow the troubleshooting guides to fix the synchronization:
How to troubleshoot password synchronization when using an Azure AD sync appliance
Troubleshoot self-service password reset in Azure Active Directory
Troubleshoot self-service password reset writeback in Azure Active Directory
Hi Marilee,
Thanks much for that information. I think that explains what is happening in our case. If password writeback is enabled for the first time in an Azure Domain, is it also normal to see an initial run of these events I suspect for all users? (Even those that haven't changed passwords recently?) I think that is what is happening in our case, but wasn't sure if it was normal after enabling password writeback for the very first time to see lots of these events.
Thanks, Jay
Are you saying that there were no password changes, but you are seeing these events? If you click into the event you can see which user it is and when the event occurred to verify if it matches for all users when the last synchronization occurred.
The password sync process runs every two minutes to look for passwords that have changed, and 656 and 657 normally indicate a successful change. In general, the synchronization wouldn't run if there was no change, but I believe enabling password writeback might be an exception (or qualify as a change) and you would see events 656 and 657 to indicate that the password synchronization is working.
I have reached out to the Azure AD Connect team to confirm though because I couldn't find documentation of how this behavior works and will update when I hear back.
Yes, there are no password changes for these users as far as I know. Just seeing those events after enabling password writeback for the very first time. I figure that is to be expected, but wasn't 100% sure on that.
Here is a sample I'm seeing from one of the event id 656. This is just one line, but I'm seeing about 50 per event.
Password Change Request - Anchor : REDACTED, CloudAnchor: False, Dn : CN=REDACTED, Change Date : 08/29/2015 05:17:08
I got clarification from the product group:
If a full PHS cycle is run, 656 and 657 will be logged since we re-sync all hashes. So this is expected behavior in your case.
I have made a pull request to update the documentation to include this information.
If this answer helped resolve the question, please consider "marking as answer" so that others in the community with similar questions can more easily find a solution.
2 people are following this question.
