Introduction

In the traditional approach, users typically access computer systems by entering a password. However, this method poses a significant risk if hackers manage to obtain the password. They can impersonate the user and infiltrate an organization’s network. Therefore, organizations require a more robust security solution, and this is where Kerberos authentication comes into play.

For brevity’s sake, this article focuses on understanding and explaining the authentication protocol (process) utilized in Active Directory – Kerberos.

What is Kerberos?

Kerberos was named after the three-headed guard dogs from Greek mythodology –   Cerberus. It was initially developed at the Massachusetts Institute of Technology (MIT) in the late 1980s and has since been widely adopted as the standard authentication protocol in modern operating systems and network environments.

It is an authentication protocol that verifies the identity of a user or host when they attempt to login to their computers or access resources on the network. Beyond this crucial role, Kerberos also facilitates mutual authentication between users and servers by establishing trusts.

Kerberos Authentication Process

The authentication process uses a ticketing system instead of sending cleartext, hashed, or encrypted passwords over the network. The Domain Controller (DC) operates a service called the Key Distribution Center (KDC), which also functions as an Authentication Server (AS) to issue tickets.

There are 3 main subprotocols involved in Kerberos authentication process:

1. Authentication Service (AS) Exchange
2. Ticket Granting Service (TGS) Exchange
3. Client/Server (CS) Exchange

Authentication Service Exchange

This is the initial step where the user authenticates to the KDC to request a Ticket Granting Ticket (TGT). The AS protocol verifies the user’s identity and credentials.

Below is an outline of logon Authentication Service (AS) exchange:

1. A user (client) attempts to log in to a computer by providing a logon name & password thereby initiating a request to the DC known as a Kerberos Authentication Service Request (KRB_AS_REQ) for a TGT. During this process, the presented password is converted to an NTLM hash, and is used to encrypt a timestamp with that password hash.
2. On receiving the KRB_AS_REQ, the DC looks up the password hash associated with that specific username and attempts to decrypt the timestamp using its own copy of the password hash within the NTDS.DIT database file. A successful decryption of the timestamp would confirm that the user’s password is valid, followed by a timestamp check to ensure it is not a duplicate, as a duplicate timestamp could indicate a possible relay attack.
3. The Domain Controller (DC) then responds to the client with a Kerberos Authentication Service Reply (KRB_AS_REP). This reply includes a session key, encrypted with the user’s password hash, so that the client can decrypt it for future use.  
4. The client stores the new key and extracts the TGT from the KRB_AS_REP and stores them in its ticket cache.

Ticket Granting Service Exchange

As part of the seamless Kerberos authentication process, the Ticket-Granting Service (TGS) exchange comes into play because it is responsible for issuing service tickets to users after they have obtained a TGT. Therefore, if a user seeks access to resources such as file shares, mailboxes, printers, or a database on a SQL server within the domain, they must request a second ticket – TGS, using the acquired TGT.

The following steps explains the exchange flow:

1. After a TGT and session key have been issued to the client (user), a Kerberos TicketGranting Service Request (KRB_TGS_REQ) is sent to the KDC. This request comprises of the identity of the service that the client is requesting credentials, an authenticator message encrypted with the user’s new logon session key, and the TGT obtained from the Authentication Service Exchange.
2. Once the KRB_TGS_REQ is received, the KDC decrypts the TGT with its secret key and extracts the user’s logon session key.
3. The KDC uses the logon session key to decrypt the user’s authenticator message and assess it. If the authenticator passes the test, the KDC extracts the user’s authorization data from the TGT and generates a new session key for the user to share with the requested server.
4. Afterwards, the KDC encrypts one copy of the service session key with the user’s logon session key, embeds another copy along with the user’s authorization data, and encrypts the ticket with the server’s master key.
5. Finally, the KDC sends these credentials back to the client as a Kerberos TicketGranting Service Reply (KRB_TGS_REP).  Once the client receives the reply, it decrypts the service session key with the user’s logon session key and stores the service session key in its ticket cache.

Client/Server Exchange

This is the final stage (subprotocol) of the Kerberos authentication service, and it occurs after a user has acquired a TGS to a server to establish a secure communications session with said server.

To establish a secure communications session with the server:

1. The client requests access to the server by sending a Kerberos Application Request (KRB_AP_REQ). The request (KRB_AP_REQ) consists of an authenticator message that is encrypted with the key sent by the KDC for the session with the server, the ticket for sessions with the server, and a flag that indicates whether the client requests mutual authentication. However, setting the flag that requests mutual authentication is optional and the server will return the client’s timestamp from the authenticator, encrypted with the session key if the flag is set.
2. Once the server receives the KRB_AP_REQ, it will decrypt the ticket and extract the user’s authorization data and the session key. The server will then use the session key from the ticket to decrypt the user’s authenticator message and evaluate the time stamp inside.
3. If the authenticator message proves to be valid, the server will examine the mutual authentication flag within the client’s request.
4. If the mutual authentication flag is activated, the server will utilize the session key to encrypt the timestamp from the user’s authenticator message and send back the encrypted result as a Kerberos Application Reply (KRB_AP_REP).
5. Upon receiving the KRB_AP_REP, the client will decrypt the server’s authenticator message using the shared session key, then compare the time sent back by the service with the time in its original authenticator message. If they correspond, the client is assured that the service is genuine, and a connection established.

Conclusion

It is evident that Kerberos authentication serves as a cornerstone of security within network communication. Its robust encryption methods, ticketing system, authentication protocols, and timestamp feature collectively form a robust defense against unauthorized access and mitigates relay attacks.

However, Kerberos authentication is not without its vulnerabilities. It is susceptibility to misconfigurations (such as disabling preauth) and issues like constrained Kerberos Delegation exploitation, etc.

Despite these challenges, Kerberos remains a fundamental protocol in securing network and Windows environments because it prevents unauthorized access by verifying the identity of users or hosts and establishes trust between entities through its mechanisms.