Kerberos
It is an authentication protocol that identifies each user, but does not determine what resources or services the user can or cannot access. Kerberos provides information on the privileges of each authenticated user, but it is up to the services to verify that these privileges are sufficient to access their resources.
Kerberos relies on UDP and TCP transport protocols (port 88 on each protocol) for the exchange of messages between the client and the KDC Server. These protocols do not include native encryption mechanisms, but Kerberos takes care of integrating its own encryption layer.
Main Entities
Client: Entity requesting access to a resource or service within the network. The client initiates the authentication process by requesting a Ticket Granting Ticket (TGT) from the KDC.
AP: The Application Server is where the service or resource the client wishes to access resides. It verifies the client's authenticity by ensuring that the client has a valid ticket, issued by the KDC, and authorizes access to the requested service.
KDC: The Key Distribution Center functions as the central authentication authority within the network. Typically found at the Domain Controller (DC). It's composed of two fundamental parts:
AS: Authentication Service: Its primary function is to issue TGTs (Ticket Granting Tickets) to customers who successfully prove their identity. The TGT is essential for the user to be able to request access tickets to specific services within the network without having to re-authenticate.
TGS: The Ticket Granting Service is the issuer of service tickets. Once the client obtains a TGT from the AS, it can present it to the TGS to request service tickets, which in turn will allow access to specific application servers
Authentication Flow
To understand the authentication flow of Kerberos, we can check the step-by-step process:
Authentication Request (AS-REQ): The client sends a request to the Authentication Service (AS). This request contains:
A timestamp encrypted with the client's key to authenticate the user. This key is derived from the NTLM hash of the user's password
The name of the user being authenticated
The Service Principal Name (SPN) of the service associated with the krbtgt account
A nonce generated by the user
Authentication Response (AS-REP): The KDC verifies the identity of the client by decrypting the timestamp and sends back a Ticket Granting Ticket (TGT) encrypted with the KDC's secret key. The complete response contains:
The client's username
The TGT which includes the username, Session key, TGT expiration date, and a PAC with the user's privileges signed by the KDC. All this is encrypted with a krbtgt (KDC key) derived from the NTLM hash of the krbtgt account's password
A set of data encrypted with the user's key, including the Session key, TGT expiration date, and the Client's nonce
TGS Request (TGS-REQ): The client sends the TGT to the TGS with a request for access to a specific service. This request contains:
The client's username and timestamp, encrypted with the session key
The TGT
The Service Principal Name (SPN) of the requested service
The client's nonce
TGS Response (TGS-REP): The TGS validates the TGT and authenticator and returns a Service Ticket (TGS or ST). The complete response contains:
The client's username
The TGS which includes the username, a Service Session key, the TGS expiration date, and the PAC with the user's privileges signed by the KDC. All this is encrypted this time, with a service key derived from the NTLM hash of the password of the service's proprietary
A set of data encrypted with the session key, including the Service Session key, the TGS expiration date, and the Client's nonce
Application Request (AP-REQ): The client sends the Service Ticket to the target service. The service decrypts the ticket (using its secret key), validates it, and grants access. The complete request contains:
The TGS
The client's username and the timestamp encrypted with the service session key
Optional Application Response (AP-REP): The service optionally responds with an authenticator encrypted with the session key and confirms it has successfully authenticated the client
Last updated