Cannot log in as an sssd provided user. I've never logged in as this user before, or run anything as this user. sssd_BORG.log: (Thu May 9 10:49:25 2013) [sssd[be[BORG]]] [krb5_auth_done] (0x0020): No ccache for Administrator.LAN in DIR:/run/user/1067400500/krb5cc? Nothing interesting in krb5_child.log: (Thu May 9 10:49:25 2013) [[sssd[krb5_child[28042]]]] [map_krb5_error] (0x0020): 1161: [0][Success] How to reproduce: [stef@stef ~]$ realm join domain.com [stef@stef ~]$ sudo sss_debuglevel 0x00F0 [stef@stef ~]$ pamtester system-auth 'BORG\Administrator' authenticate Password: pamtester: Authentication failure
I'm pretty sure this is related to bug 961235. Never the less sssd should be robust and create the directory when necessary. We don't want people getting locked out of their accounts, if the directory goes away for some reason ... since /run isn't long lived.
Hmm, even when I create the directory it still doesn't work: [stef@stef ~]$ uid=$(getent passwd 'BORG\Administrator' | cut -d ':' -f 3) [stef@stef ~]$ sudo mkdir -p /run/user/$uid/krb5cc [stef@stef ~]$ sudo chown $uid /run/user/$uid/krb5cc [stef@stef ~]$ pamtester system-auth 'BORG\Administrator' authenticate Password: pamtester: Authentication failure [stef@stef ~]$ pamtester system-auth 'BORG\Administrator' authenticate Password: pamtester: Authentication failure [stef@stef ~]$ sudo ls -l /run/user/1067400500/krb5cc total 36 -rw-------. 1 administrator domain users 10 9. Mai 11:03 primary -rw-------. 1 administrator domain users 1482 9. Mai 11:02 tkt08pt73 -rw-------. 1 administrator domain users 1482 9. Mai 10:49 tkt42DOuU -rw-------. 1 administrator domain users 1482 9. Mai 10:43 tkteeVNRr -rw-------. 1 administrator domain users 1482 9. Mai 10:45 tktfVHdN6 -rw-------. 1 administrator domain users 1482 9. Mai 10:45 tktHAG2L9 -rw-------. 1 administrator domain users 1482 9. Mai 10:47 tktKO0s0V -rw-------. 1 administrator domain users 1482 9. Mai 11:03 tktos40Vq -rw-------. 1 administrator domain users 1482 9. Mai 10:43 tktZ1w1wZ [stef@stef ~]$ sudo cat /run/user/1067400500/krb5cc/primary tktos40Vq There are lots of tickets there.
[stef@stef ~]$ sudo klist DIR:/run/user/$uid/krb5cc Ticket cache: DIR::/run/user/1067400500/krb5cc/tktos40Vq Default principal: Administrator\@BORG.THEWALTER.LAN.LAN Valid starting Expires Service principal 09.05.2013 11:03:23 09.05.2013 21:03:23 krbtgt/BORG.THEWALTER.LAN.LAN renew until 16.05.2013 11:03:23 Is that backslash supposed to be there in the 'Default principal'?
Installed Packages Name : krb5-libs Arch : x86_64 Version : 1.11.2 Release : 4.fc19 Size : 2.1 M Name : sssd Arch : x86_64 Version : 1.10.0 Release : 4.fc19.beta1 Size : 4.9 M
This might be a duplicate of #961278 We explicitly tested this case prior to releasing 1.10beta1 (and actually found out that the enterprise principal support broke stuff - see 42084c0f500ba849393b0e87477cd1af397ddecb). But it turned out we tested with a different krb5 version, that might play a role, too.
(In reply to comment #3) > [stef@stef ~]$ sudo klist DIR:/run/user/$uid/krb5cc > Ticket cache: DIR::/run/user/1067400500/krb5cc/tktos40Vq > Default principal: Administrator\@BORG.THEWALTER.LAN.LAN > > Valid starting Expires Service principal > 09.05.2013 11:03:23 09.05.2013 21:03:23 > krbtgt/BORG.THEWALTER.LAN.LAN > renew until 16.05.2013 11:03:23 > > Is that backslash supposed to be there in the 'Default principal'? Yes, the backslash escapes the first "@".
Fixed in sssd-1.10.0-5.fc19.beta1 OLD: sssd.x86_64 0:1.10.0-4.fc19.beta [test@pkis ~]$ pamtester system-auth 'LaBarbara.qe' authenticate Password: pamtester: Authentication failure ==> /var/log/sssd/sssd_ad.baseos.qe.log <== (Tue May 14 16:16:14 2013) [sssd[be[ad.baseos.qe]]] [krb5_auth_done] (0x0020): No ccache for LaBarbara.QE in DIR:/run/user/1197601119/krb5cc? NEW: sssd-1.10.0-5.fc19.beta1 [test@pkis ~]$ pamtester system-auth 'LaBarbara.qe' authenticate Password: pamtester: successfully authenticated ==> /var/log/sssd/sssd_ad.baseos.qe.log <== (Tue May 14 16:18:01 2013) [sssd[be[ad.baseos.qe]]] [check_for_valid_tgt] (0x0020): krb5_cc_retrieve_cred failed.
sssd-1.10.0-5.fc19.beta1 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/sssd-1.10.0-5.fc19.beta1
Package sssd-1.10.0-5.fc19.beta1: * 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-5.fc19.beta1' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-8176/sssd-1.10.0-5.fc19.beta1 then log in and leave karma (feedback).
sssd-1.10.0-5.fc19.beta1 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.