One of our users keeps getting locked out of their domain account. I unlock it, they work for a while, then within an hour it is locked again. They swear they are typing the right password. I can unlock it each time but that is not fixing anything. How do I unlock the account properly, and more importantly, how do I find what keeps locking it so this stops happening?
Active Directory Account Locked Out: How to Unlock and Find the Source
Resolved
Data Recovery
CM
Community Member August 26, 2026
6 replies
891 views
Reviewed by moderators
6 Answers
First, the distinction that matters: a locked out account is not the same as a disabled one. Lockout is automatic and temporary, it happens when the number of wrong password attempts hits your domain's account lockout threshold. The account unlocks itself after the lockout duration, or an admin can unlock it immediately. A disabled account, by contrast, was switched off deliberately and stays off until re-enabled.
Because it is automatic, unlocking alone never fixes a repeat lockout, something keeps submitting a bad password. So you will do two things: unlock it now, then trace the source. The repeat pattern you describe is almost always a stale saved password somewhere, not the user mistyping.
To unlock right now, use the ActiveDirectory module. Find locked accounts across the domain:
Search-ADAccount -LockedOut -UsersOnly | Select-Object Name,SamAccountName
Then unlock the specific one:
Unlock-ADAccount -Identity jsmith
You can also right-click the user in Active Directory Users and Computers, open Properties, Account tab, and tick "Unlock account". Same result. But keep going, unlocking is the band-aid, the next steps are the actual cure.
Now find the source, this is the important part. Every lockout is recorded as Event ID 4740 in the Security log of a domain controller, and crucially the PDC Emulator is notified of every lockout in the domain, so that is the one DC to check rather than hunting across all of them. Find the PDC Emulator:
Get-ADDomainController -Filter * | Where-Object {$_.OperationMasterRoles -contains "PDCEmulator"}
Then pull the recent lockout events from it:
Get-WinEvent -ComputerName (that DC) -FilterHashtable @{LogName='Security';Id=4740} | Select-Object TimeCreated,Message
Open a 4740 event for your user and look at the Caller Computer Name field. That is the machine or device that submitted the bad password and triggered the lock. That single field usually solves the case, it points you straight at the culprit computer, phone, or server.
If Caller Computer Name is blank (common with VPN, RADIUS, or some network devices), correlate by timestamp with Event ID 4625 (failed logon) on the suspected source machine, or check Kerberos Event ID 4771 on the DC, which includes the client IP address. Note 4740 only lives on DCs, while 4625 is logged on the device where the logon actually failed.
Once you know the source machine, the fix is almost always an old cached credential. Work through these on that device:
Open Credential Manager (Windows Credentials) and remove any saved entries with the user's old password. Check mapped network drives reconnecting with stale credentials. Look at scheduled tasks and Windows services configured to run as the user, if the password changed, they keep retrying the old one. Do not forget mobile devices with the corporate email account still using the previous password, that is a classic silent locker. And clear any saved passwords in browsers or apps for internal sites.
A couple of finishing points. If Event ID 4740 is not appearing at all, Audit Account Management auditing is probably not enabled, turn it on in Group Policy under Computer Configuration, Policies, Windows Settings, Security Settings, Advanced Audit Policy Configuration, Account Management. And after you clear the stale credential, do one more password reset for the user so every device is forced onto a known-good password, then watch the 4740 log stays quiet. If this account also syncs to Microsoft 365, sorting the on-premises lockout is what fixes their cloud sign-in too, since the account state flows up from AD.