Multiprotocol NAS access to Netapp resources with ACLs

A small preface to the article.
The customer has requested to organize CIFS (SMB) access to some NFS exports that lie on NetApp. It sounds like it is easy: you need to create a CIFS-ball on an already exported qtree. It was later demanded that it is necessary to granularly control access to these balls. Again, the problem seems to be solved: it can be controlled with NetApp and through the Shared Folders snap-in (share permissions). Then it turned out that you need to vary the access to the various subfolders on the CIFS ball. This has already turned out to be a nontrivial task. Since it was necessary to configure access control lists (ACL) for both CIFS and NFS to the same data.

At first glance, you can use classic permissions in Linux. Each folder and file has attributes of owner, group of owner and others (all the others). The following is an example of classic Linux permissions.

>$ ls -lrt drwxr-xr-x. 2 root root 4096 May 8 15:47 nfsv4_test 

But what if you need more granular control of access? POSIX ACLs? They are not supported by NetApp. As a result, the only solution turned out to be NFSv4 ACLs.
')
This article provides a description of how to broadcast NFSv4 ACLs for Windows users. We will carry out our setup step by step. Style will be as concise and capacious. I will not dwell on each item in detail, besides I will not give a detailed listing of all the teams. So let's get started.

Bind NetApp to LDAP

It is assumed that there is an LDAP server in this infrastructure through which user authorization and authentication takes place. Therefore, mapping is not used and, accordingly, the usermap.cfg file is not corrected. There is also no need to make changes to the passwd and group files - all users and groups are taken from LDAP. Below are the parameters necessary for the normal operation of the hitch:

 ldap.ADdomain ##  ,     ldap.base DC=com ldap.enable on ldap.fast_timeout.enable on ldap.minimum_bind_level simple ldap.name ##,        ldap.nssmap.attribute.homeDirectory unixHomeDirectory ldap.nssmap.attribute.uid sAMAccountName ldap.nssmap.objectClass.posixAccount User ldap.nssmap.objectClass.posixGroup Group ldap.port 3268 ldap.retry_delay 10 ldap.servers ## - ldap.usermap.attribute.unixaccount uid ldap.usermap.attribute.windowsaccount sAMAccountName 

They must be run on the target vFiler. I note that there are different variations of these settings. And in your specific infrastructure, this may not take off. In our case, we clung to AD DC with the FSMO Global Catalog role. Testing the linkage on NetApp is possible with the commands getXXbyYY and wcc . These commands can only be executed in advanced mode.

Examples of the correct operation of the getXXbyYY command :

 FILER0*> vfiler run VFILER03 getXXbyYY getpwbyname_r ivanov ===== VFILER03 pw_name = ivanov pw_passwd = {{******}} pw_uid = 10000, pw_gid = 10000 pw_gecos = Ivanov, Ivan pw_dir = /home/ivanov pw_shell = /bin/bash 

If this command does not return a similar output, then something is configured wrong.

In order for name and group resolution to work correctly, in Unix environments, you need to make edits in the /etc/nsswitch.conf file . We put ldap at the beginning for the passwd and group strings:

passwd: ldap nis files
group: ldap nis files
There is a small remark about the correct work of groups in the case of using LDAP. Within groups that will have access to Linux and Windows environments simultaneously, the 'memberUid' attribute must be populated. Important: it must be filled in lower case. Attribute must register users of this group. The memberuid field is highlighted in the attributes of the group, which should be available in Linux and Windows environments.

NFSv4 configuration on NetApp.

We want to broadcast NFSv4 permissions (read UNIX) to the Windows environment, that is, they will be the main access control lists. Therefore, we will use for our volumes / qtree UNIX-style permissions .

We create volume / qtree, we create on it export of NFS. In the / etc / exports file we see the following picture:

/vol/xxx_VFILER03_nfs_vol00/ACL_test -sec=sys,rw,root=192.168.0.1,nosuid

Set up the following options:

 nfs.v4.acl.enable on nfs.v4.enable on nfs.v4.id.allow_numerics on 

Configuring NFSv4 ACLs on Linux

The following settings must be made on the destination Linux server, on which our export with NetApp is mounted.

We mount the export with the following options:
nfs acl, defaults, intr, hard, bg, tcp, auto, rw 0 0

Then inside our export we assign ACLs according to our needs. NFSv4 ACLs are slightly more powerful than POSIX ACLs and are pretty close to CIFS ACLs. There are 2 commands for working with lists: nfs4_getfacl and nfs4_setfacl. It is not hard to guess that we read the available access lists with one team, and assign the second. Below is an example of setting up NFSv4 ACLS on the test folder:

 >$ nfs4_getfacl test A::OWNER@:rwatTnNcCy A::alice@nfsdomain.org:rxtncy A::bob@nfsdomain.org:rwadtTnNcCy A:g:GROUP@:rtncy D:g:GROUP@:waxTC A::EVERYONE@:rtncy D::EVERYONE@:waxTC 

Where A is allow, D is deny.

When making changes, use the command:

 >$nfs4_setfacl –e test 

Then the config will open in a text editor.

As we see there are many possibilities to control access for each file and folder.

Now you need to configure access. After that we check that on Linux the necessary rights for the necessary users.

Creating CIFS balls on NetApp

To do this, set up CIFS services via cifs setup.
After that we create a CIFS ball on the file on the same volume / qtree on which we have export.

 FILER0> vfiler run VFILER03 cifs shares -add ACL_test /vol/xxx_ VFILER03 _nfs_vol00/ACL_test 

Rights when creating balls leave EVERYONE / FULL CONTROL. This is to ensure that there are no unnecessary restrictions at the level of the balls.

 FILER0> vfiler run VFILER03 cifs shares ACL_test /vol/xxx_ VFILER03 _nfs_vol00/ACL_test everyone / Full Control 

File system permissions are already regulated using the NFSv4 ACLs tool.

This was the final setting. Now we connect with the same users that we connected to Linux and check access. NetApp has an old utility that shows Linux permissions in Windows environments. It is called SecureShare. You can also use it for verification. Below is a screenshot of the additional tab after installing the SecureShare utility.