Kerberos derives its name from Greek mythology, inspired by Cerberus, the three-headed dog guarding the gates to the underworld. Kerberos was initially developed by MIT in the 1980s. Later refined by Microsoft for Windows 2000, it replaced NTLM and remains Open Source.

In a nutshell, the key difference between Kerberos and NTLM is this:

• NTLM uses a three-way handshake between the client and server, involving sending credentials over the network.
• In contrast, Kerberos avoids sending credentials across the network, enhancing security.

Now, let’s delve into the details of how Kerberos works.

Kerberos operates within a “realm,” which represents the domain over which Kerberos has the authority to authenticate users to services. Multiple realms can be interconnected. Within a realm, we have “principals,” unique identities representing users or services. Users accessing a service are referred to as “clients,” while the resources they want to access are termed “services.”

At the heart of Kerberos lies the Key Distribution Center (KDC). The KDC supplies tickets and generates temporary session keys for secure user-to-service authentication. It stores all the secret symmetric keys for users and services, housing both the Authentication Server and Ticket Granting Server. We will explore this just a little later.

The authentication process involves multiple message exchanges between the user, the Authentication Server, the Ticket Granting Server, and the service. Several types of messages play vital roles, including “authenticators” that enable mutual authentication between users and services, and “tickets” that contain encrypted authentication information.

1. A user, let’s call him Rob, wants to access a service (e.g., CRM application) over an insecure network. Rob sends a message containing time stamp and other data to the server. The Authentication Server receives Rob’s message and checks its list of users.
2. If Rob’s identity is verified, the Authentication Server issues a Ticket Granting Ticket (TGT) encrypted with Rob’s secret key (krbtgt password) and a session key encrypted with Rob’s password.
3. Rob decrypts the TGT using his secret key, gaining access to critical information, including the Ticket Granting Server’s ID and a session key. Rob creates a new message, including an Authenticator with his ID and timestamp. This message is encrypted with the session key from the previous step. Along with the TGT, Rob sends these new messages to the Ticket Granting Server.
4. The Ticket Granting Server decrypts the TGT using its secret key, and after validating Rob’s request, it issues a Service Ticket (encrypted with the service’s secret key) and a new service session key for Rob.
5. Rob receives the Service Ticket and creates another Authenticator encrypted with the new service session key. He sends the Service Ticket and the new Authenticator to the service he wants to access.
6. The service decrypts the Service Ticket using its secret key (service user password), confirming Rob’s request, and creates its own Authenticator. The service sends the final Authenticator message back to Rob, ensuring mutual authentication.

KRBTGT

Before going in much detail, we need to understand KRBTGT as it performs a major role in kerberos authentication. Every active directory domain has something called krbtgt account. By default, the krbtgt account is not visible in the user’s container. However, you can reveal it by accessing “View” and then selecting “Advanced Features” in the menu. After doing this, you will see the krbtgt account listed. This account is referred to as the key distribution centre service account, which plays a significant role in Kerberos.

The term “key distribution center” (KDC) is commonly used to describe the central database that stores user credentials and manages incoming ticket requests. In the context of Active Directory, each domain controller essentially functions as a KDC. Therefore, when you encounter the term DC (domain controller) or KDC in Kerberos language, you can equate it to the key distribution center.

While the krbtgt account appears as a user account, it cannot be used for regular logins. By default, it is disabled and cannot be enabled. Its password is set by the system and is highly complex. You need not be concerned about the specifics of this password, as you will never need to use this account for login purposes. The system keeps the password secure, and no other entity should ever be aware of it.

Kerberos Deep Drive

Let’s take a journey into the world of Kerberos, step by step, to understand how this enchanting protocol works.

Phase 1: When a user requests a ticket for their user account, they don’t send their password directly. Instead, they send encrypted data known as “preauthentication data.” In this discussion, we’ll assume the account has preauthentication enabled, as it is the default setting for most accounts.

With preauthentication enabled, the user sends the current time encrypted with their password to the domain controller. Since the domain controller can access everyone’s passwords, it decrypts the timestamp using the user’s password to verify its accuracy, helping to detect replay attacks (although this detail is less important for our current understanding).

With preauthntication disabled, when the user enters his/her username & password in the client system, it stores the NTLM has of the password locally and send the following information to the authentication server without encryption. Note that later steps are exactly the same whether preauthentication is enabled or not.

User’s Initial Message to Authentication Server

• User ID (e.g., “Rob”)
• Service ID (e.g., Outlook application)
• User’s IP address
• Requested lifetime of the Ticket Granting Ticket (TGT)

Note that the KDC may ignore the requested lifetime of TGT.

Phase 2: If the user is a valid domain user, the KDC authentication server responds by sending back the “TGT” (ticket granting ticket), aptly named because it allows the user to request other tickets for various services. Alongside the TGT, the domain controller also sends a “session key.” Keep in mind that with preauthentication enabled, the DC needs to decrypt the data sent by the user to issue a TGT.

This seemingly minor “session key” is, in fact, critical to the entire process. It is encrypted in two different ways: First, it is encrypted with the krbtgt account’s password and stored inside the TGT. Second, the same session key is encrypted with the user’s password. The user can decrypt this version of the session key using their password.

Authentication Server’s Response to User

• ID of the Ticket Granting Server (TGS)
• Timestamp of message creation
• Message lifetime
• User IP
• Ticket Granting Server Session Key (randomly generated

Ticket Granting Ticket (TGT)

• User ID
• TGS ID
• Timestamp
• User’s IP address
• Lifetime of TGT
• Ticket Granting Server Session Key (randomly generated)

To illustrate, let’s assume the session key is represented by the word “firstSessionKey” (although, in reality, it would be random bytes). The word “firstSessionKey” is encrypted with the krbtgt account’s password and stored inside the TGT, which is then further encrypted with the krbtgt account’s password, known only to domain controllers. Simultaneously, the same session key “firstSessionKey” is encrypted with the user’s password.

Now, the user possesses the TGT, which they cannot read directly because it’s encrypted with the krbtgt account’s password. However, they have the session key, which they can read by decrypting it using their password. If an attacker attempts to request a ticket for “Rob” without knowing his password, they will only receive the TGT encrypted with an unknown password (krbtgt password), and session key encrypted with user password which they do not have, rendering it useless to them.

Phase 3. The next step involves sending a request to the domain controller for a service ticket. This request includes the user ticket (TGT), which remains unreadable to anyone except the domain controller. Additionally, the request contains an “Authenticator,” which is simple data containing the user’s username, service principal name and a timestamp. However, this data is encrypted with the session key received in previous step and decrypted with user password.

Upon receiving the request, the domain controller decrypts the ticket (TGT) using its krbtgt account password and extracts the session key from inside the ticket. Subsequently, it attempts to use this session key to decrypt the data within the Authenticator that we sent along with the request.

However, if we were to pretend to have the session key and send a request for a service ticket, it would fail because the session key we provide would not match the one inside the TGT (ticket granting ticket). This highlights the significance of encrypting the session key twice — once inside the TGT using the krbtgt account password, and once more separately using the user’s password.

By encrypting the session key in this manner, the system ensures that only the domain controller, possessing both passwords, can successfully decrypt the data, preventing unauthorized parties from obtaining service tickets or accessing sensitive information.

Phase 4: Next two phases (4 & 5) are essentially a repeat of steps 2 and 3, but with the service ticket instead of the ticket granting ticket.

In this step, the domain controller (DC) sends back a service ticket for the service that the user has requested (let’s say Outlook in this example) and a new session key. The service ticket is encrypted with the service account’s password (the account that runs that service.), not the krbtgt account this time.

The DC knows which account is responsible for which service by looking up the service principal name (SPN) for that service. The SPN is a unique identifier for the service. In step 3, the client sent the request to the DC with the SPN for the service that it wanted to access.

The DC then searched the domain for the account that has the SPN for that service. Once the DC has found the service account, it encrypts the service ticket with the service account’s password and sends it back to the client. The client then decrypts the service ticket with its own password. This gives the client a session key that can be used to communicate with the service.

Additional points:

• The service principal name for Outlook is MSSQLSvc/<server name>@<domain name>. The <server name> is the name of the server that runs the Outlook service. The <domain name> is the name of the domain that the server is in.
• The session key is a randomly generated 128-bit value. The session key is used to encrypt all communication between the client and the Outlook service.

Phase 5: This is very similar to step 3, but instead of sending a ticket to a domain controller and asking for a service ticket back, we are now sending a ticket to the actual service we want to authenticate with. We are using the exact same method to prove that everything is legitimate. We send the service ticket encrypted with the service account’s password and some data that we have encrypted with the session key.

The session key is only available to the client and the service account. This means that the client can only get the session key if they actually have the password for J Smith. The whole purpose of this process is to prove that the client is Rob.

Phase 6: The Outlook service can decrypt the service ticket because it was encrypted with the Outlook server’s account password. If the server was instead running as local system instead of the user account in Active Directory, the authentication would fail. However, assuming that the Outlook service is actually running as that user account, it can decrypt the ticket because it has access to its own password.

The Outlook service can then get the session key from the service ticket and compare it to the session key that was used to encrypt the authenticator that was sent with it. If the session keys match, then the Outlook service knows that the request is legitimate and then it grants access to the service. Point to be noted here is that this only “authenticates” the user, but user “authorization” has not been checked. It’s because Kerberos is only an authentication mechanism with no capability to check authorizations.

Conclusion

After spending some time understanding the process, I realized that phase 6 is not strictly true. In that step, we say that the Outlook service can just decrypt the ticket because it has access to its own password. However, this is not entirely accurate.

The Outlook service is just a program that someone has written. It cannot simply read the password from Active Directory or from the user’s logon session. Fortunately, there are a set of Windows APIs that can handle this for us. These APIs, such as accept security context and acquire credentials, allow us to access the user’s password hash without having to directly read it from Active Directory.

It is important to note that when we say “credentials” and “passwords,” we are not referring to the actual password that the user has set. Instead, we are referring to the NTLM hash of that password. The NTLM hash is a one-way function that cannot be reversed. This means that even if an attacker were to obtain the NTLM hash of your password, they would not be able to use it to log in to your account.

In step 6, the Outlook service uses the NTLM hash of the user’s password to decrypt the service ticket. This allows the Outlook service to verify that the user is who they say they are and to grant them access to the service.

I hope this helps to clarify the Kerberos authentication process.