Auto-renewing kerberos tickets with SSSD/AD

I've been trying to get users' ccache files to auto-renew with a couple methods neither of which are exactly working for me. This is a debian 11 box, MIT kerberos. My preferred option is to auto-renew the tickets WITHOUT cron jobs using SSSD config options. 2nd choice would be with cron jobs set up by individual users. The goal is to always have valid tickets for use by the users when logged on and also for the cronjobs they may establish which need connectivity to network resources (MSSQL hosts typically)

1.Using the configuration parameters found at the bottom of this answer I edited my /etc/krb5.conf file by adding the below to the [libdefaults] section and rebooting the machine:

ldap_krb5_init_creds = True
krb5_ccname_template = FILE:/tmp/krb5cc_%U
krb5_lifetime           =  86400
krb5_renewable_lifetime = 604800
krb5_renew_interval     =   7200

Expected behavior is that my ccache file upon reboot would show as krb5cc_username but the change had no discernible effect - I continue to see a file with random alpha-numerics (like "krb5cc_123456789_7mabEj") within /tmp. This file is shown when i run klist but I believe it is created when I log onto the machine initially. As far as I know this machine meets the preconditions of using SSSD against Active Directory for this solution to work.

2. I also tried to set up a cronjob to run kinit -fkt using my keytab. I tested this from the terminal and it does work, but from cron it is only sort of working - I am seeing a file recreated every minute (as scheduled for testing) within /tmp. However this file has an unexpected name (random numeric characters appended - like "krb5cc_1922807467"), it is being created alongside/in addition to the initial ccache file I obtain when logging onto the box, and this file is not showing when I run klist. For the cron solution to work I need to use/renew the expected ticket cache filename shown by klist.

If someone could point me to what I may be doing wrong for solution 1 (best) or else solution 2 I would appreciate the help - thx in advance.

I edited my /etc/krb5.conf file by adding the below to the [libdefaults] section and rebooting the machine

None of those parameters are for krb5.conf – they are parameters for SSSD. Put them in sssd.conf in the section corresponding to your SSSD "domain".

For the cron solution to work I need to use/renew the expected ticket cache filename shown by klist.

Both klist and kinit use the cache path that they receive via the KRB5CCNAME environment variable. This is not automatically the same for everything that the user runs (indeed the whole point of it being an environment variable is that it could be distinct from the krb5.conf "default" format – the random suffix is added by SSSD deliberately when pam_sss sets the variable for each new login). When it is set by a PAM module for interactive logins, it will not necessarily be set for cronjobs as they might have a different PAM module stack configured.

So if you want to rely on SSSD (remember that it can only keep renewing the ticket for so long), you should make SSSD use a deterministic cache name (using krb5_ccname_template) and then have your cronjobs set KRB5CCNAME accordingly.

On the other hand, if you are using a keytab, then you should start with setting KRB5CCNAME for both the 'kinit' cronjob and the actual Kerberos-using tasks to point at some custom location (or unsetting it to use the system default "krb5cc_<uid>").

For example, all our cronjob shellscripts do export KRB5CCNAME=/tmp/krb5cc_${UID}_cron.

Keep in mind that when you use any method that gets tickets using a keytab, SSSD's cache becomes completely irrelevant; there is almost no point in trying to re-use the same path as SSSD, as kinit -k will be getting fresh tickets anyway.

However this file has an unexpected name (random numeric characters appended - like "krb5cc_1922807467"),

Those are not "random numeric characters", that's the user's UID (i.e. the %U part); the stock default cache format is simply FILE:/tmp/krb5cc_<uid>. The long UID is typical for SSSD's method of mapping Windows SIDs/RIDs to Unix UIDs.

Only the third component added by pam_sss, such as the _7mabEj in your example, is really randomized.