Kerberos configuration is not necessary on the FSTs, only on the MGM.
So the whoami command from the client gives you a nobody identity, despite your valid kerberos ticket.
To understand what is going on on client side, you can enable the 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: context lock
Seckrb5: context locked
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 the mgm side, you can look at the logs (
/var/log/eos/mgm/xrdlog.mgm), if the verbosity is high enough.
Of course, the 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 eosstorage
eosstorage@ACME.COM: kvno = 3