Event id 656 and 657 for Directory Synchonization

Question

Event id 656 and 657 for Directory Synchonization

Jay 256

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?

Accepted answer

1 additional answer

Your answer

Answer 1

Marilee Turscak-MSFT 37,206 Microsoft Employee Moderator

Hi @Jay ,

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

Jay 256 Reputation points

2022-02-14T22:08:21.807+00:00

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
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2022-02-14T22:51:07.837+00:00

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.
Jay 256 Reputation points

2022-02-15T14:20:44.2+00:00

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.
Jay 256 Reputation points

2022-02-15T17:24:30.983+00:00

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
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2022-02-25T16:23:28.5+00:00

Have you tried to enable an auditing policy in the domain environment ? There should be an event log at security logs category in AD machines with id 4723 or 4724 if a password change happened.
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2022-02-25T16:56:40.953+00:00

If a full password hash cycle was triggered you would observe these events being logged.
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2022-02-25T17:05:05.947+00:00

I notice that date is from 2015 as well. Is that what is logged?
Jay 256 Reputation points

2022-02-25T17:42:48.737+00:00

I'm pretty sure it's from enabling password write back at this point. As soon as we enabled password write back, we immediately were seeing them 50 at a time in one log, that start right at the moment we did the enabling. We wouldn't have seen thousands o users resetting passwords and there were thousands of users that we were seeing those events for.
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2022-02-25T18:17:06.733+00:00

Yes, looks like that's expected behavior from running the PHS cycle, and the product team confirmed this as well.
Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator

2022-02-25T20:22:21.72+00:00

@Jay ,

I made a pull request to update the documentation. If you have a chance, would you mind accepting the answer for this so that others in the community searching for this information can more easily find it?

Answer 2

Marilee Turscak-MSFT 37,206 Microsoft Employee Moderator

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.

Share via

Event id 656 and 657 for Directory Synchonization

1 additional answer

Your answer