Skip to content
Calcrivo

Kerberos Ticket Lifetime Calculator

Work out TGT renewals per session, the 7-day renewal ceiling and KDC request load from your Kerberos policy.

Inputs

hours

Windows and MIT Kerberos both default to 10 hours.

days
hours
users
minutes

Renewals per Session

1

Ticket Lifetime

10h

Renewal Ceiling

168hours

AS Requests to the KDC per Day

15,000

Total Clock Skew Window

10minutes

Full Re-Authentication Required

No

Step by step

  1. Values used

    Ticket-granting ticket lifetime = 10 hours; Renewal window = 7 days; Typical user session length = 12 hours; Users authenticating per day = 5,000 users; Maximum tolerated clock skew = 5 minutes

  2. Kerberos Ticket Lifetime

    renewals per session = ceil(session length ÷ ticket lifetime) − 1, capped by the renewal window; beyond that window the client must authenticate again from scratch.

  3. Clock skew tolerance

    clock skew window = 2 × maximum tolerated skew, because a ticket can be either ahead of or behind the KDC clock.

  4. Renewals per Session

    = 1

  5. Ticket Lifetime

    = 600

  6. Renewal Ceiling

    = 168 hours

  7. AS Requests to the KDC per Day

    = 15,000

  8. Total Clock Skew Window

    = 10 minutes

  9. Full Re-Authentication Required

    = No

How it works

A ticket-granting ticket is valid for its lifetime and can be renewed repeatedly until the renewal window expires. Renewals are cheap TGS exchanges; crossing the renewal ceiling forces a full AS exchange, which needs the user's credential rather than just the existing ticket. The 10-hour default exists so a stolen ticket expires within a working day, and lengthening it to avoid mid-shift prompts extends exactly that theft window — while a machine more than five minutes out of sync fails Kerberos entirely.

Formulas

Kerberos Ticket Lifetime

renewals per session = ceil(session length ÷ ticket lifetime) − 1, capped by the renewal window; beyond that window the client must authenticate again from scratch.

ticket lifetime
How long a TGT is valid before it must be renewed — 10 hours by default
renewal window
How long renewals may continue before a fresh AS exchange is required — 7 days by default

Clock skew tolerance

clock skew window = 2 × maximum tolerated skew, because a ticket can be either ahead of or behind the KDC clock.

5 minutes
Default maximum skew in both Windows and MIT Kerberos

Frequently Asked Questions

How is Kerberos Ticket Lifetime calculated?

renewals per session = ceil(session length ÷ ticket lifetime) − 1, capped by the renewal window; beyond that window the client must authenticate again from scratch. A ticket-granting ticket is valid for its lifetime and can be renewed repeatedly until the renewal window expires. Renewals are cheap TGS exchanges; crossing the renewal ceiling forces a full AS exchange, which needs the user's credential rather than just the existing ticket.

Why does Kerberos Ticket Lifetime matter?

The 10-hour default exists so a stolen ticket expires within a working day, and lengthening it to avoid mid-shift prompts extends exactly that theft window — while a machine more than five minutes out of sync fails Kerberos entirely.

What values do I need to enter?

This calculator takes 5 inputs: Ticket-granting ticket lifetime, Renewal window, Typical user session length, Users authenticating per day, Maximum tolerated clock skew. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why is the Kerberos ticket lifetime 10 hours?

It is chosen to outlast one working day so users are not prompted mid-shift, while guaranteeing that a stolen ticket is useless the next morning. The paired 7-day renewal window lets long-running sessions and services keep renewing for a week without ever re-sending credentials.

What happens if a clock drifts more than five minutes?

Authentication fails with a clock-skew error, because the KDC treats timestamps outside the tolerance as a replay attempt. This is why domain members synchronise time from the domain hierarchy and why a broken NTP source can look exactly like a total authentication outage.

You might also need