Kerberos Authentication Protocol

Introduction

Kerberos is a network authentication protocol designed to provide strong authentication for client-server applications using symmetric key cryptography and a trusted third party. Named after the three-headed dog of Greek mythology that guards the gates of the underworld, Kerberos guards access to network services by requiring proof of identity through cryptographic tickets rather than transmitting passwords over the network.

The fundamental problem Kerberos solves is mutual authentication in an untrusted network. In a typical enterprise environment with thousands of users and hundreds of services, each user would need to authenticate separately to each service -- and each service would need to verify identities independently. Kerberos centralizes authentication through a trusted Key Distribution Center (KDC), enabling single sign-on (SSO): a user authenticates once and receives tickets that grant access to multiple services without re-entering credentials.

Kerberos is the default authentication protocol in Microsoft Active Directory, used in virtually every Windows enterprise environment. It is also widely implemented in Unix/Linux systems, Hadoop clusters, and many other enterprise applications.

"Kerberos provides a centralized authentication server whose function is to authenticate users to servers and servers to users. It uses only symmetric encryption, making it faster and simpler than public-key alternatives for internal networks." -- William Stallings, Network Security Essentials

History and Development

Kerberos was developed at the Massachusetts Institute of Technology (MIT) as part of Project Athena, a large-scale distributed computing project begun in 1983. The project needed a way to authenticate users across a network of thousands of workstations connected to shared services.

Kerberos v5 is the current standard and has been the dominant version since its publication. It addressed several limitations of v4, including support for multiple encryption algorithms, cross-realm authentication, and ticket forwarding and proxying.

Core Concepts

Principals and Realms

A principal is any entity that participates in Kerberos authentication -- users, services, or hosts. Each principal has a unique name within a realm (a Kerberos administrative domain, typically an organization or domain).

Principal name format:component/instance@REALM

• User principal:jsmith@EXAMPLE.COM
• Service principal:HTTP/webserver.example.com@EXAMPLE.COM
• Host principal:host/server01.example.com@EXAMPLE.COM
• krbtgt principal:krbtgt/EXAMPLE.COM@EXAMPLE.COM (the KDC's own principal)

Realm names are conventionally written in uppercase and often correspond to the DNS domain name. Cross-realm trust relationships allow principals in one realm to authenticate to services in another.

Key Distribution Center (KDC)

The KDC is the trusted third party at the center of Kerberos. It consists of three logical components:

• Authentication Server (AS): Handles initial authentication and issues Ticket-Granting Tickets (TGTs)
• Ticket-Granting Server (TGS): Issues service tickets based on valid TGTs
• Kerberos Database: Stores the secret keys (derived from passwords) for all principals in the realm

In Active Directory environments, every Domain Controller runs as a KDC. The security of the entire Kerberos realm depends on the security of the KDC -- if an attacker compromises the KDC database, they gain the ability to impersonate any principal.

Tickets and Session Keys

Kerberos uses tickets as cryptographic proof of identity. A ticket is an encrypted data structure that contains the client's identity, the service's identity, a session key, and validity timestamps. Tickets are encrypted with the service's secret key, so the client cannot read or modify them -- they can only present them.

Authentication Flow

Kerberos authentication involves three exchanges, each between the client and a different entity. At no point is the user's password sent over the network.

AS Exchange (Getting the TGT)

This exchange occurs when the user first logs in:

1. AS-REQ: The client sends a request to the Authentication Server containing the user's principal name, the requested TGT service (krbtgt/REALM), and a timestamp
2. The AS looks up the user's secret key (derived from their password hash) in the Kerberos database
3. AS-REP: The AS responds with two items:
   • A TGT encrypted with the krbtgt secret key (the client cannot decrypt this)
   • A session key and metadata encrypted with the user's secret key (only the user can decrypt this)
4. The client decrypts the second part using the key derived from the user's password, obtaining the session key and TGT

Pre-authentication: In modern Kerberos (enabled by default in Active Directory), the client must include an encrypted timestamp in the AS-REQ to prove knowledge of the user's key. Without pre-authentication, an attacker could request a TGT for any user and attempt to crack it offline (an AS-REP roasting attack).

TGS Exchange (Getting Service Tickets)

When the user needs to access a service:

1. TGS-REQ: The client sends the TGT (still encrypted, untouched) and an authenticator (client identity + timestamp encrypted with the TGT session key) to the TGS, along with the target service's principal name
2. The TGS decrypts the TGT with the krbtgt key, extracts the session key, and uses it to decrypt the authenticator
3. The TGS verifies the client's identity matches between the TGT and authenticator, and that the timestamp is within the acceptable skew (typically 5 minutes)
4. TGS-REP: The TGS responds with a service ticket encrypted with the target service's secret key, and a new session key encrypted with the TGT session key

Client/Server Exchange

1. AP-REQ: The client sends the service ticket and a new authenticator (encrypted with the service session key) to the target service
2. The service decrypts the ticket with its own secret key, extracts the session key, and decrypts the authenticator
3. The service verifies the client's identity and timestamp
4. AP-REP (optional): For mutual authentication, the service responds with the timestamp from the authenticator encrypted with the session key, proving to the client that the service possesses the correct secret key

Kerberos in Active Directory

Microsoft adopted Kerberos v5 as the default authentication protocol for Active Directory beginning with Windows 2000, replacing the older NTLM protocol. In AD environments, Kerberos is deeply integrated with the directory service:

• Every Domain Controller serves as a KDC
• The AD domain name becomes the Kerberos realm name (e.g., CORP.EXAMPLE.COM)
• Service Principal Names (SPNs) are stored as attributes on AD computer and service accounts
• Group membership and authorization data are embedded in tickets via the Privilege Attribute Certificate (PAC), a Microsoft extension
• Kerberos delegation allows services to impersonate users when accessing other services on their behalf

Active Directory supports three types of Kerberos delegation:

"Kerberos is the backbone of Windows enterprise security. Understanding its internals is essential for both defenders protecting Active Directory and attackers attempting to compromise it." -- Sean Metcalf, Microsoft MVP and Active Directory security researcher

Encryption Types

Kerberos supports multiple encryption algorithms, and the choice of encryption type significantly impacts security:

A critical security concern is that many Active Directory environments still support RC4-HMAC for backward compatibility. RC4 encryption uses the NTLM hash directly as the Kerberos key, which means that an attacker with an NTLM hash can forge Kerberos tickets without needing the plaintext password. Disabling RC4 and enforcing AES is one of the most impactful hardening steps for AD environments.

Kerberos Attacks

Kerberos has been the subject of intensive security research, particularly in the context of Active Directory. Several well-known attack techniques exploit design features or misconfigurations:

Golden Ticket Attack: If an attacker obtains the krbtgt account's password hash (the secret key used to encrypt all TGTs), they can forge TGTs for any user, including non-existent users, with arbitrary group memberships and lifetimes. A Golden Ticket grants complete and unrestricted access to every resource in the domain. The only remediation is to reset the krbtgt password twice (since AD stores the current and previous password), and even then, tickets created before the reset remain valid until they expire.

Silver Ticket Attack: An attacker who obtains a service account's password hash can forge service tickets for that specific service. Silver Tickets bypass the KDC entirely -- the forged ticket goes directly to the target service. Because the KDC is never contacted, Silver Ticket usage does not generate the same audit logs as legitimate authentication, making detection more difficult.

Kerberoasting: Any authenticated domain user can request service tickets for accounts with registered SPNs. Since service tickets are encrypted with the service account's secret key, the attacker can extract the ticket and attempt to crack the service account's password offline. Service accounts with weak passwords are trivially compromised through Kerberoasting. Tools like Rubeus and Impacket automate this attack.

AS-REP Roasting: Similar to Kerberoasting, but targets accounts with Kerberos pre-authentication disabled. The attacker requests an AS-REP for such accounts and cracks the encrypted portion offline. This setting should never be disabled without a specific technical requirement.

Pass-the-Ticket: An attacker who extracts Kerberos tickets from memory (using tools like Mimikatz) can inject them into another session to impersonate the ticket holder. Unlike pass-the-hash attacks, pass-the-ticket works even when NTLM is disabled.

Skeleton Key: A malware technique that patches the LSASS process on a Domain Controller to accept a master password alongside the legitimate password for any account. The legitimate password continues to work, making the attack stealthy.

Hardening and Defense

• Change the krbtgt password regularly (at least twice per year) to limit Golden Ticket viability
• Use AES encryption exclusively; disable DES and RC4 across the domain
• Require Kerberos pre-authentication for all accounts
• Use Managed Service Accounts (gMSAs) for service accounts to ensure automatic, strong password rotation (120+ character passwords)
• Implement Protected Users security group for privileged accounts (prevents delegation, enforces AES, reduces ticket lifetime)
• Monitor for Kerberoasting by auditing service ticket requests (Event ID 4769) for unusual patterns
• Set maximum ticket lifetime to the minimum acceptable duration and enforce clock synchronization (NTP)
• Avoid unconstrained delegation; prefer resource-based constrained delegation
• Use Privileged Access Workstations (PAWs) and tiered administration to limit credential exposure
• Deploy Microsoft Defender for Identity or equivalent tools to detect Kerberos-based attacks in real time

For related topics, see LDAP (the directory protocol used alongside Kerberos in Active Directory), SAML (for web-based SSO extending beyond the Kerberos realm), and authentication fundamentals.

Summary

Kerberos provides robust, ticket-based authentication that eliminates the need to transmit passwords over the network. Its single sign-on capability and mutual authentication make it ideal for enterprise environments. However, its security depends entirely on protecting the KDC and the krbtgt secret, enforcing modern encryption types, and monitoring for abuse of its delegation and ticketing mechanisms.

• Authentication relies on tickets issued by a trusted KDC, never on transmitting passwords
• The TGT acts as proof of identity for requesting service tickets without re-authentication
• Active Directory uses Kerberos as its primary authentication protocol, with Microsoft-specific extensions like the PAC
• Golden Ticket and Silver Ticket attacks exploit compromised keys to forge tickets
• Kerberoasting is the most common Kerberos attack and is mitigated by strong service account passwords and gMSAs
• Modern hardening requires AES enforcement, pre-authentication, and continuous monitoring

References

• Neuman, C., et al. (2005). RFC 4120: The Kerberos Network Authentication Service (V5). IETF.
• Steiner, J., Neuman, C., & Schiller, J. (1988). "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings.
• Microsoft. (2024). "Kerberos Authentication Overview." Microsoft Learn.
• Metcalf, S. (2015). "Kerberos, Active Directory's Secret Decoder Ring." DerbyCon 2015.
• Duckwall, T., & Campbell, C. (2014). "Abusing Microsoft Kerberos: Sorry You Guys Don't Get It." Black Hat USA 2014.
• Schroeder, W. (2019). "A Case Study in Wagging the Dog: Computer Takeover via Resource-Based Constrained Delegation." SpecterOps Blog.
• Pilkington, M. (2014). RFC 6649: Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos. IETF.
• Stallings, W. (2020). Network Security Essentials: Applications and Standards. 7th Edition. Pearson.
• Delpy, B. (2014). "Mimikatz." github.com/gentilkiwi/mimikatz.
• Mudge, R. (2016). "Kerberos Golden Tickets are Now More Golden." Cobalt Strike Blog.