What category of protocol this is
Kerberos is a network authentication protocol. The core specification taught here is The Kerberos Network Authentication Service (Version 5), published as RFC 4120 in July 2005. RFC 4120 obsoletes RFC 1510, the earlier Version 5 specification. It is an IETF standards-track document. It is not a U.S. statute, not a federal program, and not a product.
The core idea is a trusted third party. Clients obtain tickets from a Key Distribution Center (KDC), so a client and a service can authenticate without the client sending a long-term secret, such as a password-derived key, to every service it uses. RFC 4120 assumes an open network where packets can be read, modified, and inserted, which is why tickets are encrypted and paired with session keys. Users and services are principals, and they belong to a realm, the administrative domain a KDC serves.
Edition pin
Teach Kerberos Version 5 as specified in RFC 4120 (July 2005), which obsoletes RFC 1510. Later RFCs update parts of Version 5, such as encryption types and extensions. This page stays at the RFC 4120 concept level and does not track each update. Re-open the RFC Editor page at publish and check its Updated by list before you cite a specific detail.
Optional vocabulary companion: NIST SP 800-57 Part 3 Revision 1 (Recommendation for Key Management, Part 3: Application-Specific Key Management Guidance) includes a high-level Kerberos overview. Use it for key management vocabulary only. This page does not turn it into a hardening or configuration checklist.
Four actors on one screen
Client: the principal asking to use something, such as a user's workstation. Authentication Service (AS): the KDC entry point for the first exchange, which issues a ticket-granting ticket. Ticket-Granting Service (TGS): the KDC entry point that accepts a ticket-granting ticket and issues tickets for named services. Application service: the target server the client actually wants, such as a file, mail, or web service in the realm.
AS and TGS are different protocol entry points with different jobs. They are often hosted together in one KDC. Co-located does not mean the same exchange.
The ticket path at slogan depth
First, the client asks the AS. In the usual case the AS returns a ticket-granting ticket (TGT) plus a session key for talking to the TGS. Second, the client presents the TGT to the TGS and asks for a ticket to a named service. The TGS returns a service ticket plus a session key for that service. Third, the client presents the service ticket, together with a fresh authenticator, to the application service. The service decrypts the ticket with its own key and checks the authenticator. RFC 4120 calls these the AS exchange, the TGS exchange, and the client/server (AP) exchange.
The habit: a TGT gets you more tickets. A service ticket authenticates you to one named service. A TGT is a ticket for the TGS itself, not for the file share, and a service ticket for one service does not open a different one.
Tickets have lifetimes set by realm policy. This page does not recommend lifetimes, clock skew values, or encryption types. Those are owner decisions made against current vendor and standards guidance, not Atlas numbers.
What a ticket proves, and what still happens
A validated exchange gives the service cryptographic evidence about which client principal it is talking to, within the trust of that realm. That is authentication. RFC 4120 says Kerberos does not, by itself, provide authorization. Possession of a ticket for a service only authenticates the client to that service, and an application should not treat it as permission without a separate authorization step.
The relying service still decides authorization. It checks local policy, group membership, access control lists (ACLs), and its own application rules. Some deployments carry authorization data inside tickets, and the service still has to interpret and enforce it. Got a ticket is not the same as allowed to do everything.
SSO names several ticket grammars
People say SSO for Kerberos on an enterprise network, for OAuth and OpenID Connect in browsers and apps, and for SAML in enterprise web sign-in. Those are different protocol families with different objects, different audiences, and different validation rules. Sort the object before you debug it.
A Kerberos service ticket is a KDC-issued authentication credential for a Kerberos service in a realm. An OAuth access token is an authorization credential for a resource API. An OIDC ID Token is an identity assertion to the client about an authentication event. A SAML assertion is an XML statement from an identity provider, often used in enterprise browser SSO. The Identity federation path teaches the last three: who holds the ticket (IF1), claims are not admin (IF2), and federation failure modes (IF3).
A protocol, not one product, and not obsolete
Kerberos is a protocol. Microsoft Active Directory is a very common deployment context, and many people first meet Kerberos there. It is not only Active Directory. MIT Kerberos, Heimdal, and other implementations run Kerberos realms, and many operating systems and services speak it.
It is also not obsolete. Version 5 remains in wide use for enterprise network authentication, and it often sits beside federation protocols rather than being replaced by them. This page stays at literacy depth. It does not cover attack techniques or domain controller hardening. Those belong with the owning team and current vendor guidance, not in a teaching card.
Rewrite the SSO ticket sentence
Synthetic case: an employee signs in to a workstation on a corporate network, opens an internal file share without a second prompt, then opens a SaaS dashboard through the company identity provider. Someone says "the SSO ticket let them in everywhere."
Rewrite it: the workstation sign-in obtained a Kerberos TGT, the TGS issued a service ticket for the file share, and the file share still checked its own permissions. The SaaS dashboard received a SAML assertion or an OIDC ID Token from the identity provider, and the dashboard still decided what the account may do. Two protocol families, two objects, and two authorization decisions.
At work, privately ask the identity owner which protocol each app actually uses. Do not paste real realm names, principal names, tickets, or tokens into Atlas.
A Kerberos ticket is not every SSO ticket
Teaching table only. It does not assess a realm, an identity provider, or an application, and it does not assign a security finding.
| Phrase people say | Literacy correction |
|---|---|
| A Kerberos service ticket. | KDC-mediated authentication credential for a named Kerberos service in a realm, presented with an authenticator. Not an OAuth access token, an OIDC ID Token, or a SAML assertion. |
| An OAuth access token. | Authorization credential a client presents to a resource API. Different protocol family from Kerberos. Lesson: /learn/topics/who-holds-the-ticket/ (IF1). Term: /reference/terms/oauth/. |
| An OIDC ID Token. | Identity assertion to the client about an authentication event. Not an API credential and not a Kerberos ticket. Lesson: /learn/topics/assertion-claims-not-admin/ (IF2). Term: /reference/terms/oidc/. |
| A SAML assertion. | XML assertion from an identity provider, often used in enterprise browser SSO. The service provider still validates it and still authorizes. Lesson: /learn/topics/federation-failure-modes/ (IF3). Term: /reference/terms/saml/. |
| I have a Kerberos ticket, so the app must allow every action. | A ticket authenticates the client to one service. The service still decides authorization from local policy, groups, ACLs, and app rules. Terms: /reference/terms/authentication/ and /reference/terms/authorization/. |
Claims to retire
SSO means one ticket type, so Kerberos, OAuth, OIDC, and SAML are the same thing.
SSO is an experience, not one object. A Kerberos service ticket, an OAuth access token, an OIDC ID Token, and a SAML assertion come from different protocol families with different audiences and validation rules.
If Kerberos authenticated me, the app must allow every action.
A ticket authenticates the client to a service. RFC 4120 says Kerberos does not, by itself, provide authorization. The service still decides what the client may do.
Kerberos is only Active Directory, or it is obsolete.
Kerberos is a protocol with several implementations. Active Directory is a common deployment context, not the definition. Version 5 is still in wide use for enterprise network authentication.
Learning Kerberos means practicing ticket attacks.
Literacy comes first: actors, tickets, and the authentication versus authorization split. This page contains no attack procedures and no exploit content.
Atlas can certify a realm as Kerberos-secure.
Atlas does not attest realms or domains and issues no Kerberos seal. Completing this lesson is not an assessment of any deployment.
CHECK THE CATEGORY
Which sentence matches this page?
Glossary and nearby pages
- Identity federation path: Trust tickets, not hallway trust
- IF1: Who holds the ticket, and what does it open? (OAuth access tokens)
- IF2: ID Token and SAML assertion are claims, not blank admin passes
- IF3: Five ways the ticket still burns you (federation failure modes)
- Authentication vs authorization (term guides)
- Privacy is not a CIA checkbox
Use the agency page in the sources for the authoritative text. This page has no figure.