Category: Federation & SSO

Kerberos

Simply put

Kerberos is a network authentication protocol, originally developed at MIT, that lets a user or service prove its identity to another party across a network that may not be secure. It uses a trusted third party and time-limited tickets so that parties can verify who they are talking to without repeatedly sending passwords over the network. It addresses authentication (verifying identity) and is distinct from authorization, which determines what an authenticated party is permitted to do.

Formal definition

Kerberos is a ticket-based network authentication protocol developed at MIT that relies on secret-key (symmetric) cryptography and a trusted third party to enable two parties to mutually verify identity over an untrusted network. In typical deployments it involves a Key Distribution Center (KDC) that issues time-limited tickets, allowing a principal to authenticate to services without transmitting a shared secret in the clear on each exchange; the evidence provided does not detail the specific KDC message flow, so those internals are out of scope here. Kerberos performs authentication of users or hosts and does not by itself define an authorization model such as RBAC or ABAC, though authorization data may be conveyed alongside authentication depending on the implementation (for example, Windows Server integrates Kerberos into its authentication stack). Note that vendor descriptions vary in accuracy: contrary to one source in the evidence, Kerberos is an authentication protocol and not a gateway or router between users and the internet.

Why it matters

Kerberos underpins authentication in many enterprise networks, most notably as a core component of the Windows Server authentication stack. Because it allows a principal to prove its identity without repeatedly transmitting a shared secret in the clear across the network, it reduces the exposure of credentials to interception on untrusted links. For security architects and administrators, understanding Kerberos is essential to reasoning about how users and hosts establish trust in domain-joined environments and how that trust propagates to network services.

Kerberos handles authentication, verifying who a principal is, and does not by itself define an authorization model such as RBAC or ABAC. This distinction matters operationally: confirming a user's identity via Kerberos is a separate concern from deciding what that user may access, even though some implementations convey authorization-related data alongside the authentication exchange. Treating Kerberos as though it settles authorization decisions can lead to gaps in access enforcement design.

The evidence also illustrates why precision matters when consulting vendor and third-party descriptions: at least one source in the digest inaccurately characterizes Kerberos as a system or router providing a gateway between users and the internet. Kerberos is an authentication protocol, not a network gateway or perimeter device, and engineers relying on imprecise definitions risk misdesigning the role it plays in their architecture.

Who it's relevant to

System Administrators

Administrators managing domain-joined environments encounter Kerberos directly, since it is integrated into the Windows Server authentication stack to verify the identity of users and hosts. Understanding its ticket-based model helps in diagnosing authentication behavior across network services.

Security Architects

Architects need to place Kerberos correctly as an authentication protocol, not a gateway or authorization mechanism, when designing how trust is established between principals and services over untrusted networks, and when reasoning about where authorization decisions must be enforced separately.

IAM Engineers

Engineers building or integrating authentication flows benefit from understanding Kerberos's use of a trusted third party (the KDC) and time-limited tickets, which avoids repeatedly sending credentials over the network. Knowing that Kerberos performs authentication but does not by itself define an authorization model informs how it is combined with access control systems.

Compliance Officers

Those assessing authentication controls should recognize that Kerberos addresses identity verification and that its use of symmetric cryptography and time-limited tickets is one part of an overall access architecture, distinct from the authorization and governance controls that determine what authenticated principals may do.

Inside Kerberos

Key Distribution Center (KDC)

The trusted third-party service at the center of Kerberos, typically comprising the Authentication Service (AS) and the Ticket-Granting Service (TGS). In most deployments the KDC maintains or accesses a database of principals and their long-term secret keys.

Authentication Service (AS)

The KDC component that verifies a principal's identity during initial authentication and, on success, issues a Ticket-Granting Ticket (TGT). This step performs authentication rather than authorization.

Ticket-Granting Ticket (TGT)

A ticket issued by the AS after initial authentication that the client subsequently presents to the TGS to obtain service tickets, avoiding repeated submission of the long-term credential. The TGT is typically time-limited depending on configuration.

Ticket-Granting Service (TGS)

The KDC component that, given a valid TGT, issues service tickets for specific target services. It does not by itself determine what the principal may do within the target service; fine-grained authorization is generally handled by the service.

Service Ticket

A ticket the client presents to a target service to prove its authenticated identity for that specific service. It typically encodes session information and is scoped to the requested service.

Principal

A uniquely named entity (a user, host, or service) known to the KDC. Principals are the subjects and targets of authentication in a Kerberos realm.

Realm

The administrative boundary of a Kerberos deployment, encompassing the KDC and the principals it serves. Cross-realm trust, where configured, allows authentication to span multiple realms.

Session Keys and Authenticators

Symmetric session keys distributed within tickets, together with authenticators that include timestamps, are used to establish mutually agreed sessions and to help mitigate replay. Kerberos relies heavily on symmetric-key cryptography and on synchronized clocks across participants.

Common questions

Answers to the questions practitioners most commonly ask about Kerberos.

Does Kerberos handle authorization as well as authentication?

No. Kerberos is fundamentally an authentication protocol: it verifies the identity of a principal (a user or service) and issues tickets proving that identity. It does not determine what an authenticated principal is permitted to do. Authorization is a separate step handled by the resource or application, sometimes using data carried alongside Kerberos tickets. For example, Microsoft's Active Directory implementation places group membership and related data in a Privilege Attribute Certificate (PAC) inside the ticket, but interpreting that data to make access decisions is the service's responsibility, not Kerberos's. Keep identification, authentication, and authorization as distinct stages when reasoning about a Kerberos-based access flow.

Is the Kerberos ticket-granting ticket (TGT) a user's password sent across the network?

No. A common misconception is that Kerberos transmits passwords for authentication. In most deployments the password (or a key derived from it) never traverses the network during ticket exchange. Instead, the Key Distribution Center (KDC) issues a TGT that the client uses to request service tickets, relying on shared symmetric keys and encrypted exchanges rather than sending the credential itself. This design is one of the protocol's core goals. Note that specifics depend on the implementation, configured encryption types, and whether pre-authentication is enabled.

What components do I need to operate a Kerberos environment?

At minimum, a Kerberos deployment involves a Key Distribution Center (KDC), which typically comprises an Authentication Service (AS) and a Ticket-Granting Service (TGS); client principals; and service principals that clients wish to access. Each principal shares a long-term key with the KDC. In many enterprise environments the KDC role is provided by a directory-integrated system, such as Active Directory Domain Controllers, rather than a standalone MIT Kerberos KDC. The exact topology, replication, and high-availability approach depend on your chosen implementation and scale requirements.

Why is time synchronization important in Kerberos deployments?

Kerberos tickets carry timestamps and have limited validity windows to reduce the risk of replay. Because of this, clients, servers, and the KDC generally need clocks that agree within a configured tolerance (often a few minutes by default, though this is adjustable). If clock skew exceeds the allowed tolerance, authentication typically fails. For this reason most deployments rely on a consistent time source such as NTP across all participating hosts. The precise default skew tolerance depends on the implementation and its configuration.

How does Kerberos relate to single sign-on within an environment?

Once a principal obtains a ticket-granting ticket, it can request service tickets for additional services without re-entering credentials for the lifetime of the TGT, which provides an SSO experience within the Kerberos realm. This is distinct from web federation SSO approaches such as SAML 2.0 or OpenID Connect, which address browser-based cross-domain scenarios. In practice, organizations often combine Kerberos for intranet or internal service SSO with federation protocols for external and web applications, depending on the applications involved.

What should I consider when troubleshooting Kerberos authentication failures?

Common areas to examine include clock skew between hosts, correct Service Principal Name (SPN) registration for the target service, DNS resolution consistency, and matching supported encryption types between client, KDC, and service. Misconfigured or duplicate SPNs and name-resolution mismatches are frequent causes of failures in many deployments. The specific diagnostic tools and log locations vary by implementation, so consult the documentation for your particular KDC and client platform rather than assuming a single procedure applies universally.

Common misconceptions

Kerberos handles both authentication and authorization.

Kerberos is fundamentally an authentication protocol that verifies principal identity and issues tickets. Determining what an authenticated principal may do is generally left to the target service or a separate authorization mechanism; any authorization data carried in tickets depends on the deployment and profile.

Kerberos tickets are secure because they are encrypted, so contents are always hidden from everyone.

Ticket protection relies on symmetric keys, and different portions of a ticket are readable by different parties depending on which key encrypts them. Encryption and integrity protection are not the same guarantee, and the security properties depend on key management and configuration.

Kerberos works out of the box across any network without special requirements.

Kerberos typically depends on reasonably synchronized clocks across clients, the KDC, and services because authenticators use timestamps to help resist replay. Time skew beyond the configured tolerance commonly causes authentication failures.

Best practices

Harden and closely restrict access to the KDC, since it holds or accesses principal secret keys and is the central trust anchor whose compromise typically undermines the entire realm.

Maintain reliable, synchronized time across the KDC, clients, and services to stay within the configured clock-skew tolerance and avoid timestamp-related authentication failures.

Treat Kerberos as an authentication mechanism and implement authorization separately at the target service or via a dedicated policy layer, rather than assuming tickets alone enforce entitlements.

Configure appropriate ticket lifetimes and renewal policies so that TGTs and service tickets balance usability against exposure if a ticket is compromised.

Review and, where supported, strengthen the encryption types and key management used for principals, retiring weak configurations in favor of stronger options offered by your implementation.

When spanning multiple realms, configure cross-realm trust deliberately and scope it narrowly, documenting which realms are trusted and for what purpose.