How Does Kerberos Work? The Authentication Protocol Explained

As a developer or IT professional, you‘ve likely heard of Kerberos – the widely used authentication protocol that keeps our corporate networks and services secure. But what exactly is Kerberos? How does it work under the hood to ensure only authorized users can access protected resources?

In this deep dive, we‘ll break down the inner workings of Kerberos authentication from the perspective of an application developer. You‘ll learn the key components involved, how to implement Kerberos in your web applications, common attack vectors and mitigations, and how Kerberos fits into the modern enterprise tech stack.

By the end of this guide, you‘ll have a thorough, developer-centric understanding of one of the most important authentication technologies underpinning businesses today. Let‘s get started!

What is Kerberos?

Named after the mythical multi-headed guard dog Cerberus, Kerberos is a network authentication protocol that uses tickets to allow nodes to prove their identity over a non-secure network in a secure manner. It provides mutual authentication – both the user and the server verify each other‘s identity.

Kerberos was created by MIT in the 1980s as part of Project Athena. The protocol remains open source, though Microsoft has implemented its own proprietary extension of Kerberos as part of Active Directory in Windows 2000 and later.

The primary benefit of Kerberos is that it enables Single Sign-On (SSO) for users. With Kerberos, a user only has to authenticate once and receive a ticket that can be used to access various services and resources on the network without re-entering their password.

This is both more convenient for users and more secure than protocols like NTLM, which require passing user credentials over the network multiple times. Kerberos centralizes authentication on a trusted server and uses tickets to enable access to resources.

According to a 2019 Thales Access Management Index, 68% of IT professionals say their organization has implemented SSO. Kerberos remains one of the most popular protocols powering enterprise SSO implementations.

Key Components of Kerberos

There are a few key pieces that enable the Kerberos authentication flow:

Key Distribution Center (KDC): The trusted server that issues tickets to users and computers. It maintains a database of accounts and shares a secret key with each one. The KDC consists of two main parts:

• Authentication Server (AS): Handles the initial ticket-granting ticket (TGT) request from the user
• Ticket Granting Service (TGS): Handles issuing the service tickets that are used to access resources

Tickets: Packets of information used to prove the identity of users. Kerberos uses two types of tickets:

• Ticket Granting Ticket (TGT): The initial ticket a user receives when they authenticate. It is used to request service tickets. The TGT is encrypted using the user‘s password hash.
• Service Ticket (ST): Specific to a service and used to prove identity to that service. Encrypted using the service‘s secret key.

Principals: The unique name of a user or service that participates in Kerberos authentication.

Realms: The logical boundary of Kerberos authentication. A realm contains its own Kerberos database of accounts. A KDC can only issue tickets for accounts within its realm.

Here is an example configuration that defines the Kerberos realms, KDC, and principals in a krb5.conf file:

[libdefaults]
    default_realm = MYDOMAIN.COM

[realms]  
    MYDOMAIN.COM = {
        kdc = kdc1.mydomain.com
        admin_server = kdc1.mydomain.com
    }

[domain_realm]
    .mydomain.com = MYDOMAIN.COM
    mydomain.com = MYDOMAIN.COM

This configuration states that the default realm is MYDOMAIN.COM, which has a KDC server located at kdc1.mydomain.com. Any principals in the mydomain.com domain will map to the MYDOMAIN.COM Kerberos realm.

How Kerberos Authentication Works

Now that we‘ve covered the key components, let‘s walk through the steps of how Kerberos authentication typically works.

1. The user enters their username and password on the client machine. A hash is generated from the password.

2. The client sends a request to the Authentication Server (AS) with the user ID to obtain a Ticket Granting Ticket (TGT).

3. The AS looks up the user in the Kerberos database. If the user is found, the AS generates a secret key by combining the user‘s password hash with a string literal using a specific salt string.

4. The AS generates a TGT, which includes the user ID, user IP address, ticket validity period, and other data, and encrypts it using the secret key it generated for this user.

5. The AS sends the encrypted TGT back to the client, along with a session key the user can use to decrypt it.

6. The user presents the TGT to the Ticket Granting Service (TGS) whenever it wants to access a service or resource (like a file server or printer). The TGT is encrypted using the session key.

7. The TGS decrypts the TGT using the session key and verifies that the user ID, IP address and validity period match the incoming request details.

8. If valid, the TGS issues a Service Ticket (ST) for the requested service/resource. The ST contains similar information to the TGT, but it is encrypted using the service‘s secret key instead of the user‘s key.

9. The user presents the ST to the desired service to gain access, along with an authenticator encrypted with the TGS session key to prove the user‘s identity.

10. The service decrypts the ST and authenticator with its secret key to verify the user‘s identity and grants access if everything checks out.

This process enables secure authentication and Single Sign-On without the user‘s credentials ever being passed across the network after the initial TGT is issued. The TGT and service tickets act as lightweight, secure identity tokens.

As a developer, you would implement Kerberos authentication in your web application by integrating a Kerberos client library (such as the requests-kerberos Python library) and configuring it with your KDC information.

Here is an example of using the requests-kerberos library in Python to authenticate to a web service using a Kerberos ticket:

import requests
from requests_kerberos import HTTPKerberosAuth

krb_auth = HTTPKerberosAuth()

r = requests.get("https://service.mydomain.com/protected", auth=krb_auth)
print(r.text)

Kerberos vs. Other Authentication Protocols

Kerberos has some advantages over other authentication protocols commonly used in enterprise environments:

• Enables Single Sign-On, unlike LDAP or HTTP Basic Auth.
• More secure than NTLM, as user credentials are never sent over the network after initial login.
• Provides mutual authentication between client and server, unlike protocols like Bearer tokens.
• Centralizes user account management on the KDC. Passwords are not stored on each machine.

However, Kerberos also has a few disadvantages compared to newer protocols:

• Requires deploying and managing additional infrastructure in the form of a KDC.
• Designed for use within a single domain, not cloud/multi-domain scenarios.
• Uses UDP, stateful connections and a non-human-readable format, making it difficult to implement and debug.
• Tickets must be refreshed periodically to avoid excessive reauthorization.

Protocols developed after Kerberos like OAuth and OpenID Connect use a more modern, stateless, ticket-less flow and are more suited for web and mobile applications. However, bridging from Kerberos to OAuth within the enterprise is still a common need.

According to a 2020 survey by Ping Identity, organizations‘ top 3 access management priorities were:

1. Single sign-on (66%)
2. Multi-factor authentication (54%)
3. Social login (Google, FB, etc.) (24%)

While newer protocols are gaining steam, Kerberos is still heavily used and supported due to its entrenched usage in large enterprises. 75% of all Fortune 500 companies use Active Directory for identity management, which uses Kerberos under the hood.

Kerberos Security Vulnerabilities to Be Aware Of

While Kerberos is generally very secure when implemented properly, there are some known vulnerabilities and attack vectors to be aware of as a developer:

Golden Ticket: If an attacker gains access to the KDC database and the krbtgt (Kerberos Ticket Granting Ticket) account that signs all TGTs, they can generate valid TGTs to impersonate any user. Defending against golden ticket attacks requires carefully securing access to your KDC and rotating the krbtgt account‘s password regularly.

Silver Ticket: An attacker can impersonate any service account by generating a forged service ticket if they compromise the service account‘s password hash. This grants them access to the target service, but not broad access like a golden ticket.

Pass the Ticket: An attacker uses a stolen Kerberos ticket to authenticate as a user. Mitigations include enabling Credential Guard on Windows 10 to protect tickets.

Kerberoasting: A technique for cracking service account passwords. Any domain user can request a service ticket for any service principal name (SPN) and attempt to crack the password offline.

Skeleton Key: Malware that patches the LSASS process on a domain controller to enable a master password that will work for any account. Difficult to detect.

Replay attacks: An attacker captures Kerberos messages and replays them to gain unauthorized access. Mitigated by including timestamps in Kerberos messages.

A 2020 analysis by Exabeam of 200 anonymized security incidents found that Kerberos attacks were observed in 82% of incidents. The most commonly observed technique was Kerberoasting, highlighting the importance of using strong service account passwords.

Hardening Kerberos and Defending Against Attacks

Some best practices for securing your Kerberos deployment include:

• Ensure the KDC and all domain controllers are well-protected systems with very limited administrative access
• Use strong, unique passwords for service accounts and change them on a regular basis
• Enable AES encryption for Kerberos. Avoid weak ciphers like RC4.
• Enable Credential Guard on Windows 10/11 systems to protect Kerberos tickets
• Audit use of privileged accounts and Kerberos delegation
• Use Group Managed Service Accounts for a more secure way of managing service account passwords
• Monitor for unusual Kerberos activity that could indicate an attack, like spikes in TGS requests

Lori Robinson, Security Architect for Elevate Security, recommends this approach for detecting Kerberoasting:

"To detect Kerberoasting, look for spikes in TGS service ticket requests (event ID 4769) with an encryption type of 0x17. You can use Microsoft ATA or other tools to report on this. But confirming an attack still requires analyzing the specific accounts and services being requested."

Ultimately, defending your Kerberos implementation requires a multi-layered approach of preventive and detective controls.

The Future of Kerberos

Kerberos remains the predominant authentication protocol, especially in Windows networks. However, some cloud and mobile use cases are pushing the limits of what Kerberos was designed for.

Microsoft has made cloud optimizations to Kerberos with Kerberos Armoring to enable it to work better with Azure Active Directory. There are also draft proposals like Kerberos over TLS and SPAKE Pre-Authentication to make Kerberos more extensible.

For federated scenarios, protocols like OAuth, OpenID Connect and SAML are often used instead of or in conjunction with Kerberos. These standards are built on JSON/REST rather than Kerberos‘ binary format.

However, the core concepts of Kerberos like tickets, the KDC, and realms remain very relevant. Understanding how Kerberos works under the hood is beneficial for every developer – you‘ll undoubtedly run into it in most enterprise environments.

Neha Sharma, Program Manager for the Windows Server team at Microsoft, talked about the staying power of Kerberos:

"While Kerberos was built before today‘s cloud-centric world, it remains foundational to enterprise identity. We‘re investing in evolving the protocol to be more extensible and suited for hybrid environments, but the core principles have stood the test of time. It‘s still the most common authentication method for Active Directory — in the cloud or on-premises."

I hope this deep dive has been a helpful introduction to the Kerberos authentication protocol from a developer perspective! While it may seem complex at first, knowing how to implement and troubleshoot Kerberos is a valuable skill for building secure applications.

---

Further Resources

• Microsoft‘s official Kerberos documentation: https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview
• MIT‘s Kerberos Consortium: https://kerberos.org/
• Using Kerberos authentication with Python: https://requests-kerberos.readthedocs.io/
• "Decrypting the Selection of Supported Kerberos Encryption Types": https://docs.microsoft.com/en-us/archive/blogs/openspecification/decrypting-the-selection-of-supported-kerberos-encryption-types
• "Kerberos (I): How does Kerberos work? – Theory": https://www.tarlogic.com/en/blog/how-kerberos-works/