In Kerberos, TGT stands for Ticket-Granting Ticket. It is an encrypted, time-sensitive token issued to a user after they have successfully authenticated with the Kerberos server, known as the Key Distribution Center (KDC). The TGT is the master key that allows a user to request subsequent "service tickets" for other network resources, such as file servers, without re-entering their password.
Detailed breakdown of the TGT and the Kerberos process
The key components
To understand the TGT, it's essential to first know the three main components of a Kerberos environment:
- Principal: Any entity, whether a user or a service, that can be assigned a Kerberos ticket.
- Key Distribution Center (KDC): A trusted, central server that manages all Kerberos tickets and encryption keys. It has two parts:
- Authentication Server (AS): Verifies the user's initial login credentials.
- Ticket-Granting Server (TGS): Issues service tickets to users upon presentation of a valid TGT.
- Application Server (Service): The server hosting the network resource (e.g., a file share or database) that the user wants to access.
The TGT in the Kerberos authentication process
The entire Kerberos workflow is a series of encrypted exchanges involving these three components. The TGT is central to this flow, acting as the "master" ticket that grants the ability to get more specific "subordinate" tickets.
1. Initial login (AS-REQ and AS-REP)
- User login: A user logs into their workstation and provides a username and password. The workstation creates a request to the KDC's Authentication Server (AS), encrypted with a key derived from the user's password.
- AS verification: The AS uses its database of user accounts to look up the user and the hash of their password. If the provided credentials match, the AS verifies the user's identity.
- TGT issuance (The AS Reply): The AS generates a Ticket-Granting Ticket (TGT), which contains information such as the user's identity, IP address, and a limited validity period. The TGT is encrypted with a key shared between the AS and the Ticket-Granting Service (TGS). The AS also generates a temporary session key, which is encrypted with the user's password hash and sent along with the TGT.
- Client storage: The user's workstation uses the user's password to decrypt the session key. It then stores the encrypted TGT and the decrypted session key in a local "ticket cache". This initial, one-time use of the password protects against sending the password over the network.
2. Requesting a service (TGS-REQ and TGS-REP)
- Service ticket request: When the user wants to access a network resource (e.g., a file share), their workstation sends a request to the KDC's Ticket-Granting Service (TGS). The request includes the cached TGT and a new authenticator message, which is encrypted with the session key from the first step.
- TGS verification: The TGS receives the request and uses its shared secret key to decrypt the TGT. Inside the TGT, it finds the session key. It then uses that session key to decrypt the user's authenticator message, confirming the user's identity.
- Service ticket issuance (The TGS Reply): If the TGS validates the request, it issues a new "service ticket" for the specific resource the user wants to access. This service ticket is encrypted with a key shared between the TGS and the target application server. A new session key for the client-server communication is also generated and encrypted with the client's session key. The TGS sends both back to the user.
- Client storage: The user's workstation decrypts the client-server session key and stores it with the service ticket in its cache.
3. Accessing the service (AP-REQ and AP-REP)
- Ticket presentation: The user's workstation presents the service ticket to the application server.
- Server verification: The application server receives the service ticket and uses its own key, shared with the KDC, to decrypt it. If successful, the server is assured of the user's identity. The server can then check the user's permissions and grant access.
The TGT's role in security and efficiency
The TGT is critical to the Kerberos protocol because it enables a secure single sign-on (SSO) experience for the user.
- Eliminates repeated password entry: By using the TGT, the user can access many different network services over a period of hours without needing to re-enter their password for each one.
- Prevents password exposure: The user's password is only ever used once, at the initial login, and only to get the initial TGT. It is not transmitted over the network.
- Enforces time limits: TGTs are set to expire after a certain period (e.g., 8-10 hours). This means that even if a TGT is intercepted, it will become useless after its limited lifespan.
- Enables delegation and other features: The TGT and the service tickets it generates contain information about the user's group memberships and privileges, which the application server can use to enforce access control.
Enjoyed this article? Share it with a friend.