How Kerberos Works: Ticket-Based Authentication Without Sending Passwords

Kerberos is a ticket-based network authentication protocol that allows users and services to prove their identity to each other without transmitting passwords over the network. Named after the three-headed dog guarding the gates of Hades in Greek mythology, Kerberos was developed at MIT in the 1980s and is now the default authentication protocol in every Active Directory environment. When you log into a Windows domain-joined computer and seamlessly access file shares, printers, and intranet applications without entering your password again, Kerberos is issuing tickets behind the scenes. Kerberos v5 is defined in RFC 4120 (2005) and is implemented across all major operating systems.

The Problem: Authenticating on an Untrusted Network

In a networked environment, authenticating users and services presents fundamental challenges:

• Password transmission — Sending passwords over the network exposes them to eavesdropping. Even with encryption, every service receiving the password becomes a potential leak point.
• Credential reuse — If a user authenticates to 20 different services, 20 services see the password. Each one is a potential breach vector.
• Mutual authentication — The user needs to prove their identity to the service, but the service also needs to prove its identity to the user. Without mutual authentication, a rogue server can impersonate a legitimate service.
• Scalability — In an organization with N users and M services, managing shared secrets between every user-service pair requires N x M credentials. This does not scale.

Kerberos solves these by introducing a trusted third party — the Key Distribution Center (KDC) — that both users and services trust. Users authenticate once to the KDC and receive tickets that prove their identity to individual services. Passwords never traverse the network after the initial authentication.

Kerberos Architecture

The Kerberos system has three main components:

• Key Distribution Center (KDC) — The central authentication authority. It consists of two logical services (usually running on the same server):
  • Authentication Service (AS) — Handles initial user authentication and issues Ticket-Granting Tickets (TGTs).
  • Ticket-Granting Service (TGS) — Issues service tickets based on valid TGTs.
• Client — The user or process requesting authentication. On a Windows domain, this is the workstation running the user's session.
• Service (Application Server) — The resource the client wants to access: a file server, web application, database, or any Kerberos-aware service.

Every participant in the Kerberos realm shares a long-term key with the KDC. For users, this key is derived from their password. For services, it is a randomly generated key stored in a keytab file. The KDC has a database containing the keys for every principal (user or service) in the realm.

The Three Exchanges

Phase 1: Authentication Service (AS) Exchange

The client authenticates to the KDC and obtains a Ticket-Granting Ticket (TGT):

1. AS-REQ — The client sends an Authentication Service Request containing: the user's principal name ([email protected]), a timestamp encrypted with the user's long-term key (derived from their password), and the requested TGT lifetime.
2. Pre-authentication — The KDC looks up the user's key in its database and attempts to decrypt the timestamp. If it decrypts to a valid time (within the allowed clock skew), the user's identity is confirmed without the password ever being sent.
3. AS-REP — The KDC responds with two items:
   • A TGT — encrypted with the KDC's own key (krbtgt). The client cannot read or modify the TGT; it is opaque to the client.
   • A session key — encrypted with the user's key (so only the user can decrypt it). This session key will be used in subsequent TGS requests.

After this exchange, the client has a TGT and a session key, both stored in a credential cache (on Linux, typically /tmp/krb5cc_<uid> or a kernel keyring; on Windows, in LSASS memory). The password-derived key is discarded — it is no longer needed until the TGT expires (typically 10 hours in AD).

Phase 2: Ticket-Granting Service (TGS) Exchange

When the client wants to access a service, it requests a service ticket from the TGS:

1. TGS-REQ — The client sends: the TGT (still encrypted with the KDC's key), the name of the target service (the Service Principal Name, e.g., HTTP/[email protected]), and an authenticator (username + timestamp encrypted with the TGT session key, proving the client knows the session key).
2. TGS-REP — The TGS decrypts the TGT using its own key, extracts the session key, uses it to verify the authenticator, then generates:
   • A service ticket — encrypted with the target service's key (which the KDC knows from its database). Contains the client's identity, the session key for client-service communication, and authorization data (in AD, this includes the user's group memberships via the PAC — Privilege Attribute Certificate).
   • A new session key — encrypted with the TGT session key, for the client-service communication.

The client can obtain multiple service tickets using the same TGT without re-entering the password. This is the "single sign-on" experience: authenticate once, access many services.

Phase 3: Application (AP) Exchange

The client presents the service ticket to the application server:

1. AP-REQ — The client sends the service ticket (encrypted with the service's key) and an authenticator (timestamp encrypted with the service session key).
2. The service decrypts the ticket using its keytab, extracts the session key, and verifies the authenticator. The service now knows the client's identity.
3. AP-REP (optional) — If mutual authentication is requested, the service encrypts the client's timestamp with the session key and returns it. The client verifies this to confirm it is talking to the legitimate service, not an impostor.

The critical security property: the user's password was never sent to the application server. The service only receives a ticket that proves the KDC authenticated the user. If the service is compromised, the attacker gets the service's own keytab (which can impersonate that specific service) but not the user's password or TGT.

Service Principal Names (SPNs)

A Service Principal Name (SPN) uniquely identifies a service instance in a Kerberos realm. The format is:

service-class/hostname[:port][@REALM]

Examples:

• HTTP/[email protected] — A web server
• MSSQLSvc/db.example.com:[email protected] — A SQL Server instance
• cifs/[email protected] — A Windows file share (CIFS/SMB)
• ldap/[email protected] — An LDAP directory service
• host/[email protected] — A host service (SSH, remote management)

In Active Directory, SPNs are registered as attributes on the service's AD account. The setspn command manages SPN registrations. Duplicate SPNs cause authentication failures because the KDC cannot determine which service account's key to use for encrypting the service ticket.

The PAC: Privilege Attribute Certificate

In Active Directory environments, Kerberos tickets contain a PAC (Privilege Attribute Certificate) — a Microsoft-specific extension that carries the user's authorization data: Security Identifier (SID), group memberships, and other security attributes.

The PAC is embedded in the ticket's authorization-data field and is signed by both the KDC's key and the target service's key. The service extracts the PAC to make authorization decisions (e.g., "is this user a member of the Domain Admins group?") without making additional calls to the domain controller.

The PAC has been the target of critical vulnerabilities. The most notable is MS14-068 (CVE-2014-6324), where a flaw in PAC signature validation allowed a regular domain user to forge a PAC claiming Domain Admin membership. An attacker could authenticate as a low-privilege user, modify the PAC in their TGT to include Domain Admins, and gain full domain control.

Delegation: Constrained and Unconstrained

Kerberos delegation allows a service to act on behalf of a user when accessing other services. This is essential for multi-tier applications where a web frontend needs to access a database server as the authenticated user.

Unconstrained Delegation

A service configured for unconstrained delegation receives a copy of the user's TGT along with the service ticket. The service can use this TGT to request tickets for any service as the user — essentially impersonating the user for any purpose.

This is extremely dangerous. If an attacker compromises a server with unconstrained delegation, they obtain TGTs for every user who authenticates to that server. With a domain admin's TGT, the attacker has full domain control. Unconstrained delegation should be avoided in modern environments.

Constrained Delegation

Constrained delegation limits which services a delegated service can access. The service's AD account has an msDS-AllowedToDelegateTo attribute listing the specific SPNs it can delegate to. The KDC checks this list and refuses to issue tickets for any service not in the list.

Constrained delegation comes in two forms:

• Traditional (with protocol transition) — The service uses the S4U2Self (Service for User to Self) extension to obtain a ticket on behalf of a user without that user authenticating via Kerberos, then uses S4U2Proxy to present that ticket to the KDC for a service ticket to the target service. This allows Kerberos delegation even when the user authenticated via a non-Kerberos method (like forms-based authentication).
• Resource-Based Constrained Delegation (RBCD) — Instead of configuring delegation on the front-end service, the target service controls who can delegate to it via the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. This is more flexible because the target service owner controls their own delegation policy.

Kerberoasting

Kerberoasting is an attack that exploits the fact that service tickets are encrypted with the service account's password hash. Any authenticated domain user can request a service ticket for any service with an SPN registered — the KDC does not check whether the requesting user is authorized to access the service. The TGS simply issues the ticket.

The attack works like this:

1. The attacker enumerates user accounts with SPNs registered (these are service accounts running under user accounts, not machine accounts).
2. The attacker requests a service ticket for each SPN.
3. The attacker extracts the ticket's encrypted data and performs offline brute-force/dictionary attacks to recover the service account's password.

Kerberoasting is effective because:

• Service accounts often have weak passwords (set once and never changed).
• Service accounts often have elevated privileges (e.g., a SQL Server service account that is also a Domain Admin).
• The attack is stealthy — requesting service tickets is normal activity that generates minimal logging by default.

Defenses include:

• Use Group Managed Service Accounts (gMSA), which have automatically rotated, 120-character random passwords that are practically impossible to brute-force.
• Set strong passwords (25+ characters) on any service accounts that cannot use gMSA.
• Use AES encryption for service account tickets (AES-256 is significantly harder to crack offline than RC4/NTLM).
• Monitor for anomalous TGS requests — a user requesting tickets for many SPNs in a short time is likely Kerberoasting.

Other Kerberos Attacks

• AS-REP Roasting — Targets accounts that have pre-authentication disabled. Without pre-authentication, anyone can request an AS-REP for the account, which is encrypted with the user's password hash — enabling offline cracking. Defense: never disable pre-authentication.
• Golden Ticket — If an attacker obtains the krbtgt account's password hash (from a domain controller compromise), they can forge TGTs for any user, including non-existent users with any group memberships. A golden ticket gives unlimited, persistent access to every resource in the domain. Defense: rotate the krbtgt password twice to invalidate existing golden tickets.
• Silver Ticket — If an attacker obtains a service account's password hash, they can forge service tickets for that specific service without contacting the KDC. Harder to detect because no TGS request is generated. Defense: enable PAC validation on the service so it checks the PAC signature with the KDC.
• Pass-the-Ticket — An attacker exports Kerberos tickets from memory (using tools like Mimikatz) and imports them on another machine to impersonate the ticket's owner. Defense: protect LSASS memory, use Credential Guard on Windows.

SPNEGO and Kerberos in Web Applications

SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) is the protocol that enables Kerberos authentication in web browsers. When you access an intranet site and are automatically logged in without entering credentials, SPNEGO is negotiating Kerberos authentication between your browser and the web server.

The flow:

1. The browser sends an HTTP request to the web server.
2. The server responds with 401 Unauthorized and WWW-Authenticate: Negotiate.
3. The browser obtains a Kerberos service ticket for the web server's SPN (HTTP/web.example.com).
4. The browser wraps the ticket in a SPNEGO token and sends it in the Authorization: Negotiate YII... header.
5. The server decrypts the ticket, validates the authenticator, and the user is authenticated.

SPNEGO can also negotiate NTLM as a fallback when Kerberos is unavailable (e.g., the server is accessed by IP address instead of hostname, or the client is not domain-joined). NTLM is weaker than Kerberos and should be disabled where possible.

Cross-Realm Authentication

Kerberos supports authentication across different realms (domains) through cross-realm trust. When a user in CORP.EXAMPLE.COM needs to access a service in PARTNER.EXAMPLE.COM:

1. The user's KDC issues a referral TGT encrypted with a shared inter-realm key.
2. The user presents this referral TGT to the partner realm's KDC.
3. The partner KDC issues a service ticket for the requested service.

In Active Directory, cross-realm trusts can be:

• One-way — Users in realm A can access services in realm B, but not vice versa.
• Two-way — Bidirectional trust (the default for AD forest trusts).
• Transitive — If A trusts B and B trusts C, then A implicitly trusts C (the default within an AD forest).
• Non-transitive — Only the directly trusting realms are trusted (external trusts).

Clock Synchronization

Kerberos is extremely sensitive to clock differences between clients, services, and the KDC. By default, AD allows a maximum clock skew of 5 minutes. If clocks are out of sync beyond this threshold, authentication fails with a KRB_AP_ERR_SKEW error.

This is a security feature, not a limitation. Timestamps in authenticators prevent replay attacks — an attacker who captures an authenticator cannot replay it because it will have expired by the time they try. But it means NTP (Network Time Protocol) is critical infrastructure for Kerberos. In AD environments, the PDC Emulator is the authoritative time source, and all domain members synchronize their clocks with it.

Kerberos vs. Other Authentication Protocols

• Kerberos vs. NTLM — NTLM is the legacy Windows authentication protocol. It uses a challenge-response mechanism that does not support mutual authentication, delegation, or protection against replay attacks. Kerberos is strictly superior and NTLM should be disabled where possible.
• Kerberos vs. RADIUS — RADIUS is for network access control (Wi-Fi, VPN). Kerberos is for application-level authentication. They often work together: RADIUS authenticates the user to the network, then Kerberos authenticates the user to services on the network.
• Kerberos vs. SAML/OIDC — SAML and OIDC are designed for web-based federated SSO across organizations. Kerberos is designed for authentication within a network/domain. In practice, SAML IdPs and OIDC providers often authenticate users via Kerberos internally (e.g., ADFS uses Kerberos to authenticate domain users, then issues SAML assertions to cloud applications).
• Kerberos vs. LDAP bind — LDAP bind is a simpler authentication mechanism where the password is sent to the LDAP server. Kerberos is more secure because the password never leaves the client. In AD, Kerberos is preferred; LDAP simple bind should only be used over LDAPS and only when Kerberos is not available.

Kerberos and Network Infrastructure

Kerberos depends on several infrastructure components for correct operation:

• DNS — Kerberos relies on DNS for KDC discovery (SRV records: _kerberos._tcp.EXAMPLE.COM) and for SPN-to-hostname resolution. DNS failures directly cause Kerberos authentication failures.
• NTP — Clock synchronization is mandatory. NTP failures cause Kerberos to break within minutes as clock skew accumulates.
• LDAP — Active Directory stores all Kerberos principal data (keys, ticket policies, SPNs) in the LDAP directory. The KDC queries LDAP for every authentication request.
• TLS — While Kerberos itself provides authentication and optional encryption, TLS is often layered on top for defense in depth (HTTPS with Kerberos/SPNEGO authentication).
• BGP — In multi-site AD deployments, Kerberos traffic between clients and domain controllers traverses WAN links. Routing disruptions can prevent authentication for an entire site, which is why each AD site should have local domain controllers.

Relevant RFCs

• RFC 4120 — The Kerberos Network Authentication Service (V5). The core protocol specification.
• RFC 4121 — The Kerberos Version 5 GSS-API Mechanism. How Kerberos integrates with GSSAPI.
• RFC 4178 — The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism (SPNEGO).
• RFC 6113 — A Generalized Framework for Kerberos Pre-Authentication.
• RFC 6806 — Kerberos Principal Name Canonicalization and Cross-Realm Referrals.
• RFC 6560 — One-Time Password (OTP) Pre-Authentication (Kerberos + MFA).
• RFC 3961 — Encryption and Checksum Specifications for Kerberos 5 (cryptographic framework).
• MS-KILE — Microsoft Kerberos Protocol Extensions (PAC, S4U, constrained delegation).

See It in Action

The networks that power Active Directory and Kerberos infrastructure are routed via BGP. Explore them using the god.ad BGP Looking Glass:

• AS8075 — Microsoft (Azure AD / Entra ID, Active Directory)
• AS15169 — Google (Google Workspace with Kerberos constrained delegation)
• AS16509 — Amazon (AWS Managed Microsoft AD, Kerberos authentication)
• AS36459 — GitHub (Kerberos/SPNEGO for GitHub Enterprise Server)
• AS14618 — Amazon (WorkSpaces, AppStream with AD/Kerberos integration)