Learn more about these different git repos.
Other Git URLs
Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 965133
Created attachment 750583 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.
This problem is cause by 2 bugs. One in SSSD where we store the wrong ccache name for DIR caches, ie we store DIR::/path/to/collection/dir/current_file instead of FIR:/path/to/collection/dir The other bug is in GSSAPI as it fails to use the DIR:: format. The GSSAPI bug is tracked here: http://krbdev.mit.edu/rt/Ticket/Display.html?id=7172
blockedby: => blocking: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => review: True => 0 selected: => testsupdated: => 0
When fixing the bug, please note that it's not enough to just store DIR:/path/to/collection in ccache as for some reason the SSSD expects the ccache to be stored in the sysdb. The SSSD needs to be amended to be able to read the collection itself.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.10.0
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=966556
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=965133 965133] => [https://bugzilla.redhat.com/show_bug.cgi?id=965133 965133], [https://bugzilla.redhat.com/show_bug.cgi?id=966556 966556]
owner: somebody => lslebodn status: new => assigned
gdb log gdb_log.txt
You can see in file gdb_log.txt, that function cc_dir_cache_for_princ was called with argument location = 0x7f5e77331400 "DIR:/run/user/325600000/krb5cc", but kerberos function krb5_cc_get_full_name (http://web.mit.edu/Kerberos/krb5-devel/doc/appdev/refs/api/krb5_cc_get_full_name.html) returns wrong name.[[BR]] name= DIR::/run/user/325600000/krb5cc/tktt1yNP8
It should be:
Function krb5_cc_get_full_name internally call static function dcc_get_name (and not krb5_fcc_get_name), therefore the first option should be returned.
So I think that, it is not sssd bug but krb5-libs bug.
Replying to [comment:6 lslebodn]:
This is by design.
It should be: either DIR::/run/user/325600000/krb5cc/ or FILE::/run/user/325600000/krb5cc/tktt1yNP8
Nope.
Function krb5_cc_get_full_name internally call static function dcc_get_name (and not krb5_fcc_get_name), therefore the first option should be returned. So I think that, it is not sssd bug but krb5-libs bug.
Nope. DIR:: is returned by design to tell you which one of the caches in the collection is being used but also to let you know that this is a cache collection and not just a file ccache.
SSSD needs to be patched to understand how to handle this case.
In cc_dir_cache_for_princ() we should call krb5_cc_get_full_name() only as a way to validate that we have the right cache, but not return name.
If the operation is successful we should instead look at location, if it is not NULL just copy and return that, otherwise we should probably return an error as we can't possibly get the right ccache anyway if I am reading the code right.
Replying to [comment:8 simo]:
In cc_dir_cache_for_princ() we should call krb5_cc_get_full_name() only as a way to validate that we have the right cache, but not return name. If the operation is successful we should instead look at location, if it is not NULL just copy and return that, otherwise we should probably return an error as we can't possibly get the right ccache anyway if I am reading the code right.
With this approach: User will login in first time, he will automatically get krb5 ticket(by sssd). User will decide to kinit(switch) as another user(admin). After logging out of a user and then logging back in. User will have TGT for admin.
Do we really want to store only DIR:/run/user/$uid/krb5cc/ to cache?
BTW: GSSAPI works well on the second login with latest krb5-1.11.2-6.fc19
Replying to [comment:9 lslebodn]:
With this approach: User will login in first time, he will automatically get krb5 ticket(by sssd). User will decide to kinit(switch) as another user(admin). After logging out of a user and then logging back in. User will have TGT for admin. Do we really want to store only DIR:/run/user/$uid/krb5cc/ to cache?
Yes, this is exactly what we want as a ccache.
If you are concerned about the primary cache you can use krb5_cc_ functions to select a specific cache after you searched the collection.
Yup.
patch: 0 => 1
changelog: => resolution: => fixed status: assigned => closed
[http://stoppnd.tumblr.com/ http://stoppnd.tumblr.com/] main.inc.php
[http://stoppnd.tumblr.com/ http://stoppnd.tumblr.com/] main.inc.2.php
Metadata Update from @jhrozek: - Issue assigned to lslebodn - Issue set to the milestone: SSSD 1.10.0
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2978
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.