Description of problem: TGT renewal is configured in /etc/sssd/sssd.conf (some settings redacted), but not working consistently: [kcm] tgt_renewal = true tgt_renewal_inherit = default and: [domain/default] id_provider = ldap ldap_id_use_start_tls = False auth_provider = krb5 chpass_provider = krb5 cache_credentials = true krb5_store_password_if_offline = true krb5_renewable_lifetime = 7d krb5_renew_interval = 5m krb5_use_fast = demand Version-Release number of selected component (if applicable): sssd-2.10.2-1.fc41.x86_64 (but also 2.10.1 and probably other versions) How reproducible: Sometimes. At times, sssd will renew the TGT. Steps to Reproduce: 1. Get krb5 TGT by logging in through pam_sss. 2. Suspend laptop, resume, rinse, repeat. Use U2F authentication to unlock Gnome lock screen (i.e. not password to refresh TGT). 3. Wait for the point where TGT does not get renewed, despite meeting conditions. Actual results (sanitised): $ klist Ticket cache: KCM:6000 Default principal: user Valid starting Expires Service principal 03/02/25 13:35:47 04/02/25 11:00:43 host/server.domain.com renew until 09/02/25 16:55:56 03/02/25 11:01:04 04/02/25 11:00:43 imap/mail.domain.com renew until 09/02/25 16:55:56 03/02/25 11:00:43 04/02/25 11:00:43 krbtgt/DOMAIN.COM renew until 09/02/25 16:55:56 03/02/25 11:27:00 04/02/25 11:00:43 nfs/server.domain.com renew until 09/02/25 16:55:56 03/02/25 15:54:15 04/02/25 11:00:43 smtp/mail.domain.com renew until 09/02/25 16:55:56 In the example above, a TGT issued for a day, which expires at 11:00 on this day, should be renewed, because as of this writing, it is 07:12, which means over half of the life of TGT already expired. And yet, it will not be, despite the laptop being on for over 5 minutes, which is the renewal lifetime. Whether the settings are explicitly configured or inherited does not seem to make a difference. Expected results: TGT should be renewed, as configured. Additional info:
This might be confusing but there are two distinct features SSSD supports: (1) renew of TGTs acquired by krb5 provider of SSSD itself (configured via `krb5_renew_interval` in the domain section) - ccache type doesn't matter; and (2) renew of TGTs stored in KCM: by sssd_kcm (see `man sssd-kcm::RENEWALS` for configuration options) - doesn't matter what software was using to acquire a TGT. Looks like you are mixing those two in your configuration. I'd suggest to select one, configure accordingly and if it still doesn't work as expected then please provide corresponding logs with debug_level = 9 (domain log for (1) and sssd_kcm.log for (2))
Well, yes and no. The option to renew TGT in the domain section never worked properly here. So, I recently configured the KCM option by inheriting domain settings, which works sometimes. Anyhow, if these are not to be mixed, why would inheritance exist? Back end is krb5/openldap, so nothing exotic. I'll get you some logs after I try just KCM thing by itself.
As you suggested, I moved the renewal config to [kcm] section and removed it from default domain. Like this: [kcm] tgt_renewal = true krb5_renewable_lifetime = 7d krb5_renew_interval = 5m As I suspected, it made no difference whatsoever. Right now, I have TGT that expires at 14:03 today (it's 5 Feb here). The TGT is renewable till the same time on 11 Feb and was issued at the same time yesterday (i.e. 4 Feb), for 1 day. Meaning, over half of its life is gone and it should get renewed. But, that's not happening. I'll try to collect some logs.
Eventually that TGT renewal happened. Now I have to use the machine for a few days again with suspend/resume to see whether it will actually be reliable this time.
It renewed my TGT for the second time, after I got one with kinit, so that part appears to work. It has only been a few days, so the result may not be definitive, but I'll reopen this if the problem happens again. It is still a mystery to me why inheritance would be a thing and explicitly documented, if these two setting are not compatible with each other.