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.

I’ll show you two methods, the first one uses PowerShell and the second is a GUI tool I created that makes it super easy to unlock user accounts and find the lockout source.

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:

Video Tutorial

If you don’t like video tutorials or want more details, then continue reading the instructions below.

Method 1: 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.

Step 1: Enabling Auditing

The event ID 4740 needs to be enabled so it gets locked anytime a user is locked out. This event ID will contain the source computer of the lockout.

1. Open the Group Policy Management console. This can be from the domain controller or any computer that has the RSAT tools installed.

2. Modify the Default Domain Controllers Policy

Browse to the Default Domain Controllers Policy, right click, and select edit.

3. Modify the Advanced Audit Policy Configuration

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

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

Auditing is now turned on and event 4740 will be logged in the security events logs when an account is locked out.

Step 2: 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

Step 3: Finding event ID 4740 using PowerShell

All of the details you need is 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 a list like 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

That is it for method 1.

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.

Check out the steps below for using the unlock GUI tool.

Method 2: Using the User Unlock GUI Tool to Find the Source of Account 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.

Just like PowerShell this tool requires the auditing to be turned on for Account Management. See the steps above for enabling these audit logs.

Step 1. Open the AD Pro Toolkit, click on User Unlock

You can download a free trial here.

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.

Use the search box to filter the events for a specific user

In the screenshot above I can see event 4740 says “a user account was lockout out” and the source computer is 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.

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

Recommended Tool: Hybrid Cloud Monitor

The Hybrid Cloud Monitor tool is designed to monitor and analyze IT infrastructure across on-premises and multi-cloud environments.

Monitor Azure, Active Directory, virtual and physical servers, manage IP addresses, log management and analysis, network flow and bandwidth graphs, and much more.

Get end-to-end visibility, analytics, and performance monitoring from a single web dashboard.

10 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.


Leave a Reply to Pat Cancel reply