In this article, we will discuss about the Common Causes for Account Lockouts and troubleshooting steps and resolutions for account lockouts.
In order to avoid account lockouts, you need to check each computer on which a lockout occurred for the following reasons:
Most of the programs cache credentials or keep active threads that retain the credentials after a user changes their password.
Service account passwords are cached by the service control manager on member computers that use the account as well as domain controllers. If you reset the password for a service account and you do not reset the password in the service control manager, account lockouts for the service account occur.
Bad Password Threshold is set too low:
Bad password threshold is one of the most common misconfiguration issues. Many companies/organizations set the Bad Password Threshold registry value to a value lower than the default value of 10.
User logging on to multiple computers:
Most of the time this happens user logon on multiple computers at one time and the running programs access network resources with the user credentials and If user change password in one computer and the program running in other computer using old/original password and when those programs authenticate they request access to network and then the old password continues to be used and user account becomes lockout. To avoid this user must logoff from all computers then change password from one after that logoff and logon back.
Stored user names and passwords retain redundant credentials:
The credentials are redundant because Windows tries the logon credentials when explicit credentials are not found.
Scheduled processes may be configured to using credentials that have expired.
Persistent drive mappings:
Many times happens that the Persistent drives established with credentials that subsequently expired. When user type explicit credentials to connect a share, the credential is not persistent unless those credentials explicitly saved by Stored User Names and Passwords. Whenever the user logs off / logs on to the network, or restarts the computer, the authentication attempt fails when Windows attempts to restore the connection because there are no stored credentials. In order to avoid this behavior, you have to configure net use so that is does not make persistent connections.
Active Directory replication:
You need to verify that the proper Active Directory replication is occurring.
Disconnected Terminal Server sessions:
Always update authentication information because it happens that the Disconnected Terminal Server sessions running a process that accesses network resources with outdated authentication information.
By default, most computer services are configured to start in the security context of the Local System account. Also, you can manually configure a service to use a specific user account and password. If you configure a service to start with a specific user account and that accounts password is changed, the service logon property must be updated with the new password or that service may lock out the account.
Internet Information Services:
By default, IIS uses a token-caching mechanism that locally caches user account authentication information. If lockouts are limited to users who try to gain access to Exchange mailboxes through Outlook Web Access and IIS, you can resolve the lockout by resetting the IIS token cache.
Stored server connections can be displayed by opening a command prompt and running the command …
rundll32.exe keymgr.dll, KRShowKeyMgr
Then you can delete the old connections keys
For more information, please refer to the following link: