Authentication

  1. A principal sends an authentication server request (known as AS_REQ) to the DC.

  2. If authentication succeeds, then the DC sends back a reply (AS_REP) to the principal. In this reply is a ticket that gives the principal permission to request access to resources on the network. This ticket is called the Ticket Granting Ticket (TGT). The TGT only proves that the principal has successfully authenticated on the network and provides access to one service – the Ticket Granting Service (TGS).

  3. When the principal wants to request resources on a Kerberos-enabled service, it first must request a ticket to access that specific resource from the TGS. This TGS Request (TGS_REQ) is sent to the TGS, hosted on the DC.

  4. The TGS then verifies the TGT and accepts that the principal has been given access to the requested resource presented in the TGS request. If everything checks out, then the TGS sends a reply (TGS_REP) back to the principal with a secret key inside called the session key. The session key is used to encrypt messages between the principal and the service for which it is requesting resources.

  5. Once the principal receives the TGS_REP, it can then request access to the network resource from the service. This is done through an Application Request (AP_REQ) to the service that is secured with the session key provided in the TGS_REP.

  6. Once the service receives the AP_REQ, it verifies that the request is valid by decrypting the message from the principal. Successful decryption is enough to validate the request. If everything checks out, then the service allows access to the requested resources and sends a reply (AP_REP).

Last updated