Bug 965133 - GSSAPI working only on first login
GSSAPI working only on first login
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
19
All Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
:
Depends On: 965574
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-20 09:35 EDT by Stephen Gallagher
Modified: 2013-07-30 13:51 EDT (History)
6 users (show)

See Also:
Fixed In Version: sssd-1.10.1-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-09 11:31:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Complete set of RPM versions on my system (83.84 KB, text/plain)
2013-05-20 09:35 EDT, Stephen Gallagher
no flags Details

  None (edit)
Description Stephen Gallagher 2013-05-20 09:35:03 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.
Comment 1 Jakub Hrozek 2013-05-20 10:46:53 EDT
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.
Comment 2 Sumit Bose 2013-05-21 03:34:13 EDT
Can you try to run the ssh or ldap client with KRB5_TRACE=/dev/stdout and add the output here?
Comment 4 Stephen Gallagher 2013-05-21 07:38:43 EDT
(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.
Comment 5 Martin Kosek 2013-05-21 09:38:22 EDT
I filed a relevant Bugzilla that may be causing this fail too: Bug 965574.
Comment 6 Stephen Gallagher 2013-05-21 10:53:31 EDT
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.
Comment 7 Jakub Hrozek 2013-05-21 12:13:02 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1936
Comment 8 Fedora Update System 2013-06-28 05:13:27 EDT
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
Comment 9 Fedora Update System 2013-06-29 11:23:31 EDT
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).
Comment 10 Jakub Hrozek 2013-07-09 11:31:00 EDT
Fixed in sssd-1.10.0-16 which is in stable updates already.
Comment 11 Fedora Update System 2013-07-18 15:46:42 EDT
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
Comment 12 Fedora Update System 2013-07-30 13:51:20 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.