Bug 1010553 - sssd setting KRB5CCNAME=(null) on login
sssd setting KRB5CCNAME=(null) on login
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
19
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
:
: 1010690 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-21 07:37 EDT by Jeff Layton
Modified: 2014-06-18 03:43 EDT (History)
13 users (show)

See Also:
Fixed In Version: sssd-1.11.0-2.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-24 18:57:07 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)

  None (edit)
Description Jeff Layton 2013-09-21 07:37:33 EDT
I did a yum update on my laptop yesterday, and all of the sssd related packages got updated to 1.11.0-1.

Since then, when I initially log in, I get this set in my environment:

    KRB5CCNAME=(null)

Note that it's actually setting the value to the string "(null)", not unsetting it in the environment or anything.

At that point, I can log out and ssh into the machine, and the shell running under ssh will then *not* have KRB5CCNAME set. I can then log out of gnome-shell and back in and KRB5CCNAME will be set to the correct location.

So, my workaround for the time being is to boot the laptop, switch to a VC, log in, ssh into localhost and then log back out. Then I can log into gnome-shell properly.

Prior to updating to this version I was running 1.10.0-11.fc19.beta2 and it didn't seem to have this problem. Here are the sss package versions on this host:

$ rpm -qa \*sss\*
libsss_idmap-1.11.0-1.fc19.x86_64
sssd-krb5-1.11.0-1.fc19.x86_64
sssd-client-1.11.0-1.fc19.x86_64
sssd-ipa-1.11.0-1.fc19.x86_64
sssd-common-1.11.0-1.fc19.x86_64
sssd-1.11.0-1.fc19.x86_64
sssd-proxy-1.11.0-1.fc19.x86_64
python-sssdconfig-1.11.0-1.fc19.noarch
sssd-ad-1.11.0-1.fc19.x86_64
sssd-ldap-1.11.0-1.fc19.x86_64
sssd-krb5-common-1.11.0-1.fc19.x86_64
Comment 1 Jeff Layton 2013-09-21 08:21:57 EDT
I should also mention that on another machine running 1.10.0-11.fc19.beta2 in the same configuration, it seems to leave $KRB5CCNAME unset on login.
Comment 2 Jakub Hrozek 2013-09-22 15:18:13 EDT
I don't see this behaviour, but granted, I run git HEAD and there's been a bunch of commits that touch the krb5 provider..

Pavel/Lukas, can either of you try with 1.11.0 tomorrow?
Comment 3 Jakub Hrozek 2013-09-22 15:19:00 EDT
(In reply to Jeff Layton from comment #1)
> I should also mention that on another machine running 1.10.0-11.fc19.beta2
> in the same configuration, it seems to leave $KRB5CCNAME unset on login.

What exactly do you mean by "unset"? Can you paste the output of klist?
Comment 4 Jeff Layton 2013-09-22 19:35:32 EDT
(In reply to Jakub Hrozek from comment #3)
> (In reply to Jeff Layton from comment #1)
> > I should also mention that on another machine running 1.10.0-11.fc19.beta2
> > in the same configuration, it seems to leave $KRB5CCNAME unset on login.
> 
> What exactly do you mean by "unset"? Can you paste the output of klist?

My mistake. I had thought that the environment variable wasn't being set at all, but looking now, it's set to:

$ env | grep KRB5
KRB5CCNAME=DIR:/run/user/<myuid>/krb5cc

...fwiw:

$ klist
Ticket cache: DIR::/run/user/4447/krb5cc/tktfFvYF5
Default principal: jlayton@REDHAT.COM

Valid starting       Expires              Service principal
09/22/2013 19:30:26  09/23/2013 05:30:26  krbtgt/REDHAT.COM@REDHAT.COM
	renew until 09/22/2013 19:30:26
09/22/2013 19:30:29  09/23/2013 05:30:26  imap/mail.corp.redhat.com@REDHAT.COM
	renew until 09/22/2013 19:30:26


...which is of course correct. In any case, it seems like something changed between 1.11.0-0.2.beta2 and 1.11.0-1 that made that env var get set improperly on an initial login in some cases.
Comment 5 Jakub Hrozek 2013-09-23 03:32:54 EDT
Right, thanks for checking. If the machine that's exhibiting the NULL behaviour is something you can install test packages on, can you try the packages from:
http://jdennis.fedorapeople.org/ipa-devel/ipa-devel-fedora.repo

btw when you log in and see the NULL cache, do you log in while connected to the RH VPN (so that SSSD can kinit) or offline (like, resume laptop from sleep and login through GDM before you can connect to VPN)
Comment 6 Jakub Hrozek 2013-09-23 03:34:07 EDT
(In reply to Jakub Hrozek from comment #5)
> Right, thanks for checking. If the machine that's exhibiting the NULL
> behaviour is something you can install test packages on, can you try the
> packages from:
> http://jdennis.fedorapeople.org/ipa-devel/ipa-devel-fedora.repo

Please note that the packages here are nightly snapshots, so really just something you should install on a test machine (or somewhere you can roll back to a more stable version).
Comment 7 Lukas Slebodnik 2013-09-23 04:28:06 EDT
I don't use gnome on my laptop, therefore I tried to reproduce this bug only on virtual machine. After each login, environment variable had value:
$ env | grep KRB5
KRB5CCNAME=DIR:/run/user/<myuid>/krb5cc

I could not reproduce it.

Could you put "debug_level = 0x7770" into domain and pam section (/etc/sssd/sssd.conf)? I hope that log files will contain useful informations. 

Version of tested software:
bash# rpm -qa \*sss\*
sssd-tools-1.11.0-1.fc19.x86_64
sssd-proxy-1.11.0-1.fc19.x86_64
sssd-client-1.11.0-1.fc19.x86_64
libsss_idmap-1.11.0-1.fc19.x86_64
sssd-ipa-1.11.0-1.fc19.x86_64
sssd-ldap-1.11.0-1.fc19.x86_64
sssd-krb5-1.11.0-1.fc19.x86_64
sssd-common-1.11.0-1.fc19.x86_64
libsss_nss_idmap-1.11.0-1.fc19.x86_64
sssd-krb5-common-1.11.0-1.fc19.x86_64
python-sssdconfig-1.11.0-1.fc19.noarch
sssd-1.11.0-1.fc19.x86_64
sssd-ad-1.11.0-1.fc19.x86_64

bash# rpm -q gdm
gdm-3.8.4-2.fc19.x86_64
Comment 8 Jakub Hrozek 2013-09-23 07:02:30 EDT
I think I managed to reproduce the bug, it only ever happens if you log in offline and it's been fixed in the 1.11 branch already which explains why I didn't see the bug with HEAD..

Jeff, here is a scratch build with 1.11.0 + the fixes that made SSSD happily work offline again for me:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5970549

Would you mind trying it out?
Comment 9 Jeff Bastian 2013-09-23 08:23:12 EDT
I'm hitting this bug too since I have to connect to the VPN before the kerberos server is reachable so it's effectively offline.

~]$ klist
Ticket cache: FILE:(null)
...

~]$ env | grep KRB
KRB5CCNAME=(null)


I'l try the koji build in comment 8.
Comment 10 Jeff Bastian 2013-09-23 08:41:01 EDT
That fixed it for me!  Thanks!

~]$ rpm -q sssd
sssd-1.11.0-2.fc19.x86_64

~]$ klist
Ticket cache: DIR::/run/user/12345/krb5cc/tkt.....
...

~]$ env | grep KRB
KRB5CCNAME=DIR:/run/user/12345/krb5cc


After I connect to the VPN, my Kerberos credentials are updated automatically again.
Comment 11 Fedora Update System 2013-09-23 09:21:03 EDT
sssd-1.11.0-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/sssd-1.11.0-2.fc19
Comment 12 Jeff Layton 2013-09-23 13:53:14 EDT
(In reply to Jakub Hrozek from comment #8)
> I think I managed to reproduce the bug, it only ever happens if you log in
> offline and it's been fixed in the 1.11 branch already which explains why I
> didn't see the bug with HEAD..
> 
> Jeff, here is a scratch build with 1.11.0 + the fixes that made SSSD happily
> work offline again for me:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5970549
> 
> Would you mind trying it out?

Yes! That fixes it for me too. Many thanks!
Comment 13 Simo Sorce 2013-09-23 14:51:58 EDT
*** Bug 1010690 has been marked as a duplicate of this bug. ***
Comment 14 Fedora Update System 2013-09-23 20:21:20 EDT
Package sssd-1.11.0-2.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.11.0-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-17409/sssd-1.11.0-2.fc19
then log in and leave karma (feedback).
Comment 15 Jakub Hrozek 2013-09-24 04:21:53 EDT
Jeff & Jeff,

would you mind adding Karma to the update so that it makes its way to updates proper faster?
Comment 16 Fedora Update System 2013-09-24 18:57:07 EDT
sssd-1.11.0-2.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.