Windows Active Directory Cached User Credentials

We get questions about Active Directory credential caching quite often from customers and prospects. Since we provide Active Directory solutions, it would make sense that we have insight into AD credentials caching in Windows but the caching mechanism is actually a function of the client and not the server. We take a closer look at some best practices to avoid account lockout issues when cached credentials and AD credentials become out of sync.

Understanding cached credentials is particularly important when working with remote users in a SSPR (self-service password reset) scenario. Basically, this scenario—supported with solutions like Web Active Directory’s PeoplePassword product—occurs when users who don’t regularly log directly into a domain and authenticate against a domain controller forget their Windows password. This includes VPN-connected users as well as users who take advantage of resources like portals that store user credentials in AD. The important part here is that the user is not authenticating directly against a Windows domain controller for authentication. An SSPR solution allows the AD credentials to be reset but does nothing to affect the cached credentials on the client machine.

Windows Credential Caching

SSPR solutions typically allow a user to easily reset her Active Directory password. This is great when a user is authenticating directly against a domain controller but not so good when a user, especially a remote user, is logging onto a machine or a VPN connection using Windows cached credentials.

What are Cached Credentials?

Cached credentials allow a user to access machine resources when a domain controller is unavailable.

After a successful domain logon, a form of the logon information is cached. Later, a user can log on to the computer by using the domain account, even if the domain controller that authenticated the user is unavailable. Because the user has already been authenticated, Windows uses the cached credentials to log the user on locally. For example, suppose a mobile user uses a domain account to log on to a laptop that is joined to a domain. Then, the user takes the laptop to a location where the domain is unavailable. In this scenario, Windows uses the cached credentials from the last logon to log the user on locally and to allocate access to local computer resources.


What is the Issue with Cached Credentials?

So cached credentials allow users to access a machine even when no DC is available to authenticate the user. Great! And since AD passwords generally only change every 30-90 days this is a fantastic method to provide a great user experience in a highly mobile environment. That is, until the AD credentials and the cached credentials become out of sync. Then all kinds of problems can occur when a user tries to access domain resources and the main problem is repeated account lockouts because the Windows client is passing invalid cached credentials to a domain controller.

What’s the Best Way to Handle Credential Synchronization Issues?

First and foremost, it’s not possible to reset cached credentials when an AD password is reset. Yes, this sounds like a bummer but it’s actually a good thing. Check out the following excerpt for an explanation.

Security of cached domain credentials

The term cached credentials does not accurately describe how Windows caches logon information for domain logons. In Windows 2000 and in later versions of Windows, the username and password are not cached. Instead, the system stores an encrypted verifier of the password. This verifier is a salted MD4 hash that is computed two times. The double computation effectively makes the verifier a hash of the hash of the user password. This behavior is unlike the behavior of Microsoft Windows NT 4.0 and earlier versions of Windows NT. 

If an attacker tries to conduct a cryptanalytic attack on the verifier, this encryption has two consequences:

  • A precompiled table must be created for each salt.
  • The verifier cannot be used to log on anywhere else.


This is good. It means that an attacker cannot compromise AD credentials from a client machine by looking at the “cached credentials” since credentials really aren’t cached and only a hash of the password is cached. We like these kinds of things as a security-minded society.

What Tools Can I Use to Reset Cached Credentials?

But what happens if I am a trusted system like Active Directory or an SSPR product and I want to reset the cached credentials to match AD credentials? Microsoft tells it best.


There are no tools or utilities from Microsoft to update cached credentials. This is by design. Only cached validated domain logons are stored as cached credentials.


So there are no tools from Microsoft to do this. I also know I have never seen any reputable commercial tools and I can pretty much guarantee there aren’t going to be any because of the nature of the security issue here. Sure, there are probably hacker tools out there to attempt to do this but you probably don’t want to deploy these from your enterprise’s IT shop. So the core issue still exists: how to prevent account lockouts for remote clients when the AD password is changed and the local cached credentials are not changed.

Best Practices and User Education to the Rescue

The final solution in this scenario is to ensure that your users are properly educated about how to log on to their computer or over VPN after changing or resetting an AD password. In PeoplePassword, you can customize the page that displays after users change or reset their AD password and tell the user the best ways to log on after the change or reset. There are two options to consider here based upon whether a user is actively connected to an AD domain or not.

Note (Posted on August 15, 2011 and many thanks to Christopher Lowde for the insight): With both options, the best practice to force a refresh of the local password cache is to lock and unlock your screen. After resetting or changing an AD password, immediately lock and unlock the screen with the new password to update the local cache. This is an easy method to convey to your users and it’s easy to describe the Ctrl + Alt + Del sequence since users are already familiar with the key sequence and process.

Option 1: Log on Without Automatically Using Windows Name and Password (Users Not Connected to a Domain)

Have your non-domain-connected users uncheck the Automatically use my Windows logon name and password option in the default Windows logon screen. This will reset cached credentials to the newly-changed AD password.

Problem: You cannot log on after you correctly change your logon credentials

This problem occurs because the new domain password is not synchronized with the password of the cached credentials. When you log off and then log on again without a network connection to the domain, you cannot access the workstation. If you turn off the Automatically use my Windows logon name and password option, the changed domain password is synchronized with the cached credentials. Therefore, you can log on.


Check out the Microsoft Knowledge Base article entitled Configure identity authentication and data encryption settings for setting more options with automatic logon credentials.

Option 2: Log On to the Domain with a New Password (Domain-connected Users)

Use this option for domain-connected users who can authenticate against a domain controller.

Problem: You cannot log on to a computer that is using cached credentials after you change your password by using a domain controller

When you successfully log on to a domain with a domain user account, your domain logon credentials are cached locally on your computer. If you then disconnect that computer from the network and log on, you are logged on with the cached credentials for the domain. 

When you log on to the domain and are prompted to change your password, your cached domain logon credentials are not updated until you successfully log on to the domain with the new password. After you have successfully logged on to the domain with the new password, your cached domain credentials are updated, and you can then log on to the computer when you are disconnected from the domain.



AD password and cached credential password synchronization can cause Windows account lockouts and other problems for remotely-connected domain users. Comment and let us know your best practices when dealing with the synchronization situation in your Active Directory environment.


  1. Jason Cox

    We recently had a comment on this article through a LinkedIn discussion so I wanted to expand on the comment here. Someone asked if the cache time of the hash is calculated based on the max password age. To my knowledge, I’m not aware that the cache has a time limit for the hash. Instead, the cache stores a number of previous logon attempts, which by default is 10. The KB article at has more information about cached domain logon information

    You can also manage the cache using the Stored User Names and Passwords utility. Get more information on that tool at and The command to run the Stored User Names and Passwords utility is rundll32.exe keymgr.dll, KRShowKeyMgr.

  2. Synergix ( ) has a product called Active Directory Client Extensions which will synchronize the cached credentials with domain credentials whenever the domain account password is changed.

  3. Eddie Seok

    Funny how Microsoft doesn’t know how to resync their cached credentials. So let me inform you:

    1) Log onto the system with the old credentials
    2) Connect through VPN and verify that you have connection to the domain
    3) Lock your system
    4) Unlock your system (prompting you for credentials)

    There you have it. Your login credentials are now effectively synced with AD. This is a free and cheap method that works. (Verified with Windows XP SP3 and Windows 7).


    Eddie Seok

  4. Welll…in our environment we have Sharepoint and we have problems due the fact that either the DomainControllers or Sharepoint itself caches the passwords. I have realized that migration between these MS-components is very loose. Has anyone experienced similar problems in Sharepoint environment, that users are:
    – able to use OLD and NEW AD-password simultaniously
    – are not able to log in to the Sharepoint with accounts that are NOT “locked” or “disabled” in AD. BUT, if account is “disabled” and “enabled” for an one second AFTER the password change ( using ADUC for fast disable-enable operation )-> Sharepoint notices the account changes AND now the new AD_password works ! I have been able to simulate this “feature” at least one hundred times !
    Does anyone know, what to change in Sharepoint ? Sharepoint is 2007 version, DC:s are 2003 servers.

  5. Jawdat.Daou

    This is a bit of ‘Chicken and egg” subject, why? for example how can you follow what Eddie Seok suggested when you have forgotten your password and can’t get to your desktop?

    Any SSPR tool will only change the password on the domain and will need further wizardry in order to reset/update the Cached Credentials.

    Now if you can start a VPN net connect session and login to the domain (not locally) from the Gina (win XP) PLAP (win 7) stage using the newly reset password that you reset earlier using your SSPR tool then windows will update/synch your password cache locally. Most VPN clients will support kind of VPN sessions and respect the credential exchange and update that takes place with windows.
    I found that his is the only way that will help in a scenario where a user is working at home and have forgot his password and can’t login to the laptop

Sign in
Forgot password?
Sign up

(*) Required fields

I agree with OptimaSales Terms & Privacy Policy