Kerberos Tickets – List and Check Expiration Details with SSSD/Realm

kerberossssd

tl;dr – how do I check details of users' kerberos tickets to confirm they are being renewed as I've sought to configure, using realm or sssd (no klist installed)?

Hi – I'm on a Debian 11 system which is AD/domain joined with some mix of SSSD and realm. Notably I do not have whatever package provides the 'kinit', 'klist', etc commands I'm familiar with from a previous platform.

Every time a domain user logs in they obtain a new kerberos ticket I believe judging by a new file is created in /tmp, something like "/tmp/krb5cc_1922807467_vhNkj5". This allows them to access network resources with windows credentials. I have noticed the tickets seem to expire after 12-24 hours so I am looking for a way to either request longer-valid tickets up to the maximum my domain will provide, and/or to automatically renew existing tickets and obtain new ones. This is so that I can allow users to schedule tasks using cron and guarantee a valid ticket will be available.

I have edited some settings within /etc/sssd/sssd.conf attempting to increase renewable lifetime and set renewal interval on tickets and restarted the sssd service. Now I am stuck trying to confirm these settings have taken – I cannot find a way to list details for active tickets. I can see that my ticket file is being created each time I log in, but can not tell if it is renewing on the short interval I set for testing purposes.

Is there a way to show a user's ticket status/details using sssd, realm, or something else I may have already installed/enabled? If not, is there another package I can install (such as something providing klist) which will not break my existing realm/sssd configuration and does not require AD admin credentials? Ultimately I just want a way to confirm if my attempts are working or not.

Best Answer

tl;dr - how do I check details of users' kerberos tickets to confirm they are being renewed as I've sought to configure, using realm or sssd (no klist installed)?

Install klist. For MIT Kerberos the package is krb5-user and it is harmless; its dependencies (the krb5 libraries) are already installed due to being required by SSSD anyway.

In the somewhat unlikely case that your system might be using Heimdal Kerberos (which is not the default but is supported by Debian), the equivalent package would be heimdal-clients.

Finally, you could scp the ticket cache to another system and run klist -c <path> there (the file-based cache formats are compatible even between MIT Krb5 and Heimdal systems).

Is there a way to show a user's ticket status/details using sssd, realm, or something else I may have already installed/enabled?

No, they're meant to work together with the standard tools from a Kerberos distribution, i.e. you're mostly expected to have the regular klist installed.

I have noticed the tickets seem to expire after 12-24 hours so I am looking for a way to either request longer-valid tickets up to the maximum my domain will provide, and/or to automatically renew existing tickets and obtain new ones.

24 hours is generally the maximum I would expect a domain to provide. (Longer lifetimes increase the impact of stolen tickets, should that ever happen, as it's impossible to revoke a ticket that's still valid – which is why they have a separate "renewable" lifetime, requiring to contact the KDC again to extend the validity.)

However, the maximum renewable lifetime is generally 7 or 14 days, after which it becomes necessary to supply credentials (password, smartcard) again. Making cronjobs work unattended for longer would require the system to store the initial credentials (like how Windows services or scheduled tasks require you to supply the account's password in clear text).

This is so that I can allow users to schedule tasks using cron and guarantee a valid ticket will be available.

There are several existing methods besides SSSD to do that. (I'm actually not sure whether the version of SSSD found in Debian can renew user tickets on its own; I think that was added later, and even then only for the SSSD-managed KCM: cache type, not for file-based caches.)

There is most likely no point in relying on the tickets acquired during interactive login (as sooner or later someone will forget to log in before they expire). Instead, have the user explicitly store their actual password – for Linux, it would be in the form of a keytab storing the derived key (not the cleartext password). After all, if you trust the system to permanently store a Kerberos TGT for a user, then the same system can be trusted to secure the password for that user as well.

Once you have a keytab (which can be created using the addent -f subcommand of ktutil), there are multiple ways to have a cronjob use that keytab:

  1. The gssproxy daemon, which is a little like ssh-agent but for Kerberos. It comes with an example for NFS which uses keytabs stored at /var/lib/gssproxy/clients/<uid>.keytab to automatically acquire tickets on behalf of programs configured to use it (for programs using regular libkrb5, that means GSS_USE_PROXY=1 in environment).

    One advantage of gssproxy is that it can be given keytabs that are not accessible to the users themselves, similar to how ssh-agent does not allow extraction of the decrypted keys.

  2. The built-in "client credentials" feature in recent libkrb5 which allows you to place a keytab at /var/lib/krb5/user/<uid>/client.keytab (or at some custom location defined by KRB5_CLIENT_KTNAME=) and libkrb5 will use it to acquire tickets as needed.

    Unlike with gssproxy, this does require the keytab to be readable by the job.

  3. The k5start tool from the kstart package, a program that acquires tickets using a keytab and keeps them renewed for the duration of the process that it's running.

  4. A basic kinit -k -t <keytab> cronjob to re-acquire tickets every few hours.

(If you do want to rely on the existing cache, the same kstart Debian package also has a krenew tool which is similar to k5start except only meant to keep existing tickets renewed.)

Related Topic