↓Skip to main content
  1. posts/

Kerberos in Active Directory

·4 mins
Table of Contents
cerberus

Introduction #

Before diving into Active Directory (AD) attacks, it’s important to understand the basics of Kerberos. This post breaks down the Kerberos protocol and how it works.

What is Kerberos #

  • Kerberos is the authentication protocol used in AD that lets users and services prove identity to each other without sending passwords over the network.
  • The name comes from Cerberus in Greek mythology, the multi-headed dog that guards the gates of the Underworld.

Terminology #

1. Kerberos Realm
The administrative domain where Kerberos issues and validates tickets. Realms can be linked via trusts.

2. Principals
Unique identities in the realm (users, computers, or services).

3. Client / User
The entity requesting access to a service.

4. Service
The resource a client wants to access (file server, database, web app).

5. Key Distribution Center (KDC)
Issues tickets and session keys; stores symmetric secrets for users and services.
The KDC exposes two logical services:

  1. Authentication Service (AS)
  2. Ticket Granting Service (TGS)

6. Authentication Service (AS)
Validates initial authentication requests and issues the Ticket-Granting Ticket (TGT).

7. Ticket Granting Service (TGS)
Validates a TGT and issues service tickets for specific services.

Messages & Artifacts #

1. Ticket
Contains client identity, target service, session key, timestamps, lifetime, etc.

  • TGTs are encrypted with the krbtgt key.
  • Service tickets are encrypted with the service account key.

2. Authenticator
A short structure (usually timestamped) encrypted with the session key to prove freshness and prevent replay attacks.

Kerberos Communication Flow #

AS-REQ → AS-REP (TGT) #

  1. Client requests a TGT from the AS.
  2. If validated, AS issues a TGT (encrypted with the KDC key) and a message encrypted for the client containing the TGS session key.

TGS-REQ → TGS-REP (Service Ticket) #

  1. Client presents the TGT to the TGS and requests a service ticket for a specific SPN.
  2. If validated, TGS issues a service ticket encrypted with the service account key and a service session key for client–service communication.

AP-REQ → AP-REP (Client → Service) #

  1. Client sends the service ticket and an authenticator to the target service.
  2. The service decrypts the ticket, validates the authenticator, and (optionally) replies with its own authenticator to complete mutual authentication.

All messages use symmetric encryption and timestamps to prevent replay and tampering. The client’s password is never sent over the network.

Initial (Unencrypted) Request #

The first request (AS-REQ) contains:

  • User principal name (e.g., rob@REALM)
  • Service principal name (TGS service)
  • Client address (optional)
  • Requested ticket lifetime (KDC enforces policy)

The client’s requested lifetime is advisory; the KDC determines the actual ticket lifetime.

What the AS Returns #

1. Encrypted Client Message

  • Contains the TGS session key and metadata (timestamp, lifetime)
  • Encrypted with the client’s secret (derived from the password)

2. Ticket-Granting Ticket (TGT)

  • Contains client identity, TGS identity, timestamp, client address, lifetime, and TGS session key
  • Encrypted with the KDC’s krbtgt key (client cannot decrypt)

The client uses its secret to decrypt the client message, obtaining the TGS session key, which allows it to request service tickets from the TGS.

TGS Exchange (Brief) #

  1. Client sends TGT and TGS-REQ (including target SPN), encrypted with the TGS session key.

  2. TGS validates TGT, creates a service ticket (encrypted with service account key), and returns:

    • Service ticket
    • Service session key (encrypted with TGS session key)

  3. Client decrypts the first message to get the service session key and creates a new Authenticator:

    • Contains user ID and timestamp
    • Encrypted with the service session key
    • Sent along with the service ticket to the service

Service Validation #

  1. Service decrypts service ticket with its secret key → obtains service session key.

  2. Service decrypts authenticator with service session key.

  3. Service validates:

    • User ID matches
    • Timestamp difference ≤ 2 minutes
    • IP address matches (if provided)
    • Ticket has not expired

  4. Replay protection: checks service cache of recent authenticators.

  5. If valid, service creates its own Authenticator:

    • Contains service name/ID and timestamp
    • Encrypted with service session key
    • Sent to the client to complete mutual authentication

Once the client receives and decrypts this authenticator, Kerberos authentication is successfully completed.

Conclusion #

  • Understanding Kerberos is fundamental for anyone working with Active Directory. It is the backbone of secure authentication in AD, enabling users and services to prove their identity without transmitting passwords over the network.

  • By grasping the flow of tickets, authenticators, and session keys, as well as the roles of the AS, TGS, and service—you gain insight not only into how authentication works but also into potential attack vectors that adversaries may exploit.

↑