Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
A co-worker of mine had a case with the following description:
We've set the CachedLogonsCount registry value to 1 on our workstations because we want to limit the number of cached user logons in the LSA cache on the system.However, this seems to have the side-effect of sometimes making it impossible for the user to log on to the laptop while offline!?
The LSA cache contains entries for security entities that have logged on to the machine while it was online and had access to a Domain Controller - this includes service accounts, the computer account, etc.
The registry value CachedLogonsCount controls how many such entries are cached - the defaults will be 10 or 25 depending on OS or SP level of the system with a maximum of 50.If a logon occurs (for example a service is restarted) and the number of cached entries is "full" it means the oldest entry will be pushed out and the newest appended to the end of the list.I.e. if you set a value of 1 for CachedLogonsCount then your list of 1 entries will continously be overwritten by the last entry that is being cached.
In general you'll see one security principal per each slot in the LSA Cache but there are exceptions to this (for example, logging on the same user with a smartcard or password will create two separate entries).
Setting the value of CachedLogonsCount to 1 is effectively only caching the last logon entry - if this happens to be something other than the user that interactively logged on then that user will no longer be present in the LSA cache and won't be able to log on while offline.
What was happening here is fully by design; setting CachedLogonsCount to 1 is not recommended if you want users to be able to log on offline as it means the single LSA Cache entry for the user that logged on will automatically be overwritten the next time anything else on the system writes an entry to the LSA Cache.
In short; the LSA cache is used by various security principals on the system - not just the users that physically log on to the system with a user account.
If you run Procmon and configure a filter to include only paths beginning with HKLM\Security\Cache in the capture and drop everything else (Filter/Drop filtered events) then it will show a SetReg operation each time a cache entry is written to.The slots are numbered N1$, N2$, N3$, etc.You can also set Procmon to log during boot (Options/Enable Boot Logging) - with this filter set you should see what else is touching the LS cache at boot and logon.You should also get a LsaSrv 45058 event in the System log whenever an older entry has been removed from the LS cache and what account it was for (see http://support.microsoft.com/kb/2555663).
Cached domain logon informationhttp://support.microsoft.com/kb/172931The default value of the cachedlogonscount registry entry has changed from 10 to 25 in Windows Server 2008http://support.microsoft.com/kb/911605
A domain controller for your domain could not be contacted. You have been logged on using cached account information. http://support.microsoft.com/kb/172931
"Interactive Logon: Number of Previous Logons to Cache" Help Topic Contains Incorrect Informationhttp://support.microsoft.com/kb/825805/en-us
Cached credentials security in Windows Server 2003, in Windows XP, and in Windows 2000http://support.microsoft.com/kb/913485/en-usCached User logon fails when LSASRV event 45058 indicates FIFO deletion of cached credentialhttp://support.microsoft.com/kb/2555663
Where can I find the extended list of exactly what security principals that is using the LSA cache?
(in order to configure the registry value CachedLogonsCount (and understand the best security design)
There is currently no public utility that I'm aware of that will list the contents of the LS cache.
If you run Procmon and configure a path filter to include only paths beginning HKLM\Security\Cache in the capture and drop everything else then it will show a SetReg operation each time a new entry is written.
You can also set Procmon to log during boot (Options/Enable Boot Logging) - with this filter set you should see what else is touching the LS cache.
You will also get a Netlogon 45058 event whenever an older entry has been removed from the LS cache and what account it was (see support.microsoft.com/.../2555663).