Cached Credentials Expiring

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have seen this question asked many times but without a verifiable answer.

There are numerous LAPTOP users who logon with cached credentials
successfully day after day. Then one day the users get an error advising they
can not be logged on because there are no DCs available. If we log them on
attached to the network their credentials are refreshed and they can again
logon while disconnected from the network using the SAME cahed credentials as
before the error.

One thing we are fairly sure of is that it has nothing to do with the
"interactive Lgon: number of previous logons to cache ...." policy. ( i am on
the # of sets of credentials side of this fence from what I have seen (as
apposed to the number of times a credential set can be used))

for background these user accounts are used to auto logon to a kiosk
environment for training purposes. Once logged on there is often a VPN
connection established for application demonstrations and all works fine
until this error condition occurrs.

At this stage I am starting to wonder if part of the credentials caching
process is tied to the computer's workstation account password and if this is
changed (30 day expiry ) by the computer while connected through VPN the
computer is then unable to read previously cached credentials, hence the
requirement to refresh them.

Has anyone found a verifiable solution\workaround to this problem?
Is it possible that the workstation password (or some other event) is
affecting the computer's ability to read the cached credentials?
Any other thoughts?

Thanks in advance for replies.
 
ffoeg said:
I have seen this question asked many times but without a verifiable answer.

There are numerous LAPTOP users who logon with cached credentials
successfully day after day. Then one day the users get an error advising
they
can not be logged on because there are no DCs available. If we log them on
attached to the network their credentials are refreshed and they can again
logon while disconnected from the network using the SAME cahed credentials
as
before the error.

One thing we are fairly sure of is that it has nothing to do with the
"interactive Lgon: number of previous logons to cache ...." policy. ( i am
on
the # of sets of credentials side of this fence from what I have seen (as
apposed to the number of times a credential set can be used))

for background these user accounts are used to auto logon to a kiosk
environment for training purposes. Once logged on there is often a VPN
connection established for application demonstrations and all works fine
until this error condition occurrs.

At this stage I am starting to wonder if part of the credentials caching
process is tied to the computer's workstation account password and if this
is
changed (30 day expiry ) by the computer while connected through VPN the
computer is then unable to read previously cached credentials, hence the
requirement to refresh them.

Has anyone found a verifiable solution\workaround to this problem?
Is it possible that the workstation password (or some other event) is
affecting the computer's ability to read the cached credentials?
Any other thoughts?

Thanks in advance for replies.
Click to expand...

I don't think there is an expiry. Usually this is caused by the user logging
on locally. Once the user logs on locally the cached credentials are gone
until they are physically conected to the domain again. As far as I know
there is no way around this.

Kerry
 
thanks kerry but the users do not log on locally. As stated the laptops are
auto logged on "kiosk" fashion to the domain account.
 
ffoeg said:
thanks kerry but the users do not log on locally. As stated the laptops
are
auto logged on "kiosk" fashion to the domain account.
Click to expand...

Your sure no one has found a way around this, safe mode, booting from CD,
etc.?

Kerry
 
It's always possible though I think unlikely.
There are ~50 of these training laptops deployed and so far ~6 have shown
the problem They have been out just on a month now). There is only one local
account that can logon to the machines which is the local admin account with
changed name and theoretically the users do not know these passwords.
Additionally the 6 machines that have now shown the problem have been in
different parts of the country in the custody of different people
 
ffoeg said:
It's always possible though I think unlikely.
There are ~50 of these training laptops deployed and so far ~6 have shown
the problem They have been out just on a month now). There is only one
local
account that can logon to the machines which is the local admin account
with
changed name and theoretically the users do not know these passwords.
Additionally the 6 machines that have now shown the problem have been in
different parts of the country in the custody of different people
Click to expand...

Maybe try reposting this question in
microsoft.public.windows.server.general. I've never seen it happen except
when users logon locally. My experience with Windows Server is limited to
smaller networks with not too many roaming users. I'm sure someone over
there will have experienced the problem before.

Kerry
 
Back
Top