AD Account Lockout Source: Event 4740 Tracing

A user account that locks out every few minutes, even after a password reset, is almost never an attacker. It is a stale credential somewhere: a saved RDP session, a scheduled task, a mapped drive, a phone mail profile or a service running as that user. The trick is that the lockout is recorded on the domain controller, but the bad password comes from a client, so you have to follow the chain from the DC back to the workstation. These steps apply to Windows Server 2019, 2022 and 2025 domain controllers with Windows 10/11 clients.

Short answer: Every lockout in the domain is forwarded to the PDC emulator, so query its Security log for Event ID 4740 and read the “Caller Computer Name” field to identify the machine that sent the bad passwords. On that machine, look for Event ID 4625 (failed logon) and Event 4776 to find the process, then remove the stale credential from Credential Manager, scheduled tasks, services, mapped drives or mobile devices. Make sure auditing of account lockout events is enabled on the Default Domain Controllers Policy or 4740 will not be logged.

Confirm auditing is switched on

Event 4740 only appears if the “Audit User Account Management” and “Audit Account Lockout” subcategories are enabled on the domain controllers. Check the effective policy on a DC:

auditpol /get /subcategory:"User Account Management"
auditpol /get /subcategory:"Account Lockout"

If either shows “No Auditing”, edit the Default Domain Controllers Policy at Computer Configuration » Policies » Windows Settings » Security Settings » Advanced Audit Policy Configuration » Audit Policies » Account Management » Audit User Account Management (Success) and Logon/Logoff » Audit Account Lockout (Failure), then run gpupdate /force on the DCs. Also confirm the lockout threshold and window under Account Policies » Account Lockout Policy, because a threshold of three with a ten-minute window makes a single mistyped password on two devices look like an attack.

Query the PDC emulator for Event 4740

Find the PDC emulator and pull the lockout events for the affected user in one PowerShell session:

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

The “Caller” value is the NetBIOS name of the computer that submitted the failing password. If it shows a domain controller instead of a workstation, the requests arrived over a channel that hides the true client, most commonly RADIUS/NPS, an Exchange or web front end, or a Linux host using Kerberos. In that case go to that server and check its own logs (IIS logs, NPS Event 6273, or the application’s authentication log) for the originating IP address.

Find the stale credential on the caller

On the caller computer, list failed logons for the user with the process and logon type:

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625} -MaxEvents 100 |
  Where-Object { $_.Message -match 'jsmith' } |
  Format-List TimeCreated, Message

Logon Type 2 is interactive, 3 is network (mapped drive or share), 4 is a scheduled task, 5 is a service, 7 is an unlock and 10 is RDP. The “Process Name” and “Caller Process ID” fields usually point straight at the culprit. Work through the common hiding places in this order:

• Credential Manager: cmdkey /list and cmdkey /delete:TERMSRV/server for saved RDP and share passwords
• Scheduled tasks: schtasks /query /v /fo list | findstr /i "jsmith"
• Services: Get-CimInstance Win32_Service | Where-Object StartName -match 'jsmith'
• Mapped drives with stored credentials: net use and remove entries with net use X: /delete
• Disconnected RDP sessions on servers: query user /server:rds01 and log them off
• Mobile devices with an old ActiveSync or IMAP password, and browser-saved passwords for internal web apps

If the user has recently changed their password, the old one is often still cached in a disconnected session on a terminal server, which keeps replaying it every time a background process refreshes a token.

When the caller is blank or an unfamiliar name

A blank caller name usually means a Kerberos pre-authentication failure from a non-Windows device. Look on the DC for Event ID 4771 with failure code 0x18, which includes the client IP address. Resolve the address, and if it belongs to a printer, NAS or network appliance, update the stored credential there. Repeated failures from an internet-facing IP against an externally published service such as RDP, Exchange or a VPN indicate password spraying; block the source and put MFA in front of the service.

Verify and keep it from recurring

Unlock the account with Unlock-ADAccount -Identity jsmith, then watch for a fresh 4740 for at least one lockout window. If nothing appears, the stale credential has been removed. To avoid repeating this exercise manually, set an alert on Event 4740 in your monitoring platform, and consider extending the lockout observation window to 30 minutes with a threshold of 10, which tolerates genuine typos while still throttling brute-force attempts. Related reading: check domain controller health with dcdiag and repadmin if lockout events are not replicating consistently between DCs.

AD account lockout source at a glance

Official documentation: Active Directory Domain Services docs, Windows Server documentation.

Related guides: Transfer and seize FSMO roles with PowerShell and ntdsutil · Fix AD replication errors 8453 and 1722 “The RPC server is unavailable” · Change a domain controller’s IP address without breaking replication.

See also: Event ID 4771: Kerberos Pre-Authentication Failed (Codes) · Event ID 4625: An Account Failed to Log On (Status Codes)

Frequently asked questions