What this does
Computes a Kerberos ticket's initial expiry, its absolute renew-till cap, and whether a renewal attempted at a specific time would succeed — and if so, what the new expiry would actually be — from a domain's Kerberos Policy settings (maximum ticket lifetime, maximum renewal lifetime, clock skew tolerance). Entirely in your browser.
Why renewal has a cap that doesn't reset
A renewable Kerberos ticket has two separate expiration concepts: its current endtime (when it stops being valid unless renewed) and an absolute renew-till time, fixed relative to when the ticket was originally issued. Each renewal pushes the endtime forward by up to the maximum lifetime — but never past renew-till, which doesn't move. This is deliberate: without a fixed outer boundary, a ticket could be renewed forever without the holder ever having to re-authenticate with actual credentials again.
FAQ
Why doesn't renewing a ticket just add another full lifetime on top?
Because that would let a ticket be renewed indefinitely, forever. Renew-till is an absolute cap measured from the original issue time — each renewal extends the expiry by up to the maximum lifetime, but never past that fixed cap. Once renew-till passes, the only way to get a new ticket is a fresh logon with actual credentials, not another renewal.
What's actually different between the maximum lifetime and the maximum renewal lifetime settings?
Maximum lifetime controls how long a single ticket is valid before it needs renewing or replacing at all. Maximum renewal lifetime controls the outer boundary on how many times (and for how long in total) that renewal process can keep extending it. Setting the renewal maximum shorter than the lifetime maximum makes the renewal setting pointless — a renewed ticket could never gain any extra validity beyond what it already had.
Why does clock skew tolerance matter for ticket validity at all?
Kerberos timestamps are the mechanism that prevents replaying an old, captured authentication exchange — but that only works if the client and the domain controller roughly agree on what time it is. The skew tolerance is how much disagreement is allowed before a ticket is rejected as either expired or not-yet-valid; too tight and normal clock drift causes real failures, too loose and it weakens the protection against replay.
Are the 10-hour and 7-day defaults actually Windows' defaults?
Yes — Active Directory's Default Domain Policy ships with a 10-hour maximum user ticket lifetime, a 7-day maximum renewal lifetime, and a 5-minute clock skew tolerance, unless an administrator has changed the domain's Kerberos Policy settings.
Does this tool account for service ticket lifetimes separately from the user's TGT?
No — it models a single ticket's lifetime and renewal window generically, which applies the same underlying math whether you're reasoning about a Ticket Granting Ticket or a service ticket. It doesn't model the additional step of a TGT being used to request separate service tickets with their own (often shorter) lifetimes.
Try it yourself
Working with group membership or SIDs instead of ticket policy? AD Security Group Nesting Analyzer and SID Decoder cover those.