Thanks Russ, some more comments/questions below
On Wed, Sep 1, 2010 at 2:12 PM, Russ Allbery <[email protected]> wrote: > Di Pe <[email protected]> writes: > > 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. > This seems to be a good idea. I used export PROMPT_COMMAND="k5start -H 500" and it does what it's supposed to do. One issue tough: k5start seems to look at ticket_lifetime instead of renew_liefetime. ticket_lifetime is enforced to 10 hours by active directory. If I don't use a cron job to renew the ticket users would have to enter their credentials every few hours or so which is not good if they run jobs over night. If I use a cron job to renew the ticket I would not be prompted for 7days but if renew_lifetime ran out on a saturday I would only have another few hours to refresh the ticket. Another problem we notice on our terminal server is that user sessions are completely locking up when a ticket expires on a nfs mounted home directory. It would be good if we had a cron job that forces a logout for users where the ticket is about to expire in 60 minutes or less. Is there a way to check for a happy ticket in a shell script without getting a prompt if the ticket is not happy? dipe >> 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. We have started using this feature and it will be a great replacement for ssh keys because sys admins cannot enforce a password policy with SSH keys. > > -- > Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
