Have you ever had problems with account lockouts, changes occur on objects but you don’t know where it came from? There are good tools you could download and use for this kind of things but there is a built in tool that can help us immediately.

Repadmin is a tool for managing and troubleshooting replication between DC/DSAs. It’s built in in Windows server 2008 and later, it comes with 2003 Server if you promote it to a DC. You could also add it through RSAT.

If you open a command prompt and run repadmin /? It will present us a lot of options. In this case we are interested in the /showobjmeta option.

Showobjmeta: Displays the replication metadata for a specified object stored in Active Directory, such as attribute ID, version number, originating and local Update Sequence Number (USN), and originating server’s GUID and Date and Time stamp.

With this information we could track different type of changes in the domain by running:

repadmin /showobjmeta [DC Name] [distinguished Name]

If we start with a password reset of a user, 6 attributes will change and replicate to the other DCs.

• dBCSPwd
• unicodePwd
• ntPwdHistory
• pwdLastSet
• supplementalCredentials
• lmPwdHistory

As you can see in the picture we will get info about the local USN, Originating DSA/DC and its corresponding site. Originating USN, the time of the change, version number and of course the attribute.

What if you would like to know where the user account was disabled, or a change of the flag password never expires was made?

Then we have to look at the userAccountControl attribute. The userAccountControl attribute dictates some behaviors and characteristics of the user accounts, and ha whole list of different flags to be used could be found here.

In this picture we can see the highlighted userAccountControl, we have the same information as in the last picture which will give us a good hint of which site and DC the changes are being made in.

The last thing I’m going to cover is the account lockout which could be a bit tricky and there is a lot of people having trouble with localizing the source problem.

When a user gets locked out after entering the wrong password we need to trace where it happened to be able to evaluate what’s causing this lockout.

In this picture we have the lockoutTime attribute highlighted and it show us the originating site and DC. One thing to note is that when a authentication failure occurs the authenticating DC will retry at the PDC Emulator DC and if the threshold is reached the PDC Emulator DC will also perform a lockout. The PDC DC will start to replicate this as an Urgent Replication within its site, the DC that handled the authentication will also perform a lockout and start an Urgent Replication within its own site.

This behavior will give us two originating DSA/DCs. When looking for account lockouts you need to be aware of which DC holds the PDC Emulator FSMO role and then go after the one that handled the authentication to be able to investigate it further.

Example command to query all the DCs for a specific user:
repadmin /showobjmeta * “cn=clarice starling,ou=domain users,dc=corp,dc=secid,dc=se”

The star (*) tells repadmin to query all the DCs in the domain (use server name if you want to target a specific DC) and then which user you want to query by its distinguished name (DN). Then you compare the output to find the real originating DC.

Another problem with this behavior is that the account is locked out on two different DCs approximately at the same time. The PDC Emulator DC could eventually (during normal replication) overwrite as last change and it will look like it’s the originating DC. If we also have enabled change notification between sites it could go fast and you don’t even notice the real originating DC at the beginning.

For this we could use another option:
repadmin /showattr * “cn=Clarice Starling,ou=domain users,dc=corp,dc=secid,dc=se” /atts:badPasswordTime,badPwdCount

The showattr option is when we want to see the attributes for a specific user, add the atts option to show only specific attributes value which in this case is the badPasswordTime and badPwdCount.

If we look at the marked attributes we see the bad password count that triggered the lockout and the oldest timestamp from where the account lockout actually took place and then the most recent, in this case the DC holding the PDC Emulator FSMO role.

The LockoutStatus.exe application that is part of the ALTools package and can be downloaded here from Microsoft, also show you the same information and behavior.

Another easy way to trace account lockouts is to query the Security event log for event id: 4740 on the DC holding the PDC Emulator FSMO role.

And hopefully you will see the computer name where the user tried to login from, in this case Client7.

It’s a good recommendation to enable auditing for this kinds of events and there is a few more event IDs and logs you could enable in your domain for deeper troubleshooting of lockout problems, you can find more information in the article: Maintaining and Monitoring Account Lockout at TechNet.

Well that’s all for today.