Account Locked Too Many Failed Logins — Fix Without Waiting

When This Error Appears

You're sitting at your desk (or ssh'd into a remote server) and you type your password carefully — but the system throws back: "Your account has been locked out. Please contact your administrator." Maybe you've been typing your password wrong for a few minutes, maybe a stray caps key, maybe a script running in the background kept retrying an old password. On Windows, you'll see event ID 4740 in the Security log. On Linux, you'll get something like "Account locked due to 5 failed logins." This isn't random — it's by design.

Root Cause

What's actually happening here is the Account Lockout Threshold policy kicking in. This is a security guardrail: after N consecutive failed login attempts within a set time window (usually 15-30 minutes), the system locks the account to prevent brute-force attacks. The lockout duration is also a policy setting — some environments auto-unlock after 15 minutes, others require an admin to manually unlock. The culprit is often not you — it's a forgotten saved credential, a scheduled task using an old password, or a mobile device trying to sync email with the wrong password.

The real trigger? I've seen this most often when someone changes their domain password, then Outlook on their phone keeps retrying the old one. Each retry counts as a failed attempt. 5 minutes later, your desktop account is locked too, because the same AD account is being hit from multiple sources.

The Fix

Skip waiting 15 minutes — if you need access now, here's the direct path.

Identify the lockout source. On Windows, open Event Viewer (eventvwr.msc), navigate to Windows Logs > Security. Filter by event ID 4740. The log entry shows the caller computer name or IP that triggered the lockout. Write that down.
Unlock the account (if you have admin rights). Open Command Prompt as Administrator and run:
```
net user username /domain /active:yes
```
Replace username with the locked account name. For local accounts (no domain), drop /domain:
```
net user username /active:yes
```
If that doesn't work on a domain, use Active Directory Users and Computers (ADUC): right-click the user → Properties → Account → check "Unlock account".
If you're not an admin, call your admin. But before you do, tell them the caller computer from step 1. That cuts their diagnosis time from 20 minutes to 2. Admins can run:
```
LockoutStatus.exe
```
from the Windows Server Resource Kit to see all lockout sources.
Fix the source. If step 1 showed your phone, go to its mail settings and update the password. If it's a scheduled task, update the stored credential in Task Scheduler. If it's a mapped drive with old creds, disconnect it (net use * /delete).
Prevent recurrence. On your own machine, open secpol.msc → Account Policies → Account Lockout Policy. The default threshold is often 5 attempts. You can increase it to 10 if you're prone to typos (but don't disable it — that's asking for trouble).

If It Still Fails

Three things to check if the unlock didn't work:

Replication delay. On multi-DC domains, the unlock may not have propagated to the DC that's authenticating you. Wait 60 seconds and try again, or specify a different DC: net user username /domain /active:yes /server:DC2
Password expired. Sometimes the account is locked AND the password has expired. The lockout message obscures the expiration. Change the password via Ctrl+Alt+Del → Change a password (if possible) or ask admin to reset it.
Bad cached credential. Windows caches the last 10 validated logins in the registry. If the cache has the old password and a lockout state, you may need to clear it. Run gpupdate /force, then reboot. If that fails, use reg delete HKLM\SECURITY\CACHE /va /f (requires SYSTEM privileges — use psexec -i -s cmd).

One last opinionated note: don't disable the lockout policy on production systems. I've seen companies that did that get hit by password spray attacks and end up with a week of incident response. The fix is to find the rogue retry source, not remove the guardrails.