First published on CloudBlogs on Aug, 16 2006
A while back we had a customer contact us that was seeing something with authentication that they were struggling with understanding.
They had a lot of small, remote sites where it was impractical to have a local domain controller. So each site relied on WAN network connectivity to receive domain authentication (aka communicate with domain controllers).
Many of you have already guessed that the problem arose when the WAN links experienced intermittent problems. End result was an occasional loss of connectivity from the domain clients to the domain controllers.
They were actually not interested in focusing on the network links themselves, but rather the behavior of the clients in these little holidays the network connections were taking.
It seems that user would logon in the morning while the network link would be up and see that their mapped drives (to local resources) were mapped successfully. At some point in the day the user would lock their machine (or allow a screen saver interval to occur and do that for them) and go away (lunch, whatever). When they came back from lunch they would unlock the computer using their credentials.
At this point they would go about doing their various daily duties. After a while, the network link to the domain controllers would take its little vacation.
The problem arose in that if they had not accessed the mapped drive(s) in the interval between unlocking the computer and the loss of connectivity to the DCs then they would get an access denied when that was attempted.
In other words, if they hadn’t double clicked the mapped drive after unlocking the computer and before the network connectivity went away then they would not get access to it at all (error 5). Again, this was when trying to access a local share they were mapped to.
Doesn't seem to make sense on the face of it. You've successfully mapped this resource, it's online and reachable across the local area network. Why have access "taken away"?
To make a long story short there are a few things which come into play here:
-When you unlock an existing session and your computer is "well-connected" (a DC is responsive across the network) all Kerberos tickets are flushed and you request a new TGT and session ticket.
-Kerberos is an on demand authentication service; in other words access must be attempted before authentication can be requested. Tickets are only requested and received when a (usually manually) initiated request.
-No access had been attempted by the user while the computer was still connected well to the DCs. Granted, an icon was still appearing in the shell for the mapped drive, but this is really only a placeholder in the user interface.
All of that is behavior we have designed into the product.
What are they advantages to this? One of the ideas behind Kerberos is a planned obsolescence for the tickets you have cached and a need for renewal at some point (default 10 hours). Think of it like changing keys to a room every once in a while. Sure, we're leaving the key locked on our desk, and that's secure, but we're also swapping those keys (forcibly so the old one won't work) periodically so that if a bad guy gets one, he won't have use of it for long.
****
In an unrelated note, I saw a fellow MS blog post that was hilarious. Maybe the Millennium Edition reference was what did it for me since I worked on that pre-release (this is the point where I usually say "its not my fault") but maybe you all will appreciate it too:
http://blogs.technet.com/windowsserver/archive/2006/07/06/Other_Rejected_Longhorn_Server_Names....
