When a user from an Active Directory domain authenticates on a Windows computer (or server) that is a member of the domain, their credentials are cached locally, automatically. We are talking about Cached credentials. Thus, the user can connect to his session, on the same computer, when the domain controller is unreachable, the computer is not connected to the network, or when the computer is connected to a different network and that ‘he cannot contact the domain controller (telecommuting, hotel, train, etc.).
Caching of credentials comes in handy for laptops, as they are likely to be used under a variety of conditions where the user will need to access their session and data.
In this article, we will see how does credential caching work, how it is configured et what are the risks associated with this featureboth from the point of view of security what of use : caching has its limits, as we will see, but there are solutions.
II. How credential caching works
An entry is added to the credential cache when a user logs on to a Windows computer or Windows Server. It’s really the login action that powers the cache. If a user logs in with a new password, the cached entry will also be refreshed. The cache comes into play when the user wants to connect to his session without Windows being able to contact the Active Directory. This information is stored in the registry, without time limits.
Therefore, if the Active Directory domain is unreachable when a user attempts to log in, Windows checks whether the username and password entered on the system login page match credentials available in the local cache. If so, he accesses his session.
Since the cache makes it possible to authenticate while being disconnected from the Active Directory, one can imagine the following case. If a user connects to a computer integrated into the Active Directory domain, shuts down this computer, disconnects it from the network, and changes his password from a second computer, he will still be able to authenticate on the first computer. with their old password (provided they are using the computer in offline mode).
A. Where is the Windows ID cache stored?
By default, when you open a session of an Active Directory user on Windows, the operating system caches the identifiers: the user name and a hash of the password. This cache is stored directly in the Windows Registry within the following key:
Even with administrator rights you will not be able to see the “Cache” key in the Windows Registry. It’s understandable. Nevertheless, it is quite easy to access this information using PsExec which will allow us toopen the Windows Registry with System rights.
For information, here is the command to execute:
.\PsExec.exe -s -i -d regedit.exe
On my computer, whether it is Windows 10, Windows 11 or another version of Windows, I will be able to view the cache. Each value “NL$X” matches a cache entry and the hash of each entry uses the username as salt data. Deleting entries from this list purges the cache.
B. Windows Credential Cache: Credential Limit
Windows will not store an unlimited number of identifiers in its cache. In its default configuration, Windows will store in its cache the identifiers of 10 users. In any case, this has been the behavior since Windows 10 and Windows Server 2016, and it is true today with Windows 11 and Windows Server 2022. We can even say that Windows stores in its cache the identifiers of the last 10 users who have logged on to the machine in question.
This threshold of 10 is determined in a registry value named “CachedLogonsCount” and which is located at this location:
In the image below, from a Windows 10 machine in its default configuration, we can see that the limit is set to 10.
Even changing this value, you should also know that Windows cannot store more than 50 entries in its credential cache. Thus, it should be considered that the maximum value for this option is 50 identifiers, but personally I recommend that you rather review this value downwards (less than 10). I will return to this point later in this article.
C. Credential cache configuration by GPO
Whether from Active Directory Group Policy or Local Group Policy (gpedit.msc), there is a setting that allows administrators to configure credential caching without having to edit the registry directly. If we take the example of the GPO Active Directory, we must access this location:
Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité
Here it will be necessary to configure the parameter “Interactive logons: number of previous logons performed using cache (when no domain controller is available)“by checking the option”Set this policy setting” and then setting a threshold.
III. Windows Credential Caching Risks
A. Teleworking and the risk of being blocked
When a user is working remotely and connects to his session, he uses the identifier cache and accesses his environment. Then, in most cases, it will try to set up a VPN connection to connect to company resources: applications, files, etc… When VPN authentication is based on the Active Directory, you can find yourself blocked despite the presence of the identifier cache. Why ?
In fact, credential cache does not prevent user account from living in Active Directory. So there will come a day when the user will need to change their password in accordance with the company’s password policy. Except that the company’s VPN client won’t be able to offer him the change, and the user won’t be able to connect.
I took the example of the VPN, but this also applies if it needs to authenticate to a web application based on Active Directory authentication. These repeated attempts will be considered failed by the Active Directory and this could trigger a user account lockout. Let’s say this behavior depends on the password and account lockout policy, but in the case of a secure infrastructure, it will normally be the case.
Faced with this problem, what solution for users and the IT department? First, we can make surenotify users by email a few days before the password expires so that they anticipate and change the password. This will surely eliminate some of the problematic cases.
In addition, it is relevant to focus on a self-service password reset solution for Active Directory, which allows the user to be autonomous in changing their password, in a secure manner. This solution will allow the IT department to no longer have (or almost more, let’s be honests) these requests and these problems to be managed.
B. Windows Credential Cache Compromise
Credential caching is a security risk. An attacker who gains access to a computer with cached credentials may attempt various attacks, including a brute force attack on the password hash. Thus, it becomes possible to carry out a brute force attack without being detected by the Active Directory itself (which will not trigger the locking of the Active Directory account), because it targets the local cache, and not authenticates not directly from Active Directory.
If a user logs on to their assigned laptop, their credentials will be cached. Nextif a domain administrator logs on to the machine (normally, one should not connect directly with an administrator account of the domain, but it is very frequent), its identifiers will also be included in the cache. Therefore, an attacker who obtains physical access to this computer can perform a brute force on the cache of identifiers in order to hope to recover the Domain Administrator password ! The task will be more or less complicated depending on the strength of the password.
To reduce the risks, it is advisable to limit the cache of identifiers to “1”. Thus, if an administrator logs in, his credentials will be cached, and when the user recovers his computer and logs in again, it will overwrite the entry corresponding to the administrator’s credentials. We can apply this policy on laptops and go further on desktops by disabling cache (value at “0”): these are machines that are used only in the office, in “online” mode one can say. Be careful all the same, this means that in case of unavailability of the domain controller or the network, the user will not be able to open his session to work.
Nevertheless, there is a method that does not require performing a brute force attack on the cache, but consists of starting the computer in Windows system recovery mode and coming overwrite a cache entry with a new password, using Mimikatz (see this article). Thus, we change the cache password and we can authenticate on the machine with the username and the falsified password.
To protect accounts with elevated privileges, you shouldadd the accounts to the “Protected Users” group of the Active Directory to enable certain protections, including disabling credential caching for members of this group. You can read this tutorial about it: Active Directory and Protected Users.
After reading this article, you know more about how the credential cache works in Windows, and you also know the associated issues, whether in terms of security or functionally speaking.
#Windows #Active #Directory #credential #cache