en en en en en en it en en en en en en en en en en nb en sv en en nl en en en en en en en it fr en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en it en nl it en nb en en es en en en es en en en en nl en en en en en en en en en bn en en nb en en en en en en nl en en en en en nb en en en en nl en en en en en en en en en
EOS authentication system (unix and krb5) - Site Administrators - EOS Community
dpugnere (Denis Pugnere) April 3, 2018, 4:30pm #1
Here is my configuration :
And te eos command shows :
I suspect I should use te mapping command :
eos -b vid set map -unix
eos -b vid set map -krb5
But I don’t know how. I’d be happy to read any suggestion / comment.
franck-jrc (Franck Eyraud) April 4, 2018, 9:39am #2
Probably te kerberos authentication is not enforce because some things are missing. To know if te user is authenticated, run this : eos whoami
Do you have a file /etc/krb5.keytab containing te key of te principal you use to authenticate against (host/np02ss18@CERN.CH), you can check by running klist -k /etc/krb5.keytab.
Your user should also have a valid kerberos ticket created by kinit.
For what I know, you shouldn’t need any map set.
Using Kerberos with a laboratory's Active Directory
dpugnere (Denis Pugnere) April 4, 2018, 11:49am #3
on te MGM (as root) :
[root@np02ss18 mgm]# eos whoami
Virtual Identity: uid=0 (2,99,3,0) gid=0 (99,4,0) [authz:sss] sudo* host=localhost
[root@np02ss18 mgm] # klist -k /etc/krb5.keytab
On te client (as root) :
[root@np02ss19 ~]# klist -k /etc/krb5.keytab
On te client (as te user) :
Virtual Identity: uid=99 (99) gid=99 (99) [authz:unix] host=np02ss19.cern.ch
Valid starting Expires Service principal 04/04/2018 10:48:32 04/05/2018 11:48:25 krbtgt/CERN.CH@CERN.CH renew until 04/09/2018 10:48:25
dpugnere (Denis Pugnere) April 4, 2018, 12:08pm #4
I realize that te krb5 configuration is only present in te /etc/xrd.cf.mgm MGM node, but not on te FSTs.
On te FSTs :
[root@np02ss04 ~]# grep -E “sec.(protocol|protbind)” /etc/xrd.cf.fst
sec.protocol sss -c /etc/eos.keytab -s /etc/eos.keytab
sec.protbind * only unix sss
Should I have this ?
sec.protocol sss -c /etc/eos.keytab -s /etc/eos.keytab
sec.protbind localhost.localdomain unix sss
sec.protbind localhost unix sss
sec.protbind * only krb5 sss unix
franck-jrc (Franck Eyraud) April 4, 2018, 1:40pm #5
Kerberos configuration is not necessary on te FSTs, only on te MGM.
So te whoami command from te client gives you a nobody identity, despite your valid kerberos ticket.
To understand what is going on on client side, you can enable te debugging of xrootd security : XrdSecDEBUG=1 eos whoami
You should get something like :
sec_Client: protocol request for host eos-contingency.acme.com token='&P=krb5,eosstorage@ACME.COM&P=sss,0.13:/etc/eos.keytab&P=unix' sec_PM: Loaded krb5 protocol object from libXrdSeckrb5.so sec_PM: Using krb5 protocol, args='eosstorage@ACME.COM' Seckrb5: getCredentials Seckrb5: context lock Seckrb5: context locked Seckrb5: FILE:/tmp/krb5cc_61928_kc8pWeEwrZ Seckrb5: init context Seckrb5: cc set default name Seckrb5: Returned 512 bytes of creds; p=eosstorage@ACME.COM Virtual Identity: uid=61928 (61928,99) gid=40507 (99,61895,65422,29431,41068,54068,43590,63804,40507,22605,50003,504,507) [authz:krb5] host=s-fdfasf87v.acme.com
To debug what is going on on te mgm side, you can look at te logs (/var/log/eos/mgm/xrdlog.mgm), if te verbosity is high enough.
Of course, te kerberos principal dpugnere@CERN.CH should be entitled to get ticket against host/np02ss19@CERN.CH principal. This can be tested this way with MIT kerberos : kvno host/np02ss18@CERN.CH
$ kvno eosstorage eosstorage@ACME.COM: kvno = 3
dpugnere (Denis Pugnere) April 4, 2018, 3:54pm #6
Thanks a lot Franck,
[dpugnere@np02ss19:~/]$ XrdSecDEBUG=1 eos whoami sec_Client: protocol request for host np02ss18.cern.ch token='&P=krb5,host/np02ss18@CERN.CH&P=sss,0.13:/etc/eos.keytab&P=unix' sec_PM: Loaded krb5 protocol object from libXrdSeckrb5.so sec_PM: Using krb5 protocol, args='host/np02ss18@CERN.CH' Seckrb5: getCredentials Seckrb5: FILE:/tmp/krb5cc_28122_r7StfgaEnt Seckrb5: init context Seckrb5: cc set default name Seckrb5: cc default Seckrb5: context lock Seckrb5: context locked Seckrb5: get_krbCreds: unable to get creds; Server not found in Kerberos database sec_Client: protocol request for host np02ss18.cern.ch token='&P=sss,0.13:/etc/eos.keytab&P=unix' sec_PM: Loaded sss protocol object from libXrdSecsss.so sec_PM: Using sss protocol, args='0.13:/etc/eos.keytab' sec_sss: Init_Client: Unable to determine keytab location. sec_PM: Loaded unix protocol object from libXrdSecunix.so sec_PM: Using unix protocol, args='' Virtual Identity: uid=99 (99) gid=99 (99) [authz:unix] host=np02ss19.cern.ch
I see there Seckrb5: get_krbCreds: unable to get creds; Server not found in Kerberos database
[dpugnere@np02ss19:~/]$ kvno host/np02ss18@CERN.CH kvno: Server not found in Kerberos database while getting credentials for host/np02ss18@CERN.CH [dpugnere@np02ss19:~/]$ kvno host/np02ss18.cern.ch@CERN.CH host/np02ss18.cern.ch@CERN.CH: kvno = 3 [dpugnere@np02ss19:~/]$ kvno np02ss18 np02ss18@CERN.CH: kvno = 3
[root@np02ss19 ~]# cern-get-keytab Current keytab file (/etc/krb5.keytab) is valid. Use --force to reinitialize.
franck-jrc (Franck Eyraud) April 4, 2018, 4:25pm #7
OK, so for some reason linked to te kerberos infrastructure at CERN (of which I don’t know anything), you cannot use host/np02ss18@CERN.CH as principal to authenticate against for your eos instance (te kvno test fails; te principal might have been disabled, or te system configuration doesn’t specify a KDC server for it). But te two others are good candidates it seems, since te kvno action succeeds for them.
You might already have deduced that you can change te line in te xrd.cf.mgm file by specific another principal, e.g. :
You need to restart te mgm after this change, and you should be able to authenticate using kerberos, hopefully…
dpugnere (Denis Pugnere) April 4, 2018, 5:35pm #8
You got it !
[dpugnere@np02ss19:~/]$ XrdSecDEBUG=1 eos whoami sec_Client: protocol request for host np02ss18.cern.ch token='&P=krb5,host/np02ss18.cern.ch@CERN.CH&P=sss,0.13:/etc/eos.keytab&P=unix' sec_PM: Loaded krb5 protocol object from libXrdSeckrb5.so sec_PM: Using krb5 protocol, args='host/np02ss18.cern.ch@CERN.CH' Seckrb5: getCredentials Seckrb5: FILE:/tmp/krb5cc_28122_r7StfgaEnt Seckrb5: init context Seckrb5: cc set default name Seckrb5: cc default Seckrb5: context lock Seckrb5: context locked Seckrb5: Returned 2100 bytes of creds; p=host/np02ss18.cern.ch@CERN.CH Virtual Identity: uid=28122 (28122,99) gid=1395 (1395,99) [authz:krb5] host=np02ss19.cern.ch
You save my week ! thank you so much Franck.
Powered by Discourse, best viewed with JavaScript enabled