Foreword

In this entry I would like to briefly explain how Kerberos works in an Active Directory environment.

Active Directory is used for Windows management (User, Server, Clients, Authentication) and provides several services. One of the authentication method it offers is Kerberos.

Kerberos is a protocol that allows users to authenticate on the network through tickets and access services once authenticated.

How Kerberos works

Kerberos is utilized whenever a user attempts to access services on the network. It allows the user to authenticate without having to enter their password repeatedly, and eliminates the need for the server to store or know each user’s password. Kerberos is a good example for centralized authentication.

At least three things are required for it to work:

• Client
• Service (CIFS, SMB, etc.)
• Key Distribution Center (KDC) which is a Domain Controller (DC) in an Active Directory environment

The concept behind this approach is that when a client needs to access a service, no password is transmitted over the network, thus reducing the risk of password exposure and potential security breaches.

The process, while effective, involves three key steps:

• Authentication Service (AS): The client first authenticates with the Key Distribution Center (KDC)
• Ticket-Granting Ticket (TGT): Next, the client requests a ticket to access a specific service (e.g., CIFS, SMB, RDP)
• Application Request (AP): Finally, the client presents the ticket to use the desired service

A helpful analogy is visiting a theme park. You first show your ID at the entrance to prove your identity (TGT). If you want to go on a ride, you take your ID (TGT) to the ticket counter and request a ride pass (TGS). The ticket counter gives you a special, non-replicable pass with your age, height, weight and other details on it. You can then go to the ride, present the pass, and if it’s valid, the attendant allows you to board. The ride attendant verifies the pass’s authenticity by checking the unique markings, ensuring you meet the age requirements.

So how does it look like in practice?

In this example, we are in an Active Directory environment, so, as already mentioned, the KDC is also the domain controller. The KDC contains all domain information, including secrets of each service, machine and user.

Apart from the DC, everyone in the network only knows their own secret.

Let’s take the user “Lukas” as an example. Lukas wants to use the service “XYZ”. As a first step he will have to authenticate himself at the KDC and then he will send a request that he wants to use the service “XYZ”. This phase is called Authentication Service (AS).

Authentication Service (AS)

KRB_AS_REQ

Lukas first sends a request to the Domain Controller (DC) to obtain a Ticket Granting Ticket (TGT). This request is referred to as KRB_AS_REQ (Kerberos Authentication Service Request). The requested TGT contains encrypted data, including a session key and information about the user such as ID, name and groups.

For this request, Lukas transmits his name to the KDC together with the current time of the request, whereby this information is encrypted with a hashed version of his password.

Then, the KDC receives the username and will verify it against it’s database.

When the KDC has found the user in the database, it will retrieve the hashed password from the user Lukas and try to decrypt the encrypted timestamp. If this fails, the client has used the wrong password.

If the decryption is successful, the KDC knows that it is really the user “Lukas” who made the request. The KDC will then create a unique session key which is bound to the user “Lukas” and is time-limited.

KRB_AS_REP

In the next step, the KDC sends various information back to the user “Lukas” (KRB_AS_REP).

This includes:

• The session key, which is encrypted with the hashed password of the user “Lukas”
• The TGT, which contains various information such as:
  • Username (Lukas)
  • Validity period
  • Generated session key
  • The Privilege Attribute Certificate (PAC), which contains specific information about the user, including his identification (SID) and all groups he is a member of

The TGT is encrypted with the key from the KDC. This means that only the KDC is able to decrypt it and read the content of the ticket.

The TGT is regarded as public information. It can be intercepted during the authentication phase. In the next step we will see why the “Authenticator”, which accompanies the TGT when the client communicates with the KDC, is so important.

Ticket Granting Service (TGS)

With the user now authenticated, the situation is as follows: The user possesses their personal key, a time-limited session key known only to them at this moment, and a KDC-encrypted TGT that includes this same session key among other details.

KRB_TGS_REQ

When the user “Lukas” wants to access a service, such as SMB on the server SRV-FILE-01, they will provide several pieces of information to the KDC to obtain a Service Ticket:

• The TGT.
• The desired service and associated host (e.g., SMB/SRV-FILE-01 in this case).
• An authenticator, which includes Lukas’s username and the current timestamp, all encrypted using the session key.

The authenticator is provided to ensure that the request is genuinely being made by the user “Lukas.” To verify this, the KDC compares the contents of the TGT with those of the authenticator. Since only the KDC can decrypt the TGT, its integrity is guaranteed. The KDC extracts the TGT’s contents, including the owner’s identity and the associated session key. It then uses this session key to decrypt the authenticator. If the decryption is successful and the information in the authenticator matches the TGT, the KDC confirms that “Lukas” is legitimate. This process assures the KDC that the requester possesses the TGT and knows the agreed-upon session key.

Below is a diagram that outlines the verification process at the KDC level:

KRB_TGS_REP

After verifying that the user is “Lukas”, the KDC will respond with information enabling the user to request access to the desired service. This response, known as the KRB_TGS_REP, contains the following parts:

• A ticket encrypted with the service’s key (specifically, the host key, as the SMB service operates under the host account). This ticket includes:

  • The name and host of the requested service (SMB/SRV-FILE-01)
  • The user’s username (“Lukas”)
  • The PAC (Privilege Attribute Certificate)
  • A new session key, valid exclusively for communication between “Lukas” and SRV-FILE-01 for a limited time

• The new session key

Both the ticket and the session key are encrypted using the first session key initially exchanged between the KDC and the client.

The client receives this message and decrypts the first layer to retrieve the session key designed for communication with the service, along with the ticket generated for accessing the service. This ticket is commonly referred to as the Ticket-Granting-Service (TGS).

Application Request (AP)

KRB_AP_REQ

The user “Lukas” will then create a new authenticator, encrypting it with the new session key along with the TGS. This process mirrors the one used with the KDC.

The SMB service receives the TGS and decrypts it using its own secret. Since only the Domain Controller possesses this secret, the service can trust the authenticity of the TGS. The TGS includes the session key, which the service uses to decrypt the authenticator. By comparing the contents of the TGS with those of the authenticator, the service can confidently verify the authenticity of the user “Lukas”.

Summary

Benefits of Kerberos

There are some key advantages to using Kerberos as an authentication service.

Access Control

The Kerberos authentication protocol enables effective access control. Users benefit from a single point for keeping track of all logins and the enforcement of security policies.

Mutual Authentication

Kerberos authentication allows service systems and users to authenticate each other. During all steps of the process, the user and the server will know that the counterparts that they are interacting with are authentic.

Limited Ticket Lifetime

Each ticket in Kerberos has timestamps and lifetime data, and the duration of authentication is controlled by admins.

Reusable Authentication

Kerberos authentication is durable and reusable. Each user will only have to be verified by the system once. Then throughout the lifetime of the ticket, the user can authenticate without the need to reenter personal information.

Security

Multiple secret keys, third-party authorization, and cryptography make Kerberos a secure verification protocol. Passwords are not sent over the networks, and secret keys are encrypted, making it difficult for attackers to impersonate users or services.