AD Account Keeps Locking Out

7.5K

AD user account lockout policy is used to protect against brute-force password attacks. However, some users have repeated account lockout events that occur randomly without a sign-in attack incident. In this article, we will look at how to find the source (computer or service) of a user account lockout in an Active Directory domain.

Account is currently locked out message

If a user’s account is locked, they will receive the following error on the sign-in screen when they try to log on to domain computers:

The referenced account is currently locked out and may not be logged on to.

This can happen after several failed login attempts with an incorrect password, or without direct user interaction when a service (application) tries to use an old saved user password.

Account Lockout Policy in Active Directory Domain

An account lockout event indicates that the user account is automatically temporarily locked by the Active Directory domain security policy. The domain Account Lockout Policy can be configured using the Default Domain Policy, Fine-Grained Password Policies (FGPP), or custom password policy configs.

The lockout policy allows you to configure the following parameters:

• Account lockout threshold;
• Account lockout duration;
• Reset account lockout counter after

Run the following PowerShell command to get the resulting account lockout policy settings that apply to the specific user:

Get-ADUserResultantPasswordPolicy -Identity [username]

If the command returns nothing, the user is affected by the default domain lockout policy settings. List the default GPO lockout settings:

Get-ADDefaultDomainPasswordPolicy |
Select-Object *lockout* |
Format-Table

View or change default lockout setting in Group Policy Management console GUI

Also, you can view or change default lockout setting in the Group Policy Management console GUI (Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy).

In this case, an account will be locked out after 5 failed attempts to log in with an incorrect password. The lockout time is 30 minutes, after which the user is automatically unlocked. We recommend you to balance account lockout thresholds carefully to reduce the risk of denial-of-service conditions caused by password spraying attacks. Many organizations combine smart lockout policies with MFA, Microsoft Entra smart lockout, Conditional Access policies, and identity protection systems instead of relying solely on aggressive account lockout policies.

An administrator can manually unlock the user account using the Active Directory Users and Computers snap-in. Find the user, go to the Account tab, check the box Unlock account tab. This account is currently locked out on this Active Directory Domain Controller and press Ok.

You can also use PowerShell to list all the locked accounts in a domain:

Search-ADAccount -LockedOut -UsersOnly | Select-Object Name, SamAccountName, Lockedout

Unlock specific AD user account:

Unlock-ADAccount jjackson –Confirm

If you want to unlock a verified account, run:

# Review locked accounts first
Search-ADAccount -LockedOut -UsersOnly |
Select-Object Name,SamAccountName

# Unlock only verified accounts
Unlock-ADAccount jjackson

Security note. You should avoid bulk unlocking all locked accounts unless the root cause of the lockout events has been verified. Keep in mind that during security incidents, mass unlock operations may unintentionally restore access to compromised accounts.

Note. If LockoutDuration = 0, then such an account will never be automatically unlocked. Only the domain administrator can remove the lock.

Enable Account Lockout Audit Policy in Active Directory

But in some cases, user accounts are locked for no apparent reason. In this situation, users report that they have done nothing and have never entered an incorrect password, but their account keeps getting locked. The administrator can manually remove the lock at the request of the user, but after a while, the situation repeats.

Find the source of the account lockout events using the Audit User Account Management 

In this case, an administrator needs to find the source of the account lockout events that are causing the lockout. This can be done using the Audit User Account Management policy:

1. Open the Group Policy Management Console (gpmc.msc);
2. Edit the Default Domain Controllers Policy;
3. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Management
4. Enable the following audit policies:
   Audit User Account Management — Success and Failure;
   Audit Computer Account Management — Success and Failure (optional but recommended for broader investigation cases).
5. Then navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon;
6. Enable the Audit Kerberos Authentication Service policy with the Success and Failure options.

   

7. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff. Enable the Audit Account Lockout policy;

   

8. Wait a while for the policy to apply to all domain controllers.

How to Find Account Lockout Source in Domain

Keep in mind that account lockout events can originate on any writable DC. However, the PDC Emulator FSMO role typically receives urgent replication updates related to account lockouts and is commonly used as the primary source during lockout investigations.

Use the following PowerShell command to find the domain controller that is running the PDC Emulator FSMO role:

Get-ADDomain | Select-Object PDCEmulator

Event ID 4740

Event ID 4740 is logged on the DC that processes the account lockout. In most environments, you may start investigation on the PDC Emulator because account lockout information is urgently replicated there and it is usually the most reliable place to search for lockout events.

Log on to the PDC and open the Event Viewer (eventvwr.msc). Expand Event Viewer > Windows Logs > Security. Right-click the Security item and select Filter Current Log.

Filter the security log by the Event ID 4740.

You will see a list of account lockout events on the PDC with a message: A user account was locked out. Find the most recent entry in the log containing the name of the required user in the Account Name value. Find the name of the computer from which the lockout event occurred in the event details (Caller Computer Name). In this case, the computer’s name is WKS11.

Check the domain controller’s security log for event ID 4771

If you can’t find event ID 4740 with a user lockout, or if the Caller Computer Name value is empty, you need to check the domain controller’s security log for event ID 4771.

1. Enable the Security log filter by the event ID 4771;
2. You will find several Kerberos authentication service events;
3. Look through the Kerberos pre-authentication failed events. Depending on the investigation stage, you may encounter different Kerberos failure codes. For example:
   – Failure Code 0x18 (KDC_ERR_PREAUTH_FAILED) indicates an incorrect password and is commonly seen before an account lockout.
   – Failure Code 0x12 (KDC_ERR_CLIENT_REVOKED) indicates that the account has been revoked (for example, locked out, disabled, or otherwise unavailable). If present, this can help you to confirm that the account was already locked when the authentication attempt occurred.
4. In this case, the Client Address field in the event description will contain the IP address of a machine on which the lockout event occurred.
   

   

5. In this example, the device with IP address 172.16.61.9 initiated the user account lockout.

Use Netlogon Debug Logging for Difficult Cases

In case standard Security events do not clearly identify the lockout source, you can enable Netlogon debug logging on a DC. The Netlogon.log file may contain additional authentication details that can help you to identify legacy apps, services, or devices repeatedly submitting invalid credentials.

Correlate Event ID 4625 Failed Logon Events

Often Event ID 4625 provides you with additional context about failed authentication attempts that eventually lead to an account lockout. You should review the following fields:

• Logon Type;
• Workstation Name;
• Source Network Address;
• Process Name.

These values can help you to identify scheduled tasks, services, legacy apps, VPN clients, or user workstations that continue using outdated credentials.

Using Event Viewer and PowerShell for Lockout Investigation

Account lockout investigations in modern AD environments are typically performed using:

• Event Viewer with Security log filtering;
• XPath-based event queries;
• PowerShell automation;
• Centralized SIEM platforms;
• Windows Event Forwarding (WEF);
• Microsoft Sentinel analytics rules.

In large AD environments, you should consider using Windows Event Forwarding (WEF) to centralize Security logs from all DCs for faster lockout investigations and improved visibility.

The most important security events related to account lockouts include:

• Event ID 4740 — A user account was locked out;
• Event ID 4771 — Kerberos pre-authentication failed;
• Event ID 4625 — Failed logon attempt;
• Event ID 4776 — NTLM authentication attempt.

Note that modern identity security monitoring platforms (such as Microsoft Defender for Identity) can correlate these events across multiple DCs and identity systems. This can help you to identify attack patterns that may not be visible from a single DC perspective.

In case your enterprise environments have multiple DCs, we strongly recommend you to centralize event collection instead of relying on manual inspection of individual DC security logs.

Here is PowerShell example:

Get-WinEvent -FilterHashtable @{
LogName='Security'
ID=4740
StartTime=(Get-Date).AddHours(-24)
} | Select-Object TimeCreated,
@{Name='User';Expression={$_.Properties[0].Value}},
@{Name='CallerComputer';Expression={$_.Properties[1].Value}}

Security note. Account lockout monitoring should ideally be integrated into centralized security monitoring platforms such as Microsoft Sentinel/other SIEM systems. This will allow you to automate a correlation of failed authentication attempts, lateral movement detection, to perform brute-force attack analysis, and alerting across multiple DCs and identity systems.

Note that Microsoft Defender for Identity can also help detect suspicious authentication activity associated with repeated account lockouts (including password spraying, brute-force attacks, compromised credentials, abnormal authentication patterns, and lateral movement attempts). In enterprise environments, you should review Defender for Identity alerts together with Security event logs and SIEM correlation data during account lockout investigations.

Hybrid identity note. In Microsoft Entra hybrid environments, during account lockout investigations you may also require reviewing Microsoft Entra sign-in logs, Defender for Identity alerts, VPN authentication logs, and federated identity provider events.

Investigate Account Lockouts with Microsoft Defender for Identity

In organizations using Microsoft Defender for Identity, you can perform account lockout investigations directly from the Defender portal.

Defender for Identity correlates:

• Failed sign-in attempts;
• Kerberos authentication failures;
• NTLM authentication events;
• Lateral movement activity;
• Password spraying indicators.

Note that this can significantly reduce the time required to identify the system responsible for repeated account lockouts.

Get Account Lockout Source Using PowerShell

Also, you can find the account lockout source on the Primary domain controller using PowerShell. List the last account lockout events on the PDC:

$properties = @('TimeCreated',@{n='Account Name';e={$_.Properties[0].Value}},
@{n='Caller Computer Name';e={$_.Properties[1].Value}})
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4740} | Select $properties

The source of the account lockout is specified in the Caller Computer Name property.

You can find the sources of lockout events for a specific user in the last 2 days using the command:

$username = ‘m.becker’
$pdcname = (Get-ADDomain).PDCEmulator
$Date = (Get-Date).AddDays(-2)
Get-WinEvent -computername $pdcname -FilterHashtable `
@{logname='security';id=4740;data='m.becker'; StartTime=$Date} |`
Select-Object -Property timecreated,`
@{label='username';expression={$_.properties[0].value}},`
@{label='computername';expression={$_.properties[1].value}}

Get Account Lockout Source Using LockoutStatus Tool

LockoutStatus.exe is part of the Microsoft Account Lockout and Management Tools package. It can help you to quickly determine:

• Which DC locked the account;
• Lockout timestamps;
• Bad password count (comparing these values across DCs can help you to identify where authentication failures are occurring and whether replication delays are involved);
• Account lockout status across DCs.

Although PowerShell provides more automation capabilities, you can use LockoutStatus for rapid troubleshooting and help desk investigations.

Common Causes of Account Lockouts

In most cases, the account lockout begins after the user changes the domain password. A periodic account lockout can be caused by different reasons:

1. A brute-force attack is actually being performed on your domain. Find the source computer according to this guide and disconnect it from the network;
2. User errors when typing a password. The user makes a mistake when entering a password or forgets the password that was recently changed;
3. Disconnected RDP/RDS session — usually happens if the user closed the remote session instead of logging out. You can prevent such a problem by configuring the force Log off Idle Remote Desktop sessions policy in the domain (GPO option: Set time limit for active but idle Remote Desktop Services sessions);
4. Windows service running under saved user password. Don’t use the user account to run services on domain servers/computers. Instead, use a separate service account or Managed Service Account (MSA);
5. Saved user credentials in the Task Scheduler jobs. As with services, user accounts are often used to run the scheduler task. It is better to use service accounts to run scheduled tasks;
6. Persistent mapped network drives with saved credentials;
7. Mobile devices with saved user credentials — check email client settings on your mobile device for saved AD credentials (like Outlook, ActiveSync, etc.). The saved networks (passwords for Wi-Fi connections) can also be assigned to this category (if you use the Wi-Fi authentication with Windows Active Directory via the Radius server);
8. Microsoft Outlook profiles using cached credentials. Older Outlook profiles, shared mailboxes, mobile Outlook clients, and legacy Exchange connections can continue attempting authentication with outdated passwords after a password change.
9. Saved password in browsers;
10. Saved user password in the Windows Credential Manager. Open Credential Manager (control /name Microsoft.CredentialManager) and remove any stored credentials associated with the affected account. You can also access the legacy Stored User Names and Passwords dialog using rundll32.exe keymgr.dll,KRShowKeyMgr.
11. Microsoft Entra Connect sync account issues or hybrid identity sync problems. Incorrect credentials stored in sync services can generate repeated authentication failures and lockouts.
12. Cached credentials stored by legacy apps, VPN clients, backup software, monitoring agents, or third-party sync tools.

Note that you can significantly reduce the number of traditional password-related account lockout incidents by implementing passwordless authentication technologies (such as Windows Hello for Business, FIDO2 security keys, and Microsoft Entra passwordless authentication).

Watch for Password Spraying Attacks

Note that when you are facing repeated account lockouts affecting multiple users at the same time, it may indicate a password spraying attack rather than user error. In case several accounts become locked within a short period, you should review:

• Event ID 4625;
• Event ID 4771;
• Microsoft Defender for Identity alerts;
• Microsoft Sentinel detections;
• VPN and federated identity logs.

You should not immediately unlock affected accounts until the root cause has been verified.

Managed Service Accounts Recommendation

Keep in mind that you should not use traditional user accounts for services, IIS application pools, scheduled tasks, or automation jobs in enterprise environments.

Instead, you should use:

• Group Managed Service Accounts (gMSA);
• Managed Service Accounts (MSA);
• Dedicated low-privilege service accounts.

Keep in mind that service accounts should also follow privilege separation and admin tiering principles. You should avoid reusing the same service accounts across multiple systems, tiers, or apps.

Note that using gMSA significantly reduces password-related account lockouts and improves credential hygiene and operational security. 

As part of modern identity security hardening, you should also reduce legacy NTLM usage whenever possible, enforce LDAP signing/channel binding, and migrate legacy apps toward modern authentication protocols.