Kerberos is one of the more complicated technologies we deal with at Microsoft support. It is complex and can be utilized in highly customized ways between clients and servers which adds to the difficulty in troubleshooting. Application specific implementations are commonly unique in ways which aren’t documented well. An additional part which makes troubleshooting Kerberos so very difficult though is the fact that it typically just works without problems. So no ‘under the hood’ knowledge is needed in the first place.
As a result there are not a large number of troubleshooting tools for Kerberos. However we see many application specific scenarios where we need to understand where Kerberos tickets are cached and details about those tickets.
There is the additional scenario of the ‘former employee’ and cached tickets. The hypothetical scenario goes like this: Bob, who has domain administrator privileges (DA) or has access to sensitive data on a server, has his last day at the job. Disabling his user account in Active Directory is the first thing which is done by his former peers.
Keep in mind how Kerberos tickets are exchanged and cached:
So each identity-whether it is a computer, user or service- has its own Kerberos cache. Klist.exe, a tool which is included in the operating system for versions Windows 2008/Vista and later, allows users to view Kerberos tickets for any session if you know the LogonId of that user.
Getting back to our Bob-has-left-the-company scenario…Of course, new ticket requests would fail since the user account is now disabled. But what about the tickets issued to that user which are in a current interactive or remote interactive logon session? And what about tickets which are cached for that user on application servers? Since they renew up to a week wouldn’t there be some risk in having those tickets there?
Most likely there would be minimal risk since most network connections would require a new user logon session but why tolerate even minimal risk?
One solution would be to reboot the computers in the environment. This would clear the Kerberos tickets from all session caches. However, rebooting a server is not always allowed in an impromptu way and in some cases the server needs to be available 24x7.
So we are left with a quick and easy way to list the cached tickets for all users on a computer. We are also left with a quick way to purge all cached tickets from a server while keeping the server available to provide services.
To address those needs I’ve written two PowerShell scripts. You can get the scripts from the links below:
List All Cached Kerberos Tickets (GetKerbTix.ps1)
Purge All Kerberos Tickets (PurgeAllKerbTickets.ps1)http://gallery.technet.microsoft.com/Purge-All-Kerberos-Tickets-13e5abfb
The scripts automate commands which would be sent to Klist.exe (the inbox Windows Kerberos ticket utility). A session ID (in hexadecimal) is needed by Klist.exe in order to view or purge tickets which are for sessions other than the user’s (your) current session. The Klist.exe which is included Windows 8/Server 2012 and later will provide a list of those sessions-which is awesome-however the earlier version did not give a session list though it will allow you to specify sessions to view or purge. To workaround this and make the script work well on Vista/Server 2008/Windows 7/Server 2008 R2 the scripts use the WMI class win32_LogonSession to obtain all logon session IDs to pass to Klist.exe.
It can be a bit of an eye opener to view the cached tickets on a computer which has been running for a while in an environment so it’s possible this may lead to some questions about access. Keep in mind that the GetKerbTix.ps1 script is not intended in any way to replace auditing. It cannot replace auditing but may be useful in troubleshooting problems, and viewing what cached user tickets are available.
Hopefully this helps folks understand what tickets are present on a server or client and purge them when they need to.