13

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?

1
  • Wrong question. For long-running jobs automate login with keytab, otherwise the default 7d renewal period is anyway too long.
    – rhoerbe
    Apr 15, 2020 at 6:32

2 Answers 2

15

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.

3
  • are you sure it works that way when it comes to the krb_renewable_lifetime? I don't think it goes beyond what is set on the KDC, and I don't think SSSD will store the credentials for renewal beyond what is set on the KDC. If 7 days is set for the maximum lifetime, so SSSD won't renew it beyond that, just within that lifetime. Mar 20, 2023 at 10:06
  • @francisaugusto The truth lies in between. The KDC enforces a configured maximum cap on the renewable lifetime, but the client also asks for a particular lifetime when requesting a renewable ticket. The default lifetime is usually set in krb5.conf on the client, but krb5_renewable_lifetime can override it for SSSD. So you often get situations where the client asks for a ticket renewable for 7 days, but the KDC would have happily issued a ticket renewable for 30 days, had the client asked for that. Once a ticket is issued, there's no way to extend the allowed renewal lifetime.
    – TooTea
    Jan 11 at 8:26
  • According to this issue, they implemented that. github.com/SSSD/sssd/issues/2765 Might want to review your answer to have the up-to-date information.
    – Braiam
    Mar 23 at 16:26
0

A quick googling gives me this thread

If you insist on a permanent thing, you can run a cron job that periodically obtain a new ticket (using kinit) instead.

2
  • 1
    I know that I can just extend the maxlifetime of the ticket. However that seems like a hack that will at some point break (namely when users are logged in longer than the lifetime) and I do not want to really give out unlimited tickets as that seems like a big security risk.
    – Blackclaws
    Dec 11, 2015 at 10:44
  • 1
    When you decided to extend ticket lifetime indefinitely, it's a security risk already. Expiration is designed in the system, I am all ears for any other alternatives.
    – strongline
    Dec 11, 2015 at 16:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .