How to Find the Source of Account Lockouts in Active Directory

In this post, you will learn how to find the source of account lockouts in Active Directory.

Here are the steps to find the source of account lockouts:

Users locking their accounts is a common problem, it’s one of the top calls to the helpdesk.

What is frustrating is when you unlock a user’s account and it keeps randomly locking. The user could be logged into multiple devices (phone, computer, application, and so on) and when they change their password it will cause ongoing lock-out issues.

This guide will help you to track down the source of those lockouts.

Check it out:

Step 1: Enabling Auditing Logs

The first step to tracking down the source of account lockouts is to enable auditing. If you do not turn on the proper auditing logs then the lockout events will not be logged.

Here are the steps to turn on the audit logs:

1. Open Group Policy Management Console

This can be from the domain controller or any computer that has the RSAT tools installed.

2. Modify Default Domain Controllers Policy

Browse to the Default Domain Controllers Policy, right-click, and select edit. You can also create a new GPO on the “Domain Controllers” OU if you prefer to not edit the default GPO.

3. Modify the Advanced Audit Policy Configuration

Browse to computer configuration -> Policies -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Management

Enable success and failure for the “Audit User Account Management” policy.

Next, enable the following:

computer configuration -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Logon

Enable Success and Failure for “Audit Kerberos Authentication Service.

Auditing is now turned on and event 4740 will be logged in the security events logs when an account is locked out. In addition, the Kerberos logs are enabling which will log authentication failures with the lockout. Sometimes event 4740 does not log the source computer and the Kerberos logs provide additional details.

Step 2: Using the User Unlock GUI Tool to Find the Source of Account Lockouts

This step uses the User Unlock Tool to find the event ID 4740 and other event IDs that will help troubleshoot lockouts.

I created this tool to make it super easy for any staff member to unlock accounts, reset passwords and find the source of account lockouts. It also has some additional features to help find the source of lockouts.

This is a much easier option than PowerShell.

1. Open the AD Pro Toolkit

You can download a free trial here.

Click on the “User Unlock” tool in the left side menu.

Step 2. Select Troubleshoot Lockouts

Select Troubleshoot lockouts and click run

You will now have a list of events that will show the source of a lockout or the source of bad authentication attempts.

In the above screenshot, you can see the account “robert.allen” lockout came from computer PC1.

There will be times when event 4740 does not show the source computer. When that happens you can use the other logged events to help troubleshoot log out events. For example, if the above screenshot had no event 4740 I can look at 4771 and see the failed authentication attempt was from a computer with the IP

In addition, you can unlock the account and reset the password all from one tool. The tool will display all locked accounts, you can select a single account or multiple accounts to unlock.

The unlock tool is part of the AD Pro Toolkit. Download your free trial here.

Step 3: Using PowerShell to Find the Source of Account Lockouts

Both the PowerShell and the GUI tool need auditing turned before the domain controllers will log any useful information.

1. Find the Domain Controller with the PDC Emulator Role

If you have a single domain controller (shame on you) then you can skip to the next step…hopefully you have at least two DCs.

The DC with the PDC emulator role will record every account lockout with an event ID of 4740.

To find the DC that has the PDCEmulator role run this PowerShell command

get-addomain | select PDCEmulator

2: Finding event ID 4740 using PowerShell

All of the details you need are in event 4740. Now that you know which DC holds the pdcemulator role you can filter the logs for this event.

On the DC holding the PDCEmulator role open PowerShell and run this command

Get-WinEvent -FilterHashtable @{logname=’security’; id=4740}

This will search the security event logs for event ID 4740. If you have any account lockouts you should see a list like the below.

To display the details of these events and get the source of the lockout use this command.

Get-WinEvent -FilterHashtable @{logname=’security’; id=4740} | fl

This will display the caller computer name of the lockout. This is the source of the user account lockout.

You can also open the event log and filter the events for 4740

Although this method works it takes a few manual steps and can be time consuming. You may also have staff that is not familiar with PowerShell and need to perform other functions like unlock or reset the user’s account.

That is why I created the Active Directory User Unlock GUI tool. This tool makes it super easy for staff to find all locked users and the source of account lockouts.

I hope you found this article useful. If you have questions or comments let me know by posting a comment below.

Recommended Tool: Permissions Analyzer for Active Directory

This FREE tool lets you get instant visibility into user and group permissions and allows you to quickly check user or group permissions for files, network, and folder shares.

You can analyze user permissions based on an individual user or group membership.

This is a Free tool, download your copy here.

12 thoughts on “How to Find the Source of Account Lockouts in Active Directory”

  1. Hi,

    What about the events with an empty Calle machine and no IP information? How could you track that issue?

    Than you.

    • Yeah, I have an account with no caller computer name, how does that get tracked?

      • It could be non-windows device such as mobile device as AD can’t read non-windows devices so need to ask user to clear cached credentials on his personal devices if he is using office/skype/email application on it

  2. In real terms it is not unusual in some environments to see the event viewer on the dc contain an event with no originating source information, perhaps just saying “WORKSTATION”. The best auditing tool in the world can’t report on what is not logged. Leaves you with two choices, work with customer to consider any and all devices they could have cached profiles / creds on and eliminate one by one. (Also consider whether any of your services could have basic auth enabled as the cause could be a brute force password attempt from a malicious party, which is simpler with basic auth). OR go nuclear and enable netlogon debug logging. Not to be taken lightly and in the strongest possible terms DO NOT leave this on and walk away. As per MS guidance use at your own risk. “”

    • Good information. Thanks Mark

    • Wow. Thank you, Mark for the “go nuclear” advice and link. It totally uncovered something very bad on our network that was causing accounts to get locked out.

      • Glad this worked. I’ve had trouble getting the debug to display anything useful on 2019 servers.

  3. Smartquotes: The bane of Sysadmins everywhere. Totally put a monkeywrench in the commands shown here. Thanks for the tips though! Very helpful!

  4. I’m trying your GUI tool now… does it not just connect to the PDC? I’m showing it query every DC in my environment when I click More Details.

    • Some information it pulls from the user account so it needs to connect to all domain controllers.

  5. I have a user who keeps getting locked out. They are generating a 4740 event that shows their computer as the source of the lockout but no process/application information.

    There are no 4771 events being logged.

    Any ideas?

    • Make sure success and failure are enabled for “Audit User Account Management” and Audit Kerberos Authentication Service” policies.

      I walk through this at around 7:40 in the video on this page.


Leave a Reply to Mark Cancel reply