Kerberos V5

What it is

Kerberos V5 is a network authentication protocol built on a trusted third party, the Key Distribution Center (KDC), that shares a secret key with every user and service in its realm. The KDC hands out encrypted, time-limited tickets; a client proves who it is to a service by presenting a ticket the service can decrypt, plus a fresh authenticator only the legitimate client could produce. Passwords never cross the network, and users sign in once per session.

The protocol is RFC 4120 (July 2005), written by C. Neuman (USC-ISI) with T. Yu, S. Hartman and K. Raeburn (MIT); it obsoletes RFC 1510. The GSS-API mechanism that applications actually call is RFC 4121. Every Active Directory domain controller is a KDC, and Windows adds its own extensions in MS-KILE and the authorization data format MS-PAC. On Linux, MIT Kerberos and Heimdal are the main implementations; FreeIPA bundles MIT Kerberos, and Keycloak documents a Kerberos bridge for desktop SSO (both checked on the project sites, 5 November 2026).

Status (November 2026)

Kerberos is not being replaced in Windows networks any time soon, but its configuration is changing underneath: the RC4 default for service tickets in Active Directory was the subject of CVE-2026-20833, and PAC validation enforcement has been tightened in stages since 2022 (see CVE-2024-26248).

How it works

Three exchanges, each defined in RFC 4120 §3:

1. AS exchange (§3.1). The client sends AS-REQ naming itself and the ticket-granting service krbtgt/REALM. With pre-authentication, it includes a timestamp encrypted with its long-term key (PA-ENC-TIMESTAMP, §5.2.7.2). The KDC replies with AS-REP: a ticket-granting ticket (TGT) encrypted with the krbtgt key, and a session key encrypted with the client's key.
2. TGS exchange (§3.3). For each service, the client sends TGS-REQ with the TGT and an authenticator, naming a service principal such as HTTP/app.example.com. The KDC returns a service ticket encrypted with that service's key.
3. AP exchange (§3.2). The client sends AP-REQ to the service, carried inside the application protocol (SMB, LDAP SASL GSSAPI, or HTTP Negotiate per RFC 4559). The service decrypts the ticket with its own key, checks the authenticator, and optionally answers with AP-REP for mutual authentication.

Time matters: authenticators are rejected outside an allowable clock skew (RFC 4120 gives 5 minutes as the example), and servers keep a replay cache for that window. The field-by-field version of all three exchanges is in how Kerberos works, message by message.

Active Directory specifics that change the security picture

• The PAC. Domain controllers put a Privilege Attribute Certificate in the ticket's authorization data with the user's SIDs and group memberships, signed by the KDC (MS-PAC). Services authorize from it, so PAC forgery or skipped PAC validation means privilege escalation.
• Service keys come from passwords. A service principal registered on a user account has a key derived from that account's password. Any domain user can request a ticket for it, and a weak password can be cracked offline: Kerberoasting.
• Delegation. Unconstrained, constrained and resource-based constrained delegation (S4U2self and S4U2proxy in MS-SFU) let services act as users; misconfigured delegation is a domain-compromise path: Kerberos delegation abuse.
• Certificate logon. PKINIT ties Kerberos to AD Certificate Services, so certificate template mistakes become Kerberos logons as other users: AD CS certificate template abuse.
• The krbtgt key. Whoever holds it can mint TGTs for anyone, so a suspected domain compromise includes rotating it.

Where Kerberos breaks in practice

On 5 November 2026 the SWI identity CVE catalog held 14 entries tagged Kerberos and Active Directory. The recurring classes:

• PAC and identity validation gaps: CVE-2024-26248, CVE-2024-29056 (cross-forest), CVE-2026-27912 (kpasswd ignoring PAC_REQUESTOR_SID).
• Protocol extension logic: CVE-2025-60704 (S4U missing a cryptographic step), CVE-2025-26647 (PKINIT and NTAuth), CVE-2022-26923 (Certifried).
• KDC impersonation and reflection: CVE-2024-20674, CVE-2025-33073 and CVE-2025-58726 (Kerberos reflection over SMB).
• Weak defaults and naming: CVE-2026-20833 (RC4 service tickets), CVE-2026-25177 (look-alike SPNs with invisible Unicode).

When to use it

Kerberos is the right protocol for authentication inside a managed network: Windows domains, Linux hosts joined to a realm, file and database services, and LDAP binds via SASL GSSAPI. It is a poor fit across the internet or into SaaS, where it needs direct reachability to the KDC; SAML 2.0 and OpenID Connect federate from the same directory instead. Where an application can do Kerberos, prefer it over NTLM and over LDAP simple binds with passwords.

Pitfalls

• Service accounts with SPNs, weak passwords and RC4 still enabled.
• Unconstrained delegation on servers that are not domain controllers.
• Clock drift between clients, servers and KDCs, which breaks logons and tempts admins to widen the skew.
• Clients connecting by IP address or a name with no matching service principal, which can fall back to NTLM without anyone noticing.
• Treating a decrypted ticket as authorization. RFC 4120 §3.2.3 says passing the checks "provides only authentication of the named principal"; the application must still decide what that principal may do.

How it works, message by message

The Kerberos message-flow walkthrough decodes AS-REQ with pre-authentication, AS-REP, TGS-REQ, TGS-REP and AP-REQ field by field, shows what is inside a ticket and an authenticator, ties every field to RFC 4120 section 5, and lists the checks the client, the KDC and the service must each run.

Related

Walkthrough: how Kerberos works, message by message. Standards: LDAP, RADIUS. Glossary: Kerberos, NTLM, Active Directory. Guides: what is ITDR, identity threat detection and response.