Kerberos

Introduction

Kerberos is used every time a user wants to access services on a network. Thanks to Kerberos, the user does not need to enter their password every time, and the server does not need to know every user’s password. This is centralized authentication. The idea is that when a client wants to access a service, the password is not transmitted over the network, which helps avoid password leakage that could compromise the network.

KDC is the Key Distribution Center located on the domain controller (DC).

The process of obtaining access to a service happens in three stages:

Authentication Service (AS): the client must authenticate to the KDC.
Ticket-Granting Service (TGS): then it must request a ticket to access the selected service (for example, CIFS, HTTP, SQL, …).
Application Request (AP): finally, it uses the service by presenting the ticket.

The KDC contains all domain information, including the secret key of each service, machine, and user. Thus, except for the DC, everyone knows only their own secret key and therefore does not know the keys of other Active Directory objects. We will look at this in more detail below. To distinguish participants in the process, the colors are as follows:

Authentication Service (AS)

KRB_AS_REQ (Kerberos Authentication Service Request)

First, the client (pixis) sends a request to obtain a Ticket Granting Ticket (TGT) to the domain controller (DC). This request is called KRB_AS_REQ. The TGT requested by the client is a piece of encrypted information containing, among other things, a session key and user information (ID, name, groups, …).

To perform this TGT request, the client (pixis) sends its name to the KDC, as well as the exact request time encrypted with a hashed version of its password.

The KDC receives this username and checks whether it exists in its database.

If the KDC finds the user in its database, it obtains the NT hashed password of pixis and uses it to try to decrypt the encrypted timestamp. If this fails, or if the timestamp differs by more than 5 minutes, then the client did not use the correct password to encrypt the timestamp.

If it succeeds, the KDC is confident that it is really talking to pixis. It generates a unique session key tied to this user and limited in time.

KRB_AS_REP (Kerberos Authentication Service Response)

The response from the KDC contains:

the session key encrypted with the hashed password of pixis;
the TGT, containing various information, for example:
- username (pixis);
- validity period;
- generated session key;
- Privilege Attribute Certificate (PAC), containing a lot of user-specific information, including the user’s identifier (SID) and all groups they belong to.

The client receives these pieces of information. Using the hashed password, the first part is decrypted to obtain the session key required for further exchange.

Ticket-Granting Service (TGS)

Now that the user is authenticated, we are in the following situation: the user has their own key, as well as a time-limited session key currently known only to them, and a KDC-encrypted TGT containing, among other things, this same session key.

KRB_TGS_REQ (Kerberos Ticket-Granting Service Request)

If pixis wants to use a service, for example CIFS on SERVER01, it sends several pieces of information to the KDC so that the KDC can send a Service Ticket in response:

an authenticator containing its username and current timestamp, encrypted with the session key;
the TGT;
the service it wants to use and the associated host, in this example CIFS/SERV01;

The authenticator is sent to make sure that the request is really made by pixis.

To do this, the KDC compares the contents of the TGT and the authenticator. Since only the KDC can read the contents of the TGT, it could not have been forged. The KDC reads the contents of the TGT, including the owner of the TGT and the associated session key.

Then it decrypts the contents of the authenticator using the same session key. If decryption succeeds and the authenticator data matches the TGT data, then pixis is who it claims to be. The KDC is confident that whoever made the request has the TGT and knows the agreed session key.

KRB_TGS_REP (Kerberos Ticket-Granting Service Response)

Now that the KDC has verified that the user is pixis, it sends back information that will allow the user to make a request to the service. This message is KRB_TGS_REP. It includes the following elements:

a ticket containing the name and host of the requested service (CIFS/SERV01), username (pixis), PAC, and a new session key that is valid only for communication between pixis and SERVER01 for a certain time. This key is encrypted with the service key (that is, the host key, because the CIFS service runs under the host account);
a new session key.

These two pieces of information (ticket and session key) are encrypted with the first session key, the one initially exchanged between the KDC and the client.

After receiving this message, the client can decrypt the first layer and obtain the session key created for communication with the service, as well as the ticket generated for using this service. Such a ticket is usually called a Ticket-Granting-Service (TGS).

Application Request (AP)

KRB_AP_REQ (Kerberos Application Request)

pixis generates a new authenticator, which it encrypts with the new session key together with the TGS.

The CIFS service receives the TGS and can decrypt it using its own key. Since only the CIFS service knows its key, it can be confident in the authenticity of this TGS.

This TGS contains the session key that will be used to decrypt the authenticator. By comparing the contents of the TGS and the authenticator, the service can be confident in the authenticity of the user.