Kerberos Overview

<aside> 💡 **Kerberos is the default authentication protocol in an Active Directory environment.

Kerberos is an authentication protocol and NOT authorization, it only authenticates users to the domain. If Kerberos authentication fails, the authentication falls back to NTMLv2.

Kerberos uses tickets to authenticate a user and completely avoids sending passwords across the network.**

</aside>

Kerberos Authentication Components

• Client is the user.

• Key Distribution Center (KDC) has 3 components:

  • Database that stores all the below key hashes:
    • User keys
    • Services keys
    • sessions keys
    • Krbtgt key or known as the KDC key
  • Authentication Server (AS)
  • Ticket Granting Ticket Service that has the KRBTGT account in which issues TGT tickets.

• Application Server: any dedicated server for specific service, i.e. SQL, Web, Exchange, etc.

• Tickets

  • Ticket Granting Ticket (TGT) is the ticket that is given to the user after the KDC verifies their identity. It is used to request service tickets. The ticket is encrypted with the Krbtgt hash (KDC key). The ticket by default lasts 10 hrs
  • Ticket Granting Service (TGS) is the ticket that the user presents to the Application server to access the service. The ticket is encrypted with the Service key in the KDC.

• Privilege Attribute Certificate (PAC) is the a feature that is included in the ticket to present the privileges a user has on the service. When the user presents their TGS to the application server; the server sends a PAC request to the KDC to verify the privileges presented in the user’s TGS ticket.

KDC Key Encryption Algorithms

<aside> 💡 KDC encrypts the tickets with either RC4, AES128 or AES256; depending on set configuration.

RC4 = NTLM hash when using RC4

AES128

AES256

</aside>

Kerberos Authentication Process

Step 1 KRB_AS_REQ

• A user sends a request message to the KDC asking for authentication. The messages contain the username, the service SPN linked with the Krbtgt account, and the time stamp. The entire message encrypted with the user NTLM hash to prevent replay attacks.

Step 2 KRB_AS_REQ

• The KDC verifies the user's identity by decrypting the encrypted messages with the user's key stored in the KDC database. If the KDC decrypts the request successfully, it has verified the user's identity. Next, the KDC issues a TGT ticket that gets encrypted with the Krbtgt hash and along with the user hash, and send it back to the user.

Step 3 KRB_TGS_REQ

• The user decrypted the response with their key and saved the TGT ticket in the user’s memory tray. Next, the user sends a service request to access a service, and the request contains a copy of the TGT ticket received in Step2. (the service request the user sends contains the name of the service SPN).

Step 4 KRB_TGS_REQ

• The KDC decrypts the request, verifies the TGT, then issues a service ticket TGS encrypted with the service hash key.

Step 5 KRB_AP_REQ

• The user receives the TGS and sends it to the Application server for the service they want to access. If the application decrypts the TGS requests with its service hash key, it will send a PAC request to the KDC to verify the user’s privileges before giving them access.