Bug 965133 - GSSAPI working only on first login
Summary: GSSAPI working only on first login
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 19
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Jakub Hrozek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 965574
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-20 13:35 UTC by Stephen Gallagher
Modified: 2020-05-02 17:21 UTC (History)
6 users (show)

Fixed In Version: sssd-1.10.1-1.fc19
Clone Of:
Environment:
Last Closed: 2013-07-09 15:31:00 UTC
Type: Bug
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 2978 0 None None None 2020-05-02 17:21:55 UTC

Description Stephen Gallagher 2013-05-20 13:35:03 UTC
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 14:46:53 UTC
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 07:34:13 UTC
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 11:38:43 UTC
(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 13:38:22 UTC
I filed a relevant Bugzilla that may be causing this fail too: Bug 965574.

Comment 6 Stephen Gallagher 2013-05-21 14:53:31 UTC
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 16:13:02 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1936

Comment 8 Fedora Update System 2013-06-28 09:13:27 UTC
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 15:23:31 UTC
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 15:31:00 UTC
Fixed in sssd-1.10.0-16 which is in stable updates already.

Comment 11 Fedora Update System 2013-07-18 19:46:42 UTC
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 17:51:20 UTC
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.