Key takeaways
Kerberos never sends passwords across the network. Users prove their identity by decrypting a challenge from the Key Distribution Center (KDC) using a key derived from their password. The password itself stays on the user's machine.
Tickets replace credentials. After one successful authentication, the KDC issues a Ticket Granting Ticket (TGT), a reusable credential that lets the user request access to additional services without entering their password again. This is how Kerberos enables single sign-on.
Kerberos is the backbone of Windows Active Directory. Every domain-joined Windows machine uses Kerberos authentication by default. The protocol also runs on Linux and macOS through MIT Kerberos and Heimdal implementations.
Securing Kerberos means securing service accounts. Attacks like Kerberoasting and ticket forgery exploit weak service account passwords and misconfigurations, not flaws in the protocol itself. Strong passwords, AES encryption, and monitoring are the primary defenses.
How does the Kerberos Key Distribution Center work?
The Key Distribution Center (KDC) is a trusted server that sits between users and the services they want to access. It has two components.
The Authentication Server (AS) handles initial login: it verifies a user's identity and issues the first ticket.
The Ticket Granting Server (TGS) handles everything after that: it issues service-specific tickets so the user can access individual resources like file shares, databases, or email servers. In a Windows Active Directory environment, the domain controller runs both components.
Kerberos authentication works as a three-step conversation between the user's computer, the KDC, and the service the user wants to reach. Each step uses encrypted tickets rather than passwords, so no credential ever crosses the network in a readable form.
1. AS exchange: proving identity
The user's computer sends a login request to the Authentication Server. This request contains the username but not the password.
Modern Kerberos requires pre-authentication: the user's computer encrypts a timestamp using a key derived from the user's password and sends it along with the request. This proves the user knows the password without transmitting it.
The AS decrypts the timestamp to verify the user's identity. If it checks out, the AS issues two things: a Ticket Granting Ticket (TGT) encrypted with the TGS's secret key, and a session key encrypted with the user's password-derived key.
The user's computer decrypts the session key. The TGT stays encrypted, the user's machine cannot read it, but it can present it to the TGS later.
The critical security property here: the password never leaves the user's machine. The AS and the user each know the password independently, and the encrypted timestamp proves the user has the right one.
2. TGS exchange: requesting access
When the user wants to access a specific service, like a file server, their computer sends the TGT and a request for that service to the Ticket Granting Server.
The TGS decrypts the TGT using its own secret key, verifies the ticket is valid, and checks that the request is coming from the same user the TGT was issued to.
The TGS issues a service ticket (ST) encrypted with the target service's secret key, plus a new session key for communication between the user and that service.
This is where single sign-on happens. The user authenticated once in step 1 and received a TGT. Now they can request service tickets for any Kerberos-protected resource without entering their password again. A typical TGT is valid for 10 hours, and users can keep requesting service tickets throughout that window.
3. Service access: presenting the ticket
The user's computer sends the service ticket and an authenticator (a timestamp encrypted with the session key from step 2) to the target service.
The service decrypts the ticket using its own secret key, extracts the session key, and uses it to decrypt the authenticator. If the timestamp is current (within five minutes), the service knows the request is genuine and not a replay of an old message.
The service grants access. Optionally, it sends its own authenticator back to the user, completing mutual authentication, where both sides have verified each other's identity.
Ticket lifetimes are limited by design. TGTs typically expire after 10 hours, and service tickets have shorter lifetimes. This limits the damage if a ticket is somehow intercepted, because it becomes unusable after the expiration window closes.
Why is Kerberos still relevant today?
Kerberos remains relevant because it is built into every Windows Active Directory deployment. Active Directory (AD) continues to serve as the backbone of enterprise IT infrastructure, which means Kerberos handles authentication across the majority of on-premises environments worldwide. Kerberos in Windows is not optional.
Active Directory pairs Kerberos for authentication with Lightweight Directory Access Protocol (LDAP) for directory lookups as the two protocols work together to handle identity in most on-premises environments.
Every domain-joined machine uses it by default for network authentication. That installed base alone guarantees its relevance.
But Kerberos also endures for technical reasons and the strength of its security model. Five properties make it difficult to replace.
Passwords never cross the network. Unlike older protocols that transmit password hashes, Kerberos uses symmetric-key cryptography so that credentials stay on the user's machine and the KDC. This eliminates an entire class of interception attacks.
Built-in mutual authentication. Both the user and the service verify each other's identity. A user connecting to a file server knows the server is genuine and not an impersonator. This protects against man-in-the-middle attacks within the network.
Native single sign-on (SSO). One authentication event produces a TGT that covers every Kerberos-protected service in the domain. Users log in once at the start of their workday and access file shares, print servers, email, and internal applications without re-entering credentials.
Broad cross-platform support. Kerberos runs on Windows, Linux, and macOS. The MIT Kerberos and Heimdal implementations serve non-Windows environments, and cross-realm trust relationships allow Kerberos domains managed by different operating systems to interoperate.
Modern encryption standards apply. Current Kerberos implementations use AES-256 encryption rather than the older DES or RC4 algorithms. RFC 4120, published by the IETF in 2005, formalized many of these improvements.
Though newer protocols exist, Kerberos and protocols like SAML and OAuth serve different purposes. SAML and OAuth handle web-based and cloud authentication. Kerberos handles network-level authentication within a domain. Most enterprise environments use all three, with Kerberos covering on-premises resources and SAML or OAuth covering cloud applications.
What are the most common Kerberos security threats?
Kerberos security threats typically exploit weak service account passwords and misconfigurations rather than breaking the protocol's cryptography.
These attacks generally require some level of initial access to the network, meaning the attacker has already compromised at least one domain user account. Four attack types account for the most common threats.
What is Kerberoasting?
Kerberoasting is an offline password attack in which an adversary uses valid domain credentials to request Kerberos service tickets for accounts with a Service Principal Name (SPN) and cracks them to recover service account passwords.
MITRE ATT&CK classifies Kerberoasting as technique T1558.003.
The attack works because service tickets are encrypted with the service account's password hash. If that password is weak, like a short or predictable string, the adversary can crack it using brute-force tools. The request itself is legitimate Kerberos behavior, so it generates minimal suspicious activity.
Service accounts are attractive targets because they often hold elevated privileges, like database administrator or application administrator access, and their passwords may go unchanged for years.
What is AS-REP roasting?
AS-REP roasting targets user accounts that have Kerberos pre-authentication disabled. Recall that pre-authentication requires the user to prove password knowledge by encrypting a timestamp before the KDC responds. When pre-authentication is disabled, the KDC responds with encrypted material without verifying the requester's identity first.
An adversary can request that material for any account with pre-authentication disabled and attempt to crack it offline to reveal the user's password. MITRE ATT&CK classifies this as technique T1558.004.
Pre-authentication is enabled by default. This vulnerability exists only when administrators explicitly disable it, usually for legacy application compatibility.
The fix is straightforward: audit Active Directory for accounts with the "Do not require Kerberos preauthentication" flag and re-enable pre-authentication wherever possible.
What is a silver ticket attack?
A silver ticket attack is a forgery. The adversary compromises a service account's password hash (the NTLM hash, a mathematical representation of the password), then uses it to create fake service tickets for that specific service. Because the forged ticket is encrypted with the correct key, the service accepts it as genuine.
The danger is stealth. Silver ticket forgery bypasses the KDC entirely, so no authentication request appears in the KDC's logs. The adversary gets access to one specific service without triggering the normal logging that would flag unusual authentication activity. The scope is limited to the compromised service, unlike golden ticket attacks, which grant domain-wide access.
What is a golden ticket attack?
A golden ticket attack is a Kerberos credential forgery technique in which an adversary compromises the KRBTGT account hash to fabricate valid TGTs for any user in the domain.
The adversary gains access to a domain controller and extracts the password hash of the KRBTGT account, the special service account that the KDC uses to sign every TGT in the domain. With that hash, the adversary can forge TGTs for any user with any privileges, effectively owning the entire domain.
Golden tickets can persist even after individual user passwords are reset, because the forged TGT is signed with the KRBTGT hash, not the user's credentials.
The only remediation is resetting the KRBTGT password twice (to clear the password history), and rebuilding trust from that point forward. This attack requires domain administrator-level compromise to execute, making it a late-stage threat that motivates the preventive measures in the next section.
What are the most effective Kerberos security best practices?
The threats above share a common pattern: they exploit weak passwords, outdated encryption, or gaps in monitoring. Four categories of defense address them directly.
How should organizations manage service account passwords?
Service accounts should use randomly generated passwords of 25 or more characters. At that length, offline cracking becomes computationally infeasible even with modern hardware.
Group Managed Service Accounts (gMSAs) in Active Directory automate this: the system generates a 240-character password and rotates it every 30 days without human intervention. For accounts that cannot use gMSAs, a password vault with automated rotation provides similar protection.
Organizations should also audit SPN registrations regularly. Every account with a registered SPN is a potential Kerberoasting target. Removing unnecessary SPNs reduces the attack surface.
How should ticket policies and encryption be configured?
AES-256 encryption should replace older RC4 and DES algorithms for all Kerberos ticket encryption. RC4-encrypted tickets are significantly easier to crack offline. Administrators can verify encryption type settings in Active Directory's domain and account policies. Microsoft's planned changes to Kerberos will disable RC4 by default in the second half of 2026, but organizations should move to AES proactively.
Ticket lifetimes should match the security requirements of the environment. The default 10-hour TGT lifetime is reasonable for most organizations. High-security environments may reduce it. Service ticket lifetimes can be shortened for sensitive services. Pre-authentication should be enabled for every account, and privileged accounts should be added to the Protected Users security group, which enforces stricter Kerberos settings automatically.
What authentication activity should organizations monitor?
Four Windows Event IDs provide the core Kerberos monitoring signal.
Event ID 4768 logs TGT requests; unusual volumes may indicate AS-REP roasting.
Event ID 4769 logs service ticket requests; a single user requesting many service tickets in a short window is a classic Kerberoasting signature.
Event ID 4770 logs ticket renewals, which can signal persistence attempts.
Event ID 4771 logs pre-authentication failures, which may indicate password attacks.
These events should feed into a Security Information and Event Management (SIEM) platform where they can be correlated with other network activity. Baseline normal authentication patterns first, then build alerts around deviations: mass service ticket requests, tickets for rarely accessed services, or service authentications that appear in the service's logs but not in the KDC's logs (a potential indicator of silver ticket forgery).
How should organizations manage privilege in Kerberos environments?
The principle of least privilege is the single most effective control against lateral movement after a credential compromise. Service accounts should receive only the specific permissions their function requires, not domain administrator or local administrator rights.
Privileged access management (PAM) solutions can provide just-in-time access, granting elevated permissions only when needed and automatically revoking them afterward. Administrators should use separate accounts for privileged tasks versus daily work, so that a compromised daily-use account does not grant access to sensitive systems. Regular privilege audits catch permission creep, where accounts accumulate unnecessary access over time.
What are the key differences between Kerberos and modern identity access management?
Kerberos authenticates users to network resources within a trusted domain. Modern identity and access management (IAM) platforms secure access across cloud services, web applications, and untrusted networks. The two serve different environments, and most organizations use both.
Differentiator | Kerberos | Modern IAM platforms |
|---|---|---|
Primary use case | Network and domain authentication | Cloud, web, and multi-environment access |
Authentication scope | Single domain or realm | Cross-platform, cloud-native, federated |
Password handling | Password-derived symmetric keys | Passwordless and MFA options |
Security model | Ticket-based, symmetric encryption | Token-based, risk-adaptive, often asymmetric |
User experience | SSO within the domain | SSO across SaaS, cloud, and on-premises |
Visibility | Event log monitoring (4768, 4769) | Device health, location, behavior analytics |
Adaptability | Static policies | Adaptive, risk-based authentication |
Kerberos does not address several challenges that modern IAM platforms are designed for. It does not prevent users from entering credentials into phishing pages. It does not verify device health or compliance before granting access. It does not adjust authentication requirements based on risk signals like location, device posture, or behavioral anomalies. And it does not natively support cloud applications, which use protocols like SAML and OAuth instead.
Where Kerberos still excels is on-premises Active Directory environments, legacy application support, and fast network-level authentication for domain-joined systems. Modern security architectures layer IAM platforms over existing Kerberos infrastructure, adding multi-factor authentication (MFA), device trust, and continuous verification to close the gaps that Kerberos was never designed to address.
How can organizations strengthen Kerberos authentication?
Organizations can strengthen Kerberos authentication by expanding verification practices beyond the limited scope Kerberos offers.
Kerberos authenticates based on what the user knows (their password). It cannot detect whether the person entering that password is the legitimate user or an adversary who stole it. Once an attacker has valid credentials, Kerberos treats them like any other user.
These additional verification steps strengthen Kerberos authentication:
Multi-factor authentication. Adding a second verification factor at the Windows login, RDP session, or VPN connection point means stolen passwords alone are not enough. Even if an adversary cracks a service account password through Kerberoasting, MFA at the access point blocks the subsequent authentication attempt.
Device trust. Verifying that a device is managed, up to date, and healthy before allowing it to complete Kerberos authentication prevents compromised or unmanaged endpoints from gaining network access, regardless of whether the credentials are valid.
Phishing-resistant authentication. FIDO2 security keys and passkeys resist credential theft at the point of entry, where Kerberos has no visibility. Pairing phishing-resistant authentication with Kerberos infrastructure means the initial credential that produces the TGT is itself resistant to interception.
Adaptive access policies. Risk-based authentication evaluates context, like location, device posture, time of day, and behavioral patterns, and adjusts requirements accordingly. A login from a known managed device on the corporate network proceeds with minimal friction. The same credentials from an unfamiliar device in an unusual location trigger additional verification.
Unified visibility. A single dashboard that correlates Kerberos authentication events with cloud access logs, device health data, and risk signals provides a more complete picture than Windows Event ID monitoring alone. This visibility helps security teams detect patterns like Kerberoasting attempts or anomalous ticket requests that might not stand out in isolated logs.
What is next for Kerberos and identity security?
Kerberos has been stable for decades. The protocol is not changing significantly. But the environment around it is shifting in ways that affect how organizations think about Kerberos security.
NTLM deprecation accelerates Kerberos adoption. Microsoft officially deprecated NTLM in June 2024 and has outlined a three-phase plan to disable it by default in future Windows releases. Phase 2, scheduled for the second half of 2026, introduces IAKerb and a Local KDC to handle scenarios that previously required NTLM fallback. As NTLM disappears, Kerberos becomes the sole network authentication protocol in Windows environments, making Kerberos security practices more critical than ever.
Non-human identities expand the attack surface. Enterprise identity programs historically focused on human users, but service accounts, automation pipelines, and machine-to-machine credentials are growing faster than human accounts. These non-human identities frequently hold elevated privileges, rarely rotate passwords, and are almost never subject to multi-factor authentication. Extending identity governance to non-human identities, including the service accounts that Kerberoasting targets, is an active area of development for identity security platforms.
Supervised machine learning models improve anomaly detection. Identity security vendors are training models on historical authentication data to flag anomalous Kerberos activity in real time. This is different from rule-based alerting: instead of a static threshold for "too many service ticket requests," a trained model establishes per-user baselines and detects deviations specific to each account's normal behavior. Risk-based authentication that responds to these signals is available today. Fully autonomous Kerberos threat detection without human-defined rules remains an emerging capability.
Continuous verification replaces point-in-time authentication. Kerberos issues a TGT that is valid for hours. Zero trust architectures push organizations to verify identity continuously, not just at the moment of initial authentication. Layering session risk monitoring on top of Kerberos means that a suspicious event mid-session, like a new device or a change in network location, can trigger step-up authentication rather than waiting for the TGT to expire.
Want to strengthen your organization's Kerberos authentication security? Duo adds multi-factor authentication, device trust, phishing-resistant authentication, and much more. Sign up for a free trial today.