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.
Do you still see this problem? I am asking because on many of the other reports about the same bug, people have been saying that they saw this issue go away over time.
If you are still seeing this, then I need some more information because while it seems to constantly affect some users, it just doesn't reproduce for others.
If you start from a clean state (ie., no Kerberos tickets or accounts anywhere) then what are the exact steps to trigger this?
To attain a clean state:
* Hard disable /usr/libexec/goa-daemon and /usr/libexec/goa-identity-service by removing the executable bit and killing them, so that they don't start up again.
* Remove all stanzas with "IsTemporary=true" or "Provider=kerberos". Or even better, just remove that file.
* Reboot the machine just to reset all the SSSD daemons, which offer the Kerberos KCM caches.
* Restore the executable bit on /usr/libexec/goa-daemon and /usr/libexec/goa-identity-service.
At this point, what are the exact steps that cause this bug to appear? For example, are you creating your Kerberos tickets using kinit? Or are you creating your tickets using the Online Accounts GUI in Settings? If you are using the GUI, then do you select the checkbox to save your password? Do you add more than one Kerberos account? Or just one?
I suspect that kinit was used, not the GUI. If so, when does this behaviour show up? Does one have to wait for the ticket to expire?
Also, does your Kerberos Key Distribution Centre (or KDC) allow tickets to be renewed or not?
The customer that the listing was opened for mentioned that the issue is still occurring, albeit infrequently. As such, they are unable to determine steps for reproducing until their production outage in May.
However, they have confirmed that they're using MS AD which does renew the tickets.
(In reply to Brandon Clark from comment #4)
> The customer that the listing was opened for mentioned that the issue is
> still occurring, albeit infrequently. As such, they are unable to determine
> steps for reproducing until their production outage in May.
>
> However, they have confirmed that they're using MS AD which does renew the
> tickets.
Ok, that's good to know.
> * Remove all stanzas with "IsTemporary=true" or "Provider=kerberos". Or
> even better, just remove that file.
By "that file", I mean ~/.config/goa-1.0/accounts.conf
Setting NEEDINFO while we wait for further details.