Account Lockout Tool: Track Down AD Lockout Events

Thanks to: https://activedirectorypro.com

A user calls the helpdesk, you unlock their account, 5 minutes later they call again with another lockout. At this point, everyone is frustrated and no one knows what the heck is causing the lockouts.

I’ve got good news.

There are account lockout tools that can assist and quickly tracking down the source of the issue.

In this post, I’ll walk you through the exact step by step process I use for tracking down the source of random account lockouts.

Recommended Tool: SolarWinds Admin Bundle for Active Directory

3 Free tools, find inactive user or computer accounts  and quickly bulk import new user accounts.

Download your free copy of Admin Bundle for Active Directory

There are many Active Directory Tools that can assist with troubleshooting account lockouts, but my favorite is the Microsoft Account Lockout and Management Tool. It’s free, simple, easy to use and comes bundled with several tools.

Common causes of account lockouts:

When troubleshooting account lockouts, keep this list in mind, 99% of account lockouts are caused by one of the items on this list.

1. Mobile Devices

Phones and other mobile devices can have multiple apps that require active directory credentials, Outlook being on of them. When the user changes their AD password they may need to update their mobile apps as well. With more and more users having multiple mobile devices this is usually the #1 cause from random lockouts.

2. Services

I’ve seen services set to run as a regular user account. This will lead to some lockout issues when the user changes their password. You can open the services console and see what account they are setup to run as. If a service needs to run as a network account it’s best to create a service account and set the password to never expire. If it doesn’t need network access, then make it a local account.

3. Tasks 

Like services, scheduled tasks are often setup with user credentials instead of a service account. Check the scheduled tasks and make sure they are setup to run under a service account.

5. RDP sessions

RDP sessions will often be closed out instead of logging out, this leaves the RDP session still logged into. Unless you have a policy that forces the logoff after a period of time, users could be left with stale RDP sessions. It is best practice to log off RDP sessions when done.

6. LDAP authentication services

This is like services but I’m mentioning it separately because there are many applications that use Active Directory authentication.
For this to work the application needs an account setup that can read the AD objects. I’ve seen individual accounts used for this many times. Like services and tasks, it is best to create a service account for this.

7. User error

Users simply typing in their password wrong. This generally doesn’t result in random, continues lockouts but does create calls to the helpdesk.

Step #1: Requirements

The following requirements must be set or the lockout tool will fail to run properly.

1. An audit policy must be set on all computers and domain controllers, details below. I recommend using group policy to manage the audit policy on all the computers.

2. You must have permissions to view the security logs on the domain controllers and computers.

Configure the Audit Policy with Group Policy

For the domain controllers configure the audit policy settings in the Default Domain Controllers Policy.
For the computers, you can set this in the Default Domain Policy.

See my Group Policy Best Practices guide for tips on the default domain policy.

1. In the Group policy management console expand computer configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy

2. Enable Audit account logon events and audit logon events, enable both success and failure.

What is the difference between the two policy settings?

Audit account logon events: For domain accounts, this policy will capture logon/logoff events on the domain controller. So when you log into the domain the events will get logged on the domain controller.
Audit logon events: This policy will capture logon/logoff events at the workstation.

Step # 2: Download and install

The install just extracts the contents to a folder of your choice.

1. Download the Microsoft Account Lockout and Management Tools here >
https://www.microsoft.com/en-us/download/details.aspx?id=184652.

2. Accept the End User License

3. Type the location where you want the tools extracted.

4. Install completed

Once the file is extracted you should have a list of files like below. The download contains several files and tools, but for tracking down the source of account lockout issues I will be using the LockOutStatus.exe tool only.

Step #4: Run Lockoutstatus.exe

1. Run the Lockoutstatus.exe tool from the folder you extracted to

2. File > Select Target

3. In the target user name box enter the user’s login name (also called the SAMAccountName).

4. In the target domain enter your domain

5. Click OK

You should now see the lockout status of the account you selected.

Make note of these columns:

User State – is it locked
Lockout Time – if its locked make not of the exact Lockout Time
Org Lock – This is the domain controller that it was originally locked on.

In my example user testguy is locked out, lockout time is 7:14:40 AM and its Orig Lock is srvung011.

Now that we have this information, move on to the next steps.

Step #5: Find the caller computer (source computer)

1. Open Event Viewer on the server that shows in the Orig Lock

2. Go to security logs

3. Filter events and for ID 4740

Right Click on Security and select filter current log

Enter event ID 4740 in the event ID field

Click OK

You should now see only events 4740. Find the event that happened at the date and time that the tool showed.

I can see from the logs the lockouts are coming from a PC called V001. Now that you know the source computer you may already know what is causing the issue. If not go to step #6 to find more details on what exactly on the source is causing the lockouts.

Step #6: View logs on the caller computer

If the steps from above revealed the caller computer and you still need more details, then follow these steps.

1. Open the security event logs on the caller computer and look at the logs with the exact time of the lockout. Depending on what is causing the lockout the eventid will be different. In my example, it’s event ID 4625.

Looking at the details I can the process is winlogon.exe and a logon type of 2. A quick google search tells me this event is created when a user attempts to log on at the local keyboard. So this tells me the user is just entering their password in wrong at the windows logon screen.

There you have it, 6 simple steps to tracking down account lock out issues.

Below is another example where the source lockouts come from a user’s cell phone.

Example 2

This example I will lock out an account from a mobile device. The steps are the same as above I just want to see that the original lockout domain controller can be different and the process or service can be different on the source computer.

Account was locked out on DC1 this time at 7:27:25 AM

Filter the event logs on DC1 and look at the details for a caller computer.

GENETECMOBILE is the source.

When I check the event logs on GENTECMOBILE I see an executable in the genetec program files.

With this information, I know a user is trying to authenticate from an app on their mobile device. 

What if there is no caller computer?

Below are several tips for when there is no caller computer listed in the EvenID 4740.

• Have the user doublecheck their mobile device and make sure they have updated their password in all the apps. This is the #1 common cause of lockouts so that’s why I’m mentioning it again.
• Disable ActiveSync and OWA for the user to see if that stops the lockouts. If this fixed it then they need to update their credentials on the mobile device.
• Have the user work on a different computer for the day. Old credentials could be saved in a local app or in the user’s browser. Working from a different computer for the day can help narrow down if the issue is with their computer.