What Is Kerberos? Authentication Protocol in Computer Networks

Authentication in enterprise networks is a problem that was solved decades ago, yet continues to challenge security teams. Kerberos, the protocol that underpins identity verification in virtually every Active Directory environment on the planet, is both remarkably elegant in its design and frequently misunderstood by the teams responsible for securing it. Originally developed at MIT in the 1980s, Kerberos has evolved into the default authentication mechanism for Windows domains, Linux realms, and cross-platform enterprise environments.

This guide provides a deep technical examination of Kerberos — its architecture, authentication flow, relationship with Active Directory, known attack vectors, and the defensive measures required to keep it secure. Understanding Kerberos at this level is not optional for security professionals — it is foundational.

What Is Kerberos?

Kerberos is a network authentication protocol that uses symmetric-key cryptography and a trusted third party to verify the identities of users and services. Unlike protocols where credentials are transmitted directly between client and server, Kerberos issues time-limited tickets that prove identity without exposing passwords on the network.

The protocol is named after Cerberus (Kerberos in Greek), the three-headed dog guarding the entrance to the underworld in Greek mythology. The three heads symbolize the three parties involved in the authentication process: the client, the server, and the Key Distribution Center (KDC) that mediates between them.

History and Evolution

Kerberos was developed at the Massachusetts Institute of Technology (MIT) as part of Project Athena, a joint effort with IBM and Digital Equipment Corporation that began in 1983. The goal was to provide secure authentication across a large, heterogeneous network of workstations.

• Kerberos v1-v3 (1983-1987) — internal MIT versions, never publicly released.
• Kerberos v4 (1989) — the first widely deployed version. It used DES encryption and had known limitations including lack of cross-realm authentication and vulnerability to certain replay attacks.
• Kerberos v5 (1993) — defined in RFC 1510 (later superseded by RFC 4120), this version addressed the shortcomings of v4. It introduced support for multiple encryption types, cross-realm authentication, forwardable and proxiable tickets, and a more extensible message format.

Kerberos v5 remains the current version in 2026. Microsoft adopted it as the default authentication protocol for Active Directory starting with Windows 2000, replacing NTLM. This single decision made Kerberos the most widely deployed authentication protocol in enterprise environments worldwide.

Core Components of Kerberos

Understanding Kerberos requires familiarity with its key components, each of which plays a specific role in the authentication process.

Key Distribution Center (KDC)

The KDC is the trusted third party at the heart of the Kerberos architecture. In an Active Directory environment, every domain controller runs a KDC. The KDC consists of two logically distinct services:

• Authentication Service (AS) — handles initial client authentication and issues Ticket Granting Tickets (TGTs).
• Ticket Granting Service (TGS) — issues service tickets based on a valid TGT, granting access to specific network resources.

The KDC maintains a database of all principals (users, computers, services) and their associated secret keys. In Active Directory, this database is the AD database itself (NTDS.dit), and the secret keys are derived from account passwords.

Tickets

Tickets are encrypted data structures that carry identity information. There are two primary types:

• Ticket Granting Ticket (TGT) — issued by the AS after successful initial authentication. The TGT proves the client’s identity to the TGS and is encrypted with the KDC’s own secret key (the krbtgt account hash). The client cannot read or modify the TGT — it can only present it to the TGS.
• Service Ticket (ST) — issued by the TGS for access to a specific service. The service ticket is encrypted with the target service’s secret key, so only the target service can decrypt and validate it.

Principals

A principal is any entity that can be authenticated by Kerberos. Principals are identified by a name with the format:

primary/instance@REALM

For example:

• john@COMPANY.COM — a user principal
• HTTP/webserver.company.com@COMPANY.COM — a service principal
• krbtgt/COMPANY.COM@COMPANY.COM — the KDC’s own principal

Realm

A Kerberos realm is an administrative domain — a set of principals managed by a single KDC. In Active Directory, a realm corresponds to a domain. Realm names are conventionally written in uppercase (e.g., COMPANY.COM).

Keytab

A keytab file stores long-term keys for service principals. Services use keytabs instead of passwords to authenticate to the KDC. On Linux systems, the keytab is typically located at /etc/krb5.keytab. Protecting keytab files is critical — possession of a keytab is equivalent to possession of the service’s password.

How Kerberos Authentication Works

The Kerberos authentication flow involves three distinct exchanges. Understanding each step is essential for both implementing and attacking the protocol.

Step 1: Authentication Service Exchange (AS-REQ / AS-REP)

When a user logs in, the client sends an AS-REQ (Authentication Service Request) to the KDC. This request includes the user’s principal name and a timestamp encrypted with the user’s secret key (derived from their password). This encrypted timestamp is called a pre-authentication data (PA-DATA) and prevents offline dictionary attacks against the AS.

If pre-authentication succeeds — the KDC decrypts the timestamp using its copy of the user’s key and verifies it falls within an acceptable time window (typically 5 minutes) — the KDC responds with an AS-REP containing:

1. A TGT encrypted with the krbtgt account key (the client cannot decrypt this).
2. A session key for communication with the TGS, encrypted with the user’s key.

The client decrypts the session key using the user’s password-derived key, caches both the TGT and session key, and the user’s password is no longer needed.

Step 2: Ticket Granting Service Exchange (TGS-REQ / TGS-REP)

When the client needs to access a network resource (e.g., a file share, web application, or database), it sends a TGS-REQ to the TGS. This request contains:

1. The TGT obtained in Step 1.
2. An authenticator — the client’s principal name and a timestamp, encrypted with the TGS session key.
3. The Service Principal Name (SPN) of the target service.

The TGS decrypts the TGT using the krbtgt key, extracts the session key, uses it to decrypt the authenticator, and validates the client’s identity. If everything checks out, the TGS responds with a TGS-REP containing:

1. A service ticket encrypted with the target service’s secret key.
2. A new session key for client-service communication, encrypted with the TGS session key.

Step 3: Client-Server Exchange (AP-REQ / AP-REP)

The client sends an AP-REQ to the target service, containing the service ticket and a new authenticator encrypted with the service session key. The service decrypts the ticket with its own key, extracts the session key, validates the authenticator, and — if everything is valid — grants access.

If mutual authentication is required (and it should be), the service responds with an AP-REP containing the timestamp from the client’s authenticator, encrypted with the service session key. This proves to the client that the service is genuine and not an impersonator.

The Role of Time

Kerberos is fundamentally dependent on synchronized clocks. Tickets and authenticators include timestamps, and the KDC rejects requests where the timestamp skew exceeds the configured tolerance (default: 5 minutes in Active Directory). This is why NTP (Network Time Protocol) is a critical dependency for Kerberos environments. Clock skew is one of the most common causes of Kerberos authentication failures.

Kerberos vs NTLM

NTLM (NT LAN Manager) is the legacy authentication protocol that Kerberos replaced as the default in Active Directory. Despite being superseded over 25 years ago, NTLM remains widely present in enterprise networks due to backward compatibility. Understanding the differences is important for both security assessment and migration planning.

Aspect	Kerberos	NTLM
Authentication model	Ticket-based with trusted third party	Challenge-response between client and server
Mutual authentication	Yes — client and server verify each other	No — only the server verifies the client
Delegation	Supported (constrained and unconstrained)	Limited (no native delegation)
Password exposure	Password never sent over network	Password hash used in every authentication
Replay protection	Timestamps and session keys	Nonce-based, weaker guarantees
Performance	Single KDC contact, then cached tickets	Server must contact DC for every authentication
Cross-domain support	Native via realm trusts	Limited, requires explicit trust configuration
Encryption	AES-128, AES-256 (modern)	MD4 hash, RC4 (weak)

Why NTLM Persists

Despite Kerberos being clearly superior, NTLM continues to survive in enterprise environments for several reasons:

• IP-based access — Kerberos requires SPNs and DNS names. When applications are accessed by IP address, the system falls back to NTLM.
• Legacy applications — older software that predates Kerberos support.
• Workgroup environments — Kerberos requires a domain; workgroup machines use NTLM.
• Cross-forest authentication edge cases — certain trust configurations may force NTLM fallback.

From a security perspective, minimizing NTLM usage is a priority. Microsoft has been gradually tightening NTLM restrictions, and monitoring NTLM authentication events is a key component of Active Directory security hardening.

Kerberos in Active Directory

Active Directory’s implementation of Kerberos extends the base protocol with several Microsoft-specific features that are important to understand.

Service Principal Names (SPNs)

In AD, services are identified by SPNs registered against computer or user accounts. An SPN takes the form:

serviceclass/hostname:port/servicename

Common examples:

• HTTP/webserver.company.com — a web server
• MSSQLSvc/dbserver.company.com:1433 — a SQL Server instance
• CIFS/fileserver.company.com — a file share

SPNs are stored in the servicePrincipalName attribute of AD accounts. Duplicate or misconfigured SPNs cause authentication failures and are a common source of troubleshooting issues.

Privilege Attribute Certificate (PAC)

Microsoft extended the Kerberos ticket format to include the Privilege Attribute Certificate (PAC), which contains the user’s security identifier (SID), group memberships, and other authorization data. The PAC is embedded within the ticket and signed by the KDC. Services use the PAC to make authorization decisions without additional LDAP lookups.

The PAC is central to several Kerberos attacks — forging or manipulating PAC data can lead to privilege escalation.

Delegation Types

Kerberos delegation allows a service to act on behalf of a user when accessing other services. Active Directory supports three delegation models:

• Unconstrained delegation — the service receives the user’s TGT and can impersonate them to any service. This is powerful but dangerous — if the service is compromised, the attacker has full impersonation capability.
• Constrained delegation — the service can only impersonate users to a specified list of target services. This limits the blast radius of a compromise.
• Resource-based constrained delegation (RBCD) — the target service defines which services can delegate to it, rather than the delegating service defining its targets. This model is more flexible and does not require domain admin privileges to configure.

Misconfigured delegation is one of the most impactful attack paths in Active Directory environments. Security assessments should always enumerate delegation settings across all accounts.

Group Managed Service Accounts (gMSA)

gMSAs are a critical security feature for Kerberos in AD. They provide automatically managed, complex passwords (240 characters) for service accounts that rotate every 30 days. No human ever knows the password, eliminating the risk of password reuse and significantly raising the bar for Kerberoasting attacks. Every service account that can be migrated to a gMSA should be.

Kerberos Attacks

Kerberos, despite its strong cryptographic foundation, is subject to several well-known attack vectors. These attacks typically exploit implementation weaknesses, misconfigurations, or the trust model itself rather than flaws in the protocol’s cryptographic design.

Kerberoasting

Kerberoasting is one of the most common and effective attacks against Active Directory. Any authenticated domain user can request a service ticket (TGS) for any service with an SPN. The service ticket is encrypted with the service account’s password hash. The attacker extracts the ticket and performs offline brute-force or dictionary attacks to recover the password.

Attack flow:

1. Enumerate accounts with SPNs: Get-ADUser -Filter {ServicePrincipalName -ne "$null"}
2. Request service tickets for target accounts.
3. Extract the ticket from memory.
4. Crack the ticket offline using tools like Hashcat or John the Ripper.

Why it works: Many service accounts use weak, static passwords that were set years ago and never rotated. RC4 (NTLM hash) encrypted tickets are significantly faster to crack than AES-encrypted ones.

Defenses:

• Use gMSAs wherever possible (automatically rotated 240-character passwords).
• Enforce passwords of 25+ characters for remaining service accounts.
• Configure AES-only encryption (disable RC4 on service accounts).
• Monitor for anomalous TGS request volumes from single accounts.
• Use honeypot SPNs to detect Kerberoasting attempts.

Golden Ticket Attack

A Golden Ticket is a forged TGT created by an attacker who has obtained the krbtgt account’s password hash. Since the krbtgt key encrypts all TGTs, possession of this hash allows the attacker to create TGTs for any user — including non-existent users — with arbitrary group memberships and lifetimes.

Impact: Complete domain compromise. The attacker can impersonate any user, including Domain Admins, and the forged tickets remain valid until the krbtgt password is changed — twice (because AD remembers the previous password).

Attack prerequisites:

• Domain Admin-level access (to extract the krbtgt hash from NTDS.dit or via DCSync).

Defenses:

• Reset the krbtgt password twice in succession (with a 12-hour gap between resets to avoid service disruption).
• Monitor for TGTs with anomalous lifetimes or issued for non-existent users.
• Implement PAC validation on services.
• Deploy Microsoft Advanced Threat Analytics (ATA) or Defender for Identity.

Silver Ticket Attack

A Silver Ticket is a forged service ticket created using a service account’s password hash. Unlike a Golden Ticket, a Silver Ticket grants access only to the specific service whose key was compromised. However, since the service ticket is validated by the service itself (not the KDC), the attack bypasses KDC logging entirely.

Key difference from Golden Ticket: Silver Tickets do not contact the KDC, making them harder to detect through centralized logging. However, enabling PAC validation on services forces a KDC check, which mitigates this attack.

Defenses:

• Enable PAC validation on sensitive services.
• Rotate service account passwords regularly.
• Monitor service-level authentication logs for anomalies.

Pass-the-Ticket (PtT)

Pass-the-Ticket involves stealing a valid Kerberos ticket (TGT or service ticket) from memory and replaying it from a different machine. Tools like Mimikatz can extract tickets from the LSASS process on a compromised workstation.

Variants:

• Overpass-the-Hash — uses a captured NTLM hash to request a legitimate TGT from the KDC, effectively converting an NTLM hash into Kerberos access.
• Pass-the-Cache — targets Linux/macOS systems by stealing ticket cache files (typically /tmp/krb5cc_*).

Defenses:

• Protect LSASS with Credential Guard (Windows 10/11, Server 2016+).
• Restrict local admin privileges to prevent memory dumping.
• Use Protected Users security group for privileged accounts.
• Monitor for lateral movement patterns in authentication logs.

AS-REP Roasting

If pre-authentication is disabled for a user account (the “Do not require Kerberos preauthentication” flag), any attacker can request an AS-REP for that account. The AS-REP contains data encrypted with the user’s password hash, which can be cracked offline.

Defenses:

• Ensure pre-authentication is required for all accounts: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}
• This setting should never be disabled unless absolutely required for legacy application compatibility, and those accounts should have extremely strong passwords.

Delegation Abuse

Misconfigured delegation — particularly unconstrained delegation — allows attackers to capture TGTs of users who authenticate to the compromised service. The attacker can then use these TGTs to impersonate those users across the domain.

Attack scenario: An attacker compromises a server with unconstrained delegation. They force a Domain Controller to authenticate to the compromised server (e.g., via the Printer Bug or PetitPotam). The DC’s TGT is captured, and the attacker uses it to perform a DCSync attack, extracting all domain credentials.

Defenses:

• Replace unconstrained delegation with constrained delegation or RBCD.
• Add sensitive accounts to the Protected Users group (which prevents delegation).
• Mark high-value accounts as “Account is sensitive and cannot be delegated.”
• Monitor for suspicious delegation configurations.

Securing Kerberos — Best Practices

Securing Kerberos in an enterprise environment requires a comprehensive approach spanning configuration, monitoring, and operational practices.

Encryption Configuration

• Disable RC4 encryption where possible. RC4 (arcfour-hmac) uses the raw NTLM hash as the key, making Kerberoasting and pass-the-hash attacks more feasible. AES-128 and AES-256 are dramatically more resistant to brute-force cracking.
• Verify encryption types in use: Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes
• Configure AES encryption for all service accounts and computer accounts.

Account Policies

• Service accounts — migrate to gMSAs. For accounts that cannot use gMSA, enforce 25+ character passwords and rotate them at least annually.
• Protected Users group — add all privileged accounts. This group disables NTLM, DES, and RC4 for its members, prevents delegation, and limits TGT lifetime to 4 hours.
• Tiered administration model — separate credentials for Tier 0 (domain controllers), Tier 1 (servers), and Tier 2 (workstations). Never use the same privileged credentials across tiers.

Monitoring and Detection

Effective Kerberos security requires active monitoring. Key events to track:

• Event 4769 — a service ticket was requested. High volumes from a single source suggest Kerberoasting.
• Event 4768 — a TGT was requested. Monitor for anomalies in pre-authentication failures.
• Event 4771 — Kerberos pre-authentication failed. May indicate brute-force or AS-REP Roasting attempts.
• Event 4770 — a service ticket was renewed. Unusual renewal patterns may indicate ticket manipulation.

Integrate these events into a SIEM platform within a SOC to enable correlation with other indicators and rapid incident response.

Infrastructure Hardening

• Time synchronization — ensure all domain-joined machines use the PDC emulator as their NTP source. Maximum clock skew should be set to no more than 5 minutes.
• DNS security — Kerberos depends heavily on DNS for SPN resolution. Implement DNSSEC and restrict DNS zone transfers.
• Credential Guard — deploy Windows Credential Guard on all endpoints to isolate LSASS and prevent ticket extraction.
• LDAP signing and channel binding — enforce these settings to prevent man-in-the-middle attacks against LDAP communication that Kerberos depends on.

krbtgt Account Management

The krbtgt account is the single most critical account in an Active Directory domain. Its hash encrypts every TGT issued in the domain.

• Rotate the krbtgt password on a scheduled basis (Microsoft recommends every 180 days).
• After any suspected domain compromise, reset the krbtgt password twice with a 12-24 hour gap between resets.
• Monitor for direct access attempts to the krbtgt account.
• Never use the krbtgt account for any service or interactive logon.

Kerberos Beyond Active Directory

While Active Directory is the most common Kerberos deployment, the protocol is used in several other contexts.

MIT Kerberos

The MIT Kerberos implementation (libkrb5) is the reference implementation used in Linux and Unix environments. It provides the same ticket-based authentication without requiring Active Directory. MIT Kerberos is commonly used in:

• Hadoop and big data clusters (HDFS, YARN, HBase all support Kerberos).
• High-performance computing (HPC) environments.
• University and research networks.
• Cross-platform authentication with AD interoperability via realm trusts.

Kerberos in Cloud and Hybrid Environments

As organizations move to hybrid architectures, Kerberos faces new challenges:

• Azure AD Kerberos — Microsoft has introduced cloud-based Kerberos ticket issuance for Azure AD-joined devices, enabling passwordless authentication to on-premise resources through cloud-issued TGTs.
• Kerberos Constrained Delegation with Azure AD Application Proxy — allows cloud-based access to on-premise applications that require Kerberos authentication.
• FAST (Flexible Authentication Secure Tunneling) — also known as Kerberos armoring, FAST wraps the AS exchange in a TLS-like tunnel, protecting pre-authentication data against offline attacks. This is increasingly relevant as attackers target the AS-REQ phase.

Integration with Modern Protocols

Kerberos does not operate in isolation. In modern environments, it integrates with:

• SAML and OIDC — identity federation protocols that can use Kerberos for the initial authentication step, then issue tokens for web-based applications.
• SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) — enables transparent Kerberos authentication in web browsers (the familiar “Windows Integrated Authentication”).
• PKINIT (Public Key Cryptography for Initial Authentication) — extends Kerberos to use X.509 certificates instead of passwords for the initial AS exchange, enabling smart card authentication.

Troubleshooting Kerberos

Kerberos failures can be notoriously difficult to diagnose. Here are the most common issues and their resolutions.

Clock Skew

Symptom: Authentication fails with “KRB_AP_ERR_SKEW” or similar time-related errors. Resolution: Verify NTP configuration. All domain members should synchronize time with the domain controller hierarchy. Check with w32tm /query /status on Windows or chronyc tracking on Linux.

SPN Issues

Symptom: Service authentication fails with “KDC_ERR_S_PRINCIPAL_UNKNOWN.” Resolution: Verify the SPN is registered: setspn -L accountname. Check for duplicate SPNs: setspn -X. Register missing SPNs: setspn -S HTTP/server.company.com serviceaccount.

Delegation Failures

Symptom: Double-hop authentication fails — the front-end service cannot access back-end resources on behalf of the user. Resolution: Verify delegation configuration on the front-end service account. Check if the user is in the Protected Users group (which blocks delegation). Ensure the target SPN is listed in the allowed delegation targets.

Encryption Type Mismatch

Symptom: Authentication fails after disabling RC4 or enabling AES-only. Resolution: Verify that all service accounts and computer accounts have the correct msDS-SupportedEncryptionTypes value. Regenerate keytabs for Linux services with the updated encryption types.

Frequently Asked Questions (FAQ)

What is the difference between Kerberos and NTLM?

Kerberos uses ticket-based authentication with a trusted third party (KDC), providing mutual authentication and stronger security. NTLM uses a challenge-response mechanism where passwords are sent as hashes directly between client and server. Kerberos is the default in modern Active Directory, while NTLM remains as a fallback for legacy compatibility.

What is Kerberoasting and how do you prevent it?

Kerberoasting is an attack where an authenticated user requests service tickets for accounts with SPNs, then cracks the ticket encryption offline to recover service account passwords. Prevention includes using long, complex passwords (25+ characters) for service accounts, deploying Group Managed Service Accounts (gMSA), and monitoring for anomalous TGS requests.

What ports does Kerberos use?

Kerberos uses TCP and UDP port 88 for authentication traffic between clients and the Key Distribution Center (KDC). In Active Directory environments, Kerberos also relies on DNS (port 53) for service discovery and LDAP (port 389/636) for directory lookups.

Can Kerberos work across different domains?

Yes, Kerberos supports cross-realm authentication through trust relationships. In Active Directory, this is implemented via domain and forest trusts, allowing users in one domain to access resources in another. Each trust establishes shared inter-realm keys that enable ticket referrals between KDCs.

Is Kerberos still secure in 2026?

Kerberos remains fundamentally sound as an authentication protocol. However, its security depends entirely on implementation and configuration. Environments using AES-256 encryption, enforcing constrained delegation, deploying PAC validation, and monitoring for known attack patterns like Golden Ticket and Kerberoasting maintain strong security postures. The protocol itself is not the weak point — misconfigurations and weak service account passwords are.

Summary

Kerberos has been the standard for network authentication for over three decades, and its position remains unchallenged in enterprise environments. The protocol’s fundamental design — trusted third-party mediation, ticket-based proof of identity, and mutual authentication — remains cryptographically sound. The real security challenges lie not in the protocol itself but in how organizations deploy and maintain it: weak service account passwords, misconfigured delegation, failure to rotate the krbtgt key, and insufficient monitoring create the attack surface that adversaries exploit.

For security teams, Kerberos is not a black box to be ignored — it is infrastructure that demands active management. Regular security audits that examine delegation settings, SPN configurations, encryption types, and service account hygiene are essential. Combined with comprehensive monitoring through a SOC that tracks authentication anomalies in real time, organizations can maintain the security guarantees that Kerberos was designed to provide while defending against the sophisticated attacks that target its implementation.

---

Related services and products

• Antimalware Effectiveness Testing
• Threat Intelligence