Why AD Accounts Lock (and How to Fix Them)

Account lockouts in Active Directory are a common help-desk drain. Users can’t sign in, and tracking down the cause—wrong password, cached credentials, or a misconfigured service—takes time. This guide gives Windows and Active Directory admins a clear path to identify and resolve lockouts.

Why AD Accounts Get Locked

Lockouts occur when failed logon attempts exceed the Account Lockout Policy threshold. Causes usually fall into a few categories:

• Wrong password — User forgets or mistypes; multiple attempts trigger lockout.
• Cached or stored credentials — Apps, mapped drives, or Credential Manager still use an old password after a change.
• Mobile and email clients — Phones or Outlook using saved credentials with an outdated password.
• Service accounts — Services or app pools running under a domain account with an expired or changed password.
• Multiple logins — Same account on several devices; one device with a bad password can lock the account everywhere.
• Malicious activity — Brute-force or compromised access; lockouts can be a signal to investigate.
• Replication issues — Password or policy not replicated correctly between domain controllers.

How to Find the Source of Lockouts

Use Event Viewer on domain controllers:

• Event ID 4740 — Indicates a lockout and often which computer triggered it.
• LockoutStatus.exe (Microsoft Account Lockout Tool) or PowerShell scripts can trace the source machine.

Check cached credentials on the user’s devices: Credential Manager, scheduled tasks, mapped drives, and services.

How to Fix Account Lockouts

1. Reset the password — Change the user’s password and ensure it’s updated on all devices. Restart devices if cached credentials persist.
2. Update service accounts — If a service account is locked, update the password in the service or app pool configuration.
3. Update mobile and email — Refresh saved passwords on phones, tablets, and Outlook profiles.
4. Security follow-up — If you suspect abuse, review security logs, lockout patterns, and consider MFA and lockout policy tuning.

Best Practices

• Enable auditing and centralized monitoring of account lockouts so you can distinguish user error, misconfiguration, and abuse.
• Review and, if needed, adjust Account Lockout Policy (threshold and duration) to balance security and usability.
• Use least-privilege and JEA where possible so only required actions are allowed and logged.

Common Pitfalls

• Resetting the password without finding which device or app is still using the old one; lockouts recur.
• Ignoring Event ID 4740 and other lockout events; admins miss the source machine or repeated abuse.
• Leaving service account passwords out of sync after rotation; lockouts and failed services continue.

FAQ

What Event ID shows account lockouts?
Event ID 4740 on domain controllers indicates an account lockout and often which computer caused it.

Why do lockouts keep happening after a password reset?
Another device, app, or service is still using the old password. Check Credential Manager, mapped drives, services, and mobile/email clients.

Should I increase the lockout threshold?
Only after you’ve improved monitoring and response. Raising the threshold can reduce lockouts but also weakens protection against brute force.

How can I manage lockouts and resets from the road?
Use a secure, mobile-friendly way to reset passwords and unlock accounts without full domain admin on the device. See ADSignify for AD-focused tasks from your phone.

Where can I read more about securing AD and reducing lockouts?
See Why MSPs Should Manage Client AD from Mobile and JEA and Active Directory for related practices.

---

Need to reset passwords or unlock accounts without sitting at a desk? ADSignify lets you handle common AD tasks from your phone—securely and without full domain admin on the device.