Kerberos Ticket Granting and Expiration in Windows 2000

Microsoft Windows 2000 enforces Kerberos ticket granting and expiration policies domain-wide through Group Policy settings managed by the Key Distribution Center (KDC) running on Active Directory domain controllers. By defining parameters such as ticket lifetimes, renewal limits, and clock synchronization thresholds, the operating system controls how long Ticket-Granting Tickets (TGTs) and session service tickets remain valid. These policies prevent unauthorized persistent access and mitigate replay attacks by actively evaluating timestamps and user account states during every stage of the authentication lifecycle.

Domain-Wide Policy Configuration

Kerberos policies in Windows 2000 are not applied on a per-user basis; instead, they are enforced at the domain level. Domain controllers obtain these rules from the Default Domain Policy under Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy.

The KDC, which runs as a subservice within the Local Security Authority Subsystem Service (LSASS) on all domain controllers, reads this policy to determine the validity periods stamped onto authentication tickets.

Core Kerberos Policy Settings

Windows 2000 defines five primary settings to manage ticket issuance and expiration:

  • Maximum lifetime for user ticket: Defines the lifespan of a Ticket-Granting Ticket (TGT). The default is 10 hours. Once this window elapses, the client cannot use the TGT to request new service tickets without re-authenticating or renewing.
  • Maximum lifetime for user ticket renewal: Determines the total duration for which a client can repeatedly renew a TGT without re-entering credentials. The default is 7 days.
  • Maximum lifetime for service ticket: Sets the expiration duration for tickets granted to access specific services or resources. The default is 600 minutes (10 hours). This value cannot exceed the remaining lifetime of the TGT used to request it.
  • Maximum tolerance for computer clock synchronization: Governs the allowable time skew between the client, domain controller, and target server. The default is 5 minutes. Tickets with timestamps that diverge further than this tolerance are rejected to protect against replay attacks.
  • Enforce user logon restrictions: When enabled (the default state), the KDC validates that the requesting account has the right to log on, has not been disabled, and is within designated logon hours each time a ticket is requested.

The Enforcement Process

  1. Initial Ticket Granting (Authentication Service Exchange):
    When a user logs on, the client sends a request to the KDC Authentication Service (AS). If authentication succeeds, the KDC issues a TGT containing two critical timestamps: the issue time and the expiration time (EndTime), calculated by adding the configured maximum user ticket lifetime to the KDC's current system time. It also writes a maximum renewal limit (RenewTill).

  2. Service Ticket Issuance (Ticket-Granting Service Exchange):
    When accessing a network resource, the client submits the TGT to the KDC Ticket-Granting Service (TGS). The KDC verifies that the TGT's expiration timestamp has not passed according to the domain controller's clock. If the TGT is valid and logon restrictions are met, the KDC issues a service ticket stamped with its own expiration time, bounded by the service ticket policy setting and the remaining life of the TGT.

  3. Ticket Renewal:
    If a TGT approaches expiration, the client can request an updated TGT from the KDC before the ticket expires. The KDC checks whether the current time is still within the RenewTill window. If valid, the KDC issues a new TGT with an updated EndTime, extending access without prompting the user for credentials. Once the renewal threshold (such as 7 days) is reached, renewal requests are denied.

  4. Resource Server Validation:
    When the client presents a service ticket to an application server, the server decrypts the ticket using its own shared secret and inspects the embedded expiration timestamp. If the local system clock shows the ticket has expired—or if the ticket's timestamp falls outside the maximum clock skew tolerance—the server rejects the connection. The client must then return to the KDC to request a fresh ticket.