Log Dejargonizer

Windows Security Log · Event 4740

Event 4740: A user account was locked out

An account hit the failed-password threshold and Windows locked it. Nine times out of ten a device is still offering an old password. The field that solves it is the caller computer name, which tells you where the bad attempts came from.

Also written as 4740Event ID 4740A user account was locked outAccount lockout 4740

What it means for you

On a personal computer

Your account is temporarily blocked because the wrong password was tried too many times. If it was not you, something on your network — a phone, a tablet, a printer, a backup drive — is still trying an old password. Find that device rather than just resetting the password again.

For an analyst

Recorded on the domain controller that processed the lockout, not on the machine where the attempts happened. Chase the Caller Computer Name, then pull 4625 or 4771 from that host to find the failure reason. A burst of lockouts across many accounts at once is spraying, not user error.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
A user account was locked out.

Subject:
  Security ID:    SYSTEM
  Account Name:   DC01$
  Account Domain: CORP
  Logon ID:       0x3E7

Account That Was Locked Out:
  Security ID:    CORP\jbrooks
  Account Name:   jbrooks

Additional Information:
  Caller Computer Name: LAPTOP-J7X2

The fields that decide it

Everything else in the log line is context.

TargetUserName
The account that was locked.
TargetDomainName
The domain the account belongs to.
SubjectUserName
The account of the security context that recorded the lockout. On a domain controller this is usually the DC's own computer account and carries no useful information.
CallerComputerName
The machine the failed attempts came from. This is the field that solves the case.
  • A workstation name you recogniseA device or saved credential on that machine is the source. Go there.
  • Blank or a dashThe attempts arrived without a resolvable machine name, common for NTLM over the network and for attacker tooling.
  • The domain controller's own nameThe attempts reached the DC directly rather than through a member machine — check VPN, Exchange, and any internet-facing authentication.

Ordinary reasons this happens

Most of the time it is one of these.

  • A password was changed and a phone, tablet, or mail client is still offering the old one. Mobile mail clients are the single most common cause.
  • A Windows service or scheduled task running under the account with an outdated stored password — these retry relentlessly and lock the account out again minutes after every unlock.
  • A mapped network drive or network printer holding an old credential.
  • An open Remote Desktop session left signed in with the previous password.
  • Credential Manager on a machine the user has not signed in to since the change.
  • Backup or monitoring software configured with the account years ago and forgotten.

When it is not ordinary

Brute force against one account.

What gives it awayA single account locked repeatedly, with a run of 4625 or 4771 failures from one source immediately before each lockout.

ATT&CK T1110.001

Password spraying that overshot the threshold.

What gives it awaySeveral different accounts locking within the same short window. Spraying normally stays under the threshold, so simultaneous lockouts mean the attempt was clumsy or the threshold is low.

ATT&CK T1110.003

Deliberate denial of service against a user or a service account.

What gives it awayRepeated lockouts of a business-critical account with no successful sign-in in between, resuming immediately after each unlock.

ATT&CK T1531

What to do next

  1. Read CallerComputerName. If it names a machine you recognise, the answer is almost certainly on that machine.
  2. On that machine, look for 4625 events for the same account and read the SubStatus code to learn why the attempts failed.
  3. Check Windows services and scheduled tasks running under the account, then Credential Manager, then mapped drives.
  4. Ask the user whether any phone or tablet collects mail with that account. Mobile mail is the most common single cause.
  5. Count how many distinct accounts locked out in the same window. More than a couple means look for spraying, not for a stale password.
  6. If the caller name is blank and the failures arrived from outside, treat the exposure as the finding and restrict it before unlocking the account.

Queries to run

kql Straight listing. Confirm the caller field name against your own connector's schema — it varies between collection methods. 
SecurityEvent | where EventID == 4740 | project TimeGenerated, TargetUserName, TargetDomainName, CallerComputerName = TargetSid | order by TimeGenerated desc
kql Several distinct accounts locking in the same window is the spraying signal, not the raw lockout count. 
SecurityEvent | where EventID == 4740 | summarize lockouts = count(), accounts = dcount(TargetUserName) by bin(TimeGenerated, 15m) | where accounts > 3
powershell Run against the PDC emulator, which is where lockouts are recorded. 
Get-WinEvent -ComputerName dc01 -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 50 | Select-Object TimeCreated, @{n='Account';e={$_.Properties[0].Value}}, @{n='Caller';e={$_.Properties[1].Value}}
wevtutil No PowerShell available — reads the last twenty lockouts straight off the log. 
wevtutil qe Security /q:"*[System[(EventID=4740)]]" /f:text /c:20 /rd:true

Common questions

Why does my account keep locking out immediately after I unlock it?

Something is retrying an old password automatically. The usual suspects are a Windows service or scheduled task running under your account, a phone or tablet collecting mail, a mapped network drive, or a saved credential in Credential Manager. Until you find and update that stored password, unlocking the account only buys a few minutes.

How do I find what is locking out an Active Directory account?

Read the Caller Computer Name in the 4740 event on the domain controller, then go to that machine and look at its 4625 events for the same account. The Sub Status code there tells you why each attempt failed, and the process or service name usually points straight at what is holding the old password.

Does Event 4740 mean I am being hacked?

Usually not. Most lockouts are a device on your own network still using a password you changed. It becomes a genuine concern when several different accounts lock out around the same time, or when the failed attempts came from an address outside your network.

Which domain controller records Event 4740?

The one that processed the lockout, and the event is also forwarded to the PDC emulator, which is the reliable place to look. If you check a single DC at random you may not find the event at all.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026