About
Kerberos ticketing process between:
Articles Related
Steps
Client's identity
Under Kerberos, a client sends a request for a ticket to the Key Distribution Center (KDC). The KDC creates a ticket-granting ticket (TGT) for the client, encrypts it using the client's password as the key, and sends the encrypted TGT back to the client. The client then attempts to decrypt the TGT, using its password. If the client successfully decrypts the TGT (i.e., if the client gave the correct password), it keeps the decrypted TGT, which indicates proof of the client's identity.
Get Access to services
The TGT, which expires at a specified time, permits the client to obtain additional service tickets, which give permission for specific services.
The requesting and granting of these additional tickets is user-transparent.
Although the KDC issues the service ticket it does not talk directly to the service that the principal is requesting the ticket for. Once a service ticket has been issued by the Ticket Granting Server, the service ticket is put into the principal’s credentials cache for later use. When the principal needs to connect to the requested service the service ticket is used from the credentials cache and sent to the service it is attempting to connect to. See the whole request process below.
Process Request
where:
- KRB_TRS_REQ is a TGS request that send backs a service ticket
- KRB_AP_REQ is an authentication process (AP) where the client sends a ticket service that it gets from the KRB_TRS_REQ request (or from its cache)
The KDC does not participate directly in the authentication of users to the end service with Kerberos. The KDC is known as the trusted 3rd party in this type of authentication. It is known this way because it is the only service that knows the passwords of the user and the service.