If account management is enabled and set for success, when changing a password you can look for event IDs 627, 628 or 642. The DC that registers on or more of these event IDs for a certain account is the DC where the change occurred. Event ID 627 with 642 means the password was changed by the user and Event ID 628 with 642 means the password was reset by someone. You could monitor these event IDs through some monitoring tool or by using EventComb from MS.
If you have a ton of DCs to look at for the event IDs that might take a lot of time to achieve. There is another way though that is easier. As you may know all changes in AD are registered along with (among others) the originating DC (which is the same as the invocation ID of the AD DB on a certain DC). This info is stored in the metadata of the object. To retrieve the metadata of an object you could use REPLMON and REPADMIN.
Start REPLMON and configure a monitored server. Right-click that server and select "Show attribute meta-data for Active Directory object", enter a DN of an object and a window will open showing the object metadata
With REPADMIN -> repadmin /showobjmeta <target DC> <object DN>. this command will output to the command prompt
When a password is changed the following attributes are changed:
The first 5 attributes will always have the same originating USN. The 6th attribute’s originating USN will differ however. For all 6 attributes the originating time will be the same.
Remember that when a password is changed (changed or reset) it is changed on the targeted DC AND on the PDC Emulator FSMO. The latter is not accomplished through normal replication but through "immediate replication" using a the "netlogon secure channel" (RPC call). After that the PDC FSMO replicates it to other DCs through normal intra-site/inter-site replication.
The target DC will also replicate the password using "urgent replication" to other DCs within its own site and to other DCs outside its site where change notifications have been enabled on the site link. The main difference between "urgent replication" and normal intra-site replication is that there is not delay involved. With "urgent replication" the change is notified to other DCs without delay (default for W2K is 5 min. and for W2K3 is 15 sec.)
If a user’s password is changed (changed or reset) and the PDC FSMO IS NOT AVAILABLE the object’s metadata (the 6 attributes mentioned above) will show the target DC where the password change occurred as the originating DC.
If a user’s password is changed (changed or reset) and the PDC FSMO IS AVAILABLE the object’s metadata (the 6 attributes mentioned above) will show the PDC Emulator FSMO as originating DC for the first 5 attributes and the target DC as the originating DC for the 6th attribute. The fun part with this is that the change on the PDC Emulator FSMO through the "Netlogon Secure Channel" is NOT a replicated change but a writing change and because of that the password change on the PDC Emulator FSMO is replicated back to the DC where the password was first changed as a new change (although the password is the same). This is true after replication has occurred to all DCs.
So the attribute called "supplementalCredentials" might help you determine where the password change/reset originated!
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########