Stopping cached logins with cached credentials ?

Following up on the previous articles about cached logons and the trouble they can cause here and here – a further note is in order on what you can do about it!!

Windows operating systems, including 2000, XP, and 2003, cache the logon credentials for the last 10 users. This allows for the user to “logon” at a later date even if the domain controller cannot be accessed at the time of logon. While this does represent a fault tolerance to DC downtime and network congestion, it is not great security.

When users are logged on using cached credentials, they are using out-of-date security credentials. New group memberships, changes to GPOs, changes to user rights, etc. are not applied. This is a threat to any truly secure environment and you should be aware of it.

Registry approach

The default value for the cached logons count is 10 (maybe increased to 25). Our job is to edit this REG_SZ value from 10 to zero. Before you go any further, check the path; there are at least four instances of ‘Winlogon’ in the registry.

Let us assume that you have reached: HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionwinlogon. The next task is to double-click CachedLogonsCount. If this setting is not present, no worries, just right-click in the right hand pane, and create a new REG_SZ called CachedLogonsCount.

For increased security, double-click and change the value for CachedLogonsCount to 0 (zero) to prevent cached logons.

Alternatively, to give a laptop the maximum cached logons when it is away from its domain controller, set the value = 50 (maximum number)

Group policy approach

To disable cached credentials, simply alter the appropriate GPOs so that every system in the environment has the Computer Configuration, Windows Setting, Local Policy, Security Options control of “Interactive Logon: Number of previous logons to cache (in case domain controller is not available)” to 0 logons (from the default of 10).

Another important issue in regards to cached logons is unlocking a workstation. A workstation can become locked if the screen saver requires the user’s password to resume to the desktop or if the Lock Computer command from the Task Manager’s Shutdown menu or the logoff dialog box is used. In either case, the default is for the local system to verify the user’s password based upon cached credentials. Even if the system is configured not to retain cached credentials, the currently logged on user’s credentials are cached in active memory because the user is logged onto the workstation. Just as with the issue of domain logon via cached credentials, if a workstation is unlocked using cached credentials, a domain controller is not consulted.

To force the workstation to consult a domain controller when unlocking, set the Computer Configuration, Windows Setting, Local Policy, Security Options control of “Interactive Logon: Require Domain Controller authentication to unlock workstation” to Enabled.

It should be obvious that while these settings are important for domain users in general, they are especially important for administrative level user accounts. In a truly secure environment, any time a logon event occurs (including unlocking a workstation) you want a domain controller to be contacted. Relying upon cached credentials may be more efficient, but it is not more secure.

Some further notes :

When you connect to a resource on another machine and supply a username/password, you are given the option to “save password”. So where are these details held – lets take a look

The process is slightly different depending on whether or not the logged on user has local admin rights.

Viewing cached credentials – with Admin rights

Open the User Accounts control panel applet.
Select the Advanced tab, and click on Manage Passwords

Viewing cached credentials – without Admin rights

Open the User Accounts control panel applet.
When you are prompted to type in the credentials of an administrator, simply click on the manage your passwords link at the bottom of the dialog box instead.

In either case, you will be presented with the a box that allows you to add, remove or modify cached credentials.

One of the issues that I’ve come across at various times in the past is that you can only authenticate to a machine with a single set of credentials. In other words, if you map a drive to servershare1 as UserA, then you cannot map a drive to servershare2 as UserB. You need to use a single user account that has access to both shares.

I found an example of exactly this as below – which simply illustrates the problem another user had

“A while back we needed users to access resources on a server in an untrusted domain (in other words, there was no trust relationship between the two domains/forests). Because the server was in and untrusted domain, users were prompted for a username and password when they tried to access an application stored on the server. We created a generic account in the destination domain so that users could connect to the server and access the application. However, the server was also a file server, and some users needed to access another share with a specific user account that the generic account didn’t have access to. The problem was that the users had already connected to the server with the generic account and had saved the password. This is where being able to remove the saved credentials came in handy. Once we removed the cached credentials of the generic account, we could then have users connect to the server with the specific account and access both the application and the data share.”