Automatic Kerberos Ticket Renewal (Indefinitely)

I am currently switching our environment from NIS over to Kerberos + LDAP.

During this migration I've now run into the following situation.

We mount our homes via NFS which obviously should also be kerberized. However since our users all login at terminal servers and usually don't log out but rather suspend their session or have long running jobs in the background this leads to the Kerberos ticket expiring sooner or later which then makes the NFS shares unavailable.

What is my best option to automatically renew these tickets for the users?

Also I want to be prepared for the case when users leave on a trip but still have their jobs running (that might take longer than the longest Kerberos renewal time) so I would need to acquire a completely new ticket for that user. What would be the best option in this case without massively extending the default maximum renewal time for tickets?

Solution 1:

It's the end of 2018 and I've run into the same question as you. After some digging, I can offer a write-up for posteriority.

tl; dr:

• "Infinite renewal" not possible and probably never will be
• SSSD will renew tickets if you log in using passwords
• SSSD will renew all tickets, at some point in the future

First off, you can't have "indefinitely". Kerberos tickets have a maximum renewable lifetime which is a KDC server setting, and nothing will let you renew one ticket past this time. The only thing you could do is store the users credentials and request a fresh new ticket on their behalf.

That being said, you shouldn't have to. Chances are that you are running the "System Security Services Daemon", or SSSD. If you do, you can use the builtin renewal options krb5_renew_interval and krb5_renewable_lifetime to renew users tickets automatically:

[domain/yourdomain.example.com]
krb5_renewable_lifetime = 90d
krb5_renew_interval = 500

You can look into man 5 sssd-krb5 for details. With these settings SSSD will ask for renewable tickets (maximum lifetime 90 days) whenever you log in* and every 500 seconds go through a list of tickets* and renew the existing tickets that are renewable.

After 90 days have passed since the original ticket, the renewal will fail and the ticket is lost. However, if you log in* in the mean time, you will get a fresh ticket from SSSD - even when you enter your password into your machines lock screen.

*) So far, so wonderful. Unfortunately, a few gotchas apply.

At the time when I am writing this, SSSD can only renew tickets that it itself requested. These are all the logins that go through the pam_sss PAM module, for example (but not limited to):

• Typing su $USER on your terminal
• Logging in to your system through a graphical shell
• Unlocking the screen through a graphical shell
• Logging in through SSH using the PasswordAuthentication method.

Now what is notably missing from this list is:

• Running kinit
• Logging in through SSH using the PubkeyAuthentication method.
• Logging in through SSH using the GSSAPIAuthentication method.
• Logging in through SSH, while the GSSAPIDelegateCredentials option is on.

Now that makes things quite awkward, and for the time being it essentially means that eitheryou force users to enter a password or that you write a ticket renewal daemon yourself. I have not found another way to make this work in the present, please anybody comment if you found a way.

This might become quite a bit easier, however.

SSSD now provides a "kerberos cache manager", a KCM that's called sssd-kcm. Basically, it's a small server that will store tickets there (KCM: when you run klist) instead of the Kernel keyring (KEYRING: when you run klist) or a file in /tmp (FILE: when you run klist).

At some point in the future, SSSD will hopefully be able to renew all tickets (not just the ones it requested itself) when sssd-kcm implements ticket renewal. This has not happened yet, and is tracked in issue 1723 on the SSSD bug tracker.

If you're running a Red Hat based system (RHEL, CentOS, Fedora), then SSHD also needs to learn to respect the selected cache creation mechanism. This is tracked in issue 1639376 on the Red Hat bugtracker.