Active Directory

How To Find Account Lockout Source in Active Directory

Ever wondered why user accounts keep getting locked out in Active Directory for no apparent reason? It often happens because a service or application is still trying to authenticate using an old password, or when a user repeatedly enters the wrong password. These continuous lockouts can frustrate users, disrupt work, and generate unnecessary support tickets. This guide shows you how to identify the source computers and applications in Active Directory so you can restore access quickly.

Find Account Lockout Sources in Active Directory Using Event Viewer

Active Directory Permission Required

Event Log Readers Least Privilege

Administrators Most Privilege

Open Server Manager, click on Tools, and select Event Viewer.
Navigate to Event Viewer (Local)»Windows Logs»Security and select Filter Current Log option from the Actions pane.
Enter 4740, 4625 in <All Event IDs> field under Filter tab and click OK to fetch all events of account lockout.
Compare the 4740 account lockout event with the 4625 failed logon event that has the same timestamp. Matching these events helps you identify what triggered the lockout and where it originated.
In the 4740 event, check the Caller Computer Name shown under the General tab, then inspect the corresponding 4625 event to identify the service or source causing account lockout.

Note: Event ID 4740 is logged only on DCs, while Event ID 4625 is logged on the device where the failed logon occurs. Collect the 4740 event from the DCs and match it with the corresponding 4625 events recorded at the same time on domain-joined machines to identify the exact lockout source details.

List the Account Lockout Source Using PowerShell

Active Directory Permission Required

Event Log Readers Least Privilege

Administrators Most Privilege

First, import the Active Directory module using the cmdlet below.
Windows PowerShell
```
 Import-Module ActiveDirectory
```
Then, run the following PowerShell command to list all source computers and services responsible for account lockouts in your Active Directory domain.

Windows PowerShell

 $Computers = Get-ADComputer -Filter {Enabled -eq $true} -Properties OperatingSystem | Where-Object { $_.OperatingSystem -ne $null } | Select-Object -ExpandProperty Name
$DCs = Get-ADDomainController -Filter {Enabled -eq $true} | Select-Object -ExpandProperty Name
$allLockOutEvents = @(); $allLogonFailures = @()
foreach ($Comp in $DCs) {
    $lockOutEvents = Get-WinEvent -ComputerName $Comp -FilterHashtable @{LogName='Security'; Id=4740} -ErrorAction SilentlyContinue |
    Select-Object `
      @{N='TimeKey';E={$_.TimeCreated.ToString('yyyy-MM-dd HH:mm:ss')}},
      TimeCreated,
      @{N='LockedOutUser';E={$_.Properties[0].Value}},
      @{N='CallerComputerName';E={$_.Properties[1].Value}}
  $allLockOutEvents += $lockOutEvents
}
foreach ($Comp in $Computers) {
  $logonFailures = Get-WinEvent -ComputerName $Comp -FilterHashtable @{LogName='Security'; Id=4625} -ErrorAction SilentlyContinue |
    Where-Object { $_.Properties[7].Value -eq '0xC000006D' } |

    Select-Object `
      @{N='TimeKey';E={$_.TimeCreated.ToString('yyyy-MM-dd HH:mm:ss')}},
      @{N='ProcessName';E={$_.Properties[18].Value}},
      @{N='LogonProcessName';E={$_.Properties[11].Value}}
  $allLogonFailures += $logonFailures
}
$allLockOutEvents | ForEach-Object {
  $allLockOutEventsItem = $_          
  $match = $allLogonFailures | Where-Object {
        [datetime]$_.TimeKey -ge $allLockOutEventsItem.TimeCreated.AddSeconds(-30) -and
        [datetime]$_.TimeKey -le $allLockOutEventsItem.TimeCreated.AddSeconds(30)
    } | Sort-Object TimeKey | Select-Object -First 1
  if ($match) {
    [PSCustomObject]@{
      TimeCreated        = $allLockOutEventsItem.TimeCreated
      LockedOutUser      = $allLockOutEventsItem.LockedOutUser
      CallerComputerName = $allLockOutEventsItem.CallerComputerName
      ProcessName        = $match.ProcessName
      LogonProcessName   = $match.LogonProcessName
    }
  }
} | Sort-Object -Descending TimeCreated | Format-Table -AutoSize

This cmdlet retrieves all lockout sources from every computer, along with the locked-out user, the computer name, the logon process name, and the time the failure occurred.

List the Account Lockout Source Using PowerShell

Note: Ensure that remote management over DCOM is configured on all computers in your Active Directory to allow remote event log retrieval. If any systems aren’t configured, the script may fail to detect the actual lockout source.

Simple & Quick
Get All Account Locked-Out Sources Using AdminDroid

AdminDroid Permission Required Delegated

Any user with the report access delegated by the Super Admin.

Log in to the AdminDroid Active Directory Companion.
Navigate to the Applications or Services Causing Account Lockouts report under AD Audit»Account Lockouts»Source Application/Service.
This report consolidates all lockout event sources in your Active Directory domain, along with details such as source computer, target account name, source application/service, locked-out time, and more.

Get All Account Locked-Out Sources Using AdminDroid

AdminDroid Active Directory Reporter

Effortlessly Analyze Account Lockout Sources in Active Directory

AdminDroid’s Active Directory auditing tool provides deep visibility into account lockout sources, powered by AI-driven analytics and smart filtering. It helps you pinpoint where and why user accounts are getting locked, whether from specific devices, or applications. This leads to faster troubleshooting, reduced downtime, and stronger account security.

Analyze Lockout Reasons to Improve User Access

Find reason for lockout events to analyze user behavior and minimize the helpdesk workload from repeated account unlocks.

Monitor Failed Logons After a Lockout to Detect Unauthorized Access

Analyze failed logons after account lockout to prevent repeated lockouts across systems and uncover persistent or malicious activity.

Review Frequently Locked-Out Users to Spot Security Threats

Review frequently locked-out users along with their lockout count to help identify accounts that may be compromised by brute-force or password-spray attacks.

Get Instantly Notified When Users Are Locked Out with Reminder Agents

Leverage AdminDroid reminder agents to alert admins when a user account is locked-out so they can easily trace the issue and resolve any app or device misconfigurations.

Get a Complete Overview of Active Directory Account Lockouts

Explore the Active Directory account lockouts dashboard for a comprehensive overview of lockout trends, unlock statistics, lockout analytics, and more to troubleshoot account lockout issues.

Effortlessly Unlock Locked-Out Accounts to Reduce Downtime

Easily unlock locked-out accounts with AdminDroid to restore user access quickly and reduce downtime across your Active Directory organization.

Overall, AdminDroid’s Active Directory management tool offers a complete solution for identifying account lockout sources and resolving lockout issues efficiently. In addition, AdminDroid provides wide-ranging capabilities to monitor, manage, and streamline directory operations.

Explore a full range of reporting options

Download Live Demo

Important tips

Apply fine-grained password policies to set different lockout thresholds and password complexities for specific users to reduce unnecessary lockouts.

Set the account lockout threshold to 10, as recommended by Microsoft, to maintain a good balance between security and user experience.

Check all domain controllers, not just the PDC, because lockout events can be generated on any DC in the environment.

Common Errors and Resolution Steps

The following are possible errors and troubleshooting hints while identifying account lockout sources in Active Directory.

Error Get-WinEvent : Could not retrieve information about the Security log.

This error occurs when the account running the Get-WinEvent cmdlet does not have sufficient privileges to access the event logs.

Fix Make sure you run PowerShell with Administrator privileges to access the Security event logs and retrieve details about account lockout sources.

Error Get-WinEvent : There is not an event log on the localhost computer that matches "Security".

This error occurs when the Security log is not available or the log name is incorrect on the system.

Fix Ensure the Security event log exists and auditing is enabled. Otherwise, specify a valid log name on the system before running the cmdlet.

Error Query Error: Security – Access is denied.

This error occurs when you lack permission to read the Security event log in Event Viewer.

Fix Run Event Viewer using an account that has at least Event Log Readers permissions. If the issue still persists, grant the NT SERVICE\EventLog account the required registry permissions on the Security log key to allow access to the Security event log.

Error Get-WinEvent : No events were found that match the specified selection criteria.

This error occurs when the event log contains no entries that match the ID, log name, or filters used in the query.

Fix Verify that the event exists in the Security log and ensure that auditing is enabled for that event type. Without auditing enabled, the event will not be logged, and retrieval will not be possible later.

Active Directory

Frequently Asked Questions

Investigate And Resolve Account Lockout Issues to Prevent Unauthorized Access

How to enable auditing to capture account lockout source information in AD?

What are the risks of Active Directory account lockout?

What are the common causes and solutions for frequent account lockout issues?

How to delegate rights to unlock accounts in Active Directory?

1. How to enable auditing to capture account lockout source information in AD?

Repeated account lockouts can cause both security and operational issues. Without auditing, it becomes difficult to identify which device or process is triggering the lockouts. To trace these lockouts effectively, the appropriate advanced audit policies must be enabled so the required events are actually logged.

With auditing in place, domain controllers generate event 4740 for account lockouts, and the computer where the lockout occurred records event 4625 for failed logon attempts. This provides the detailed information needed to pinpoint the exact system or process causing the issue.

Follow the steps below to enable the required policies so that events 4740 and 4625 are recorded on the respective machines.

Enable account lockout auditing on domain controllers

Open Group Policy Management (GPM) and expand the target domain under the forest.
Next, expand Domain Controllers, right-click on the Default Domain Controllers Policy, and select Edit.
In GPM editor, navigate to Computer Configuration»Policies»Windows Settings»Security Settings»Advanced Audit Policy Configuration»Audit Policies.
Under Audit Policies, navigate to Account Management»Audit User Account Management, then right-click the policy and select Properties.
Next, select Configure the following audit events checkbox, enable both Success and Failure, and then click OK.
After that, navigate to Account Logon»Audit Kerberos Authentication Service and configure it in the same manner.

Configure audit policies to capture failed logon attempts

Follow the steps below to enable auditing for failed logon attempts (Event ID 4625), as these events are also important for tracing the sources of account lockouts.

Right-click the Default Domain Policy, under the Group Policy Management page and select Edit. Then, navigate to Audit Policies using the same path mentioned above.
Under Audit Policies»Logon/Logoff, configure the audit options for the following and enable both Success and Failure events similarly.
- Audit Account Lockout, Audit Logoff, Audit Logon, Audit Other Logoff/Logon Events
Once enabling the policies, run the command below in the Run window or terminal on the domain controller to update the default domain policy.
```
gpupdate /force
```

modify-default-domain-policy-for-advanced-auditing

2. What are the risks of Active Directory account lockout?

Account lockout policies are designed to protect systems from unauthorized access, by limiting repeated failed login attempts. However, while they strengthen security against password-guessing attacks, they can also introduce unintended consequences. Understanding the risks associated with account lockout is essential to maintaining both system security and operational stability.

Limitations and security implications of account lockout policies

Operational disruption Legitimate users may accidentally lock themselves out by entering incorrect passwords. This reduces their productivity and results in unnecessary time loss.
Denial-of-service (DoS) risk Attackers can intentionally trigger repeated failed logins to lock out some or all user accounts, effectively blocking access to critical systems.
Business impact Widespread lockouts can interrupt workflows, delay operations, and disrupt services that rely on domain authentication.
Administrative overhead Frequent lockouts require manual intervention or automated resets, which increases the burden on IT helpdesk and security teams.
User frustration Lockout incidents can lead to dissatisfaction and unnecessary password resets, which weakens overall user experience and security posture.
Limited protection scope In some cases, account lockout helps mitigate online password-guessing attacks. However, it offers little defense against large-scale credential-stuffing attempts where attackers try one stolen password per account.

3. What are the common causes and solutions for frequent account lockout issues?

When accounts keep getting locked, employees lose access to the systems they need, and the help desk receives constant unlock requests. Lockouts often happen because of cached credentials, incorrect passwords, attack attempts, and more. These problems disrupt daily work and may point to security risks. Now let’s look at the common issues behind frequent account lockouts and how to fix frequent account lockout issues.

Common issues and fix for account lockout issues in Active Directory

Cached or stale credentials Cached credentials may use an old password after a password change, and that can cause repeated lockouts. This can be fixed by advising the user to clear stored credentials and update their password on all devices and apps.
Services or applications using expired passwords Background services or scheduled tasks may keep using expired credentials and cause repeated lockouts. This issue can be fixed by resetting the password of the user and then updating the credentials for all affected services and scheduled tasks.
Mobile devices, disconnected sessions, and multiple logins Users who are signed in on multiple devices or sessions may trigger lockouts when one device continues to use an old password after a password change. This can be fixed by updating the password or signing out on every device and session once the password is changed.
Active Directory replication or policy delays When password or policy changes are not synced across all domain controllers, outdated information may cause failed logons and repeated account lockouts. This can be fixed by checking domain controller replication regularly and ensuring that all policy updates are synchronized.
Incorrect passwords due to brute-force or credential-guessing attacks Repeated failed login attempts may come from attackers who try to guess user passwords and this often triggers account lockout policies. This can be fixed by monitoring security logs and strengthening password policies to block unauthorized access.

4. How to delegate rights to unlock accounts in Active Directory?

Help Desk teams in many organizations handle routine user issues like account lockouts, but without the necessary permissions they must rely on domain administrators for assistance. This dependency can delay issue resolution and impact user productivity. Delegating the rights to unlock accounts in Active Directory enables help desk staff to resolve these incidents quickly while maintaining appropriate security controls.

Steps to delegate rights to unlock accounts in Active Directory

Open Active Directory Users and Computers (ADUC) console, right-click on the domain, and choose Delegate Control.
Then, click Next in Delegation of Control Wizard, select Add to include users or groups to whom you want to delegate permissions.
In Select Users, Computers, or Groups pane, enter the names of the group or users, and click OK to add the user.
Click Next, choose “Create a custom task to delegate”, and select Next.
Select “Only the following objects in the folder”, then scroll and choose User objects, and click Next.
Choose “Property-specific”, then in the Permissions list select Read lockoutTime and Write lockoutTime options.
Then, click Next, and choose Finish to apply the delegation.
After delegating unlock permissions, respective users or groups can unlock a user account using ADUC or PowerShell.

Tip: The delegated user can use the following PowerShell cmdlet to easily unlock the permitted user. Replace <UserName> with the locked-out user’s name.

Unlock-ADAccount -Identity "<SAMAccountName>"