Kerberos Deep Dive: Master Tickets, Trusts & Attacks for IAM

The distributed systems we build today often grapple with a fundamental problem: how do users and services authenticate securely and efficiently across a multitude of applications without resorting to a password for every interaction? The naive approach of storing credentials everywhere or repeatedly prompting users is a non-starter for anything beyond a handful of services. We need a way for a client, once authenticated, to prove its identity to multiple backend services without re-submitting its secrets, and for those services to trust that proof.

While modern web applications often lean on protocols like OAuth 2.1 and OIDC 1.0, and enterprise federations frequently use SAML 2.0, an older, battle-tested protocol still underpins a significant portion of enterprise infrastructure: Kerberos. Developed at MIT, Kerberos V5 (RFC 4120, RFC 4537 for PKINIT) provides a robust, secure method for authenticating users and services in a distributed environment, particularly prevalent in Windows Active Directory domains and many Unix/Linux environments via FreeIPA or MIT Kerberos. It's not without its quirks, complexity, and attack surface, but understanding its core mechanics—tickets, realms, and trusts—is non-negotiable for anyone operating in these ecosystems.

This isn't about "ion" or a "solid" in the abstract. This is about the gritty details of how Kerberos works, the footguns it presents, and how to defend against its common attack vectors.

01What is Kerberos, ?

At its heart, Kerberos is a network authentication protocol that employs strong cryptography to provide client-server applications with secure means of proving identity over an insecure network. Its primary goal is to provide mutual authentication: both the client and the server verify each other's identity. This is distinct from simpler mechanisms like NTLM, which often only authenticate the client to the server and transmit hashed passwords.

The core idea revolves around a trusted third party, the Key Distribution Center (KDC), which issues "tickets" that clients use to prove their identity to services. These tickets are encrypted and time-limited, preventing replay attacks and ensuring that a compromised ticket has a limited lifespan.

The main components involved in a Kerberos exchange are:

• Client: The user or service requesting access to another service.
• Key Distribution Center (KDC): The central authority for Kerberos. It's logically divided into two parts:

• Authentication Server (AS): Authenticates the client and issues a Ticket Granting Ticket (TGT).
• Ticket Granting Server (TGS): Issues service tickets to clients upon presentation of a valid TGT.

• Application Server (Service): The server providing the resource the client wants to access.

All participants (clients and services) must register with the KDC and have a shared secret (a password-derived key for users, or a randomly generated key for services) known only to themselves and the KDC. This shared secret is never transmitted over the network.

02The Kerberos Protocol Flow: A Ticket-Granting Odyssey

Let's break down the three main exchanges that constitute a full Kerberos authentication, from user login to service access. This is where most of the magic, and potential for misconfiguration, happens.

Authentication Service Exchange (AS-REQ/AS-REP)

This is the initial step where a user authenticates to the KDC to obtain a Ticket Granting Ticket (TGT).

1. AS-REQ (Authentication Service Request): The client sends a request to the AS, typically containing its principal name (username) and a timestamp. If pre-authentication is enabled (which it should be, always), the client also encrypts the timestamp using its password-derived key.

1. AS-REP (Authentication Service Reply):

• The AS looks up the client's principal and its associated secret key.
• It decrypts the pre-authentication data (if provided) to verify the client's identity. If successful, it generates a new, random session key for the client.
• The AS then constructs two parts:
• A Ticket Granting Ticket (TGT): This ticket contains the client's principal name, the session key, a timestamp, and an expiration time. The entire TGT is encrypted using the KDC's secret key (the krbtgt account key in AD). Only the KDC can decrypt and verify it.
• The client's session key: This key is encrypted using the client's secret key (derived from their password) and sent back to the client.
• The client receives the AS-REP, decrypts its part using its password, and extracts the session key. It cannot decrypt the TGT itself, but it stores it for future use.

Ticket-Granting Service Exchange (TGS-REQ/TGS-REP)

Now that the client has a TGT, it can request tickets for specific services without re-entering its password.

1. TGS-REQ (Ticket-Granting Service Request): The client wants to access a service, say HTTP/webapp.example.com. It constructs a request containing:

• The previously obtained TGT.
• An Authenticator: This is a timestamp encrypted with the client's session key (obtained in the AS-REP). This proves the client possesses the session key, thereby proving it's the legitimate holder of the TGT.
• The Service Principal Name (SPN) of the target service (e.g., HTTP/[email protected]).

1. TGS-REP (Ticket-Granting Service Reply):

• The TGS receives the TGS-REQ. It decrypts the TGT using its own krbtgt key. Inside the TGT, it finds the client's principal and the client's session key.
• It then decrypts the Authenticator using the client's session key to verify the client's identity and freshness of the request.
• If valid, the TGS generates a new, random service session key unique to this client-service interaction.
• It then constructs two parts:
• A Service Ticket: This contains the client's principal, the service session key, timestamps, and expiration. The entire Service Ticket is encrypted using the target service's secret key (derived from its password/keytab). Only the target service can decrypt it.
• The service session key: This key is encrypted using the client's session key and sent back to the client.
• The client receives the TGS-REP, decrypts its part using its client session key, and extracts the service session key. It now has a Service Ticket, which it cannot decrypt, and the service session key.

Client/Server Exchange (AP-REQ/AP-REP)

Finally, the client presents the Service Ticket to the target application server.

1. AP-REQ (Application Request): The client sends a request to the application server containing:

• The Service Ticket (encrypted with the service's key).
• A new Authenticator: This is a timestamp encrypted with the service session key (obtained in the TGS-REP).

1. AP-REP (Application Reply - Optional):

• The application server receives the AP-REQ. It uses its own secret key (stored in its keytab file) to decrypt the Service Ticket. Inside, it finds the client's principal and the service session key.
• It then decrypts the Authenticator using the service session key to verify the client's identity and the freshness of the request.
• If everything checks out, the server has mutually authenticated the client. It can optionally send an AP-REP back to the client, encrypted with the service session key, to prove its own identity to the client. This completes mutual authentication.
• The client is now authenticated to the service and can access resources based on its authorization.

03Key Concepts and Components

Understanding these fundamental building blocks is crucial for configuring and troubleshooting Kerberos.

Tickets: TGTs, Service Tickets, and Session Keys

• Ticket-Granting Ticket (TGT): The initial ticket obtained from the AS. It's encrypted with the KDC's krbtgt key and allows the client to request other service tickets from the TGS. It's effectively your passport to the Kerberos realm.
• Service Ticket: Issued by the TGS for a specific service. It's encrypted with the service's secret key and grants access to that particular service.
• Session Keys: These are symmetric keys generated by the KDC for each interaction. They are temporary and used to encrypt communication between the client and the KDC (for TGT requests), or between the client and the service (for service requests). They ensure that even if a ticket is stolen, the attacker can't decrypt subsequent communications without the corresponding session key.

Keytab Files: Service Secrets

A keytab file (.keytab) is a cryptographic key table used by a Kerberos service to store its long-term secret keys. Instead of prompting for a password, a service uses its keytab to decrypt incoming Kerberos tickets (specifically, the service ticket issued by the TGS) and prove its identity to the KDC.

# Example: Creating a keytab for a service principal 'HTTP/webapp.example.com'
# This is typically done on the KDC or a management workstation.
# For Active Directory, use ktpass. For FreeIPA/MIT Kerberos, use kadmin.
#

# FreeIPA/MIT Kerberos example:
# Ensure the service principal exists first:
# Kadmin.local -q "addprinc -randkey HTTP/webapp.example.com"
# Extract the keytab:

kadmin.local -q "xst -k /etc/krb5.keytabs/webapp.keytab HTTP/webapp.example.com"

# Verify keytab contents

klist -kt /etc/krb5.keytabs/webapp.keytab

Service Principal Names (SPNs): The Identity of Services

An SPN uniquely identifies a service instance in a Kerberos realm. It's how a client tells the KDC which service it wants a ticket for. SPNs follow the format: <service_class>/<host>:<port>/<service_name>@<REALM>.

Common service_class values include HTTP, MSSQLSvc, HOST, LDAP.

• HTTP/[email protected]
• MSSQLSvc/dbserver.example.com:[email protected]
• HOST/[email protected]

Each service account or computer account that runs a Kerberos-enabled service must have the correct SPNs registered against it. In Active Directory, this is done using setspn.

# Example: Registering an SPN for a web application running on a service account 'svc_webapp'
# This command is run on a domain controller or a machine with AD management tools.

setspn -S HTTP/webapp.example.com svc_webapp

# Verify the SPN registration

setspn -L svc_webapp

Clock Skew: A Common Footgun

Kerberos relies heavily on timestamps to prevent replay attacks. All participants (KDC, clients, services) must have their clocks synchronized within a small tolerance (typically 5 minutes by default). If a client's clock is too far off from the KDC's, or a service's clock is too far off from the KDC's, ticket validation will fail.

Cross-Realm Trusts: Bridging Domains

Kerberos realms can establish trusts with each other, allowing users from one realm to access services in another. When a client in REALMA.COM needs to access a service in REALMB.COM, the KDC in REALMA.COM issues a TGT for krbtgt/[email protected]. This "inter-realm TGT" is then presented to REALMB.COM's KDC, which issues a service ticket for the target service within REALMB.COM.

Trusts can be one-way or two-way, transitive or non-transitive. In Active Directory, these are often configured as "Forest Trusts" or "External Trusts."

04Implementation Details & Configuration

Setting up Kerberos involves meticulous configuration on both the KDC and the client/service sides.

Active Directory Specifics

Active Directory Domain Controllers are your KDCs. SPN management is handled via setspn. Service accounts running applications need their SPNs correctly registered. Delegation, a powerful feature, allows a service to impersonate a client to another backend service. This requires careful configuration.

Constrained Delegation (S4U2Proxy, S4U2Self)

This is what works for secure delegation. Unconstrained delegation is a massive security risk.

• S4U2Self (Service-for-User-to-Self): A service obtains a service ticket to itself on behalf of a user. This is often used when a service needs to determine a user's group memberships from the KDC without accessing another service.
• S4U2Proxy (Service-for-User-to-Proxy): A service (the front-end) obtains a service ticket for a different service (the back-end) on behalf of a user. This is the core of constrained delegation.

To configure constrained delegation in AD:

1. Identify the service account for your front-end application (e.g., svc_frontend).
2. On the svc_frontend account properties in Active Directory Users and Computers, go to the Delegation tab.
3. Select "Trust this user for delegation to specified services only."
4. Choose "Use Kerberos only."
5. Add the SPN(s) of the backend services that svc_frontend needs to access on behalf of users.

Example: Configuring SPN and Delegation for a Web Application

Assume a web application (webapp.example.com) running under svc_webapp needs to access a SQL Server (sqlserver.example.com) running under svc_sql.

# 1. Register SPN for the web application
# This allows clients to get tickets for HTTP/webapp.example.com

setspn -S HTTP/webapp.example.com svc_webapp

# 2. Register SPN for the SQL Server
# This allows the web app (and other clients) to get tickets for MSSQLSvc/sqlserver.example.com

setspn -S MSSQLSvc/sqlserver.example.com:1433 svc_sql

# 3. Configure Constrained Delegation for svc_webapp to svc_sql
# This allows svc_webapp to request tickets FOR USERS to MSSQLSvc/sqlserver.example.com
# This must be done via GUI in ADUC or PowerShell (Set-ADComputer/User -PrincipalsAllowedToDelegateToAccount)
# PowerShell example:
# Get-ADUser svc_webapp | Set-ADUser -PrincipalsAllowedToDelegateToAccount "MSSQLSvc/sqlserver.example.com:1433"
# Or using the -ServicePrincipalNames property:
# $SPN = "MSSQLSvc/sqlserver.example.com:1433"
# Set-ADUser -Identity "svc_webapp" -Add @{'msDS-AllowedToDelegateTo'=$SPN}

FreeIPA/MIT Kerberos Specifics

For Linux environments, FreeIPA provides an integrated identity management solution including Kerberos, LDAP, and DNS. MIT Kerberos is the underlying implementation.

krb5.conf

This is the central client-side configuration file, typically found at /etc/krb5.conf. It defines realms, KDCs, admin servers, and other Kerberos parameters.

# /etc/krb5.conf example

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 proxiable = true
 rdns = false
 # Default encryption types, order matters for negotiation
 default_etypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 arcfour-hmac-md5
 default_etypes_des = des-cbc-crc des-cbc-md5
 permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 arcfour-hmac-md5

[realms]
 EXAMPLE.COM = {
 kdc = kdc.example.com:88
 admin_server = kdc.example.com:749
 default_domain = example.com
 }
 ANOTHER.REALM = {
 kdc = kdc.another.realm:88
 admin_server = kdc.another.realm:749
 default_domain = another.realm
 }

[domain_realm].example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM.another.realm = ANOTHER.REALM
 another.realm = ANOTHER.REALM

[appdefaults]
 # Some applications might need specific settings
 pam = {
 debug = false
 forwardable = true
 ticket_lifetime = 36000
 renew_lifetime = 36000
 }

kadmin Commands

kadmin (or ipa in FreeIPA) is used to manage principals and keytabs on the KDC.

# Add a user principal

kadmin.local -q "addprinc [email protected]"

# Add a service principal with a random key (recommended)

kadmin.local -q "addprinc -randkey HTTP/[email protected]"

# Extract a keytab for a service principal

kadmin.local -q "xst -k /etc/krb5.keytabs/myservice.keytab HTTP/[email protected]"

# List principals

kadmin.local -q "list_principals"

# Change a principal's password (e.g., for a user)

kadmin.local -q "cpw [email protected]"

# View principal details

kadmin.local -q "getprinc HTTP/[email protected]"

05Security Considerations and Attack Vectors

Kerberos, while powerful, has a significant attack surface if misconfigured or if its underlying secrets are compromised. Understanding these attacks is crucial for defense.

Kerberoasting

• What it is: An attacker obtains service tickets for services configured with user accounts (not machine accounts), which are encrypted with the service account's NTLM hash. The attacker can then take these encrypted tickets offline and brute-force or dictionary-attack the service account's password.
• How it works: Any authenticated user can request a service ticket for any service principal in the domain. The KDC will oblige, encrypting the service ticket with the target service's NTLM hash.
• Mitigation:

• Use strong, long, complex passwords (25+ characters) for all service accounts.
• Prefer Managed Service Accounts (MSAs) or Group Managed Service Accounts (gMSAs) in Active Directory, as they have automatically managed, complex passwords.
• Monitor for excessive service ticket requests.
• Restrict service accounts to only what they need.

AS-REP Roasting

• What it is: If a user account has "Do not require Kerberos preauthentication" enabled in Active Directory, an attacker can request a TGT for that user without providing any credentials. The KDC will return the TGT encrypted with the user's NTLM hash. The attacker can then offline brute-force the user's password.
• Mitigation:

• NEVER disable pre-authentication for user accounts. This setting is almost always a mistake unless you have legacy systems that absolutely require it and are isolated.
• Regularly audit accounts for this flag.

Golden Ticket

• What it is: An attacker who compromises the KDC's krbtgt account (the KDC's own account used to encrypt TGTs) can forge any TGT for any user, in any realm, with any privileges, for any duration. This grants them complete control over the domain.
• How it works: Requires domain admin privileges to dump the krbtgt hash.
• Mitigation:

• Protect domain controllers with extreme prejudice.
• Rotate the krbtgt password periodically (a complex process).
• Implement Tiered Administration models to limit access to domain controllers.

Silver Ticket

• What it is: Similar to a Golden Ticket, but targets a specific service instead of the entire domain. If an attacker compromises a service account's NTLM hash, they can forge a valid service ticket for that specific service, granting them access as any user to that service.
• How it works: Requires the NTLM hash of the target service account and its SPN.
• Mitigation:

• Protect service accounts as diligently as possible.
• Use strong, unique passwords for all service accounts.
• Implement local administrator restrictions on servers to prevent hash dumping.

Pass-the-Ticket (PtT)

• What it is: An attacker obtains a valid Kerberos TGT or service ticket (e.g., from memory or a compromised machine) and reuses it to authenticate to services, bypassing the need for the user's password.
• Mitigation:

• Implement credential guard and LSA protection on Windows endpoints.
• Restrict administrative access.
• Monitor for unusual ticket usage.
• Enforce short ticket lifetimes where feasible.

DC Sync / DCSync

• What it is: An attacker with specific permissions (like "Replicating Directory Changes" or "Replicating Directory Changes All") can impersonate a domain controller and request password hashes directly from another domain controller. This gives them access to all user and service account hashes, including krbtgt.
• Mitigation:

• Strictly control permissions on domain controllers. Only domain controllers and specific backup solutions should have these replication permissions.
• Regularly audit these permissions.

Unpopular Opinion: Kerberos Complexity vs. Modern Alternatives

Kerberos is a powerful protocol, but its inherent complexity, reliance on synchronized clocks, and the intricate dance of SPNs and keytabs make it a constant source of friction and potential security vulnerabilities. For greenfield applications, especially those internet-facing or cloud-native, the operational overhead and specific attack vectors of Kerberos often outweigh its benefits compared to modern, API-first authentication protocols. OIDC 1.0, backed by OAuth 2.1, provides a more flexible, less infrastructure-dependent approach for identity federation and SSO, particularly for external users and microservices architectures. While Kerberos excels at internal, Windows-centric environments and certain legacy Unix services, pretending it's the go-to for every authentication challenge is a form of bikeshedding that ignores the current landscape. Its place is diminishing, not growing, outside of specific legacy contexts.

06Trade-offs: When to use Kerberos (and when not to)

Choosing an authentication protocol is a balancing act. Kerberos has its niche.

Pros

• Strong Mutual Authentication: Both client and server verify each other's identity.
• No Password Transmission: User credentials are never sent over the network after the initial AS-REQ (and even then, only encrypted pre-authentication data is sent).
• Single Sign-On (SSO): Once a TGT is obtained, users can access multiple Kerberos-enabled services without re-entering credentials.
• Delegation: Securely allows a service to act on behalf of a user to another service.
• Built-in to Windows: Deeply integrated with Active Directory, making it the default for Windows domain environments.

Cons

• Complexity: Steep learning curve, intricate configuration, and troubleshooting.
• Clock Synchronization: Absolute requirement for all participants, a common source of errors.
• SPN Management: Incorrect or duplicate SPNs are a constant source of frustration and authentication failures.
• KDC Dependency: A highly available KDC is critical; if it's down, no one can authenticate.
• Keytab Management: Securely managing and distributing keytabs for services is non-trivial.
• Internet Unfriendly: Designed