The account locks out, you unlock it, and ten minutes later it is locked again. The user swears they have not typed anything. They are probably right: something else is trying their old password on their behalf, over and over, and every attempt counts against the lockout threshold.
Active Directory records every lockout with the name of the computer it came from. Start there, follow the trail, and you will find the saved credential, the service or the phone that is doing it.
Start at the PDC emulator
Every domain controller forwards bad password attempts and lockouts to the domain controller holding the PDC emulator role, so that is the one place you can see all of them. Find it with Get-ADDomain and look at the PDCEmulator property. Then open its Security log and filter for Event ID 4740, A user account was locked out. The event includes the account name and, critically, the Caller Computer Name: the machine the bad attempts came from.
If auditing is not turned on, 4740 will not be there. Confirm the Default Domain Controllers Policy has Audit account management and Audit logon events (or the advanced User Account Management and Account Lockout subcategories) set to success and failure. The PowerShell below pulls the recent lockouts with the caller in one table.
$pdc = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $pdc -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 50 | ForEach-Object { [pscustomobject]@{ Time = $_.TimeCreated; User = $_.Properties[0].Value; Caller = $_.Properties[1].Value } }Trace the caller computer
The caller is where the bad password is being sent from, and that is where you look next. On that computer, the Security log records the failed attempts as Event ID 4625, and the Logon Type field tells you what kind of attempt it was: 2 is interactive (someone at the keyboard), 3 is network (a mapped drive or a share), 4 is a scheduled task, 5 is a service starting, 7 is unlocking the workstation, and 10 is Remote Desktop. The Process Name field often names the executable outright.
If the caller is a domain controller itself, an Exchange server, or a web server, the attempt came through it from somewhere else. On a domain controller look at Event ID 4771 (Kerberos pre-authentication failed) and 4776 (NTLM credential validation failed); both carry the client address, which is your next hop. On an Exchange or federation server the IIS logs show the client IP and the user agent, which tells you whether it was a phone mail app, a browser or a script.
The usual sources
The same handful of things cause nearly every repeat lockout, and the order below is roughly the order to check.
- A saved credential in Windows Credential Manager on the user's PC or on a second PC they also use.
- A mapped drive or a printer connection that was created with an explicit username and password.
- A phone or tablet mail app using ActiveSync or IMAP with the old password.
- A disconnected Remote Desktop session on a server, still logged in with the old password and re-authenticating in the background.
- A scheduled task, Windows service or IIS application pool running as the user.
- A macOS keychain entry or a Linux cron job on a machine the user manages.
- Cached credentials on an old laptop that was never wiped.
- Password spray from the internet against OWA, ADFS or a VPN login page using legacy authentication that does not stop at MFA.
Tools that speed this up
Microsoft's Account Lockout and Management Tools include LockoutStatus.exe, which queries every domain controller for the account and shows the bad password count, the last bad password time and which DC saw it. It is old, but it still works and it tells you in ten seconds which DC to look at when the PDC emulator's log is noisy.
When 4740 gives a caller name that does not exist, is blank, or is a NAT device, turn on Netlogon debug logging on the domain controllers with the command below. The resulting Netlogon.log in C:\Windows\debug records every authentication request with the source computer and, for pass-through authentication, the chain it came through. Turn it off afterwards with the flag set to 0x0, because the log grows quickly.
nltest /dbflag:0x2080ffffFix it and prevent the next one
Once you have the source, remove or update the credential, restart the service with the new password, sign the stale RDP session off, or reset the phone's mail account. Unlock the account only after that, or it locks again before you finish. Then check the lockout policy itself: a threshold of five with a thirty-minute lockout is punishing for a typo-prone user, and ten attempts with a fifteen-minute lockout and a fifteen-minute reset counter is a common balance. Be careful loosening it if you are exposed to password spray.
For the internet-facing case, block legacy authentication in Entra ID, put MFA in front of every external login, and enable Entra ID smart lockout and extranet lockout so attackers lock a cloud shadow rather than the real account. If lockouts are a weekly event in your environment, RackLedge can help trace them and tune the policy.
Frequently asked questions
The 4740 event says the caller is the user's own PC, but they have not typed anything. What now?
Something on that PC is using the old password. Check Credential Manager, mapped drives, scheduled tasks, services and any app with a saved login. Signing out and back in after a password change clears many of these.
Why is the caller computer name blank?
The attempt came through a protocol that does not pass the workstation name, often from a phone, a Mac or an internet-facing service. Use 4771 and 4776 on the DC for the client IP, or turn on Netlogon debug logging.
Takeaway
Look at Event ID 4740 on the PDC emulator, take the caller computer name, and follow it to 4625, 4771 or 4776 for the process or the client address. The source is almost always a saved credential, a stale session, a service or a phone. Remove that, then unlock the account, and the cycle stops.