Freigeben über

Viewing and Purging Cached Kerberos Tickets

  • Artikel

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:

  • A client computer attempting to access a resource across the network (for example, access to a file share)
  • Negotiates Kerberos as the authentication which be used for the session with the server
  • The clients gets a Kerberos ticket from a domain controller
  • The client then passes that ticket to the network resource it needs access to.
  • The network resource (server, really) decrypts the ticket and then bases authorization decisions based on the user token.
  • Note: The ticket is cached on the client and the recipient server.

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)

https://gallery.technet.microsoft.com/List-All-Cached-Kerberos-5ba41829

Purge All Kerberos Tickets (PurgeAllKerbTickets.ps1)
https://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.

More info

  • The scripts require administrator privileges to run
  • The scripts will display/purge Kerberos ticket granting tickets as well as service tickets.
  • The display script (GetKerbTix.ps1) will give session information such as username, type of logon session, and LogonID if available.
  • The session 0x3e7 is the local system, also known as the computer account, session.
  • The session 0x3e4 is the network service session, a less privileged session of the local system identity.
  • The scripts will run on Windows Server 2008/Vista and later.
  • The script (GetKerbTix.ps1) displays all ticket information to the PowerShell console.
  • The display script (GetKerbTix.ps1) also exports the results to a file named %computername%_CachedKerberosTickets.txt. The file is located in the c:\windows\temp directory by default.

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.

Comments

  • Anonymous
    July 16, 2015
    Very nice article Tim, This helped me understand and solve a major issue with one of the production servers.
  • Anonymous
    January 12, 2017
    Thank you Tim.. well explained.