Score:1

List kerberos tickets, expiration details with SSSD/realm

za flag

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.

Score:2
fr flag

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.)

mb158127 avatar
za flag
Thanks - took your advice and installed `krb5-user` package which got me klist - went seemlessly. Set up a simple cronjob for renewing existing tickets and another to re-acquire less frequently - we have dynamic R sessions which stay alive for long periods and we don't want new tickets every hour. Will look into some of these other methods later since this requires all users create the req cronjobs
user1686 avatar
fr flag
Renewing a ticket is practically the same as acquiring a new ticket in that sense – you still get a brand new one (emptying the cache), only by using the old ticket in place of a password. (Though admittedly I'm not sure whether the DC issues an updated PAC during renewals in case of group membership changes or just copies the old one.) Most jobs shouldn't notice a difference even if a new ticket is acquired, though.
mb158127 avatar
za flag
In my case we have users who keep R sessions alive for days. The R session runs on an environment with an env var `KRB5CCNAME` set to the FILE:/tmp/ccache. Acquiring a new ticket would invalidate the one they are pointing to and require they either terminate and start a new session or call a method to alter their host environment in the existing. I will be exploring non-FILE: based methods which eliminate this issue
user1686 avatar
fr flag
That doesn't make much sense to me. Old tickets are never invalidated (similar to how they cannot be revoked); there is nothing stopping you from putting a new ticket in the _same_ KRB5CCNAME (that's what kinit already does by default); and I don't think I've heard of "sessions" being terminated due to ticket expiry (whichever kind of session you were referring to).
mb158127 avatar
za flag
"...heard of sessions being terminated..." you certainly didn't hear that from me. I said a new ticket/file would require they either terminate the existing session to start a new one to have the valid ticket defined (since the existing will continue to link to old file) OR know and run the command to re-set the environment variable within their current session (requires they have knowledge of how to do something, can't rely on this even if I show them). They could certainly keep the existing session no longer pointing to a valid ticket and not be able to connect to network resources too...
mb158127 avatar
za flag
also, `kinit` does not re-use the existing file/filename. The new ccache file has a diff random string of letters in it. This is the problem, dude
user1686 avatar
fr flag
"kinit does not re-use the existing file/filename" it does in all versions of `kinit` I've ever used. If you have KRB5CCNAME set, it always stores the tickets there, whether it's MIT kinit, Heimdal kinit, or even Java kinit; if you don't have it set, it always stores tickets in the default_ccache. (And even in case it did not, it still has the `-c` option to point it at the desired file.)
mb158127 avatar
za flag
You're right - not sure why I thought it was replacing... that does make it a little simpler I guess in that it is only 1 crontab entry needed to kinit every few hours. Thanks
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.