When a user account becomes locked out, the cause is often attributed to a user who has simply entered an old or incorrect password too many times. However, this is far from being the only thing that can cause an account to become locked.

Another common cause, for example, is an application or script that is configured to log into the system using an old password. Perhaps the most easily overlooked cause of account lockouts, however, is the use of cached credentials.

Before I explain why cached credentials can be problematic, let's first consider what the Windows cached credentials do and why they are necessary.

Cached and stored credentials

Cached credentials are a mechanism that is used to ensure that users have a way of logging into their device in the event that the device is unable to access the Active Directory. Suppose for a moment that a user is working from a domain-joined laptop and is connected to the corporate network.

In that type of situation, the Active Directory would authenticate the user's credentials when the user logs on. If, on the other hand, the user is working from home using the same laptop but has no connection to the corporate network, then the Active Directory cannot process the user's logon request.

This is where cached credentials come into play. If it were not for cached credentials, then the user would be unable to log on to their device because there is no domain controller available to process the logon request. Because Windows supports the use of cached credentials, however, the cached credentials residing within the user's device can process the authentication request.

The user will not be able to access any of the resources on the corporate network because no connection to the network exists and the user's authentication was not processed by a domain controller. Even so, the user will at least have the ability to log into their laptop and use any applications that are installed locally on the device.

Even though cached credentials are primarily used as a mechanism for allowing users to login locally when they are working from outside of the office, cached credentials have another important use. If an organization were to suffer a catastrophic failure that resulted in an Active Directory outage, then the IT staff could use cached credentials as a means of logging into their devices so that they can begin diagnosing and repairing the Active Directory problems.

All of this is to say that Windows cached credentials do have a valid use case. As such, they are not the sort of thing that you would want to disable. As previously noted however, the use of cached credentials can cause confusion and even cause accounts to become locked out under certain circumstances.

Cached credentials causing account lockouts

Imagine for a moment that a user works from two domain joined devices: a corporate desktop, and a laptop. Now suppose that the user is working from their desktop and changes their Windows password. Assuming that the laptop is powered off at that point, the laptop is unaware of the password change. It still has the user's old credentials stored in the password cache.

With that in mind, consider what would happen the next time that the user attempts to logon from their laptop. If the user is not connected to the corporate network, then their new password will not work because the old password is still stored in the cache. However, the user can still log into the device using their old password. Once the user connects to the corporate network, however, the password will be updated. This means that if the user repeatedly attempts to log on to their laptop using their old password, then the authentication process will fail, and the user will eventually be locked out of their account.

Updating user cached credentials

Specops uReset can help with this problem. Users are able to reset their Windows passwords directly from the Windows logon screen. More importantly, when a user changes or resets their password, the Specops uReset software automatically synchronizes the new password across the user's devices, updating the local cache in the process. This means that a user should never run into a situation in which some devices have been updated with their new password while other devices continue to use the old password. From an IT standpoint, this means fewer password-related service calls to your helpdesk.