Account lockouts are one of the most common help desk tickets in any AD environment, and one of the most frustrating to chase. The user swears they typed the right password. You unlock the account. It locks again ten minutes later. Somewhere out there a device is quietly hammering the directory with an old password, and the account pays for it.
Finding the locked accounts is the easy part — one PowerShell command does it. The real work is tracing why an account keeps locking, and that trail starts at the PDC Emulator with event ID 4740.
This guide covers both: listing locked accounts quickly, reading the lockout events to find the source machine, the usual culprits behind a repeat offender, and how the lockout policy itself shapes how often this happens.
List locked-out accounts with PowerShell
The fastest way to see every currently locked account in the domain is Search-ADAccount. Run it
from any machine with the Active Directory PowerShell module (RSAT or a DC):
# Every locked-out account in the domain
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LastLogonDateThat returns the accounts sitting in a locked state right now. To unlock a single account once you know it’s safe:
Unlock-ADAccount -Identity jsmithAnd to clear several at once — only after you’ve confirmed there isn’t an active attack or a misfiring device behind them:
# Unlock every locked account (use with care)
Search-ADAccount -LockedOut | Unlock-ADAccountWhy lockout events live on the PDC Emulator
When an account locks out, the event is recorded as event ID 4740 in the Security log — and it’s written on the PDC Emulator. That’s by design. Whenever any DC rejects a bad password, it forwards that attempt to the PDC Emulator, which keeps the authoritative count and decides when the threshold is crossed. So the PDC Emulator is the one machine that sees every lockout in the domain.
Find which DC holds the role first:
# Identify the PDC Emulator
(Get-ADDomain).PDCEmulatorThat’s the server whose Security log you’ll be reading. If you’re fuzzy on what the PDC Emulator does and why it’s special, see transfer or seize FSMO roles — it carries the lockout-processing role along with time sync and password handling.
Read event 4740 to find the source
Event 4740 is the one that matters. It records the locked account and the machine the bad attempts came from. Pull recent lockout events from the PDC Emulator:
$pdc = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $pdc -FilterHashtable @{
LogName = 'Security'
Id = 4740
} -MaxEvents 20 |
Select-Object TimeCreated,
@{N='LockedAccount'; E={$_.Properties[0].Value}},
@{N='SourceComputer'; E={$_.Properties[1].Value}}The two fields you care about are the locked account and the Caller Computer Name (the source). The source is your lead — it’s the machine that submitted the failing password.
What event 4740 tells you
| TimeCreated | When the lockout happened — match it against when the user noticed. |
|---|---|
| Target Account Name | The account that got locked out. |
| Caller Computer Name | The machine the bad attempts came from (or a relay, see below). |
The usual suspects behind a repeat lockout
When an account relocks within minutes of every unlock, a cached old password is almost always to blame. Once you’ve identified the source machine from event 4740, check these in roughly this order:
Where stale credentials hide
- Mobile devices with a saved Exchange/email password (phones are the #1 cause)
- Mapped network drives using saved credentials
- Saved credentials in Windows Credential Manager
- Scheduled tasks configured to run as the user
- Windows services running under the user's account
- Persistent RDP sessions or saved RDP credentials
- Application pools or scripts with a hard-coded password
- A second machine where the user is still logged in with the old password
The pattern is always the same: the user changed their password, but something is still trying the old one on a loop. Update or clear the cached credential on the source device and the lockouts stop.
# On the source machine, list saved credentials
cmdkey /list
# Remove a stale saved credential
cmdkey /delete:targetnameTune the account lockout policy
How easily accounts lock at all is governed by the account lockout policy, set in Group Policy — usually the Default Domain Policy, under Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy.
Account lockout policy settings
| Account lockout threshold | Bad attempts before lockout. ~10 is a common balance; 0 disables lockout entirely (not recommended). |
|---|---|
| Account lockout duration | How long the account stays locked. 15–30 min, or 0 to require an admin unlock. |
| Reset account lockout counter after | How long before the bad-attempt count resets. Often 15 minutes. |
# View the current lockout policy
Get-ADDefaultDomainPasswordPolicy |
Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindowQuick workflow
When a lockout ticket lands, this is the fast path from symptom to root cause:
Search-ADAccount -LockedOut— confirm the account is actually locked.(Get-ADDomain).PDCEmulator— find the DC that logs lockouts.- Pull event 4740 from that DC — get the source computer name.
- Trace the source (and any relay behind it) to the stale credential.
- Update or remove the cached password, then
Unlock-ADAccount.
Wrapping up
Finding locked accounts takes one command. Stopping them from relocking takes a little detective work: go to the PDC Emulator, read event 4740, and follow the source computer back to whatever is still clutching the old password — usually a phone, a mapped drive, or a service account.
Unlocking without finding the cause just resets the timer, and you’ll see the same ticket again before lunch. Trace it once, fix the cached credential, and it stays fixed. If lockouts are happening across many accounts at once rather than one repeat offender, treat it as a possible password-spray attempt and review your defenses with the Windows Server hardening checklist.
