It occurred to me that my post from last week was a bit lacking in the technical detail.
As a recap, the issue was regarding the scenario of:
-Locked a computer when well connected (DC reachable across the network)
-Unlocked computer when still well connected and saw the Kerberos cache flushed
-Some time after unlocking the network connectivity to the DC is lost. No accessing of a mapped drive takes place between unlocking and network loss...
-Tried to access a drive mapped at logon (prior to lock/unlock) and were unable to with an access denied error
So, how did we determine that Kerberos tickets were cached? There are several ways, but we used one primarily.
The one that was most helpful was KLIST.EXE. This tool is standard fare for Kerberos implementations of all flavors, but it's so important a tool that it can't go without a hefty mention. Even in the most convoluted and complicated Kerberos scenarios, with protocol transition, constrained delegation and you-name-it involved, KLIST is still your best tool.
The Help for that executable goes over this, but KLIST can display the TGT and service tickets for your session. (Kerbtray.exe is a GUI tool that does the same thing (runs in the system tray) but doesn't dump to a text file.) The syntax we use is:
KLIST tgt >tgt.txt
Klist tickets >tickets.txt
Anyway, in the above scenario, we did KLIST commands to export Kerberos cache details to a text file and did this before unlock, after unlock and after loss of network connectivity following unlock.
Pertinent details include the End Time (which by default policy will be 10 hours after initial issuance. This is a good technique for determining if the ticket is the same ticket when you check it later.
Of course the presence or absence of a ticket to the file server they had a mapped drive to was important here. This appeared as a cifs/servername.domain.local service ticket in the cache. Prior to locking the computer that ticket was present, but following unlock it was not there.
An additional technique (which we did not use in this scenario) would be to enable Kerberos debug logging. There are two methods for this: to the system event log (simply increases the verbosity and number of the events which appear), and the other is to a debug log (lsass.log).
I may differ from a lot of folks in saying that the two Kerberos logging techniques (increasing verbosity and frequency of events in system event log, logging Kerberos debug entries to the lsass.log) are not an early step for troubleshooting. I'll go further and say that you probably won't get a lot of value of doing them typically. To be frank, the events are scary sounding and perhaps not always directly applicable to the problem, and the log is cryptic to decipher at best.
Well, I've gotten that off my chest. Hopefully, this helps you all out there as you run into these issues.
One more thing: please tell you friends and neighbors that are interested in this sort of thing. I'd like to see the readership increase. And let me know if you are looking for any particular topic (in the Microsoft directory services world that is) to be discussed.
Talk to you all soon...
Personally, I'd like it if you discussed the AD delegation whitepaper. I have a bunch of things I noticed which should probably be considered for an errata.
We can definetly talk about delegation. Is there a specific delegation scenario you have in mind, or specific questions I can answer?
I will email you offline as I have a few questions. May be you could do a post on the topic based on the questions?
Any way to revert that flushing of tickets?
We are in process of consolidating DCs from some branch offices with 50 to 100 users to central hub site. So what do you suggest, how do we handle network link outage resulting in lost DC connectivity.