Troubleshooting a Recurring Account Lockout
Windows user account lockout
If you haven’t had to deal with a mysterious, recurring account lockout, then you haven’t been on the job very long. Almost all Active Directory installations include a Group Policy Object specifying basic account security options such as password length and account lockout thresholds. These settings are essential for adequate data security, but they can become a real pain when a user keeps getting locked out and you can’t figure out why.
There are three basic tools I use to troubleshoot and fix this issue, and between these three, you should be able to handle 95%+ of all the recurring account lockouts that you encounter.
First, is the Account Lockout Status tool, which you can download from Microsoft here: https://www.microsoft.com/en-us/download/details.aspx?id=15201. Run it as a domain administrator from a network location that is able to reach all domain controllers on your domain. It will tell you which DCs registered a bad password attempt, when the last denied login was for each DC, and which DC registered the account lockout.
Second, you can use the server name and time from the Account Lockout Status tool to find the specific log entry that records the bad login attempts. Filter for event 4776 audit failures and search for the username. The log entry should include the name of the computer from which the login attempts are being made.
Third, after you’ve eliminated an outdated password on all email clients (especially watch out for mobile devices), wifi connections (mobile devices again!), mapped drives, and extra-long fingernails, check the Windows Credential Manager for any old credentials that contain the username anywhere in the details. Delete those and let Windows recreate the credential tiles the next time the user enters his password.
Recurring account lockouts can be very frustrating for both you and the end user, but even more so for the end user. It’s not necessarily his fault. There are a lot of places that old saved passwords can hide, and it can take some sleuthing to dig them out. Make sure you tell the user that you understand how upsetting it can be. You are on his side and that computer will behave itself…or else.
Update: If you are using Microsoft Exchange, there’s a fourth tool you might need to use. The event log might not list a source computer for the bad login attempts. In that case, you can check the IIS AdvancedLogs for entries matching the username and timestamp of the event log entry. This should give you email client information such as IP address, DeviceID, and DeviceType.
This table will help you decipher the specific error codes that you’ll find:
| 0xc0000064 | Invalid username |
| 0xc000006A | Invalid password |
| 0xc0000234 | Account is locked out |
| 0xc0000072 | Account is disabled |
| 0xc000006F | Logon hours restriction |
| 0xc0000070 | Log on to workstation restriction |
| 0xc0000193 | Account expired |
| 0xc0000071 | Password expired |
| 0xc0000224 | User must change password at next logon |
It sounds a fantastic approach to deal in such weird circumstance while waiting to resolve the account lockout issues.
Though being an administrator, I have also faced this challenges many times and used Account Lockout Status tool to short-out the problem. (Thanks to Microsoft for this excellent tool).
However, I recently explored another very informative article from Lepide team that explains in depth to find the root-cause of such cases and audit all successful logon/logoff and failed logons in Active Directory : http://www.lepide.com/blog/audit-successful-logon-logoff-and-failed-logons-in-activedirectory/
Thanks, Amritesh. If anyone else has tools that they’ve found helpful for troubleshooting account lockouts, let me know.