Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
I work on multiple systems in multiple domains, so whenever I start my workday, I knit to acquire all of the credentials I need:
* user1.ORG
* user2.ORG
* user3.ORG
* user1.ORG
* user2.ORG
* user3.ORG
* user1.ORG
* user2.ORG
* user1.ORG
I have the sssd krb5_renew_interval option set to 1h, which enables KCM ticket renewal. I will also periodically renew tickets myself. (E.g., if I am finishing up work for the day, if I am working on my laptop, before I close its lid to suspend it, I will renew all of my credentials, so that they don’t expire overnight when the laptop is suspended and KCM cannot renew them.)
The main domain I work in is user1.ORG, so whenever I kinit, I always run kswitch -p user1.ORG to switch the primary cache back to user1.ORG. E.g.:
$ klist
Ticket cache: KCM:116201957:35652
Default principal: user1.ORG
Valid starting Expires Service principal
2022-09-20 10:11:45 2022-09-21 10:11:37 krbtgt/DOMAIN1.EXAMPLE.ORG.ORG
renew until 2022-09-27 10:11:37
*But*: if KCM renews credentials, it will leave the primary cache set to an arbitrary credential—likely (I suspect) the last credential it renewed. So after a while, I can run klist again and see (e.g.):
$ klist
Ticket cache: KCM:116201957:56094
Default principal: user3.ORG
Valid starting Expires Service principal
2022-09-20 15:11:45 2022-09-21 15:11:37 krbtgt/DOMAIN2.EXAMPLE.ORG.ORG
renew until 2022-09-27 15:11:37
Having KCM silently switch the primary cache underneath me breaks workflows. For example, one of the reasons why I set user1.ORG as the primary cache is because I interact with internal web sites that perform GSSAPI authentication using that credential. And when KCM switches the default credential out from underneath me, it breaks my interaction with those web sites.
This is an error. It is a welcome feature that KCM can automatically renew credentials in the cache, *but* KCM must restore the correct primary cache after it performs its renewal operations. From the user’s perspective, KCM must not change the primary cache.
How reproducible:
Configure KCM to renew credentials, acquire credentials for multiple domains, and use kswitch to demonstrate that KCM changes the primary cache over time.
Version-Release number of selected component (if applicable):
I see this behavior on the latest RHEL9 sssd, sssd-2.6.2-4.el9_0.1.
Description of problem: I work on multiple systems in multiple domains, so whenever I start my workday, I knit to acquire all of the credentials I need: * user1.ORG * user2.ORG * user3.ORG * user1.ORG * user2.ORG * user3.ORG * user1.ORG * user2.ORG * user1.ORG I have the sssd krb5_renew_interval option set to 1h, which enables KCM ticket renewal. I will also periodically renew tickets myself. (E.g., if I am finishing up work for the day, if I am working on my laptop, before I close its lid to suspend it, I will renew all of my credentials, so that they don’t expire overnight when the laptop is suspended and KCM cannot renew them.) The main domain I work in is user1.ORG, so whenever I kinit, I always run kswitch -p user1.ORG to switch the primary cache back to user1.ORG. E.g.: $ klist Ticket cache: KCM:116201957:35652 Default principal: user1.ORG Valid starting Expires Service principal 2022-09-20 10:11:45 2022-09-21 10:11:37 krbtgt/DOMAIN1.EXAMPLE.ORG.ORG renew until 2022-09-27 10:11:37 *But*: if KCM renews credentials, it will leave the primary cache set to an arbitrary credential—likely (I suspect) the last credential it renewed. So after a while, I can run klist again and see (e.g.): $ klist Ticket cache: KCM:116201957:56094 Default principal: user3.ORG Valid starting Expires Service principal 2022-09-20 15:11:45 2022-09-21 15:11:37 krbtgt/DOMAIN2.EXAMPLE.ORG.ORG renew until 2022-09-27 15:11:37 Having KCM silently switch the primary cache underneath me breaks workflows. For example, one of the reasons why I set user1.ORG as the primary cache is because I interact with internal web sites that perform GSSAPI authentication using that credential. And when KCM switches the default credential out from underneath me, it breaks my interaction with those web sites. This is an error. It is a welcome feature that KCM can automatically renew credentials in the cache, *but* KCM must restore the correct primary cache after it performs its renewal operations. From the user’s perspective, KCM must not change the primary cache. How reproducible: Configure KCM to renew credentials, acquire credentials for multiple domains, and use kswitch to demonstrate that KCM changes the primary cache over time. Version-Release number of selected component (if applicable): I see this behavior on the latest RHEL9 sssd, sssd-2.6.2-4.el9_0.1.