IPA/IDM Identity Management and Kerberos - A simple explanation of how it is used to Authenticate in an IPA/IDM Domain

IPA/IDM Identity Management - A simple explanation of how it is used to Authenticate

Kerberos is a Network Authentication Protocol (NAP) developed at MIT and released publicly in the 1980's.  Owing to it's Greek name Kerberos, there are (3) pillars of Kerberos: Client, Server (could be an app or other service or host) and a 3rd Party Key Distribution Center (KDC). 

Within these (3) pillars, Kerberos uses Tickets to validate the identity of users and other resources within the Kerberos Realm. A Kerberos realm encompasses any resource that can be accessed via a specific Kerberos KDC. The KDC has (2) primary components: An Authentication Server (AS) and a Ticket Granting Service (TGS). 

All Kerberos communications are encrypted using a variety of configurable Ciphers.

One very important feature of Kerberos: Passwords are never sent over the network!

Let's look at an example of a user logging into a Kerberos enabled client within a Kerberos Realm/Domain.

1. A user enters their username at a client workstation, which is transmitted to the AS within the KDC.  In addition to the username, several other pieces of info are transmitted to the KDC/AS including: IP of the client, the name of the KDC and the requested Time To Live (TTL) for Ticket Granting Ticket (TGT).

2. The username the client presented to see if it exists in the KDC Database - which in the case of IPA/IDM is the Directory Server. If the username is valid, the client will proceed to step 3, otherwise an error is generated and the authentication process must be restarted at Step 1.

3. The KDC/AS now responds by sending a Ticket Granting Ticket (TGT) to the workstation or client (which is a Kerberos Realm client).

The TGT itself contains several critical pieces of information, including: username, TGS name, TimeStamp, IP of client as well as other information.  

The TGT is encrypted with a session key known only between the KDC and user (also known as a principal) - this key is most often generated with the users password. IPA/IDM uses symmetric key cryptography when generating TGT's.

 A hash is then created based on the password the user entered, and that hash is used to decrypt the Session Key. 

4. If the password decrypts the Session Key, the client now creates an Authenticator which it sends back to the KDC along with the identity of the Kerberized resource that the client wants to access.

The Authenticator is used to decrypt the TGS Secret Key which if it does so successfully, will now grant access to Kerberized Realm resources by issuing a Service Ticket (ST) or de-crypted TGT to the user.

5. The client can now use this ST or de-crypted TGT to gain access to KDC Realm resources such as servers, storage, http/s apps, databases, files and even routers and printers or any other service that is Kerberized.

The ST will have a specified lifetime in which it can be used to gain access to Kerberized resources without having to re-authenticate.  In addition, Kerberos also allows for Single Sign-On (SSO) since an ST has a System Administrator defined lifetime.

One other point: Once the TGT is de-crypted on the TGS, the key pair can then be stored in a keytab.

Here is a working definition of a keytab:

A keytab is a file containing pairs of Kerberos principals and encrypted keys (which are derived from the Kerberos password). You can use a keytab file to authenticate to various remote systems using Kerberos without entering a password. However, when you change your Kerberos password, you will need to recreate all your keytabs.

Keytab files are commonly used to allow scripts to automatically authenticate using Kerberos, without requiring human interaction or access to password stored in a plain-text file. The script is then able to use the acquired credentials to access files stored on a remote system.

In other words, the keytab will allow a principal (user) or even a script to access domain resources without having to input a password.

Here is a graphic from Red Hat that illustrates the steps above in a slightly simpler form:

It's worth noting that Kerberos Authentication is nearly transparent to System Administrators and Users -> IPA/IDM does most if not all of the heavy lifting.