Tracking down what user/computer that locks AD accounts

Tracking down that user/computer that locks AD accounts

With an environment spanning 18+ sites and more than 3000 computers around the globe, you could understand how challenging it would be to track down what device/user might be locking user accounts. There are tools out there that you can pay for that can help do this. However, Microsoft has some free tools that with a little testing and use will permit you to quickly track down where the account is being locked and address the situation.
We had a situation recently where malicious software got onto a couple of machines and attempted to use the Administrator account to login. We have account lockout on our Windows 2003 AD domain, so after the appropriate number of invalid tries the Administrator account was locked out in the domain. This is because the machines were members of the domain and the malware did not distinguish the local administrator account from the domain administrator when attempting to elevate authority. Note that we use least user authority in our environment so the malware was not able to spread beyond these two machines. We suspect the machines became infected due to out of date antivirus signatures.
Unfortunately, the antivirus we use did not alert us to the situation. The way we were alerted was by our Microsoft Systems Center Operations Manager (SCOM) implementation. It notified the SCOM admin that the domain Administrator account was locked. The operations team was then tasked with tracking down what or who was locking this account. This is where the Microsoft Account Lockout and Management Tools came in use and helped isolate the cause.
The first tool that we used was the LockoutStatus.exe. The screen looks like this after running and finding the Administrator account is NOT locked out. This is after I had already unlocked the account.

As you can see it checked a lot of domain controllers. I ran this directly on one of the AD domain controllers. When an account is locked out, there will be a lockout time and an Orig. Lock domain controller listed. You can set what account you wish to check lockout on as well as what domain you want to test. The options screen looks like this.

Set AccountLockout target

If the account is locked and a domain controller is listed, the next step is to run the EventCombMT tool. This tool can be used for much more than just account lockout analysis but that is the only focus of its use today. You need to specify several things in this tool to get it to find the event log records of interest.

The domain needs to be filled in. Then right-click in the Select To Search/Right Click to Add field and select what servers’ event logs you wish to scan for the event of interest. In this case, I’m choosing the domain controller that is shown in the Orig.Lock column in the LockoutStatus tool. Select the Security log and the Success Audit and Failure Audit Event Types. The Event ID of 675 is the specific event of interest where the client is attempting to use a locked account. The Text field would have the account of interest.
One additional thing you might consider doing is to narrow down the date range. As default, the eventcombmt tool looks through all of the active logs on the server(s). So, it could take a substantial amount of time to complete the scan. The eventcombmt Options menu item has the following selections that can help you narrow down the search or tweak how the tool runs.

EventcombMT Options

In my case, since the LockoutStatus window would have the Lockout Time listed, I would take a time span on either side of this event. So, in this example, I used a 24 hour period from 11:37 AM yesterday, until 11:37 today.

This modifies the search criteria. Then, click Search and the application searches the event logs of the server(s) for the criteria selected.

When eventcombmt finishes the log search, some summary statistics are displayed.

The application writes a text file to the C:\Temp folder by default. This text file contains a text file with a single line per event found matching the search criteria in the selected logs. A sample line for a search match is shown below with wrapping as needed.

675,AUDIT FAILURE,Security,Wed Feb 11 05:03:15 2009,NT AUTHORITY\SYSTEM,Pre-authentication failed: User Name: Administrator
User ID: %(sid removed for security purposes) Service Name: krbtgt/domain.COM Pre-Authentication Type: 0×2 Failure Code: 0×18
Client Address: 10.xx.xx.200

The Client Address may indicate another domain controller or a client machine. If it is another domain controller, then you will need to rerun the eventcombmt process against that server. If the server is across a WAN link, then consider running the eventcombmt tool directly on that server. It could take a while to search the event logs across a slow WAN link. If the Client Address is the actual suspected source, then go to the client and speak with the user about the situation. If the device or user is locking out a security principal account, then severe action may need to be taken to ensure your environment is not placed at further risk letting the device and/or user remain on the network.
Thanks for reading and let’s continue to be good network citizens!