How Kerberos Authentication Works: Tickets, KDCs, and Why It Matters for Security

What Kerberos Is and Why It Exists

Kerberos is a network authentication protocol that lets a user prove their identity once and then access multiple services without re-entering credentials. It was designed at MIT in the 1980s, named after the three-headed dog guarding the gates of the Greek underworld, and it is the default authentication mechanism in every Active Directory domain since Windows 2000.

The problem it solves is straightforward. In a network with dozens of services - file servers, mail servers, databases, intranet sites - asking users to authenticate separately to each one is impractical. Sending passwords across the network for every request is dangerous. Kerberos eliminates both issues by using encrypted tickets that prove the user's identity without transmitting the password after the initial login.

If you have ever logged into a Windows domain workstation and then opened a network share without being prompted for credentials again, Kerberos did that. If you have used single sign-on (SSO) in a corporate environment, Kerberos was almost certainly involved. It runs silently underneath, and most users never know it exists until something breaks.

Understanding Kerberos matters for security research because it is the authentication backbone of corporate networks. The majority of Active Directory attacks - pass-the-ticket, golden ticket, Kerberoasting, silver ticket - exploit Kerberos specifically. You cannot assess an AD environment without understanding how Kerberos works at the protocol level.

The Three Parties: Client, KDC, and Service

Every Kerberos transaction involves three entities:

The Client is the user or machine requesting access to a service. On a domain workstation, this is the logged-in user's security context.

The Key Distribution Center (KDC) is the trusted third party. In Active Directory, the KDC runs on every domain controller. The KDC has two logical components:

• The Authentication Service (AS) handles the initial login and issues Ticket-Granting Tickets (TGTs).
• The Ticket-Granting Service (TGS) issues service tickets for specific resources when presented with a valid TGT.

The Service is whatever the client wants to access - a file share (CIFS/SMB), a web application (HTTP), a SQL Server database (MSSQLSvc), or any other Kerberos-aware service.

The critical design principle: the client never sends a password to the service, and the service never contacts the KDC during authentication. The entire system works through pre-encrypted tickets that each party can validate independently using shared secrets.

Step 1: The Authentication Service Exchange

This is the initial login. The user sits down at a workstation and types their domain credentials.

AS-REQ (Authentication Service Request): The client sends a request to the KDC's Authentication Service. This message contains the user's principal name (username@DOMAIN) and a timestamp encrypted with a key derived from the user's password. The encrypted timestamp is the "pre-authentication" data - it proves the client knows the password without sending the password itself.

The KDC looks up the user in its database, retrieves the password hash (stored as an NTLM hash or AES key), and attempts to decrypt the timestamp. If the timestamp decrypts correctly and is within the clock skew tolerance (default: 5 minutes), the user is authenticated.

AS-REP (Authentication Service Reply): The KDC sends back two things:

• A Ticket-Granting Ticket (TGT) encrypted with the KDC's own secret key (the krbtgt account hash). The client cannot read this - it is opaque data that only the KDC can decrypt.
• A session key encrypted with the user's password-derived key. The client decrypts this to get a temporary key for communicating with the TGS.

The TGT contains the user's identity, group memberships (PAC - Privilege Attribute Certificate), the session key, and an expiration time (default: 10 hours). The client stores the TGT in memory and uses it for all subsequent ticket requests.

sequenceDiagram
    participant U as User/Client
    participant AS as KDC: Authentication Service
    participant DB as KDC Database
    
    U->>U: User types username + password
    U->>U: Derive key from password (AES256 or RC4)
    U->>U: Encrypt current timestamp with key
    U->>AS: AS-REQ: username, encrypted timestamp
    AS->>DB: Look up user's password hash
    DB->>AS: Return stored hash
    AS->>AS: Decrypt timestamp with stored hash
    AS->>AS: Verify timestamp within 5-min skew
    AS->>AS: Generate random session key
    AS->>AS: Build TGT (user info + PAC + session key)
    AS->>AS: Encrypt TGT with krbtgt hash
    AS->>U: AS-REP: encrypted TGT + session key encrypted with user's key
    U->>U: Decrypt session key with password-derived key
    U->>U: Store TGT + session key in credential cache
    Note over U: Password no longer needed - TGT is the proof of identity

The AS exchange - the user authenticates once with their password, receives a TGT and session key, and never sends the password again for the duration of the ticket's lifetime

Step 2: The Ticket-Granting Service Exchange

Now the user wants to access a specific service - say, a file share on \\fileserver01\finance. The client needs a service ticket for that specific server.

TGS-REQ (Ticket-Granting Service Request): The client sends the TGT (still encrypted with the krbtgt hash - the client cannot modify it) along with an authenticator encrypted with the session key from Step 1. The authenticator contains the user's principal name and a timestamp, proving the client actually possesses the session key.

The KDC decrypts the TGT with its krbtgt key, extracts the session key, and uses it to decrypt the authenticator. If the authenticator's timestamp is fresh and the principal name matches, the request is valid.

TGS-REP (Ticket-Granting Service Reply): The KDC builds a service ticket encrypted with the target service's password hash (the computer account password hash for fileserver01$). The client receives:

• The service ticket (encrypted with the service's key - opaque to the client)
• A new service session key (encrypted with the TGS session key from Step 1)

The service ticket contains the user's identity, PAC, and the service session key. The client cannot read or modify it because it is encrypted with the service's key, which the client does not possess.

Step 3: The Application Service Exchange

AP-REQ (Application Request): The client connects to the target service (fileserver01) and presents the service ticket along with a new authenticator encrypted with the service session key.

The service decrypts the ticket using its own password hash, extracts the service session key, and decrypts the authenticator. If everything checks out, the user is authenticated. The service now knows who the user is and what groups they belong to (from the PAC), without ever contacting the KDC.

AP-REP (Application Reply, optional): If mutual authentication is requested, the service sends back the timestamp from the authenticator encrypted with the service session key. This proves to the client that the service is legitimate - not a rogue service impersonating the real one.

From start to finish, the password crossed the network zero times. The KDC was contacted twice (Steps 1 and 2) but never by the service itself. The service validated the ticket independently using its own key.

sequenceDiagram
    participant C as Client
    participant KDC as KDC (DC)
    participant SVC as File Server

    Note over C: Already has TGT from AS exchange

    C->>KDC: TGS-REQ: TGT + authenticator + target SPN
    KDC->>KDC: Decrypt TGT with krbtgt key
    KDC->>KDC: Validate authenticator with session key
    KDC->>KDC: Build service ticket with user PAC
    KDC->>KDC: Encrypt service ticket with service's key
    KDC->>C: TGS-REP: service ticket + service session key

    Note over C: Client now has a ticket for the file server

    C->>SVC: AP-REQ: service ticket + authenticator
    SVC->>SVC: Decrypt ticket with own password hash
    SVC->>SVC: Extract session key + user identity + PAC
    SVC->>SVC: Validate authenticator timestamp
    SVC->>C: AP-REP: mutual auth confirmation
    SVC->>SVC: Check PAC group memberships for authorization
    
    Note over C,SVC: Session established - user can access files

The complete TGS and AP exchange - the client gets a service-specific ticket from the KDC, then presents it directly to the file server, which validates it without contacting the KDC

Why Tickets Instead of Passwords

The ticket system solves several problems that password-based authentication cannot:

Password never crosses the wire. After the initial AS exchange, the password is not used again. Even the initial exchange does not send the password - it sends a timestamp encrypted with a key derived from the password. An attacker sniffing network traffic never sees the password in any form.

Single sign-on. The TGT lasts 10 hours by default. During that time, the user can access any service in the domain without re-authenticating. The client silently requests service tickets as needed.

Mutual authentication. The AP-REP proves the service is who it claims to be. A rogue server cannot produce a valid AP-REP because it does not possess the real service's password hash.

Limited exposure window. Service tickets are short-lived (default: 10 hours). Even if intercepted, they expire. The session keys are unique per ticket, so capturing one does not compromise others.

No service-side credential storage. The service does not store user passwords. It validates tickets using its own key. A compromised service does not leak user credentials.

Service Principal Names

When the client requests a service ticket, it specifies the target service using a Service Principal Name (SPN). An SPN uniquely identifies a service instance in the domain. The format is:

serviceclass/hostname:port

Examples:

• CIFS/fileserver01.corp.example.com - SMB file share
• HTTP/intranet.corp.example.com - web service
• MSSQLSvc/sqlserver.corp.example.com:1433 - SQL Server
• krbtgt/CORP.EXAMPLE.COM - the TGT service itself

SPNs are registered in Active Directory on the account that runs the service. When a client requests a ticket for MSSQLSvc/sqlserver:1433, the KDC looks up which account has that SPN registered and encrypts the service ticket with that account's password hash.

This matters for security because any domain user can query AD for accounts with SPNs registered. If a service runs under a regular user account (not a machine account), the service ticket is encrypted with that user's password hash - which can be cracked offline. This is the basis of the Kerberoasting attack.

Delegation and Constrained Delegation

Delegation solves the "double hop" problem. A user connects to a web server, and the web server needs to access a database on behalf of that user. Without delegation, the web server would need its own credentials for the database - it could not act as the user.

Unconstrained delegation allows a service to impersonate the user to any other service. The KDC includes a forwardable TGT in the service ticket. The web server can use this TGT to request service tickets for any service as the user. This is extremely powerful and extremely dangerous - if an attacker compromises a server with unconstrained delegation, they can impersonate any user who connects to it.

Constrained delegation limits which services the delegating server can access. The server can only obtain service tickets for a specific list of SPNs. This reduces the blast radius of a compromised server.

Resource-based constrained delegation (RBCD) flips the model. Instead of the delegating server's AD object listing which services it can delegate to, the target service's AD object lists which servers are allowed to delegate to it. This is configured via the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

Attacks Against Kerberos

Kerberos is well-designed but not invulnerable. The major attack classes:

Kerberoasting. Any domain user can request service tickets for any SPN. The ticket is encrypted with the service account's password hash. The attacker extracts the ticket and cracks it offline with hashcat (mode 13100 for RC4, 19700 for AES). If the service account has a weak password, the attacker recovers it. Machine accounts are not vulnerable because their passwords are 120+ character random strings. Human-managed service accounts with weak passwords are the target.

AS-REP Roasting. If an account has Kerberos pre-authentication disabled (a misconfiguration), the KDC sends back an AS-REP encrypted with the user's password hash without verifying the user knows the password. The attacker can request AS-REPs for these accounts and crack them offline. This targets accounts with the "Do not require Kerberos preauthentication" flag set in AD.

Golden Ticket. If an attacker obtains the krbtgt account's password hash (by compromising a domain controller), they can forge TGTs for any user with any group memberships - including Domain Admin. The forged TGT is valid for as long as the attacker chooses. This is the most devastating AD attack because it gives persistent, undetectable domain admin access until the krbtgt password is rotated twice.

Silver Ticket. Similar to a golden ticket but forges a service ticket instead of a TGT. The attacker needs the target service's password hash (not the krbtgt hash). A silver ticket gives access to a specific service as any user. It never touches the KDC, making it harder to detect than a golden ticket.

Pass-the-Ticket. Extracting Kerberos tickets from memory (using tools like Mimikatz or Rubeus) and injecting them into another session. If you steal a user's TGT from a compromised workstation, you can impersonate that user from your own machine for the remaining lifetime of the ticket.

graph TD
    subgraph "Credential Theft"
        PTT[Pass-the-Ticket] --> STEAL[Extract TGT from memory]
        STEAL --> INJECT[Inject into attacker session]
        INJECT --> IMPERSONATE[Impersonate user until ticket expires]
    end
    
    subgraph "Offline Cracking"
        KERB[Kerberoasting] --> REQTKT[Request service ticket for any SPN]
        REQTKT --> EXTRACT[Extract encrypted ticket]
        EXTRACT --> CRACK[hashcat -m 13100 / 19700]
        CRACK --> SVCPWD[Service account password]
        
        ASREP[AS-REP Roasting] --> NOPRE[Find accounts with no pre-auth]
        NOPRE --> REQAS[Request AS-REP]
        REQAS --> CRACK2[hashcat -m 18200]
        CRACK2 --> USERPWD[User password]
    end
    
    subgraph "Ticket Forgery"
        GOLDEN[Golden Ticket] --> GETKRB[Obtain krbtgt hash]
        GETKRB --> FORGETGT[Forge TGT as any user]
        FORGETGT --> DOMADMIN[Persistent domain admin]
        
        SILVER[Silver Ticket] --> GETSVCHASH[Obtain service hash]
        GETSVCHASH --> FORGESVC[Forge service ticket]
        FORGESVC --> SVCACCESS[Access specific service as any user]
    end

Kerberos attack taxonomy - credential theft reuses legitimate tickets, offline cracking targets weak service account passwords, and ticket forgery creates fake tickets from compromised key material

Detection and Defense

Defending Kerberos-based attacks requires overlapping controls:

Against Kerberoasting: Use Group Managed Service Accounts (gMSAs) wherever possible - they have 120-character random passwords that rotate automatically. For accounts that must use traditional passwords, enforce 25+ character passwords. Monitor for anomalous TGS-REQ volume from single accounts (Event ID 4769).

Against AS-REP Roasting: Ensure all accounts have Kerberos pre-authentication enabled. Audit accounts with the flag disabled regularly. There is rarely a legitimate reason to disable pre-authentication.

Against Golden Tickets: Rotate the krbtgt password twice (the first rotation updates the current key; the second invalidates the previous key). Monitor for TGTs with abnormally long lifetimes or invalid PAC signatures. Implementing Privileged Access Workstations (PAWs) limits where domain admin credentials are exposed.

Against Pass-the-Ticket: Enable Credential Guard on Windows 10/11 endpoints to protect ticket caches. Limit domain admin logons to domain controllers only. Use tiered administration models so a compromise at one tier does not cascade.

General hardening: Enforce AES encryption (disable RC4 where possible - RC4 tickets are easier to crack). Enable Kerberos armoring (FAST). Set maximum ticket lifetimes to the minimum acceptable for your environment. Audit delegation configurations and remove unconstrained delegation from all servers except domain controllers.

Kerberos has been the default authentication protocol for enterprise Windows networks for over two decades. It is a well-designed system that eliminates password transmission and enables single sign-on. But its security depends on the secrecy of specific key material - the krbtgt hash, service account passwords, and machine account keys. When any of these are compromised, the entire trust model breaks down.

For wireless security assessments, Kerberos often comes into scope when testing corporate WiFi with 802.1X/PEAP authentication. The BLEShark Nano's WiFi scanning and handshake capture capabilities can identify which authentication protocols a network uses. When you see RADIUS traffic pointing to Active Directory, Kerberos is in the picture - and understanding how it works helps you assess the full attack surface from wireless entry point to domain compromise.

Get the BLEShark Nano - $36.99+