#1936 GSSAPI working only on first login
Closed: Fixed None Opened 6 years ago by jhrozek.

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

Fields changed

owner: somebody => lslebodn
status: new => assigned

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:

  • either DIR::/run/user/325600000/krb5cc/
  • or FILE::/run/user/325600000/krb5cc/tktt1yNP8

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]:

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

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.

BTW: GSSAPI works well on the second login with latest krb5-1.11.2-6.fc19

Yup.

Fields changed

patch: 0 => 1

changelog: =>
resolution: => fixed
status: assigned => closed

Metadata Update from @jhrozek:
- Issue assigned to lslebodn
- Issue set to the milestone: SSSD 1.10.0

2 years ago

Login to comment on this ticket.

Metadata