What is a Ticket Granting Ticket (TGT), what does it contain, and why can the client not read it?
The TGT is the AS's proof that the user logged in; it contains the user ID, the name of the TGS, a timestamp, its lifetime (around 10 hours) and the TGS session key, and it is encrypted with the KDC's own key, so only the KDC can open it.
Contents:
- User ID (client principal) and optionally network addresses
- Name of the TGS it is valid for (the
krbtgtservice) - Timestamp and lifetime (typically around a working day; Windows' default is 10 hours)
- TGS session key
The client stores the TGT encrypted in its credential cache and simply hands it back to the TGS whenever it needs a new service ticket. It cannot read or change it, which is the point: the TGT is a sealed note from the AS to the TGS, carried by the client. A forged or modified TGT would not decrypt correctly with the KDC's key.
That design also lets the KDC stay stateless: the TGS does not have to remember which sessions exist; everything it needs (who the user is, which session key to use, until when it is valid) arrives inside the TGT itself.
Go deeper:
RFC 4120, Section 5.3: Tickets — the exact fields of a ticket, encrypted and unencrypted parts.- Microsoft Learn: Maximum lifetime for user ticket — the 10-hour default for TGTs in a Windows domain.