ticket renew lifetime limited by Windows KDC policy

[Russ Allbery]

Di Pe <dipeit at gmail.com> writes:

> We use kerberized nfs for our home directories on desktops and
> computational servers. Users login via pam_krb5 and tickets are
> refreshed via a cron job that checks if users are still logged on and
> executes a kinit -R /tmp/ticketcache if they are to refresh the
> ticket. If they are logged off their ticket cache is deleted. If the
> ticket expires users are instantly cut off their home directory and
> almost all processes freeze. Sometimes a reboot is required.  Some users
> stay logged onto a system for longer than 30 days. To minimize the
> likelihood of this "freeze" to happen we increased renew_lifetime from
> 7d to 90d in the local krb5.conf. Unfortunately the renew lifetime is
> enforced by our Windows 2k3 KDC
> (http://technet.microsoft.com/en-us/library/cc738269%28WS.10%29.aspx)
> . We are debating if we should increase the ActiveDirectory policy from
> 7d to 120d for all users.

> What is the specific risk of increasing the renew lifetime? to 30days,
> 90days, 120days? For Windows and Unix systems?

The risk is that anyone who steals that ticket cache can then continue to
act as that user for the full length of the renewal period.  At least with
the KDCs I'm familiar with, this remains true even if the user changes
their password, although I don't know if that's also true of Active
Directory.  It brings the ticket cache closer and closer to a password in
terms of the security implications of it being stolen.

Have you considered using some other mechanism to ensure that users
reauthenticate periodically?  For instance, if you're using bash, you
could configure it to run kinit (or, possibly better, k5start -H) every
once in a while by (ab)using the prompt setting.

> What would be a better Kerberos setup? pam_winbind instead of pam_krb5?
> Other tools that can refresh/replace the TGT instead of renewing it?
> These tools would have to store the user's password in memory, wouldn't
> they?

Yes.  You either need to allow tickets to be renewable for longer or you
have to get the user to enter their password occasionally.  There aren't
any other alternatives, really.

Note, however, that if you use the newest version of the GSSAPI patch for
ssh, any users who are logged on via ssh with a new client will have their
tickets automatically reforwarded to all the systems to which they're
logged on and hence refreshed on those systems.  If you have relatively
sophisticated users, this is a very nice feature.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>