Kerberos Authentication Process¶
1. AS-REQ - Client Requests TGT¶
Client initiates authentication.
If pre-authentication is enabled, it sends PA-ENC-TIMESTAMP (a timestamp encrypted with the client’s long-term key); with PKINIT, a public-key exchange replaces the password-derived key.
If pre-auth is disabled, no timestamp is sent (enabling AS-REP roasting). The client may request TGT flags (e.g., forwardable/renewable); the KDC ultimately decides.
2. AS-REP - KDC sends TGT to the client¶
KDC validates pre-auth (timestamp within skew and not replayed) and account policy, then returns:
- A
TGTencrypted with thekrbtgtaccount’s long-term key. - A client enc-part containing the client–TGS session key (and ticket metadata) encrypted with the client’s key (password-derived or
PKINITresult).
3. TGS-REQ - Clients requests a Service Ticket (ST)¶
Client sends the TGT and an authenticator encrypted with the client–TGS session key, along with the target SPN and any requested flags (e.g., forwardable/renewable). The authenticator includes a timestamp to prevent replay.
4. TGS-REP - KDC sends ST to the client¶
KDC validates the TGT and authenticator, then returns:
- A
service ticketencrypted with the service account’s long-term key (in AD, typically contains a PAC). - A client enc-part with the client–service session key (and ticket metadata) encrypted with the client–TGS session key.
5. AP-REQ - Client sends ST to the service¶
Client presents the service ticket and an authenticator encrypted with the client–service session key. The service decrypts the ticket to recover the session key, validates the authenticator (and, in AD, the PAC via KDC or local verification), and authenticates the client.
6. AP-REP (optional) - Mutual authentication¶
If requested and allowed by policy/protocol, the service replies with AP-REP encrypted with the client–service session key to prove its identity.