Fwd: Fwd: Man page description of kinit -R

[Brett Randall]

On 5 September 2014 02:03, Greg Hudson <ghudson at mit.edu> wrote:
> On 09/04/2014 01:58 AM, Brett Randall wrote:
>> I create a short-life, renewable ticket, then use klist -s to check
>> before/after it has expired.  Then kinit -R is able to renew the
>> ticket.
>
> From your sequence of operations, you're just seeing the five-minute
> grace period for expired tickets.  This grace period exists in order to
> tolerate small amounts of clock skew between the client and KDC.
>

Thank you both Kevin and Greg!  Indeed this is a result of clockskew
grace period.

Initially I had checked kdc.conf, but of course clockskew is declared
in krb5.conf, and I found my KDC had a (non-default) setting of
clockskew = 3600 (1 hour).  If I wait the full hour, the renewal is
then rejected as expected.

Needless to say this caught me out.  When I was reading the main
documentation about ticket expiry, I didn't readily find any
cross-references to clockskew and grace periods.  What is interesting
is that even though the client and KDC clocks are synced to the
second, the grace period is still applied.

I'll consider a doc patch.

>> Also I have read one piece of client code that behaves like this is
>> standard behaviour - it waits until the TGT expires, then renews it.
>
> For automated processes, I would recommend trying to renew the ticket
> when it is halfway to expired.  That's reasonably efficient, allows
> plenty of time to recover from a temporary network or KDC outage, and
> doesn't eat into the built-in clock skew tolerance by relying on the
> grace period.

An excellent suggestion, and I have seen this used in places.  I
believe that the Java JDK Krb5LoginModule is currently relying on this
grace-period when renewing renewable tickets obtained from the
ticket-cache, which added to my confusion, but it is clear now,
thanks!