Account Keeps Locking Out: Find the Source From Event 4740 to the Process

Direct answer: An account that locks out again minutes after it is unlocked is most often being fed an old password by something automatic: a service, a scheduled task, a mapped drive, a saved credential, a phone or mail client, or a disconnected remote desktop session still running as that user. Find it in three hops:

1. On the PDC emulator, read Security event 4740 ("A user account was locked out"). Its Caller Computer Name names the computer the failing logon came from.
2. If that name is a server in the middle (a file server, RD Session Host, Exchange or a VPN/RADIUS server), follow the failures one hop further back. Use 4771 (Kerberos pre-authentication failed, code 0x18) and 4776 (NTLM credential validation) on the domain controllers, and 4625 (logon failure) on the server itself, to get the next source address or workstation.
3. On the final computer, look for what holds the old password: services, scheduled tasks, Credential Manager entries, mapped drives and sessions.

Raising or disabling the lockout threshold is not a fix. It hides the source, and a later password change will lock the account again.

Why it matters

Repeated lockouts cost more than help desk time. A service account that locks out stops whatever runs under it: backups, scheduled imports, application pools, integration jobs. A user who is locked out every morning loses trust in the system. Locking is also a security control. A lockout pattern you cannot explain might be a password-guessing attempt rather than a stale credential, and you only know which after following the evidence.

Accounts usually start locking out after a password change, a server migration (a job or service moved with its stored credential; see Scheduled Jobs After Migration: Prevent Duplicate Work), or a departed administrator whose credential is still in use somewhere (the Revoke a Departed Administrator's Access Across a Hosted Estate below covers removing access cleanly).

How it works

Where lockout is decided

Microsoft documents that the PDC emulator has a special role in password handling. When authentication fails at any domain controller because of an incorrect password, the failure is forwarded to the PDC emulator before the user is told the password is bad. Account lockout is processed on the PDC emulator, and password changes made at other DCs replicate to the PDC emulator preferentially.

In practice, that makes the PDC emulator's Security log the place to start. Event 4740 can also appear on other domain controllers, and Microsoft's event reference says it can be generated on member servers and workstations for user accounts too (local accounts lock out on the local computer).

The bad-password counter itself is per domain controller. Microsoft's schema reference for the badPwdCount attribute states it is not replicated: it is maintained separately on each DC and reset on a DC when the user logs on successfully there. If you query one DC and see a count of zero, other DCs may still be counting.

The events in the chain

Read Caller Computer Name for what it is. Microsoft defines it as the name of the computer the logon attempt was received from, after which the account locked out. If a user's phone sends an old password to Exchange, which validates it against a DC, the caller is often the Exchange server, not the phone. One hop is rarely the whole answer when the caller is a server.

Two documented details shape the investigation:

• 4776 records the computer the authentication came from (Source Workstation), not the destination server.
• 4625 is logged on the computer where the logon was attempted, and can include the calling process's path. That is the field that turns "something on this server" into "this executable".

Prerequisites

None of this evidence exists unless auditing is on. The relevant advanced audit policy subcategories are User Account Management (4740), Kerberos Authentication Service (4771), Credential Validation (4776) and Logon (4625). Many domains have the first three for domain controllers through their baseline, but check rather than assume. Also check the Security log size: on a busy DC, a log that wraps every few hours will have lost yesterday's events.

Read-only checks

None of these was run for this article. They read logs and directory attributes; none unlocks an account or changes policy. Reading domain controller Security logs needs membership of a group with that right (Event Log Readers on the DC, or a delegated equivalent), not necessarily Domain Admins. The examples use placeholders: jsmith for the account and DC01 for a controller.

1. Find the PDC emulator.

(Get-ADDomain).PDCEmulator

Read-only; needs the ActiveDirectory module (RSAT) and normal domain user read access.

2. Read the lockout events on the PDC emulator.

$pdc = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $pdc -FilterHashtable @{LogName='Security'; Id=4740; StartTime=(Get-Date).AddDays(-1)} |
  Where-Object { $_.Properties[0].Value -eq 'jsmith' } |
  Select-Object TimeCreated, @{n='Account';e={$_.Properties[0].Value}}, @{n='CallerComputer';e={$_.Properties[1].Value}}

Read-only. Field positions in Properties follow the event's XML order (TargetUserName first, then the caller computer as TargetDomainName). If in doubt, use Format-List Message and read the text. Remote event log reading needs the remote event log management firewall rules on the DC; if those are closed, read the log locally or from your log collection system rather than opening firewall rules for this.

3. See which domain controllers are counting bad passwords.

foreach ($dc in Get-ADDomainController -Filter *) {
  $u = Get-ADUser jsmith -Server $dc.HostName -Properties badPwdCount, badPasswordTime, LockedOut
  [pscustomobject]@{
    DC          = $dc.HostName
    BadPwdCount = $u.badPwdCount
    LastBad     = [DateTime]::FromFileTime($u.badPasswordTime)
    LockedOut   = $u.LockedOut
  }
}

Read-only, one LDAP query per DC. Because badPwdCount is not replicated, a DC with a rising count and a recent last-bad-password time is the one receiving the failing requests. Search-ADAccount -LockedOut -UsersOnly lists every currently locked user if you need the wider picture.

4. On that domain controller, read the matching failure events.

Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4771,4776; StartTime=(Get-Date).AddHours(-2)} |
  Where-Object { $_.Message -match 'jsmith' } |
  Select-Object -First 20 TimeCreated, Id, Message

Read-only. For 4771 note the Client Address and the failure code (0x18 = wrong password). For 4776 note the Source Workstation and error 0xC000006A. A different failure code points elsewhere: Microsoft's table lists, for example, 0x25 as clock skew too great and 0x12 as client credentials revoked.

5. On the caller computer, read 4625 for the account.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} |
  Where-Object { $_.Message -match 'jsmith' } |
  Select-Object -First 10 TimeCreated, Message

Run locally on the caller computer in an elevated session (reading the Security log needs administrative rights or Event Log Readers). Look at Logon Type (3 = network, 4 = batch/scheduled task, 5 = service, 10 = remote interactive), Source Network Address, and Caller Process Name. Logon type 4 or 5 with a process path usually points directly at a scheduled task or a service. If the 4625 shows a Source Network Address, that is the next hop: repeat on that computer.

6. On the final computer, list what runs as the account.

Get-CimInstance Win32_Service | Where-Object StartName -match 'jsmith' |
  Select-Object Name, State, StartMode, StartName
Get-ScheduledTask | Where-Object { $_.Principal.UserId -match 'jsmith' } |
  Select-Object TaskPath, TaskName, State

Read-only; elevation is needed to see every task. Also check IIS application pool identities and any application-specific stored credentials on servers that host them. Those are listed in the application's own configuration, not in services.

7. On a user's own machine, check saved credentials and sessions.

cmdkey /list
net use
quser

cmdkey /list lists stored credential targets for the current user without showing passwords; run it as that user, with their agreement. net use lists mapped drives with stored connections, and quser lists sessions on the machine (including disconnected ones). Also ask about phones and tablets with work mail configured. They are a common source and do not appear in any server's process list; the caller is usually the mail server.

Interpreting the results

On blank or unhelpful Caller Computer Name: Microsoft's documentation describes the field but does not list the conditions in which it is empty. This article therefore does not claim a cause. Practical experience reported widely in Microsoft's community forums is that the failure trail continues on the domain controller that received the request, and steps 3 and 4 cover that path.

Decision guidance

Fix the source, not the lockout policy

Once you know the process, change the credential at the source. Typical changes:

• Service: update the service logon password (Services console, or your configuration management), then restart the service in its maintenance window. Verification: the service starts and works, and over a window long enough to cover its usual retry or run interval there are no new 4625/4771 events for the account, no new badPasswordTime on any DC compared with the per-DC values you recorded before the change, and no new lockout. badPwdCount does not have to reach zero: it resets on a DC only after a successful logon there. Rollback: re-entering the old password does not help; if the service fails, check the account's rights rather than reverting.
• Scheduled task: re-enter the credential on the task or, better, move it to a group managed service account where the task supports it. Verification: the next scheduled run succeeds, with no new failures. Rollback: the task's previous definition can be exported before the change (Export-ScheduledTask) and re-registered if needed.
• Saved credentials and drives: the user removes the stale entry (cmdkey /delete:<target> for their own entry, or Credential Manager) and reconnects. Verification: no new lockouts at the next logon. Rollback: not applicable.
• Phones and mail clients: the user updates the password on the device, or removes and re-adds the account. Verification: failures from the mail server stop.
• Disconnected sessions: sign the user out of the stale session at an agreed time. Do not reset other users' sessions without notice.

Unlock the account after the source is fixed. Unlocking first only restarts the cycle.

When to change the lockout policy

Lockout threshold and duration are security policy, not a troubleshooting tool. Microsoft's guidance notes that Windows security baselines recommend a threshold of 10 as a balance between user error and brute-force protection, and that thresholds that are too low cause lockouts from ordinary mistakes. If your threshold is very low (for example 3) and every investigation ends at "user mistyped", a policy review is reasonable. Make it a planned change with security sign-off, never as part of fixing one account.

Service accounts as a class

If one service account locks out every time its password changes, it is used in more places than anyone recorded. Before the next change, inventory its use (services, tasks, application pools, connection strings), or move it to a group managed service account where supported, so password changes stop being a manual event. The Before Restricting NTLM: Inventory Who Uses It and Why Kerberos Was Not Used below covers finding NTLM use, which often shows these hidden callers.

What not to do

• Do not set the threshold to 0 (never lock) to stop the calls. It removes a brute-force control for the whole domain.
• Do not repeatedly unlock without finding the source, and do not script automatic unlocks.
• Do not reset the user's password again as the fix. The stale credential keeps sending the previous one, and you have now made two old passwords.
• Do not delete Credential Manager entries for a user without them knowing. Those may include credentials they need for other systems.
• Do not open firewall rules on domain controllers just to read their logs remotely; use console access or your log platform.
• Do not treat a pattern of many accounts locking out from one address as a help desk task. That is a possible attack.

Limitations

• The method assumes the audit subcategories are enabled and the Security logs retain enough history. Without them, start auditing and wait for the next lockout.
• Microsoft's event reference pages used here are from the Windows 10/Windows Server 2016 era documentation set (last updated 2021). Field definitions have not changed in later versions in the material reviewed, but newer builds were not separately checked.
• Caller Computer Name blank conditions are not documented by Microsoft in the sources reviewed.
• Network devices, VPN concentrators and RADIUS servers (for example NPS) have their own logs; their commands are out of scope.
• Hybrid identities with Entra ID smart lockout, and federation services such as AD FS extranet lockout, follow separate rules not covered here.
• The PowerShell property positions in the 4740 example depend on the event schema; confirm on your own event before relying on them in automation.

Acceptance checklist

• [ ] The PDC emulator was identified and its 4740 events for the account were read.
• [ ] The chain was followed until the caller was an end device or a process, not a server in the middle.
• [ ] The stale credential's location (service, task, saved credential, device, session) is recorded.
• [ ] The credential was updated at the source, with verification that new failures stopped.
• [ ] The account was unlocked only after the source was fixed.
• [ ] Per-DC badPwdCount and badPasswordTime recorded before the fix, with no new bad-password time, no new 4625/4771/4740 events and no lockout on any DC over a window that covers the source's usual recurrence.
• [ ] If the account is a service account, its uses are inventoried for the next password change.
• [ ] Any pattern suggesting password guessing was escalated as a security event.
• [ ] Lockout policy was not changed as part of the fix.

References

All accessed 2 November 2026.

• Microsoft Learn, "4740(S): A user account was locked out": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4740
• Microsoft Learn, "4625(F): An account failed to log on": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4625
• Microsoft Learn, "4771(F): Kerberos pre-authentication failed": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4771
• Microsoft Learn, "4776(S, F): The computer attempted to validate the credentials for an account": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4776
• Microsoft Learn, "Active Directory FSMO roles in Windows": https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/fsmo-roles
• Microsoft Learn, "Account lockout threshold": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/account-lockout-threshold
• Microsoft Learn, "Bad-Pwd-Count attribute": https://learn.microsoft.com/en-us/windows/win32/adschema/a-badpwdcount
• Microsoft Learn, Get-ADDomain: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomain
• Microsoft Learn, Search-ADAccount (including -LockedOut): https://learn.microsoft.com/en-us/powershell/module/activedirectory/search-adaccount
• Microsoft Learn, cmdkey: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/cmdkey

Related articles

• Group Policy Not Applying: gpresult, Events and SYSVOL
• Scheduled Jobs After Migration: Prevent Duplicate Work

• Server Up, Application Unusable: Build Better Health Checks

• Before Restricting NTLM: Inventory Who Uses It and Why Kerberos Was Not Used

• Revoke a Departed Administrator's Access Across a Hosted Estate

Learning notes

1. Lockout is processed on the PDC emulator, so its 4740 events are the starting point; the Caller Computer Name is a hop, not always the end of the chain.
2. badPwdCount is not replicated, so query every DC to see where failures arrive.
3. 4771 and 4776 on DCs give the source address or workstation; 4625 on the caller gives logon type and process.
4. Logon type 4 (batch) and 5 (service) on a 4625 point straight at scheduled tasks and services.
5. Fix the credential where it is stored, then unlock; never change domain lockout policy to make one account's problem go away.