To totally unlock this section you need to Log-in
Login
On Microsoft Active Directory environments, 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 MD5 hash (or stronger) 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.
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.
So there are no tools from Microsoft to do this.
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. There are two options to consider here based upon whether a user is actively connected to an AD domain or not.
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.
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.
To avoid this situation, after a successful login, the user’s credentials can be saved in the local cache on computer. This allows users to log on with domain cached credentials and access local resources of the computer even if the connection to the domain controller is not available.
To be precise, the credentials (login and password) are not cached, but only the MD5 hash of the password, modified with salt, which is generated based on the user name. Cached data is stored in the HKLM\SECURITY\Cache registry key, which is accessible only to SYSTEM account. It is also important to mention that the lifetime of this cache on the computer is not limited.
Cached Credentials in Active Directory on Windows 10
Each entry in this key, HKLM\SECURITY\Cache, contains information about the user (username, profile path, home directory, etc.), domain (name, SID, last access time, etc.) and a hashed user password.
The CashedLogonsCount registry key is responsible for the caching capability: this parameter is located in the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. This parameter specifies the number of unique users whose credentials are stored locally.
By default, the value of the parameter is 10 and this means the following: the credentials are stored for the last 10 users logged on to the system, and when the eleventh user logs on to the computer, the cached credentials of the first user will be overwritten.
You can manage the value of CashedLogonsCount centrally, using Group Policy. To do this, create a new GPO (or open an existing one), go to the Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options section and find the Interactive logon: Number of previous logons to cache (in case domain controller is not available).
By default, this policy is not defined, respectively, on all computers the default value is used. To change it, you need to enable this policy and specify the required value in the range from 0 to 50.
A value of 0 (zero) means the caching of credentials is forbidden, respectively, at this value, logon to the local system is not possible when the domain controller is unavailable or computer disconnected from network.
In theory, if there is physical access to the computer, an attacker has the opportunity to use saved credentials, it is recommended to disable local caching for better security. An exception can be made for mobile devices (laptops, tablets, etc.) that used both from inside the corporate network and outside it. For such computers, the number of saved cached credentials can be set to 1. This allows only the last user to log on to the system.
 |