I’ve run into an interesting problem that I’ve narrowed down to the interaction between
rpcidmapd and sssd. My sssd.conf is using AD as it’s id provider. When the setting
use_fully_qualified_names = True is enabled in sssd.conf, rpcidmapds append the domain
name to user lookup requests. This results in having user lookup requests that include an
extra @domain.name in them, for example: rpc.idmapd: Server : (group) id
"1002200513" -> name "user@domain.com(a)domain.xn--com-9o0a This results in users
not being able to access folders that use any kind of group permissions because they are
not recognized as being members. Also if a user creates a file, it is listed as being
owned by nfsnobody since the user isn’t mapped to an ID correctly.
When I adjust sssd.conf to be use_fully_qualified_names = False, the lookup request looks
right: rpc.idmapd: Server : (group) id "1002200513" -> name
"user(a)domain.xn--com-9o0a However, if I then mount the nfs share from a different machine,
and use a domain account with a valid Kerberos ticket, I still get permission denied when
trying to access files, presumably because even though rpcidmapd is displaying my name as
“user(a)domain.xn--com-9o0a the server is looking for the unqualified name “user” which still fails
to match.
Has anyone else experienced this? I saw there was some effort at an sssd plugin for
rpcidmapd, but that doesn’t seem complete yet. Is there a viable workaround so I can get
kerberized nfs mounts up?
Isaiah Houston