The Ticket-Granting Service is a component of the Key Distribution Center (KDC) that is responsible for issuing service tickets.

Typically hosted on a domain controller in the Active Directory domain. When a user or computer requests a service ticket, the request is sent to the TGS component of the KDC, which verifies the user's or computer's identity and checks their authorization to access the requested resource before issuing a service ticket that can be used to gain access to the resource.

Request (TGS-REQ)

The client now has a response from the server to its TGT request. This response contains the TGT, protected by the KDC's key, and a session key, protected by the client's/user's key. It can then decrypt this information to extract this temporary session key.

The next step for the user is to request a Service Ticket ST or TGS ticket with a TGS-REQ message. To do this, they will transmit three things to the KDC:

  1. The name of the service they wish to access (SERVICE/HOST, which is the Service Principal Name (SPN) representation)
  2. The TGT they previously received, containing their information and a copy of the session key
  3. An authenticator, which will be encrypted using the session key at this time

Response (TGS-REP)

The KDC receives this TGS request, but Kerberos is a stateless protocol. Thus, the KDC has no idea what information has been exchanged before. It must still verify that the TGS request is valid. It must verify that the authenticator has been encrypted with the correct session key to do this. And how does the KDC know if the session key used is correct?

Remember that there was a copy of the session key in the TGT. The KDC will decrypt the TGT (checking its authenticity along the way) and extract the session key. With this session key, it will be able to verify the authenticator's validity.

If all this is done correctly, the KDC only has to read the requested service and respond to the user with a TGS-REP message. We saw earlier that a session key had been generated for the exchanges between the user and the KDC. Well, it's the same thing here. A new session key is generated for future exchanges between the user and the service. And as before, this session key will be present in two places in the response sent by the KDC to the user. Here are all the elements sent by the KDC:

A service ticket or TGS ticket containing three elements:

  1. The name of the requested service (its SPN)
  2. A copy of the user information that was present in the TGT. The service will read this information to determine whether or not the user has the right to use it.
  3. A copy of the session key

All this information is encrypted with the user/KDC session key. Within this encrypted response, the user's information and the copy of the user/service session key are also encrypted with the service key. A diagram will help make this clearer.