Download our Capabilities Brief

Schedule a Call

Active Directory Series: Kerberos Authentication Overview

Home Blog

Active Directory uses the Kerberos protocol to authenticate clients and permit or deny access to different services like mail, databases and file services. The Kerberos name references Kerberos, the three-headed dog from Greek mythology that guarded Hades. Similarly, Kerberos protects Active Directory environments by using three private keys between three entities. Kerberos now also includes public key options. These three entities are the client, Key Distribution Center (KDC), and the Application Service.  

  1. Client– entity that is looking to access a service.
  2. Key Distribution Center– typically in the AD Domain controller, the KDC includes two servers: the Authentication Server (AS) and Ticket Granting Server (TGS). The KDC issues tickets and temporary keys that allow a client to securely authenticate to a service. The KDC stores all three private keys for users and services. The Authentication Server (AS) confirms that a known user is making an access request and issues Ticket Granting Tickets (TGT). The Ticket Granting Server (TGS) confirms that a user is a making an access request to a known service and grants Service Tickets (ST). 
  3. Application Service – this is the service the client is looking to access.

Before a client can access a service, it needs to be authenticated by the KDC. The client must first authenticate with the Authentication Server, then then Ticket Granting Server, and finally with the Application Service. To complete this sequence the Kerberos protocol relies on an exchange of tickets (TGT and ST) and Session Keys (SK1 and SK2).

Below is an overview of how these tickets (TGT and ST) and Session Keys (SK1 and SK2) are exchanged. The KDC also includes three symmetric keys: a Client Secret Key and TGS Secret Key (sent by the Authentication Server) and a Secret Service Key (sent by TGS). 

  1. AS_REQ: Authentication Server Request The Client sends a plaintext request for a TGT with the Client ID to the Authentication Server. This TGT is used to request access to other services. The Authentication Server locates the Client ID in the KDC database and locates the corresponding Client Secret Key. 
  2. AS_REP: Authentication Server Reply If the Client ID is located by AS, it will send the client two messages: a TGT and a TGS Session Key (SK1). The TGT is encrypted with the TGS Secret Key. The TGS Session Key is encrypted with the Client Secret Key. The Client Secret key is based off the client’s salted password hash. If the client submitted the wrong password, it would not be able to correctly decrypt the Session Key (SK1). To visualize: after successfully logging onto a computer, users can now attempt to access different services like Outlook.  
  3. TGS_REQ: Ticket Granting Server Request Using the TGT a client can now request access to different resources, like Outlook. The client sends the TGT and a User Authenticator request. The client can encrypt a new authenticator request with the Service Session Key (SK1). To request access, the client needs to specify that service’s name, using a Service Principal Name. This client request is sent to TGS and with the TGT encrypted with the TGS Secret Key. To visualize: a logged in user has their TGT and now clicks on the Outlook mail icon which sends the SPN and TGT to the KDC’s TGS to confirm the user has access. 
  4. TGS_REP: Ticket Granting Service Reply The TGS now receives the TGT and User Authenticator request. The TGS can decrypt the TGT with its TGS Secret Key. The TGT includes the Service Session Key (SK1), so this can then be used to decrypt the User Authenticator request. If verified, the TGS sends a Service Ticket (ST) and Service Session Key (SK2). This Service Ticket (ST) also includes the Service Session Key (SK2) and is encrypted with a third secret key: a Secret Service Key. The SK2 is also encrypted with a TGS Session Key. To visualize: the user is now ready to access outlook with the Service Ticket for Outlook. 
  5. AP_REQ: Application Service Request The client can now send the Service Ticket (ST) and a new User Authenticator message to the application. The client is requesting access directly to the resource. To visualize: an outlook application receives the user’s request for access that is encrypted with the Outlook service’s password hash (service session key). 
  6. AP_REP: Application Service Reply The requested service decrypts the ST with its Secret Service Key. Since the ST includes the Service Session Key (SK2) it can now decrypt the User Authenticator message and verifies the client’s access to the service with the KDC. If it is granted, the Application can now send the client a Service Authenticator, encrypted with the Service Session Key.  
Two excellent resources for understanding Kerberos include this article by Lynn Root and this Youtube video by Destination Certification. 

The following AD Series articles will cover Kerberos authentication attacks, including: Kerberoasting, Silver and Golden Tickets attacks, and AS-REP Roasting.