You unlock the account. Twenty minutes later it is locked again. Something on the network is still offering the old password — and Windows has already written down exactly which computer it is. You just have to read Event 4740.
Repeat lockouts follow a script: the user changed their password, and something somewhere still knows the old one — a phone, a mapped drive, a scheduled task, a service, a second PC they used once in March. Every one of those retries counts as a failed logon, the counter climbs, and the account locks again. Unlocking without investigating guarantees a repeat performance. This page is the detective order: start on the domain controller, where Event 4740 names the guilty machine, then hunt that machine's hiding places one by one. Do this once, properly, and the lockouts stop for good.
Every lockout on a domain writes Event 4740 into the Security log of the domain controller that processed it — and the PDC emulator is the most reliable place to look, because lockout processing centres there.
No event found? Auditing may be off — account lockout auditing must be enabled for 4740 to exist. That setup has its own page here; switch it on today so the next lockout explains itself.
Each domain controller keeps its own bad-password count for an account, which confuses admins who check one DC, see "not locked", and declare the user mistaken. Microsoft's classic LockoutStatus tool (from the Account Lockout and Management Tools) ends the argument: it lists every DC, each one's bad password count, and the lockout time for the account in a single grid. Use it to confirm which DC locked the account and when — then match that timestamp against Event 4625 (failed logon) entries. In 4625, the Logon Type is your biggest clue: type 3 means a network logon (drive mapping, file share), type 5 a service starting, type 4 a scheduled task, and type 10 an RDP session. The logon type alone often names the culprit category before you leave your chair.
Now go to the machine named in Event 4740 and check the usual hiding places, most common first:
control /name Microsoft.CredentialManager and look for saved Windows credentials for servers and shares with the old password. Delete the stale entries.net use and look for remembered connections to file servers; net use * /delete clears them.The single most missed cause in real offices: the user's phone or tablet still holds the old mailbox password. Mail apps retry patiently, forever, at intervals — so lockouts return like clockwork, including at night and on weekends when the user swears they "did nothing". The pattern is your tell: lockouts at regular intervals, caller computer pointing at the mail server or a generic device name, continuing outside office hours. The fix is embarrassingly small: update the password in every mail and Wi-Fi profile on every mobile device the person owns (corporate Wi-Fi with domain credentials counts too — a phone auto-joining office Wi-Fi with an old password locks accounts just as reliably as email). Then unlock once, watch the account for a full day, and close the case properly.
The complete lockout policy walkthrough and all 3 recovery methods, shown live on a real Windows system — this is the video this guide is based on.
▶️ Watch Full VideoEvent 4740 in the Security log of the domain controller that processed the lockout. Its most useful field is Caller Computer Name — the machine that presented the bad passwords. It only exists if account lockout auditing is enabled.
Follow the chain one hop further: check that server's failed-logon events (4625) around the same time to find the original device or IP. For mail servers, the culprit is usually a phone or tablet still using the old password.
LockoutStatus is Microsoft's small tool that shows an account's lockout state and bad-password count on every domain controller at once. It remains the quickest way to end the 'locked on one DC, fine on another' confusion, and it pairs with Event 4740 to pinpoint both the time and the source of a lockout.