User accessing via SSS authentication

Dear community,

I’ve a some questions about the woks via sss
1)How is working sss keys for users authorizations?
2)How does add user key for correctly into EOS?

There is a task: to authorize a user in EOS and assign him “root” rights using sss key.

My steps:

Create the key for a “eos_user”

eos-mgm2 ~]# chmod 600 /etc/eos.user.keytab 2>/dev/null; unlink /etc/eos.user.keytab 2>/dev/null
; yes | xrdsssadmin -k eos -u eos_user -g eos_user add /etc/eos.user.keytab >& /dev/null;
 chown daemon:daemon /etc/eos.user.keytab >& /dev/null ; chmod 400 /etc/eos.user.keytab

Checking the key

eos-mgm2 ~]# ll /etc/eos.user.keytab 
-r-------- 1 daemon daemon 139 дек 13 12:48 /etc/eos.user.keytab

eos-mgm2 ~]# xrdsssadmin list /etc/eos.user.keytab
     Number Len Date/Time Created Expires  Keyname User & Group
     ------ --- --------- ------- -------- -------
          1  32 12/13/21 12:48:13 -------- eos eos_user eos_user

Set mapping for eos_user to root

vid set map -sss eos_user vuid:0  vguid:0

EOS Console [root://localhost] > vid ls
***
sss:"eos_user":gid => root
sss:"eos_user":uid => root 
***

Specified and applied the user key in config both MGM:

****
SSS authentication
sec.protocol sss -c /etc/eos.user.keytab -s /etc/eos.keytab
****
sec.protbind * only sss unix krb5
***

On the client side I try to authorize:

export EOS_MGM_URL="root://vm-eos.domain.com"
export XrdSecSSSKT=/home/eos_user/eos.keytab
export XrdSecPROTOCOL=sss

[eos_user@vm4-ui1 ~]$ ll
total 4
-r-------- 1 eos_user eos_user 140 Dec 13 13:04 eos.keytab

[eos_user@vm4-ui1 ~]$ XrdSecDEBUG=1 eos  whoami
sec_Client: protocol request for host vm-eos.domain.com token='&P=sss,0.13:/etc/eos.user.keytab&P=unix&P=krb5,host/vm2-eos-mgm2.domain.com@DOMAIN.COM'                                                                                               
sec_PM: Loaded sss protocol object from libXrdSecsss.so
sec_PM: Using sss protocol, args='0.13:/etc/eos.user.keytab'
sec_sss: Init_Client: Unable to determine keytab location.
sec_PM: Skipping unix only want sss
sec_PM: Skipping krb5 only want sss
error: MGM root://vm-eos.domain.com not online/reachable

In log MGM:

***
211213 13:10:49 12827 XrootdXeq: eos_user.29312:389@vm4-ui1 disc 0:00:00
***

But
if added, user key into server key:

[root@vm2-eos-mgm2 ~]# cat /etc/eos.user.keytab >> /etc/eos.keytab

[root@vm2-eos-mgm2 ~]# xrdsssadmin list /etc/eos.keytab
     Number Len Date/Time Created Expires  Keyname User & Group
     ------ --- --------- ------- -------- -------
          1  32 12/13/21 12:48:13 -------- eos eos_user eos_user
          1  32 10/20/21 03:09:51 -------- eos daemon daemon
          1  32 10/20/21 03:09:37 -------- eos daemon daemon

Auth for eos_user is success:

[eos_user@vm4-ui1 ~]$ XrdSecDEBUG=1 eos  whoami
sec_Client: protocol request for host vm-eos.domain.com token='&P=sss,0.13:/etc/eos.user.keytab&P=unix&P=krb5,host/vm2-eos-mgm2.domain.com@domain.com'                                                                                               
sec_PM: Loaded sss protocol object from libXrdSecsss.so
sec_sss: Client keytab='/home/eos_user/eos.keytab'
sec_PM: Using sss protocol, args='0.13:/etc/eos.user.keytab'
sec_sss: Ret 151 bytes of credentials; k=1
Virtual Identity: uid=0 (0,99) gid=0 (0,99) [authz:sss] host=vm4-ui1.domain.com domain=domain.com

From what I observe, I conclude that EOS ignores the user key, which is specified under the flag “-c”:Scalla Extension: Security, i.e.

sec.protocol sss -c /etc/eos.user.keytab -s /etc/eos.keytab

eos-mgm2 ~]# rpm -qa | grep eos
eos-folly-deps-2019.11.11.00-1.el7.cern.x86_64
eos-xrootd-4.12.8-1.el7.cern.x86_64
eos-rocksdb-5.7.3-1.el7.cern.x86_64
eos-fusex-selinux-4.8.69-1.el7.cern.x86_64
eos-nginx-1.12.2-5.x86_64
eos-fusex-core-4.8.69-1.el7.cern.x86_64
eos-server-4.8.69-1.el7.cern.x86_64
libmicrohttpd-0.9.38-eos.yves.el7.cern.x86_64
eos-protobuf3-3.5.1-5.el7.cern.eos.x86_64
eos-client-4.8.69-1.el7.cern.x86_64
eos-ns-inspect-4.8.69-1.el7.cern.x86_64
eos-folly-2019.11.11.00-1.el7.cern.x86_64
eos-fusex-4.8.69-1.el7.cern.x86_64

$ cat /etc/*release
NAME="Scientific Linux"
VERSION="7.9 (Nitrogen)"
ID="scientific"
ID_LIKE="rhel centos fedora"
VERSION_ID="7.9"

Thanks for your help!

You have to remove your vid mapping to root.

To enable sss mapping according to the specified user you run:

eos vid enable sss

That’s all … ah, and eos_user must be a local existing user.

Cheers Andreas.

Thanks, Andreas for your reply, but it didn’t help or maybe I do something wrong:

You have to remove your vid mapping to root.

ок:
eos-mgm2 ~]# eos vid ls | grep sss
sss:"":gid => root
sss:"":uid => root

To enable sss mapping according to the specified user you run:

eos-mgm2 ~]# eos vid ls -a
auth=krb5
auth=sss

That’s all … ah, and eos_user must be a local existing user.

on MGM side:
eos-mgm2 ~]# id eos_user
uid=1004(eos_user) gid=1004(eos_user) groups=1004(eos_user)

on client side:
[eos_user@vm4-ui1 ~]$ id
uid=1004(eos_user) gid=1004(eos_user) groups=1004(eos_user)

In log MGM:
211213 16:05:25 32596 XrootdXeq: User authentication failed; Decryption key not found.
211213 16:05:25 32596 XrootdXeq: eos_user.29867:369@vm4-ui1 disc 0:00:00

root@vm2-eos-mgm2 ~]# xrdsssadmin list /etc/eos.keytab
     Number Len Date/Time Created Expires  Keyname User & Group
     ------ --- --------- ------- -------- -------
          1  32 10/20/21 03:09:51 -------- eos daemon daemon
          1  32 10/20/21 03:09:37 -------- eos daemon daemon
[root@vm2-eos-mgm2 ~]# xrdsssadmin list /etc/eos.user.keytab 
     Number Len Date/Time Created Expires  Keyname User & Group
     ------ --- --------- ------- -------- -------
          1  32 12/13/21 12:48:13 -------- eos eos_user eos_user

If you modify /etc/eos.keytab it takes (I think 5 minutes) before the keytab is reloaded … at least it does not happen instantaneous.

If the log says, decryption key not found, the key is not yet loaded in the MGM.

All the keys which the MGM should recognize have to be stored in /etc/eos.keytab - they are not stored in separate files.

Yes, of course, if I specify a user key in /etc/eos.keytab everything starts working. But then what is the point of the flag -с?
I think it makes sense to separate the user keys from the server keys. To avoid storing all keys in one file.

The ‘-c’ flag tells the client one more default file name, where to look for an sss key when talking to this MGM.
The ‘-s’ flag tells the MGM, which keys a client can show.

You just have a misconception here. This are symmetric keys, which exist in client and server.
The ‘-c’ just points clients to a location, but the key has to be also listed in the ‘-s’ keytab file.

Cheers Andreas.

Dear Andreas,
Thank you very much for the detailed explanation, it seems I misunderstood the purpose of the keys.

Also i’ve another questions:
When I add a user key to /etc/eos.keytab on both MGMs. Does it need to be synchronized with the FST servers that also use it? If the keys are not synchronized in content between MGM and FST can there be any problems?

Many thanks!