Otdfbt

I'm attempting to configure NFSv4 with KRB5 authentication in accordance with RedHat's current recommendations, using SSSD to access Active Directory. The NFS server in this case is a NAS appliance, which handles user mapping between user@domain accounts and UIDs/GIDs pulled from AD/LDS. I've disabled the ID mapping in SSSD, as the NAS doesn't have the same hash+modulus method available to calculate "homemade" IDs.

In its current state, the NAS recognizes the user and group ownership for file permissions, and enforces them as expected. However, ls output from the client displays nobody nobody on any files/folders owned by a domain user.

[root@nfsclient ~]# ls -al /mnt/nfs4test/
total 0
drwxr-xr-x. 1 nobody nobody 0 Jul 17 10:46 .
drwxr-xr-x. 3 root root 22 Jul 17 10:47 ..

With logging verbosity maxed for idmapd and sssd, the only event I've seen indicating any issue is:
Jul 17 11:48:23 nfsclient nfsidmap[10601]: nss_getpwnam: name 'nfsadmin' not found in domain 'testdomain.local'

I've also confirmed via packet capture that the expected user/group name strings are being returned for owner and group (not IDs) in the lookup reply:

fattr4_owner: nfsadmin@testdomain.local
fattr4_owner_group: Domain Admins@testdomain.local

Environment consists of a 2012R2 DC, CentOS 7.3 client, and a vendor-proprietary (CentOS-based) NAS appliance acting as the server. Aside from installing requisite packages and IP / NTP configuration, these are my configuration steps on the client:

• Add Domain = testdomain.local to /etc/idmapd.conf


• Join AD domain with realm join testdomain.local -U nfsadmin
  


• Allow SSH access from all domain users (realm allow)


• Set ldap_id_mapping = False in /etc/sssd/sssd.conf


• Enable/start/restart sssd.service rpcgssd rpcidmapd and nfs-secure


• Mount export with sec=sys to change ownership over to domain user


• Re-mount with sec=krb5

Whether using sec=sys or sec=krb5, root or a domain account, ls output is the same.

The only applicable solutions I've found in my searching have pointed to the need for creating local accounts for the users, but it seems like this would defeat the purpose of AD integration. I'd expect it to be possible to create a new AD user, add them to proper groups for access permissions, set UID/GID, then that user should be able to access files on the export once they've SSH'd to the client machine.

The client configuration is purely pulling data from Active Directory (only the server/NAS utilizes AD/LDS). UIDs/GIDs in active directory were manually populated via PowerShell (e.g. Get-ADUser "nfsadmin" | Set-AdUser -replace @uidNumber=10001 - trying to make this 2016 compatible and avoid using adminui/nis or the UNIX Attributes tab, even though I'm testing on 2012R2 at the moment)

How can I get NSS / nfsidmap to properly translate domain user/group names returned by the server?

I'd strongly prefer something that doesn't involve manual local account creation for each individual user so scaling to thousands of users doesn't become a huge pain. Also, forcing the server (NAS appliance in this instance) to return IDs instead of names is not possible.

idmapd was utilizing nsswitch as a default in this case, but the AD integration methods detailed in the document referenced above have no reference to any idmapd.conf modifications.

Comments in idmapd.conf state "Distributed methods include nsswitch, umich_ldap, and static." This isn't a comprehensive list of plugins however, and system security services (sss) should be used in this case.

/etc/idmapd.conf:

[General]
Domain = testdomain.local

[Translation]
Method = sss

This became apparent to me when I realized that sss was handling mapping perfectly when ldap_id_mapping was still enabled (but causing server-side mapping issues w/ the NAS appliance), and the "could not be found in domain" error was being reported by nss_getpwnam.

I'm still not clear on why NSS couldn't get the job done when sss is one of the listed db's for passwd and group in nsswitch.conf, but the above change gets the job done.