Red Hat 7/8 clients authenticating against Active Directory, but access to CIFS data is denied

[borkp]

Hi,

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:

cluster::*> export-policy check-access -vserver datasvm -volume cifs_testing -client-ip 10.11.109.18 -authentication-method krb5 -protocol nfs3 -access-type read-write
Policy Policy Rule
Path Policy Owner Owner Type Index Access
----------------------------- ---------- --------- ---------- ------ ----------
/ default datasvm_root volume 1 read
/cifs_testing cifs_test cifs_testing volume 1 read-write

cluster::*> export-policy check-access -vserver datasvm -volume cifs_testing -client-ip 10.11.109.18 -authentication-method sys -protocol nfs3 -access-type read-write
Policy Policy Rule
Path Policy Owner Owner Type Index Access
----------------------------- ---------- --------- ---------- ------ ----------
/ default datasvm_root volume 1 read
/cifs_testing cifs_test cifs_testing volume 1 read-write

Name mapping seems to be OK by shortname:

cluster::*> secd name-mapping show -node cluster-03 -vserver svmcifsnfs -direction unix-win -name fflinstone

'fflinstone' maps to 'DOMAIN01A\fflinstone'

But seems to be a bit off when specifying Domain\account:

cluster::*> secd name-mapping show -node cluster-03 -vserver svmcifsnfs -direction unix-win -name DOMAIN01A\fflinstone

'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?

[parisi · Accepted solution]

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.

https://www.netapp.com/media/19423-tr-4835.pdf

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.

[borkp]

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.

[parisi]

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.