Account Lockout Event ID: Find the Source of Account Lockouts

by Robert Allen

When an Active Directory user account is locked, an account lockout event ID is added to the Windows event logs. Event ID 4740 is added on domain controllers and the event 4625 is added to client computers.

The lockout event ID provides important details about the lockout, such as the account name, time of the event, and the source computer (caller computer name). These events are helpful for troubleshooting and auditing lockout events.

In this post, I’ll show you how to quickly find all lockout events and how to find the source of account lockouts.

Table of Contents

Enable Account Lockout Events

Before Windows will log AD lockout events the lockout policy and audit logs need to be configured. Refer to the Account Lockout Policy configuration guide for steps on creating a lockout policy. See the steps below to enable the audit log policy.

Step 1. Open Group Policy Management Console

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

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

Browse to computer configuration -> Policies ->Windows Settings -> 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 -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Logon

Enable Success and Failure for Audit Kerberos Authentication Service.

Step 3: Modify Default Domain Policy

The settings below will enable lockout event 4625 and failed logon attempts on client computers.

Browse to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration – Logon/Logoff

  • Audit Account Lockout – Success and Failure
  • Audit Logoff – Success and Failure
  • Audit Logon – Success and Failure
  • Audit Other Logon/Logon Events – Success and Failure

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 enabled which will log authentication failures with the lockout. Sometimes event 4740 does not log the source computer and the Kerberos logs provide additional details.

Event Lockout ID 4740 on Domain Controller

A domain controller will log event 4740 when an AD account is locked out. This event is not replicated so you either need to search all domain controllers or find the DC that holds the PDC emulator FSMO role.

How to find all 4740 Events

To display all of the 4740 events, open the event viewer on a domain controller, right click the security logs and select “Filter Current Log”.

Next, enter 4740 into the Includes/Excludes box and click “OK”.

The event logs should now only display the 4740 events.

Click on one of the 4740 events to display the details.

In the screenshot above I highlighted the most important details from the lockout event.

  • Security ID & Account Name – This is the name of the locked out account.
  • Caller Computer Name – This is the computer that the lockout occurred from.
  • Logged – This is the time of the account lockout.

Let’s look at some additional ways to get all 4740 lockout events.

Get ID 4740 Lockout Events with PowerShell

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    ID = 4740
}

This command will display all 4740 events from the domain controller. Again, you would need to run this on all DCs or the server with the PDC Emulator role.

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

This command will display the details of all the 4740 events.

The caller computer name is the computer the lockout or bad password attempts originated from.

With PowerShell, it is easy to display all of the account lockout events, but can be difficult to quickly view the event details.

Display lockout events with the AD Pro Toolkit

The AD Pro Toolkit is a collection of easy to use Active Directory Management Tools. The user unlock app makes it super easy to get all lockout events from all domain controllers. Just click on the User Unlock App, select Troubleshoot Lockouts and click run.

In just a single click I was able to get all of the account lockout events in the past 24 hours from all DCs. In addition, it will display logs to help troubleshoot repeat lockouts.

You can also easily check the account lockout status by selecting “All locked Users” and clicking run.

In the above screenshot, you can see the tool found two locked user accounts, it also displays the lockout time and password last set date. This tool makes it super easy for helpdesk staff to check for locked user accounts, unlock and reset passwords.

Event Lockout ID 4625 on Client Computers

Event ID 4625 is logged on the client computer when an account fails to logon or is locked out. This event will be logged for local and domain user accounts. The event is useful for troubleshooting repeat lockouts as it provides more details than the 4740 event. Event ID 4625 is only logged on the computer where the logon attempt was made from.

For example, on PC1 I entered my password wrong 3 times which caused my account to be locked out. PC1 generated the event 4625 on the local PC when the lockout occurred.

In the screenshot above you can see event 4625 provides details such as the Logon Type and the caller process. The logon type is very important as this will help determine the cause of the lockouts.

Event 4625 will also be generated each time I enter the wrong username or password.

The challenge with this is you first need to know the source of the account lockout before you can filter for event 4625. See the below section for details on how to find the source of account lockouts.

Event 4625 Logon Type

The logon type is very important as this is how the users tried to authenticate. See the table below for a reference of the 4625 logon types.

Logon Type

Description

2

Interactive (also known as, Logon locally). Examples: Console Logon, RUNAS, Network KVM

3

Network (Password, NT Hash, Kerberos ticket). Examples: NET USE, RPC calls, Remote registry

4

Batch (Password (stored as LSA secret). Examples: Scheduled tasks

5

Service (Password (stored as LSA secret). Examples: Windows services

8

NetworkCleartext (Password). Examples: IIS Basic Auth, Windows PowerShell with CredSSP

9

NetworkCredentials (Password). Examples: RUNAS /NETWORK

10

RemoteInteractive (Password, Smartcard). Examples: Remote Desktop

11

CachedInteractive (A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials).

Now let’s look at a few examples.

Logon Type 2

In this example, I tried to logon to PC1 locally. It generated event 4625 with the logon type 2. Users typically logon while sitting in front of their computer or have console access so it is common to see a lot of logon type 2.

Logon Type 10

In this example, I used RDP to try and logon to PC1. I entered the wrong password so event 4625 was logged with logon type 10.

That should help you to understand how to use the 4625 event to troubleshoot failed logons and account lockouts.

Refer to the Microsoft Event 4625 documentation for more details on this event ID.

How to Quickly Find the Source of Account Lockouts

This step uses the AD Pro Toolkit 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 did not have the event 4740 I could look at 4771 and see the failed authentication attempt was from a computer with the IP 192.168.100.20.

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.

Summary

Knowing how to audit Active Directory lockout events is critical for troubleshooting repeat lockouts. It is also a security best practice to review and monitor failed logon attempts for malicious activity on your network. In this guide, I showed you the lockout event IDs for domain and local user accounts. In addition, I showed you how to filter the logs with PowerShell and by using the AD Pro Toolkit GUI tool.

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

2 thoughts on “Account Lockout Event ID: Find the Source of Account Lockouts”

  1. Jorge Gomez

    Hi.
    How true is that enabling Account Lockout Events audit could cause performance issues on other services inside the domain ?

    thanks

    Reply
    • Avatar photo
      Robert Allen

      It is possible. Enabling audit policies can generate a ton of events. If event log policies are not defined it can quickly consume disk space which can impact performance. That is just one example.

      If anything is impacting the performance of a domain controller it can cause performance issues across the entire domain.

      Reply

Leave a Comment