Understanding Kerberos Ticket-Granting

Introduction

Kerberos is an authentication protocol invented at MIT in the 1980s and adopted by Microsoft Active Directory as the primary authentication mechanism for domain-joined Windows systems. Its elegance lies in enabling network single sign-on using only symmetric key cryptography — your password never traverses the network. Instead, Kerberos proves your identity through a chain of encrypted tickets issued by a trusted third party: the Key Distribution Center (KDC).

Key Components

KDC (Key Distribution Center):
  ├── AS (Authentication Service): Issues Ticket-Granting Tickets (TGTs)
  └── TGS (Ticket-Granting Service): Issues service tickets

Principal: Any entity (user, service) with a Kerberos identity
Ticket-Granting Ticket (TGT): Proof of identity to the KDC, valid typically 10 hours
Service Ticket (ST): Authorization to access a specific service
SPN (Service Principal Name): Unique service identifier (e.g., HTTP/server.corp.com)

Step-by-Step: Kerberos Authentication Flow

flowchart TD
    A["1. AS Exchange (Login)"]
    B["2. TGS Exchange (Request Service Ticket)"]
    C["3. AP Exchange (Service Access)"]
    D["4. Kerberos in Windows/Linux"]
    E["5. Attack Vectors"]
    A --> B
    B --> C
    C --> D
    D --> E

Step 1: AS Exchange (Login)

Client → AS: AS-REQ
  Contains: Username (plaintext), timestamp encrypted with password-derived key
  
AS:
  1. Looks up user's long-term key (derived from password hash)
  2. Decrypts timestamp — if valid, user is authenticated
  3. Generates session key: K_client-TGS

AS → Client: AS-REP
  Part 1 (encrypted with K_client): Session key K_client-TGS + TGS server name
  Part 2 (TGT, encrypted with TGS secret key): Username + K_client-TGS + timestamp + lifetime
  
Client: Decrypts Part 1 with its key, stores TGT opaquely (cannot read it — encrypted for TGS)

The password is used only to decrypt the AS response — never transmitted.

Step 2: TGS Exchange (Request Service Ticket)

When the client wants to access a service (e.g., a file server):

Client → TGS: TGS-REQ
  Contains:
    - TGT (opaque — encrypted for TGS, client can't read it)
    - Authenticator: username + timestamp encrypted with K_client-TGS
    - Requested SPN: CIFS/fileserver.corp.com

TGS:
  1. Decrypts TGT with its secret → extracts K_client-TGS and username
  2. Decrypts Authenticator with K_client-TGS → verifies username matches TGT
  3. Checks timestamp (±5 minutes tolerance — Kerberos requires clock sync!)
  4. Generates service session key: K_client-service

TGS → Client: TGS-REP
  Part 1 (encrypted with K_client-TGS): K_client-service + service name
  Part 2 (Service Ticket, encrypted with service's secret key): Username + K_client-service

Step 3: AP Exchange (Service Access)

Client → Service: AP-REQ
  Contains:
    - Service Ticket (opaque — encrypted for service with service key)
    - Authenticator: username + timestamp encrypted with K_client-service

Service:
  1. Decrypts Service Ticket with its secret → extracts K_client-service
  2. Decrypts Authenticator → verifies username matches Service Ticket
  3. Checks timestamp within ±5 minutes
  4. Client is authenticated!

Optional mutual authentication:
Service → Client: AP-REP (timestamp encrypted with K_client-service)
  → Client verifies service has the session key → mutual auth complete

Step 4: Kerberos in Windows/Linux

# Linux: Obtain TGT
kinit alice@CORP.EXAMPLE.COM
# Prompts for password → fetches TGT → stores in credential cache

# List tickets
klist
# Credentials cache: FILE:/tmp/krb5cc_1000
# Principal: alice@CORP.EXAMPLE.COM
# Issued            Expires           Principal
# Jan 15 09:00:00   Jan 15 19:00:00   krbtgt/CORP.EXAMPLE.COM

# Access Kerberized service
curl --negotiate -u : https://kerberized-service.corp.example.com/api/data

Step 5: Attack Vectors

Pass-the-Ticket: Steal TGT from memory (Mimikatz), use on attacker machine
  Defense: Credential Guard, restrict debug privileges

Kerberoasting: Request service tickets for SPNs, crack offline
  SPN with weak service account password → offline dictionary attack
  Defense: Long random passwords (>25 chars) for service accounts, use gMSA

Golden Ticket: Forge TGTs using krbtgt hash (domain persistence)
  Requires domain admin or DC compromise
  Defense: Rotate krbtgt password twice after compromise

AS-REP Roasting: For accounts with pre-authentication disabled
  Defense: Require pre-authentication for all accounts (default)

Key Takeaways

• Kerberos authenticates without transmitting passwords — authentication proves possession of the password-derived key through symmetric encryption.
• The TGT (Ticket-Granting Ticket) enables single sign-on — authenticate once, receive service tickets for any Kerberized service for the TGT lifetime.
• ±5 minute clock skew tolerance is mandatory — Kerberos requires NTP synchronization across all hosts in the domain.
• Kerberoasting exploits weak service account passwords — mitigate with Group Managed Service Accounts (gMSA) which auto-rotate passwords.
• Golden Ticket attacks persist after password resets by forging TGTs with the krbtgt hash — rotate krbtgt twice and monitor for anomalous TGT lifetimes.