UNIX host to access data with NTFS security style using NFS

Step:1 User login from the UNIX host, the host requests user and group information for the user from the name services configured in the /etc/nsswitch.conf file. The data can be retrieved from local files, an NIS server, or an LDAP server.

Step:2 The configured name service returns user and group information to the UNIX host.
All user information needed to log in, including UID, GID, and the user shell and home directory, is returned. Additionally, the user’s secondary group GIDs are returned.



Step:3 Using the user information retrieved from the identity store, the user is authenticated and allowed access to the UNIX host. The user and group information retrieved in step 1 is cached and used to determine access rights to local and remote resources.

Step:4 The user requests access to a mounted NetApp file system.

The storage system checks export options at the time the file system is mounted. Export options might affect the user’s ability to perform a requested action.

Step:5 The user requests access to data on the storage system that uses NTFS-style permissions, but the request contains UNIX-style UID and GIDs.

The storage system cannot use the UID and GIDs sent in the access request for the access check. Instead, the storage system must compare Windows user and group information to the file’s Window ACL to determine access for the user. Therefore, the storage system maps the UNIX user to the corresponding Windows user.

Step:6 The system queries the configured UNIX identity store, supplying the user’s UID, and requests the user name.

When the user requests access from a UNIX host, the request contains the user’s UID but does not contain the user name. After mapping is done by user name, the system must determine the UNIX user name before the mapping process can proceed.

Step:7 The UNIX name service returns the name of the UNIX user to the storage system.

Step:8 The storage system uses the UNIX user name to begin the user mapping process.
The storage system checks /etc/usermap.cfg and the LDAP user mapping entries, if configured, to see if there is a specific mapping entry for the UNIX user.

If there is a specific mapping entry, the storage system uses this entry for the user mapping process.

If there is not a specific mapping entry, the storage system assumes that the Windows user name is the same as the UNIX user name and automatically uses this name during the mapping process.

Step:9 The storage system queries Active Directory to determine if the mapped user name is a valid Windows user.

If the user name is a valid Windows user, the mapping process continues.

If the user name is not a valid Windows user, the user is either mapped to the generic NT user or access is denied, depending on how the wafl option wafl.default_nt_user is configured.

Step:10 Active Directory replies to the query, either supplying information on the user or returning an error indicating that the user was not found.

Step:11 The storage system queries Active Directory for the mapped Windows user’s SIDs (user SID and all group SIDs).

Step:12 Active Directory replies to the query, supplying information on the user, including the user’s SIDs.

Step:13 The storage system uses the user’s SIDs and compares them to the ACLs of files and directories for which access has been requested.

The system then determines whether the desired action is allowed.

Step:14 The system replies to the access request, either permitting the requested action if the file permissions allow it or denying the action if the permissions do not allow it.