Kerberos 1.01

Kerberos was originally designed at the Massachusetts Institute of Technology (MIT) and is a Network Service Authentication Protocol. It was named after Cerberus the three headed guard dog of hades in greek mythology.  This is quite apt as Kerberos creates a realm with 3 key components, These are Kerberised Clients, the kerberised services and the Key Distribution Center or KDC. Apple have been using Heimdal's  implementation of Kerberos Version 5 since macOS .7.

Why use Kerberos?

Well Kerberos provides secure network service authentication which unlike other authentication methods works without the need of transporting your password across the network. Kerberos works on the the basis of Tickets being sent between the 3 components. Passwords are stored in a central Database which helps Administrators to manage multiple Users. 

Kerberos also helps overcome the issue in which Users have access to multiple services with potentially multiple usernames and passwords. Kerberos allows users to gain access to all their services with a single password which only needs to be input once. This is what is commonly referred to as single sign on.

Kerberos is a Background process which most users won't be aware of. So how does it work?

Ticket Granting Ticket

Let's start from the beginning with what seems like a simple Login. By Authenticating as a user for login this prompts a packet to transport to the KDC. This packet contains the users name but does not contain any password. 

This packet is a request for a Ticket Granting Ticket or TGT. This TGT is used to gain access to all of the users kerberised services. Tickets are timestamped and therefore do expire as part of the security in kerberos.

The request sent by the client will be checked by the KDC against the Password Database where it will try to match with a valid User.  Once matched the KDC will produce the Ticket Granting Ticket.  The TGT contains the Users Name, the Name of the KDC, the Clients IP and  a Session Key.  The session Key is a time sensitive encryption key created just for this session by the KDC. The encryption key changes periodically so that if it is compromised and decrypted it can't be used on packets from other sessions. The TGT is then encrypted with the KDC's own private key. Only the KDC has this key so the Client never sees the contents on the TGT. 

The KDC then sends a packet containing both the TGT and the Session Key. This packet is then Encrypted by the Users Private Key and sent back to the Client. The Client then decrypts the packet using the Users own Private key from login to gain access to the contents of the Packet.

But, what is the point of a TGT when the client is unable to view its contents. Well it's more what they do with the TGT than what it contains.

The TGT is used in Gaining Service Tickets

The client starts by creating an Authenticator which contains the users name, Client IP and Time. It then encrypts the Authenticator with the Session Key and places this in a new packet along with the TGT and the name of the service required. The packet is transported to the KDC where it can decrypt the TGT with it's own Private key. Knowing that the TGT can't have been tampered with as it has not been opened, it can use the contents to access and check the information within the Authenticator.  

Once the KDC has confirmed the Users identity it can create a Service ticket for the requested service. The service ticket is valid for just this user and the requested service for a set period of time.  The Service Ticket contains the User Name, Requested Service, Client's IP and a new session key. The KDC then encrypts the Service Ticket with the Services Private Key. Similarly to the TGT the Client does not have a copy of the Services Private Key and will not be able to access the contents of the Service Ticket.

The KDC then sends an encrypted packet using the first session key containing the Service Ticket and a copy of the new Session Key back to the client. The client can then decrypt the packet.

Accessing Services

Now the Client has the service ticket all that is left is to gain access to the Service. The client creates a new authenticator and encrypts it with the new session key received from the KDC. It then sends this authenticator to the Kerberised service along with the service ticket received from the KDC.

Using the Services Private Key the Kerberised Server can decrypt the Service ticket and knowing it can't have been tampered with since being created by the KDC it can use the session key contained in the Service ticket to decrypt the Authenticator and confirm the identity of the client using information from the Service ticket. 

Now the identity of the user has been confirmed a confirmation is sent back to the client and the user can access their service.

Kerberos Security 

Now we know how kerberos works we can start to understand the security behind it. To add to the security of not transferring passwords across the network, kerberos servers keep a log of the packets that are received and once accepted cannot be used again.

Also as we've seen kerberos uses timestamped tickets which means that even if a ticket is compromised it is very unlikely that it can be used to gain access to your data. These timestamps become invalid if they are more than 5 minutes out. This means that all Servers and Client devices need to be set to same time. This is usually achieved by using the same Network Time Server for all devices. 

Unfortunately sometimes the security features of Kerberos can be its downfall especially when dealing with expired tickets. Most of the time Expired tickets are replaced but on the odd occasion it may be necessary that you need to manually view, add and remove these tickets.

Troubleshooting Kerberos - Ticket Viewer

We can do this a few ways. Firstly we can use the Ticket Viewer Application this can be found within Keychain access's Menu bar or you can navigate to it through the finder in /System/Library/CoreServices/Ticket Viewer.

Once Open Ticket viewer gives you access to manage you Ticket Granting Tickets as well as view all tickets for each kerberos user. We can use Ticket Viewer to create a new TGT for a User, to do this you will need to authenticate as a User which is known by the KDC. 

We can also use Ticket Viewer to remove a Users TGT. 

Lastly, there is also an option to view diagnostic information about an identity and view all that users tickets. To get this information we can use the Command + I key combination or go through the Ticket option on the Application Menu bar.

Troubleshooting Kerberos - Terminal

We can also troubleshoot kerberos tickets from within the command line using the Terminal Application found within Applications/Utilities. 

We can use the klist command to view the current Users Ticket Granting and Service tickets. The klist command has a few useful options. klist -l will list all currently cached kerberos Users and the Expiry of their TGT. The klist -A command will allow you to see all those same cached Users but this time view all of their current ticket information.

The kinit command along with valid user Identity and authentication allows you to generate a TGT from the KDC. Once run the command gives no verification that it has completed and will just give you a command prompt. It is advisable to verify that the identity was created by using the klist command again we covered earlier.

Note that if you are running macOS Sierra using kinit to authenticate you may receive a warning that the encryption type is weak and will be deprecated. At some point in a future version of macOS RC4 Encryption for kerberos will be no longer supported therefore in preparation you should contact your Domain Admin and enable AES 128 or 256 bit encryption in order to be compatible.

Lastly we can use the kdestroy command, this will remove all the current users tickets. as you can see from the slide this has only removed tickets for the aduser1 identity. 

If you wish to remove all Tickets from a client machine this can be done by using the kdestroy -A command. with this option all tickets for all users will be destroyed and as you can see now both aduser1 and Amsys no longer have any tickets cached on the client machine.

Daryl McCartney

I joined Amsys in April 2010 as a Service Technician. In 2012 i took the opportunity to move into the Training department. Since joining i have been successful in becoming certified to teach all of the current Apple Certification Courses since OS X 10.8, as well as the ACMT and ACiT qualifications. Outside of work I enjoy playing Tennis and I am a member of the club committee helping to maintain t... more

Featured Podcasts

Mapping Network Drives with Jamf Pro
Jamf Pro podcast - March 11, 2017

Kerberos 1.01
networking podcast - April 28, 2017

Joel Rennich: Owning AD Through the NoMAD AD Auth Framework
Active Directory podcast - March 2, 2018