IHAC that has a CIFS volume (NTFS security style) and would like to make this volume available to Red Hat 7 and 8 clients. Linux clients currently authenticate against Active Directory. The export policy has been configured to let all hosts mount. CIFS share and volume permissions - Everyone/Full Control
The RH client has mounted the export and export-policy check-access passed:
'DOMAIN01A\fflinstone' maps to 'DOMAIN01A\fflinstone'
How should I be thinking about this? I'm not clear on how this architecture should be.
How should RedHat clients access NTFS volumes via nfs when the usernames are managed by AD? Since RH clients auth against AD, I don't see how username mapping should come into play, but if the name maps back to itself, shouldn't that work?
Name mapping always comes into play when coming into an NTFS security style volume from NFS. The reason is that the UNIX user isn't a part of the NTFS ACLs, so ONTAP needs to find a valid Windows user to map to and then check the ACLs for that user.
secd name mapping show doesn't actually check the actual name mapping; instead, it just tells you what we'd be mapping to by default, and if there are name mapping rules, what we'd map if those were in play.
A better command to use is "authentication show-creds," which gives:
- name mappings
- group memberships in UNIX and Windows
- UID/GID/SID information
TR-4835 has a list of commands to help troubleshoot this.
What is likely happening here is that the user coming in from the Linux box isn't being translated properly by ONTAP to a user name, so we can't map to a valid Windows user. "event log show" will give you messages to clue you in to what might be happening here.
Also a possibility is that this client is using SSSD to generate UID/GID numbers dynamically via the Windows AD SID, which ONTAP doesn't support. You'd either need to populate the AD LDAP UNIX attributes with static entries and configure ONTAP to query those or add local UNIX users and groups that match those numeric IDs. You can test that theory by:
- running "id username" on the Linux client to get the UID/GID info
- creating a local UNIX user and group with those attributes (unix-user create/unix-group create)
- running the "authentication show-creds" command to verify the user is mapping and resolving properly from Windows to UNIX and back again
- testing your mount
An alternate way of doing this is using NFSv4.x and disabling numeric ID support, which forces a domain name string to come from the client, which won't require numeric ID to name resolution.
Thanks @parisi - I went with the local user creation and I was able to mount. I really appreciate the thorough explanation and the TR is awesome. The event log show command did the trick.
The customer has concerns with managing multiple user IDs (AD and local ONTAP), but I don't suppose it's a direct security concern that the ONTAP accounts exist, correct? My question is if a rogue Red Hat machine had the UID and GID of the UNIX account in question, could this access be replicated by Red Hat user creating a local UNIX user with the same UID/GID and user ID?
My background is Windows, so my apologies for what would otherwise be basic linux questions.
No more of a concern than if it was in AD LDAP. This username is there to map a UNIX user to a valid Windows user for NTFS ACL resolution. Then the ACLs control access to the client.
Yes, if someone creates a local user on a client with the same UID/GID/name as what's in AD or on the ONTAP system, they could gain access - but if that's a concern, you could add Kerberos authentication to the mix for NFS access.