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:
|0xc0000234||Account is locked out|
|0xc0000072||Account is disabled|
|0xc000006F||Logon hours restriction|
|0xc0000070||Log on to workstation restriction|
|0xc0000224||User must change password at next logon|