Overview
Kerberos was developed at MIT in the 1980s as part of Project Athena — a networked computing environment where users needed to access services on different machines without sending passwords over the network. The name comes from the three-headed dog of Greek mythology, reflecting the three parties involved: the client, the server, and the trusted third party.
Kerberos version 5 (RFC 4120, 2005) is the current standard and is the default authentication protocol for Microsoft Active Directory. Every interactive Windows domain logon, every access to a file share, every Outlook connection to Exchange — all use Kerberos unless it falls back to NTLM.
UDP/TCP port 88.
The fundamental insight: instead of sending a password to every service you want to access, you authenticate once to a trusted authority and receive a ticket. You present that ticket to services — they verify it cryptographically — no password ever leaves your workstation after the initial logon.
The Three Parties
Client: The user or computer requesting access to a service.
KDC (Key Distribution Center): The trusted authority — in Active Directory, this is the Domain Controller. The KDC has two components:
- AS (Authentication Service): Handles initial user authentication
- TGS (Ticket Granting Service): Issues service tickets to authenticated users
Service (Application Server): The resource being accessed — a file server, a web application, SQL Server, etc.
The Kerberos Authentication Flow
Step 1 — AS Exchange (Get the TGT)
When a user logs in, the client sends an AS-REQ to the KDC containing the username and a timestamp encrypted with the user’s password hash (derived via PBKDF). The KDC looks up the user’s password hash, decrypts the timestamp, and verifies it is within the acceptable clock skew window (default: 5 minutes).
If valid, the KDC returns an AS-REP containing:
- A TGT (Ticket Granting Ticket) — encrypted with the KDC’s own secret key (the krbtgt account hash). The client cannot read this.
- A session key — encrypted with the user’s password hash. The client decrypts this using the password entered at login.
The TGT contains: username, validity period, the session key. The user’s password has now done its job and is no longer needed.
Step 2 — TGS Exchange (Get a Service Ticket)
When the user accesses a service (e.g., \\fileserver\share), the client sends a TGS-REQ to the KDC containing:
- The TGT (opaque to the client — passed through)
- The Service Principal Name (SPN) of the target service
- An authenticator — the current timestamp encrypted with the session key from Step 1
The KDC decrypts the TGT, retrieves the session key, uses it to decrypt the authenticator, and verifies the timestamp. If valid, it issues a service ticket encrypted with the service’s secret key (the service account’s password hash). The client cannot read this ticket either.
Step 3 — AP Exchange (Access the Service)
The client sends the service ticket and a new authenticator to the service in an AP-REQ. The service decrypts the ticket using its own password hash, retrieves the session key from the ticket, decrypts the authenticator, and verifies the timestamp.
If everything checks out, the service knows the client is who they claim to be — without ever contacting the KDC. This is the power of Kerberos: service authentication is offline. The service only needs its own password hash to validate a ticket.
Service Principal Names (SPNs)
An SPN is a unique identifier for a service instance. It tells Kerberos which service account a service ticket should be encrypted for. Format: ServiceClass/Host:Port/ServiceName
HTTP/webserver.nakamas-it.com ← IIS web site
MSSQLSvc/sqlserver.nakamas-it.com:1433 ← SQL Server
HOST/workstation01.nakamas-it.com ← Windows file sharing
cifs/fileserver.nakamas-it.com ← SMB file shareSPNs must be registered in Active Directory (under the service account object). Duplicate SPNs across the domain cause authentication failures.
Kerberos Tickets
Kerberos Ticket (encrypted — opaque to client)
TGT lifetime: Default 10 hours in Active Directory. Users can renew their TGT without re-entering their password for up to 7 days (configurable). After expiry, re-authentication is required.
Service ticket lifetime: Default 10 hours. Once a service ticket is issued, it is valid until expiry — even if the user’s account is disabled. This is why disabling a compromised account does not immediately revoke access to services that have already issued tickets.
Ticket flags: FORWARDABLE (ticket can be forwarded to another service), RENEWABLE, PRE-AUTHENT (pre-authentication was used), INITIAL (issued by AS, not TGS).
Clock Synchronisation Requirement
Kerberos timestamps are central to its replay attack prevention. The 5-minute clock skew tolerance means:
- All domain members must have clocks within 5 minutes of the KDC
- NTP synchronisation is mandatory in Kerberos environments
- A misconfigured clock → “KRB_AP_ERR_SKEW” errors → authentication failures
This is the reason domain controllers are authoritative NTP sources in Active Directory, and all domain-joined machines sync from the domain hierarchy.
Common Kerberos Attacks
Pass-the-Ticket: Stealing a valid Kerberos ticket from memory (using tools like Mimikatz) and reusing it on another machine. The ticket is valid until it expires — no password needed.
Kerberoasting: Requesting service tickets for any SPN in the domain (any authenticated user can do this), then attempting to crack the ticket offline. The ticket is encrypted with the service account’s password hash — weak service account passwords are vulnerable.
AS-REP Roasting: Accounts with “Do not require Kerberos pre-authentication” enabled return an AS-REP without verifying the client knows the password. The encrypted session key in the AS-REP can be cracked offline.
Golden Ticket: If the krbtgt account password hash is compromised (e.g., via DCSync), an attacker can forge arbitrary TGTs with any username, groups, and lifetime. Resetting krbtgt twice invalidates all existing TGTs.
Silver Ticket: Forging a service ticket using a compromised service account’s password hash. Does not require the krbtgt hash — more limited scope than a Golden Ticket but harder to detect (never contacts the KDC).