Windows Forum

Ask something
Discussion Locked

W2K Pro & apparent cache credential prob

0 helpful
6 replies

by ed.bentley

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
Users no longer able to log in using credentials. The error message was, "UNABLE TO LOG YOU ON BECAUSE DOMAIN xxx IS NOT AVAILABLE". The problem is that we are unsure as to why these credentials all seem to be having issues at the same time. Multiple users are not using these machines. Credential setting is set to a value of 10. Any suggestions as to what could cause this would be appreciated. BTW, we even have MS stumpped at this point!

6 replies

by sgt_shultz

you have ruled out connectivity problems to the domain controller? you can ping the domain controller? tell us more. can you logon locally to the domain controller. can you see other pc's from domain controller? can anyone logon or all are not able? (administrator?) when did this crop up? are you the admin? how is your domain configured?

by ed.bentley

I apologize for not being more clear in my initial message. The users are "road warriors" trying to login in locally using cached credentials, who may not have been attached to the domain for several weeks. Microsoft states that cached credentials shouldn't expire (although I believe they do) and that this shouldn't be happening unless their profile has somehow become corrupt. We're trying to dertermine if we have users (gloablly in serveral domains) all of the sudden corrupting their profiles at the same time, and if so, why? Or if they're credential;s a truly expiring and if so, why?

by cg it

somewhere in the dim recesses of my alzheimers ridden mind I remember reading something about or about a similar problem. humm might have been a Windows & .Net Mag article or something on a Windows Newsgroup forum post about Cached credentials and an error where it gets dumped. Have to do some reading.

by cg it

I knew I saw something on keberos V5 V4 cached credentials. Heres what was said: http://www.httpsniffer.com/http/1506.htm

15.6 Authentication Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials. This is a significant defect that requires further extensions to HTTP. Circumstances under which credential caching can interfere with the application's security model include but are not limited to:

- Clients which have been idle for an extended period following
which the server might wish to cause the client to reprompt the
user for credentials.

- Applications which include a session termination indication
(such as a `logout' or `commit' button on a page) after which
the server side of the application `knows' that there is no
further reason for the client to retain the credentials.

This is currently under separate study. There are a number of work- arounds to parts of this problem, and we encourage the use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.

here's another link: http://seclists.org/lists/fulldisclosure/2003/Dec/0794.html that a hacker put up about accessing cached credentials on local machines. makes you wonder.

by ed.bentley

After many long hours spen with MS and NAI, here's what we found out. In our environment we have a McAfee ID (normal user ID) login every four hours to look for updated dat or engine files. We use this ID when machines are connected to the nework, but not logged in so that the machines are kept secure without the reliance on the end user being logged in. This ID for whatever reason (we never found out what was causing this) was eating up a credential every time it logged in and would eventually overwrite the users valid credential (similar to an issue MS reported with Smart Cards). NAI has taken on ownership of fixing the problem but has not provided a fix as of yet.

This discussion is closed to new replies.