On (10/11/15 16:25), Joschi Brauchle wrote:
On 11/10/2015 11:40 AM, Lukas Slebodnik wrote:
>Could you tell us what is a value of env variable KRB5CCNAME
>after log-in?
$ echo $KRB5CCNAME
KEYRING:persistent:3036404
>Do you test with ssh or su or "su -"
SSH tests fail each time.
Does dump of sssd cache contain attribute
"ccacheFile"
after that login?
If yes you might try to use this ccache
KRB5CCNAME=$(value from dump) klist
Local tests fail each time.
(Both meaning that login succeeds, but no ccache available)
If I do a "su - <username>" then I obtain a ccache, see:
----------SSH login...
^^^
it says ssh but you did "su -"
$ klist
klist: No credentials cache found while retrieving principal name
$ su - myusername
Password:
X11 connection rejected because of wrong authentication.
No directory, logging in with HOME=/
$ klist
Ticket cache: KEYRING:persistent:3036404:krb_ccache_LgqDqsq
Default principal: myusername@MYREALM
Valid starting Expires Service principal
11/10/2015 16:03:28 11/11/2015 02:03:28 krbtgt/MYREALM@MYREALM
renew until 11/17/2015 16:03:28
$ echo $KRB5CCNAME
KEYRING:persistent:3036404
That's good.
----------
Any followup SSH or local login succeeds as well.
It might be explained by fact that user session is opened (loginctl)
and was not closed. So the same KRB5CCNAME was ised.
If I do mixed SSH and local logins, they succeed at some point (at
least
thats what I believe)... That is really strange.
Some observations:
- local and SSH login have a substantion PAM configuration, while
- su is pretty simple.
It's expected and shoud not be used for such tests.
"su -" uses different pam service /etc/pam.d/su-l
which do full authentication
- Note that even when I successfully obtain a valid keyring ccache at
some
point, and kinit is happy... I have never ever been able to use these
credentials with kerberized NFS3+4. I always get an "access denied" error
with NFS3+4, see
This is not related to sssd :-)
---------- after su - myusername
$ klist
Ticket cache: KEYRING:persistent:3036404:krb_ccache_LgqDqsq
Default principal: myusername@MYREALM
Valid starting Expires Service principal
11/10/2015 16:03:28 11/11/2015 02:03:28 krbtgt/MYREALM@MYREALM
renew until 11/17/2015 16:03:28
$ cd /home/myusername # home is nfs4 + krb5 protected
-su: cd: /home/myusername: Permission denied
----------
The only way to get login + NFS working so far is using FILE caches so far.
In this case, after I 'cd' to my home, klist also shows an
'nfs/nfsserver.fqdn@MYREALM' ticket and all is well:
---------- after SSH login and FILE ccache in /etc/krb5.conf
$ klist
Ticket cache: FILE:/tmp/krb5cc_3036404_GZnyw8
Default principal: myusername@MYREALM
Valid starting Expires Service principal
11/10/2015 16:23:09 11/11/2015 02:23:09 krbtgt/MYREALM@MYREALM
renew until 11/17/2015 16:23:09
11/10/2015 16:23:10 11/11/2015 02:23:09 nfs/nfsserver.fqdn@MYREALM
renew until 11/17/2015 16:23:09
$ pwd
/home/myusername
----------
>Please also provide dump of sssd cache after authentication.
>There should be somethig about ccache as well.
>
>ldbsearch -H /var/lib/sss/db/cache_*.ldb
Please see here:
http://paste.opensuse.org/view/raw/46179025
I noticed that my userPrincipalName and canonicalUserPrincipalName differ...
not sure if this matters.
You can test yourself so that you will not use UPN but user@domain
ne96soh(a)ADS.MWN.DE
But we might try to solve why ssh does not work for first time.
* please try with empty sssd cache.
* destroy KEYring cache (or destroy user session with loginctl)
LS