Consideration 1: CIFS access to NTFS security style volumes always requires mapping of CIFS users to a UNIX UID (this applies to all Data ONTAP versions).
User access to files through CIFS on any type of volume requires a CIFS user to be mapped to an existing UNIX user known to the storage system. This may not seem intuitive at first but becomes clearer considering that the Data ONTAP filesystem is still based on UNIX and is necessary to have an associated UNIX UID and a GID to allow any access, even if these IDs do not determine permissions. Without mapping to an existing UNIX user, even on an NTFS security style volume, CIFS access to a share will be denied. The recommended way to set this up is as follows:
- Set a default UNIX user on the vServer:
vserver cifs options modify -vserver <vserver name> -default-unix-user <user to map to, e.g. pcuser>
Now ensure that the default mapped user and that user’s default group exist. The easiest way is to create them locally, assuming the vserver ns-switch setting includes file. (you can see this setting with vserver show)
vserver services unix-user create pcuser -id 65534 -primary-gid 65534
vserver services unix-group create pcuser -id 65534
Note: Without performing the above, CIFS access will not be granted, irrespective of the volume security style, unless there are specific maps for each CIFS user that needs access.
Consideration 2: Data ONTAP (any version) does not map groups or GIDs
It is not possible to map CIFS users to a GID, or UNIX users to a group in the Active Directory (AD). Similarly, it is not possible to map a GID to a group or a user in AD, or an AD group to a UNIX UID or GID. The groups of the user we are mapping to DO have an effect on the permissions of the mapped user.
An AD user DOMAIN\john maps to a specific UNIX user john with UID 501. Through a local unix-user table, NIS or LDAP, this user is a member of his primary group users (gid 500), and secondary groups engr (group 30) and wheel (gid 0). Mod bits on folders or files in the unix security style volume that grand users that are members of these 3 groups certain access will also grant these to john when coming in through a CIFS share.
While there are no group mappings, a group of individual users can be mapped to a specific user. Further, regular expressions can be used to get that to work more conveniently.
All AD users that start or end with the word SALES can be mapped to a specific UNIX user and to the user’s UID. To make this work, certain users in AD can be renamed and regular expressions can be used in the name-mapping table to effectively emulate group actions. The reverse of this can be also be performed.
Consideration 3: CIFS access in Data ONTAP 8.0, 8.1 and 8.2 Cluster-Mode requires an AD server
CIFS access to a vServer requires an AD server configured on that vServer. Further, the storage system requires an AD to determine CIFS access, but without a configured AD, CIFS access is not allowed. In 8.2 local users and groups can be configured, however AD connectivity is still required to create a cifs service on a vserver.
Note: This differs from Data ONTAP 7 G/8 7-modes, where local CIFS accounts can exist and allow access.
Although other LDAP type servers cannot replace an AD server for CIFS access, an additional LDAP server can be used to centrally map UNIX and AD users, thus allowing mapped CIFS access to UNIX security style volumes and vice versa.
Consideration 4: Mixed protocol NAS access does not require mixed security style volumes
Note: In a majority of cases, using the mixed security style volumes is not advised.
With the right mapping of users, mapped CIFS access to a UNIX security volume and mapped NFS access to an NTFS security style volume is feasible. Mapping CIFS directly to UNIX security style volumes or NFS to NTFS security style volumes is actually preferred to using mixed security style volumes. Using a mixed security style volume adds increased complexity, such as effective security on files and switches between mod bits and ACLs during use, which is generally not desired, since this can result in inconsistent access permissions and restrictions.
Consideration 5: User-mapping can work perfectly well without any entries in the vServer name-mapping tables
By default, when users access through CIFS or NFS, if a matching entry exists in the UNIX user table (or if configured in NIS or non-AD LDAP), the mapping of names will be completely transparent (unless there is an entry in the usermap overriding this).
If a UNIX user exists on a vServer with the name ‘xxxxx’ and UID 1001, and a user exists in the AD with that same name (say DOMAIN\xxxxx), then UNIX users with UID 1001 will be mapped to user DOMAIN\xxxxx for NFS clients in NTFS security style volumes, and AD user DOMAIN\xxxxx will be mapped to UID 1001 in CIFS shares on UNIX security style volumes.
Consideration 6: In clustered Data ONTAP 8.0 and 8.1, if there are parent volumes in the junction tree when accessing a folder directly through CIFS, their access restrictions can affect CIFS share access.
Note: This requirement has been removed from Data ONTAP 8.1.2 and later.
All CIFS users have to be mapped to a UID for access. If a share is in a volume that is not the root volume of a vServer, all folders and volumes that are above the volume with the share in the junction tree, have to provide execute permissions for the mapped user for CIFS access to be possible.
A CIFS share is created on a vServer at
/staging/rev2. Here, rev2 is an NTFS security style volume and the user accessing the share is mapped to the default pcuser. For this user to have access, both the root volume (/) and the staging directory or junctioned volume (/staging) needs to provide execute permissions to pcuser.
In all probability, the mod bit (for everyone) has to be 1 atleast, but 5 or 7 would work as well.
UNIX-permissions on the parent volumes would be set to at least
---------x. This is a requirement, irrespective of the share location in the vServer. Keep in mind that if you make a change to the root volume, it’s not effective until after the LS mirrors are updated as well.
This does not apply if all volumes in the junction tree are NTFS security style, including the root volume (and it’s LS mirrors)
How does mapping work 1: AD user accessing a CIFS share on a UNIX security style volume, mapping to a UNIX user.
In this case, a user writes a file through a CIFS share on a UNIX volume that has a UNIX NFS client. Mapping in this environment is performed as follows:
- The Windows client sends an SID for access.
- The storage system searches and identifies this SID on the AD and matches it to a username, say DOMAIN\xxxxx.
- The storage system then searches for an entry or expression in the usermap table to match the name with this username.
If a rule exists, it will map to a UNIX user. If not, the storage system searches its local UNIX-user table, LDAP or NIS user databases for a matching UNIX UID (the domain ID is removed to match the name). The lookup order is based upon settings that can be set on the vServer. Run the
vserver show -fields ns-switchcommand to display the current order.
- If the storage system finds an equivalent user in the UNIX user table, it maps the AD user to that local user.
For DOMAIN\xxxxx it finds a corresponding user xxxxx.
If it does not find the user, it looks for a vServer specific default UNIX user (which is set if the above recommendation is followed.)
- Based on the steps above, a matching UNIX UID for the mapped user is determined, which is then used to determine the access permissions. The storage system then uses that UID as the UID of any newly created files (and the default GID for that user will be the GID for a newly created file).
- In the example above, the mapped UNIX user ‘xxxxx’ gets UID 1001 on the storage system.
- The UNIX mode permission bit for the file created through the CIFS share on a UNIX qtree (for example 644, or rw-r–r–) is by default inherited from the parent folder permissions. These can be made more restrictive by adding a general umask, file-umask, and/or folder umask settings to the share. Run the
cifs share modifycommand to set these.
- If a UNIX NFS client reads the file through NFS, it will map the UID it sees to a username as per the passwd file, NIS, LDAP or other name services configuration on the client. If everything is set up correctly, it should have an entry that maps UID 1001 back to xxxxx. As result, the ownership is reported as that same user when the file is read from the client.
In an AD environment, a domain username always maps to the same SID from the storage system or any host tied to the domain. UNIX clients might not always use a central directory such as NIS or LDAP to make sure all users to UID mappings are homogeneous across the environment. When the storage system maps AD users to UNIX UIDs, if the passwd file of a UNIX client does not match the UNIX user table on the vServer, file ownership and permissions can still become unexpected when NFS exports are viewed from these clients. The file might map AD user DOMAIN\xxxxx to UID 1001, but if an NFS client has a passwd entry that maps 1001 to ‘yyyyy’, files created by DOMAIN\xxxxx through CIFS on a UNIX security style volume look like they are owned by ‘yyyyy’ from this client’s perspective. It is therefore important to make sure all clients have the same user to UID mapping (in their passwd file) that the storage system uses to avoid such confusion.
How does mapping work 2: User on NFS client accessing an NFS export on an NTFS security style volume, mapping to an AD user
In this case, a user writes a file through NFS on an NTFS security style volume that has a SOLARIS NFS client. Mapping in this environment is performed as follows:
- The NFS client, a UNIX system, maps the current user to its UID as per the passwd file, NIS or LDAP. It sends this UID as the UID for which it wants to write a file on the storage system.
- The storage system takes this UID and maps it to a username as per the unix-user table, NIS or LDAP.
This lookup order is based upon settings that can be set on the vServer. Run the
<<vserver show -fields ns-switch>>command to display the current order.
- If the storage system is unable to find an entry for the UID in the unix-user table, NIS or LDAP, it will apply the default user for UNIXaccess. Run the
vserver nfs showcommand to find the user.
- The storage system takes this name and looks for an entry/expression in the usermap table to match the name.
If a rule exists, it will map to a domain user accordingly. If not, it queries the domain controller to get a SID for the username.
With the domain name appended, it will look for DOMAIN\xxxxx when mapping xxxxx.
- The reported SID from the AD will then be used to determine access permissions, and the ownership of the newly created file. Some UNIX applications, such as vim, when creating or modifying a file, will attempt to modify UNIX style permissions as part of the file creation process. This will fail because the volume has an NTFS security style set and UNIX mode bit changes are not relevant. Similarly, trying to change a file’s security descriptor with
chmodwill normally report a failure in this scenario. The storage system can be configured to ignore these attempts and not report a failure. As a result, programs such as vim will work appropriately and chmod will not report an error (although it will not change permissions either) on NTFS security style volumes. To turn on this silent ignore, set the ntfs-unix-security-ops to ignore inside the “export-policy rule” that is exporting the volume (this is visible under the advanced level privilege) .
How does mapping work 3: The usermapping table
The name-mapping table allows mapping users that do not map automatically. This is for users in trusted domains outside the domain the vServer is on, or users whose UNIX-name does not match their Windows name (for example, due to case sensitivity). This can also be used to map groups of users with the help of regular expressions.