Red Hat Bugzilla – Bug 965133
GSSAPI working only on first login
Last modified: 2013-07-30 13:51:20 EDT
Created attachment 750583 [details] Complete set of RPM versions on my system Description of problem: After logging out of a user and then logging back in, no service that relies on GSSAPI will authenticate correctly, despite having a valid TGT (visible to kinit) and being able to manually run 'kvno' to acquire service tickets. Version-Release number of selected component (if applicable): sssd-1.10.0-5.fc19.beta1.x86_64 krb5-libs-1.11.2-5.fc19.x86_64 cyrus-sasl-gssapi-2.1.26-6.fc19.x86_64 systemd-204-2.fc19.x86_64 openldap-clients-2.4.35-4.fc19.x86_64 How reproducible: Every time Steps to Reproduce: 1. Configure SSSD to use a Kerberos login (such as FreeIPA) with the /run/user/$UID/krb5cc DIR: cache (not FILE: cache) 2. Log into a desktop session using SSSD backed by a Kerberos login 3. Verify that you have a valid TGT with kinit 4. Perform a GSSAPI action (e.g. ssh with GSSAPI or use ldapsearch -Y GSSAPI) 5. Log out of the desktop session and back in, using the same Kerberos login as before 6. Repeat steps 3 and 4. Actual results: During the initial login, everything works as expected, but on subsequent logins, all attempts to use GSSAPI receive the error "No Kerberos credentials available". 'kinit' and 'kvno' continue to behave properly, but all attempts to USE the credentials will fail with this error. Rebooting the computer completely restores it to a usable state for the first login. Expected results: Logging out and logging back in should not prevent users from properly utilizing their credentials. Additional info: I filed this against SSSD to start with, though I suspect that the underlying issue is in either Kerberos or systemd.
I could reproduce as well, albeit so far with the SSSD only. I will set up an environment to reproduce the bug with pam_krb5 as well.
Can you try to run the ssh or ldap client with KRB5_TRACE=/dev/stdout and add the output here?
(In reply to Sumit Bose from comment #2) > Can you try to run the ssh or ldap client with KRB5_TRACE=/dev/stdout and > add the output here? Submitted as a private comment due to sensitive contents.
I filed a relevant Bugzilla that may be causing this fail too: Bug 965574.
We did some additional debugging of this today on IRC. We discovered that the cause of the symptoms is that SSSD is setting a different value for the KRB5CCNAME environment variable when it's run on first login as compared to subsequent logins. In the initial login, SSSD assigns: KRB5CCNAME=DIR:/run/user/$UID/krb5cc On subsequent logins[1], SSSD assigns: KRB5CCNAME=DIR::/run/user/$UID/krb5cc/tktXXXXXX There is definitely a bug in libkrb5/gssapi somewhere, though. kinit, kvno and klist are tolerant of the KRB5CCNAME=DIR::/run/user/$UID/krb5cc/tktXXXXXX environment variable format, displaying the correct information. GSSAPI logins apparently cannot parse it correctly. [1] The original bug description indicated that logout was needed. It is not, you can simply log in with a new session in a new virtual terminal or using 'su - username' in a konsole. The new session will exhibit the incorrect behavior.
Upstream ticket: https://fedorahosted.org/sssd/ticket/1936
sssd-1.10.0-13.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/sssd-1.10.0-13.fc19
Package sssd-1.10.0-13.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing sssd-1.10.0-13.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11899/sssd-1.10.0-13.fc19 then log in and leave karma (feedback).
Fixed in sssd-1.10.0-16 which is in stable updates already.
sssd-1.10.1-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/sssd-1.10.1-1.fc19
sssd-1.10.1-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.