How to Find Locked Active Directory Accounts

Find locked Active Directory accounts with PowerShell, LDAP filters, event logs, and graphical tools while avoiding misleading lockout data.

Type
Tutorial
Level
Intermediate
Technologies
Active Directory, LDAP
On this page

Understanding Locked Accounts in Active Directory

A locked Active Directory (AD) account is one that has been temporarily suspended due to successive failed authentication attempts—typically as a result of an account lockout policy designed to disrupt brute-force attacks. When an account enters the locked state, the user cannot sign in until the lockout duration expires or administrative action is taken to reset it. In contrast, a disabled account has been manually deactivated and requires explicit administrative re-enablement.

Lockouts are both an operational pain point for users (prompting support calls) and a vital security control. Precise, reliable identification of locked accounts is essential whether you support end-users, maintain directory health, or automate identity operations.

Distinguishing Locked, Disabled, and Enabled Accounts

  • Locked: The account is blocked from authentication due to failed logon attempts and will stay locked for the duration set by policy, or until it is manually unlocked. The state is temporary and recorded in the account's attributes (e.g., lockoutTime).
  • Disabled: The account is administratively deactivated—login is denied regardless of credentials, and no policy or timer will automatically re-enable it.
  • Enabled: The account is active and not barred from authentication, assuming it is not simultaneously locked.

Locking and disabling are fundamentally different: unlocking simply resets the lockout timer, while enabling a disabled account restores access to an account that was intentionally put out of service.

How to Find Locked Accounts: Authoritative Methods

Enumerating Locked Accounts with PowerShell

For programmatic access or automation, the official and most efficient approach is to use the Active Directory PowerShell module’s Search-ADAccount cmdlet with the -LockedOut switch. This returns all currently locked user accounts within the domain:

powershell
Search-ADAccount -LockedOut

This method is robust for administrative scripts, scheduled reporting, or environments with many accounts. Results can be piped to further cmdlets (such as Unlock-ADAccount) or exported as needed.

Discovering Locked Accounts in the GUI (ADUC and Saved Queries)

For practitioners not using scripts, the Active Directory Users and Computers (ADUC) MMC snap-in provides a graphical workflow. Open ADUC, navigate to your domain, right-click the Saved Queries folder, choose “New,” and use the following LDAP filter to find locked users:

text
(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))

This technique requires no scripting knowledge and provides on-demand, visual results, making it ideal for helpdesk and first-level support staff.

Official LDAP Filters

Both PowerShell and ADUC methods rely on querying the lockoutTime attribute. An account is considered locked if lockoutTime is greater than or equal to 1. Always verify your environment’s replication and account lockout policy when interpreting these results.

Tracing and Investigating the Lockout Event

Identifying when, where, and why an account was locked is critical for resolving user issues and uncovering root causes such as misconfigured services or compromised credentials.

Event Viewer and Event ID 4740

Active Directory domain controllers write a security log event (ID 4740) every time a user account is locked. Each event details:

  • Account Name: The user account that was locked.
  • Caller Computer Name: The computer that submitted the failed logon attempt that triggered the lockout.
  • Timestamp: When the lockout occurred.

To review these events:

  1. Open Event Viewer on a domain controller.
  2. Navigate to Windows Logs → Security.
  3. Filter (or search) for events with ID 4740.

For reliable results, especially in environments with multiple domain controllers, query the server holding the PDC Emulator FSMO role. The PDC Emulator processes password changes and is prioritized for lockout tracking; its Security event log is the authoritative source.

Note: Occasionally, the Caller Computer Name may be blank due to replication delays, auditing gaps, or configuration issues. In such cases, additional log correlation or diagnostic utilities may be required.

Microsoft Tools for Lockout Investigation

For multi-domain controller environments or when manual log review is impractical, Microsoft provides specialized management tools:

  • LockoutStatus.exe: Aggregates lockout data from all domain controllers, presenting a unified view of account status and recent lockout activity.
  • EventCombMT: Facilitates centralized collection and filtering of lockout-related security events (such as 4740) across many systems.

These utilities are indispensable in large environments, complex replication topologies, or scenarios where the lockout source is unclear or logs are dispersed. However, exercise care: some tools may be outdated, require additional permissions, or impact server performance if misused.

Practical Comparisons, Troubleshooting, and Automation Tips

Method Selection

  • PowerShell (Search-ADAccount -LockedOut): Best for automation, bulk operations, or when scripting/reporting is required.
  • ADUC GUI (Saved Queries/Filters): Preferred for ad-hoc investigations, non-scripters, or support staff with limited administrative rights.
  • Event Viewer (Event ID 4740): Essential for root-cause analysis of lockouts; always consult the Security log of the PDC Emulator DC for definitive data.
  • Microsoft Tools: Necessary when lockouts are distributed, repeated, or log data is incomplete in default tools.

Common Pitfalls

  • Replication Delays: Lockout status and related events may not appear instantly across all DCs.
  • Missing Event Data: Caller Computer Name in Event ID 4740 can be blank if auditing is incomplete, or due to certain third-party authentication paths.
  • Policy Confusion: Misunderstanding the difference between locked, disabled, and expired accounts can lead to misdiagnosis or improper remediation.

Automation Possibilities

Combine PowerShell cmdlets with Windows Task Scheduler or reporting frameworks to monitor for locked accounts and respond proactively. Routine scheduled queries can alert administrators or trigger unlock workflows, reducing user downtime and improving security responsiveness.

FAQs and Misconceptions: Locked vs Disabled, Event Log Gaps, and More

Q: Is PowerShell always required to find locked AD accounts?
No. Both the GUI (Active Directory Users and Computers with Saved Queries) and PowerShell can be used, depending on your role and requirements.

Q: How is a locked account different from a disabled account?
A locked account is temporarily suspended due to failed login attempts; it may automatically unlock per policy or be unlocked by an administrator. A disabled account is manually deactivated and remains inaccessible until manually enabled.

Q: Does every lockout event show the source computer?
Not always. While the Caller Computer Name is generally populated, it can be absent due to audit misconfiguration, replication latency, or unconventional authentication flows.

Q: Is unlocking a locked account the same as enabling a disabled account?
No. Unlocking resets the lockout state but does not require changing the account’s enable/disable flag. Enabling a disabled account is a deliberate administrative action to restore access to a previously deactivated user.

Q: What if event logs are missing or tools do not report the source computer?
If logs are incomplete, correlate events across all domain controllers, verify auditing configuration, or use tools like LockoutStatus.exe to piece together distributed lockout information.

Sources

Related resources