Cached logons - generic questions

Two questions re domain cached credentials:
1. What is the default behavoiur when "Interactive logon: Number of previous logons to cache (in case domain controller is not available)" option is set to Not Defined (set under Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options)
   -> is it going to allow to log on with cached credentials or not? I google'ed information that by default it will allow to log on 10 user who succesfully logged on to the machine when DC was still available

2. After what period of time cached credential expires, in other words what is the maximum number of days when users are allowed to logon with cached credentials without computer being able to contact domain controler


Who is Participating?
Brian PierceConnect With a Mentor PhotographerCommented:
The default is to cache the credentials for 10 users - obvisously those users mush have previosuly logged on to the domain while the domain controller was available in order that the credentials can be cached in the first place.

There is no time limit for tue use of cached credentials, they remain active indefinately.
PberConnect With a Mentor Solutions ArchitectCommented:
The number is set to cache the users.  So 0 is no caching - you must be on the network.  1 is essentially the last person who logged onto the machine before it went offline.  Any more than that is the last users that have sequentially logged onto that box.

How long the cached credentials work seems a little questionable.  This isn't documented very well.  From my experience, they can logon until their domain password expires.  Then they have to connect the domain where they will be allowed to change the password and they should be allowed to use cached until their password expires.
Chris DentPowerShell DeveloperCommented:

That setting has nothing to do with the number of users cached.

It basically states that the User is allows to log on with a cached credential for the number of times specified there (up to 50, anything above is ignored, 0 disables caching) before an active session with the domain is required.

See this little KB:

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Chris DentPowerShell DeveloperCommented:

Ignore me, I can't read. Pber and KCTS are correct.

PberSolutions ArchitectCommented:
Hey guys,

I figured the cached time out was indefinite myself until we had some overseas users (users that were off the domain for a long time) that all of a sudden were prevented from logging in.  We had to create local accounts on their machine to help mitigate that.  The only thing we can attribute it to is the password expiry.  If they go back on the domain, they can use the cached logons for a while and then it stops working again.

So 50 is the limit?

Chris DentPowerShell DeveloperCommented:

Expiration and such isn't passed with the cached credential as far as I know, so the logon process (GINA) shouldn't block access because of that.

Don't mind my previous post, a day of digging into PowerShell has played havoc with my head. 50 is simply the number of credentials that it will cache as you originally pointed out :)

krzywisAuthor Commented:
You have confirmed my suspicions.... Unfortunately this is not very well documented, and I cannot test this at the moment.
We seem to be having similar problem to the one described by Pber.
There are workstations on remote site, where server infrastructure is not supported by us. They only have stub zone for our domain on the DNS servers on that site(which also are DC for their domain), plus their is two way trust relationship between two domains.
Mentioned stub zone is replicated between all DCs in their AD. The problem is with joining workstation to our domain. There is no problem however with machines that are already on our domain, they can logon fine... We excluded name resolution issues, so now we think that users may be logging on with cached credentials (could not find any trace of any users accounts nor computer accounts logging on from that site in DC logs).
I know it may seem a strange set up, but maybe one of you came across similar problem.

krzywisAuthor Commented:
Apart from mentioned user account expirery date, there is need for the machine account to have their password reset... But I am guessing here that it would not stop them from logging on with cached credentials?

Btw, I have increased number of points
poseidoncanuckConnect With a Mentor Commented:
KCTS is right that the cached creds are maintained indefinitely.  Everyone's got it mostly right about what "10" represents:
- if users are only using passwords to logon, then the last 10 domain users to logon to the PC will have their credentials cached
- if some or all users are using smart cards to logon, then the a separate cached credential will be stored for the smartcard logon "version" of that user's account
- if any user uses their password and their smart card to logon (depending on their whims, the day or availability of the card & reader), then it's possible for the user to consume two of the ten cached credentials - one for their cached password verifier, and the other for their cached smart card verifier.
- once the maximum number of cached credentials is reached (10 by default), then new cached credentials will overwrite the "oldest" existing cached credential, FIFO.

If you want to find out whether a user logged on to a DC or were authenticated using cached credentials, then you should try the following:
- ask the user to start a CMD prompt right after logon, and type "set l".  That'll show them their current LOGONSERVER variable, and if it names the local PC rather than a DC, their logon wasn't validated by a DC.
- fire up the kerbtray.exe Resource Kit tool on the user's PC and see if the user has any TGTs from their home domain.  If they do, check when the TGT was issued (i.e. right around the time they logged on, or sometime noticeably thereafter).
- Enable the "audit logon events" setting in local Security Policy (SECPOL.MSC, Security Settings > Local Policies > Audit Policy   -- or try Group Policy if these PCs are able to retrieve Group Policy from a DC) on the client PC (don't bother with the DCs in this case).  Look for Event ID 540, where the User = the username.  If the "Logon GUID" in the Description field is blank, then the user logged on with cached domain credentials.  If the "Logon GUID" is populated, then the user almost certainly was authenticated by a DC.
krzywisAuthor Commented:
Thanks for your input, especially for info about kerbtray.exe and enabling logon events auditing...Although I found out that this is being logged under EVENT ID 528.
I do not think that set command works as you described (at least not in my case) in regards to LOGONSERVER variable being set to local machine name if it is being logged in with cached credentials.

I have not found out what is actually happening with our users on remote site, as I did not get chance to go there, but I am sure that with all your tips I will be able to resolve the problem.
This is why I do not want to keep this thread open, so I will share the points.
 I will post the outcome later on...

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.