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.

-From http://support.microsoft.com/kb/913485

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.

From http://support.microsoft.com/kb/913485

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.

Important

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.

From http://support.microsoft.com/kb/818088

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.

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.

From http://support.microsoft.com/kb/829652

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.

From http://support.microsoft.com/kb/818088

Conclusion

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.