Disable Cached Credentials in Windows

If the Domain Controller is not available when users log in, two things can happen: if a was previously able to log in successfully at the current machine, Windows will let him/her in. If the user is new to the workstation and hasn’t previously authenticated with that machine, login is denied.

This has to do with “Cached Credentials”. Whenever you log on successfully to the domain on a computer, Windows stores your credentials. Well, the “credentials” actually do not contain username and password but an encrypted version of your password. It is a two-times computed, salted MD4 hash value that is used. By default, 10 user passwords are stored in Windows in that way.

There are two reasons why you would want to disable Cached Credentials in Windows:

(a) You want your users to always authenticate at the domain and don’t want them to work at the workstations if Domain Controllers are unavailable (due to the fact that Group Policy can’t be updated: http://technet2.microsoft.com/windowsserver/en/library/0bead5a1-afba-4c58-984b-11881be5348e1033.mspx?mfr=true)

(b) You have security concerns because you are afraid that the hash function might be “hacked” at a machine so that domain users and passwords could be re-computed and used to get further access on resources.

For (a), you can use the following Group Policy:

CompConf\Windows Setting\Local Policy\Security Options:
“Interactive Logon: Number of previous logons to cache (in case domain controller is not available)”
– the default should be 10 – just set it to 0 and users need to authenticate at the domain to log in.

Be sure to use this with caution. It is not a good idea to apply this policy to mobile users since they’ll get locked out, if they have no access to a Domain Controller on the road.

For (b), well, as previously stated, the password is hashed and salted with your username. It is pretty hard to crack, if you can access it. To access it, you would need to hack a machine and gain “Local System” credentials in order to get the hash, since it’s stored in the secure “security hive” of the system. (And what happens if a user had “LocalSystem” credentials on a machine? He could do literally *everything* with the machine – e.g. install a rootkit and get the passwords in a much easier way).

It is really unlikely that “Bob the bad guy” can gain access to the credentials in the hash. If you really want to mitigate the risk, implement a strong Password Policy and – more important than that – teach your users to use strong and long passwords.

If you still have concerns about “Cached Credentials” you’re of course free to use the above mentioned Group Policy as well. But keep in mind that setting the value to 0 will result in a lockout for your users, if they have no Domain Controller available. A bad thing for mobile users on the road…

1 Comment so far

  1. Frank on October 26th, 2010

    “To access it, you would need to hack a machine and gain “Local System” credentials in order to get the hash, since it’s stored in the secure “security hive” of the system. ”

    Just Remember: Physical Access to Machine = I own it. I don’t need Windows to get to your password. There are many password revealing CD’s that can be booted from to allow a person to read passwords from the hash, without ever booting windows.