Explain how Kerberos authentication works with TGTs and service tickets.
Short answer
Kerberos relies on a trusted Key Distribution Center (KDC). The client authenticates once to the Authentication Server and gets a Ticket-Granting Ticket (TGT) encrypted with the KDC's key. To reach a service, it presents the TGT to the Ticket-Granting Service and receives a service ticket encrypted with that service's key. The service decrypts and trusts it. Passwords never traverse the network, and tickets are time-limited.
Kerberos is the backbone of Active Directory authentication, so this is a staple for anyone touching enterprise environments. The interviewer wants the three-party model and why passwords stay off the wire.
The players
- Client — the user or machine wanting access.
- KDC (Key Distribution Center) — the trusted authority, split into the Authentication Server (AS) and the Ticket-Granting Service (TGS). It knows every principal's secret key.
- Service — the resource the client wants (a file share, SQL server, web app).
The ticket dance
- Get a TGT. The client proves it knows its password by encrypting a timestamp with a key derived from that password. The AS validates it and returns a Ticket-Granting Ticket (TGT) plus a session key. The TGT is encrypted with the KDC's own key, so the client can't read or forge it.
- Request a service ticket. When the client wants a specific service, it sends the TGT to the TGS. The TGS issues a service ticket encrypted with that service's secret key.
- Access the service. The client presents the service ticket. The service decrypts it with its own key, confirms the contents, and grants access — without ever contacting the KDC itself.
The crucial property: the user's password is used only locally to derive a key; it never crosses the network, and services never see it. Timestamps in tickets, validated against synchronized clocks, prevent replay — which is why Kerberos is sensitive to time skew (typically a 5-minute tolerance).
The attacker's angle
Because a service ticket is encrypted with the service account's key, an attacker who requests one can crack it offline to recover that account's password — this is Kerberoasting, and weak service-account passwords make it cheap. Compromising the KDC's master key (the krbtgt account) enables golden tickets: arbitrary forged TGTs.
What interviewers look for
The KDC/AS/TGS roles, the TGT-then-service-ticket exchange, "passwords never cross the network," the role of timestamps and clock sync, and ideally Kerberoasting as the practical attack.
Likely follow-ups
- What is Kerberoasting and how does it abuse service tickets?
- Why does Kerberos depend heavily on synchronized clocks?
- What is a golden ticket and what does it require an attacker to have?