Learn Kerberos - Ticket Management & Lifetime

#Introduction

In episode 8 you set principal attributes such as -maxlife and -maxrenewlife from the admin side. Episode 9 covers the same subject from the ticket itself — how these properties behave at runtime, how to control them when requesting a ticket, and how to keep tickets alive for long-running jobs. This material feels very real every time you run into a Ticket expired message in the middle of a batch process.

#Ticket Properties

Every ticket carries a set of properties (attributes) that determine what can and cannot be done with it:

• Lifetime — how long the ticket is valid from issuance. This is the most basic "validity period."
• Renewable — the ticket can be renewed without entering the password again, up to the renew lifetime limit. Analogy: a passport can still be extended as long as it's within its validity period.
• Forwardable — the ticket can be sent to another host and used there, for example when SSHing into a second machine.
• Proxiable — similar to forwardable, but only for the designated service; the destination host cannot forward it again.
• Postdated — the ticket becomes valid at a specific time in the future, not when issued.

The difference between forwardable and proxiable is often confusing. Forwardable gives the destination host a blank card — that host can pass it on again. Proxiable gives a card with a name on it — only for a specific service and cannot be forwarded further. For daily use, forwardable is by far the most common; proxiable is rarer.

#Setting Lifetime in Configuration

Default lifetime values are set in the [libdefaults] section of /etc/krb5.conf:

Lifetime settings in /etc/krb5.conf

[libdefaults]
    default_realm = EXAMPLE.COM
    ticket_lifetime = 10h
    renew_lifetime = 7d
    forwardable = true
    proxiable = false

ticket_lifetime sets the default TGT age; renew_lifetime sets how long a ticket can still be renewed. The effective value is always min(client request, principal maxlife, KDC default) — as you learned in episode 8. So changing ticket_lifetime here only affects this client, not the whole realm.

#Requesting a Specific Lifetime: kinit -l and -r

Sometimes you need a shorter ticket (for a sensitive, brief session) or a longer one (for a long job). kinit provides -l for lifetime and -r for renewable:

kinit -l 4h -r 7d budi
klist

kinit -l 4h -r 7d requests a TGT with a 4-hour lifetime that can be renewed for up to 7 days. Without -r, the ticket cannot be renewed at all. The combination of -l and -r is the foundation of every renewable strategy below.

#Renewing Tickets for Long-Running Jobs

The classic problem: a batch job (for example, a data pipeline or backup) starts at 8 a.m. and needs to keep authenticating for the next 3 days. A normal ticket expires in a matter of hours. There are two layers of solution:

1. Manual renewal — kinit -R extends the ticket as long as it's still within the renewable limit and hasn't expired.

kinit -R

2. Automatic renewal — k5start or krenew keep tickets alive using a keytab, without human intervention. k5start acquires the initial ticket and renews it periodically; krenew only renews an already-existing ticket.

k5start -f /etc/keytabs/batch.keytab -b -K 60 -l 24h -r 7d -p /run/batch.pid

The -f option points to the keytab, -b runs in the background, -K 60 renews every 60 minutes, -l 24h requests a 24-hour lifetime, -r 7d allows renewal for up to 7 days, and -p writes the PID to monitor the process. With this pattern, a job running for days always has a valid ticket — as long as the lifetime is renewed before it expires.

#TGT vs Service Ticket

Not all tickets are created equal. TGTs and service tickets have different lifecycles:

The key point: when the TGT expires, any service tickets already held remain valid until their own lifetime ends — but you cannot request new service tickets without a valid TGT. In practice, it's the TGT that gets renewed most often, not service tickets.

#Reading Ticket Flags: klist -f

To find out what properties the tickets you hold possess, use klist with the -f flag:

klist -f

The output shows flags in a dedicated column with these meanings:

Note the upper and lower case: F is the capability (the ticket can be forwarded), f is the state (this ticket has indeed been forwarded). The same applies to P vs p and D vs d. Reading these flags is a debugging skill that often saves you when an application complains that a ticket cannot be forwarded.

#Destroying Tickets: kdestroy

If kinit is the front door, kdestroy is the exit. Explicitly clearing the ticket cache is important, especially on shared machines, public terminals, or after you finish an administrative task:

kdestroy
kdestroy -A

kdestroy clears the default cache; kdestroy -A clears all existing caches. Use -A only when you're sure no other session still needs its tickets. A good habit: hook kdestroy into shell logout or the end of administrative scripts that use kinit — so credentials never linger on disk longer than necessary.

#Conclusion

In episode 9, you understood the ticket lifecycle: the lifetime, renewable, forwardable, proxiable, and postdated properties; how to set defaults in krb5.conf; requesting a specific lifetime with kinit -l and -r; keeping long jobs alive with kinit -R and k5start; the difference between TGT and service tickets; reading flags with klist -f; and closing sessions with kdestroy.

Key takeaways:

• Renewable is different from long-lived — renew_lifetime is the maximum extension limit, not the initial lifetime.
• Renew before expiration — once expired, kinit -R can't save anything.
• The TGT is what matters — service tickets can't be renewed, the TGT can.
• klist -f is the window into a ticket's actual properties.

In the next episode, episode 10, we widen the horizon from one realm to many: cross-realm authentication — how two organizations or two domains connect their Kerberos through trust. The ticket and principal concepts you've mastered now will be tested at a larger scale.