Fix 'Account Locked Out' Errors in Windows Active Directory

1. Rogue Application or Scheduled Task with Bad Password

This is the one that bites most small businesses. Someone changed their password but forgot to update it in Outlook, a mapped drive, or a scheduled task. That old credential keeps trying to authenticate and locks the account.

The fix: First, unlock the account temporarily so the user can work. Then find the source.

Open Active Directory Users and Computers on a domain controller. Find the user, right-click, select Properties, go to the Account tab, and check Unlock account. But this is just a band-aid—the lockout comes back if you don't kill the root cause.

To find the culprit, use the LockoutStatus.exe tool from the Windows Server Resource Kit. Run it against the user account. It tells you which domain controller processed the last bad attempt. Then check that DC's Security Event Log for event ID 4740 (account locked out). The event shows the caller computer name—that's your target.

Had a client last month whose account locked every 15 minutes. Turned out their iPhone's mail app was using the old password. Updated it, problem gone. Check all devices: phones, tablets, laptops, VMs, RDP sessions, and any saved network credentials in the Credential Manager.

2. Stale RDP Session or Service Running Under the User's Account

If the user leaves an RDP session open and the remote machine's network connection drops, the session might keep trying to re-authenticate with cached credentials. Same thing happens with Windows services or scheduled tasks configured to run under the user's account instead of a service account.

The fix: Log off all user sessions. On the user's workstation, open Task Manager > Users tab, and disconnect or log off any active sessions. Also check services.msc on any server where the user might have set up a service under their domain account. Change those to a dedicated service account with a long, complex password that never expires.

For RDP specifically, check the Remote Desktop Services manager on the terminal server. See if the user's session is disconnected but not logged off. If so, log it off. That kills the re-auth loop.

A while back, a client had a backup script running under a domain admin account. When the admin changed his password, the script failed silently and locked his account daily. Stopped the script, updated the password in the task scheduler, and never seen it again.

3. Bad Password Policy or Low Lockout Threshold

Some admins set the lockout threshold too low—like 3 bad attempts—thinking it's more secure. In practice, users type their password wrong a few times and boom, locked out for 30 minutes. This is especially painful if the policy also has a long lockout duration.

The fix: Review your Default Domain Policy in Group Policy Management. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Account Lockout Policy. Set the Account lockout threshold to 10 invalid logon attempts. Set the Account lockout duration to 15 minutes (or 0 if you want the admin to manually unlock, but that's a pain). Set Reset account lockout counter after to 30 minutes.

These numbers balance security and usability. Users screw up sometimes—don't punish them for a typo. And if someone's really brute-forcing, 10 attempts is enough to trigger an alert without locking the account on the first mistake.

One client had it set to 1 attempt and a 999-minute lockout. Had to manually unlock 20 people every Monday morning. Changed it to 10/15/30 and the helpdesk tickets dropped to zero.

Quick-Reference Summary Table

If you still get locked out after these steps, run net user username /domain on a DC to check the account's lockout status. And if the lockout source shows as the user's own workstation, it's almost always a saved credential in the Windows Credential Manager. Open Control Panel > Credential Manager > Windows Credentials and wipe anything related to the domain or the user's account. That clears old cached logins that keep trying.