Why Kerberos Uses Tickets
Kerberos is a widely implemented protocol for strong, repeatable authentication within trusted networks. Its core innovation is the use of encrypted tickets, not passwords or static tokens, to prove identity and grant access to network resources. Tickets allow users and services to authenticate securely and repeatedly without transmitting sensitive credentials over the network after the initial login. This architecture is central to supporting single sign-on (SSO), reducing password exposure, and enabling controlled delegation across systems.
A Kerberos ticket is not a password, nor is it a generic bearer token. It is an encrypted, time-limited indicator—issued by a central authority—that the holder has authenticated and is permitted to interact with specific services. Understanding Kerberos tickets, how they are issued and managed, and how they differ from other tokens like SAML or JWT, is essential for securely integrating LDAP authentication and managing directory-based SSO.
Ticket Types: TGTs and Service Tickets Explained
Kerberos defines two main types of tickets, each serving a distinct role in the protocol:
- Ticket-Granting Ticket (TGT): Issued upon successful authentication, the TGT allows a client to obtain service tickets for other resources without re-entering a password.
- Service Ticket (ST): Issued when a user requests access to a specific service, the service ticket is presented directly to that service to prove identity and authorization.
The TGT acts as a reusable, encrypted "proof of authentication" valid for a limited time. It does not directly grant access to services, but is exchanged with the Key Distribution Center (KDC) for service tickets. Service tickets are purpose-specific and valid only for one service; they are encrypted so that only the target service can validate them.
TGTs and service tickets work together to deliver SSO, allow for delegation, and minimize password exposure, ensuring that sensitive credentials never cross the network after the initial authentication.
How Are Kerberos Tickets Issued and Used? Step-by-Step Flow
Kerberos authentication is a multi-step process involving clear roles:
1. Authentication Service Exchange (AS Exchange):
- The client sends an initial authentication request to the KDC’s Authentication Server (AS).
- The AS verifies the user's identity and creates a TGT, encrypting it with the KDC’s secret key (not the user’s password). The client also receives a session key, usually encrypted with a key derived from the user’s password.
- The TGT, accompanied by the session key, is stored in the client’s credential cache.
2. Ticket-Granting Service Exchange (TGS Exchange):
- When the client needs to access a service (such as an LDAP directory), it sends the TGT and an authenticator to the Ticket Granting Service (TGS), a function of the KDC.
- The TGS validates the TGT and creates a service ticket, encrypting it with the target service’s secret key.
- The client receives the service ticket and a session key for communication with the service.
3. Service Exchange:
- The client presents the service ticket (and a new authenticator) to the target service.
- The service decrypts the ticket with its own key and validates the ticket and authenticator.
- If valid, the service grants access for the duration of the ticket’s validity.
At every step, neither passwords nor reusable secrets traverse the network. Instead, short-lived, encrypted tickets and authenticators prove identity and session continuity.
Anatomy of a Kerberos Ticket: Structure, Flags, and Key Fields
A Kerberos ticket contains more than just user identity. The general structure (refer to RFC 4120) encapsulates:
- Client Principal: The authenticated identity (e.g., username@REALM).
- Server Principal: The service for which the ticket is valid (e.g., ldap/server.example.com@REALM).
- Session Key: A symmetric key shared between the client and service for securing subsequent communications.
- Validity Timestamps: Including start time, end time (expiration), and (optionally) a renewable-until value.
- Ticket Flags: Bitfield properties that define allowed uses and behaviors:
- Forwardable: The ticket can be presented to other services or hosts to obtain additional tickets—enabling delegation.
- Renewable: The ticket can be renewed for an extended period, supporting long-running sessions or scripts.
- Proxiable: Allows the service holding the ticket to request tickets on behalf of the user, for delegated access.
- Postdated/Invalid: Ticket is not valid before a certain time, often requiring validation upon activation.
- Initial: Indicates that this ticket was issued based on initial authentication, not from ticket renewal.
- Flags are critical for controlling how tickets behave in SSO, delegation, and automated environments.
Tickets are always encrypted: TGTs with the KDC’s key; service tickets with the target service’s key. Only the correct service or KDC can decrypt and validate the ticket, ensuring strict audience control.
Kerberos Ticket Lifecycle: Expiration, Renewal, and Revocation
Tickets are issued for limited periods to balance usability and security:
- Lifetime: The default for TGTs is often around 10 hours (e.g., Windows default), but can be less depending on policy. Service tickets generally inherit the TGT's expiration, or are often shorter-lived.
- Renewal: If the renewable flag is set, a ticket can be renewed (typically without re-entering a password) within a defined renewal window (commonly up to 7 days). Renewal does not extend past the maximum lifetime set by policy.
- Revocation and Destruction: Tickets are not individually revoked via protocol-level blacklists. Instead, when they expire or are destroyed (e.g., via logout or explicit cache destruction), they become unusable. Manual destruction of tickets (clearing credential caches) is critical in high-security or shared environments.
- Expiration: When a ticket expires, authentication requests will fail until a new ticket is issued, usually requiring fresh authentication at the KDC.
Ticket lifetime policies are crucial for balancing continuous SSO with mitigating risks like session hijacking or credential theft.
Storing and Managing Kerberos Tickets: Credential Caches and Security Concerns
Tickets are stored on the client in credential caches (commonly called ccache or, in Windows and some tools, .kirbi files). These caches hold all active tickets and their session keys for the user's session.
Key considerations:
- Access to a credential cache grants the ability to impersonate the ticket’s owner until the tickets expire or are destroyed.
- Stale or forgotten caches can allow attackers post-session access, especially on shared systems.
- Explicit cache destruction (e.g., running a kdestroy tool) is a best practice at session end in sensitive contexts.
Credential caches can be inspected to debug ticket presence, flags, and lifetimes, helping developers and engineers troubleshoot authentication or delegation issues.
Kerberos Tickets in Active Directory: Policies and Practical Differences
In Active Directory (AD), Kerberos ticket mechanics follow the standard protocol with environment-specific behaviors:
- Default Lifetime: User TGTs have a default 10-hour lifetime and a 7-day renewal window, controlled via Group Policy settings.
- Service Tickets: Generally have shorter lifetimes or track the parent TGT expiration. Renewal and forwardability policies may be set per policy or per-principal.
- Auditing: AD logs ticket issuance/expiration events for security monitoring (e.g., Event 4768 for TGT issuance).
- Policy Controls: Ticket lifetimes, renewability, and forwardability flags are centrally managed, and misconfigurations can introduce authentication or SSO failures, or create unnecessary risk.
While the basics mirror MIT Kerberos, AD often adds administrative controls and enhanced auditing, which are especially relevant in regulated or sensitive environments.
Security Implications: Ticket Flags, Golden Tickets, and Attacks
The security of Kerberos hinges on careful ticket management:
- Forwardable and Proxiable Flags: Enable SSO and delegation, but if misused or over-permissive, can allow lateral movement by attackers or credential theft.
- Golden Ticket Attacks: An attacker with access to the KDC’s secret key can forge TGTs for any user (a "Golden Ticket"), resulting in undetectable privilege escalation. This risk underscores the need for strict KDC protection and regular key rotation.
- Session Hijacking: If credential caches are compromised, attackers can replay valid tickets until they expire. Secure cache management is essential.
- Auditing and Monitoring: Validating unusual volumes of renewals, ticket requests, or anomalous flag usage can help detect misuse.
Security best practices include enforcing minimal ticket lifetimes, setting renewal constraints, and ensuring ticket caches are ephemeral and properly destroyed.
Kerberos Tickets vs SAML/JWT: What Makes Them Different?
While SAML tokens, JWTs, and Kerberos tickets all play a role in access control, their models and usage differ fundamentally:
- Kerberos: Tickets are issued and validated entirely within a trusted, symmetric-crypto environment (the KDC). Audience is guaranteed by direct encryption. Tickets are always time-limited, non-portable, and validated by possession of principal secrets.
- SAML/JWT: These are often bearer tokens validated via public-key signatures, not symmetric encryption. They can be transmitted across security domains (e.g., across the web), and the trust model depends on signature validation rather than secret possession.
- Usage: Kerberos is optimal for controlled, internal network authentication (e.g., enterprise SSO, LDAP, AD), while SAML/JWT are suited to federated, stateless, and web-scale scenarios.
They are not interchangeable; swapping one for another can introduce trust, validity, or auditing failures.
Practical Takeaways
Kerberos tickets are time-limited, encrypted credentials that enable repeatable, passwordless, and auditable authentication in distributed systems. Developers and practitioners should always remember:
- Tickets never contain user passwords; they encapsulate identity and session keys.
- TGTs and service tickets play distinct roles, enabling SSO and strict access boundaries.
- Tickets are never permanent—they expire, can be (optionally) renewed, and must be deleted when sessions end.
- Ticket flags (forwardable, renewable, etc.) control crucial behaviors for delegation, SSO, and security—review them carefully.
- Secure and purge ticket caches to minimize impersonation risks.
- Active Directory adds specific lifetime, audit, and policy controls—and misconfigurations can impact authentication robustness.
- Kerberos tickets operate on a different trust and cryptographic model than SAML or JWT tokens; treat them accordingly.
- Misunderstandings—such as conflating tickets with passwords or other tokens—lead to integration, security, and troubleshooting pitfalls.
Correct management of Kerberos tickets is essential to achieving secure, reliable SSO and LDAP authentication in both standard and Active Directory environments.