In most case the user’s account will get locked because user’s old or incorrect password is still being used, usually this occurs after the user has changed their password. The issue is trying to find out what and where the old or incorrect password has been used, this could be a mapped drive that has user credentials, a RDP session that has not closed correctly and leaves a disconnected session, mobile phone, remote email access, or cached credentials on the workstation.
To help find the cause of the lock out you can use NetTools which includes a number of tools\reports to show how and when the account was locked.
From NetTools, select Last Logon under Users in the Left hand pane. Enter the user's samaccountname in the username field and click Go. You only need to enter the server name in the server field, if the user account is in a different domain.
NetTools will collect the logon details from each of the domain controllers in the domain and display the details held for that account.
The Columns have the following means:
|Server||The name of the domain controller the details are from|
|Last Logon*||The last time the domain controller successfully authenticated the user’s credentials|
|LastLogonTime||AD attribute LastLongTimeStamp attribute see this article for more info http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx|
|Locked||Indicates if the account is locked on this domain controller|
|Locked Time||The time the account was locked out|
|Bad Pwd*||The number of bad password attempts has been seen by this domain controller|
|Pwd Set||When the password was last set|
|LastBadPwd||The time when the last bad password attempt was received by this domain controller|
|Logon Count*||The number of times the account has been successfully authenticated by the domain controller|
|Meta Time||AD meta data Time of the last change to the unicodepwd attribute|
|Ver||AD meta data version number of the unicodepwd attribute|
* Some attributes are not replicated between domain controllers these are highlight with an asterisks after the name. Due to this each domain controller has its own set of details for each user account and you need to review all domain controllers when trying to work out why and when an account is locked.
This is the same account after the account has been locked, you can see not all the domain controllers think the account is locked, this is caused by AD replication latency, over time all the domain controller will have the same view.
To troubleshoot when and why an account is locked out we first need to sort the results, click on the Last BadPwd column so the times are in descending order. The top most entry is when the account was last locked. If the bad password time, is not a time when the user would be using the account, this could indicate that the account was locked by saved credentials.
The security event logs on the domain controllers and the member servers of the domain contains the details of the account lockout. NetTools can search the event logs to find event relevant to the account on the select domain controller and then search the event logs of any member servers in the authentication chain, it will then display the information on the cause of the lockout.
To find the lockout details, select the domain controller with the last lockout time and right click and select Display Event Details from the context menu. This will enumerate the security logs for any failed authentication request for the user account.
HowTo: Check that a user has actually changed their password
For more information on why and how accounts get locked out see this article, https://technet.microsoft.com/en-us/library/hh994566(v=ws.10).aspx