Wednesday, May 15, 2013

MultiProtocol on NetApp storage system - Part 1

Ever wonder how to allocate same volume to both Windows and Unix environment on NetApp systems? Many of my colleagues and friends have questions on this and so I determined to write up a article on this, hope it makes good sense.

After the drive is mapped or an export is mounted users that request data access on the network must be authenticated by whatever method is configured, typically windows clients are authenticated in a windows domain or very less frequently by the workstation. Unix users are authenticated by system or kerberos (network-based authentication).

Unix: NFS being connection less protocol, after the export is mounted and to request access of data a user needs to be authenticated to determine the user ID (UID) and group IDs (GIDs) and secondar/auxiliary GID's when user first logs in. This mapping information is retrieved from /etc/passwd and /etc/groups, network information system (NIS), or LDAP identity store.

Windows: CIFS being a session based protocol, the identity of the user can be determined just once when the session is first setup by mapping a drive. Data ONTAP always maps the user's windows identity to the user's UNIX identity during a CIFS session setup process.

Data ONTAP does not map the user's UNIX identity to the users windows identity during the UNIX/NFS authentication process. It only maps the user's UNIX identity to the user's Windows identity when a UNIX user tried to access files/folders with an effective windows NT ACL.

Points to Note:
1. UNIX export rules are host-based; Windows share permissions and NTFS Windows ACLs are both user based.

2. CIFS share ACLs can be managed through the Windows Computer Management snap-in or through the cifs access command.

3. Export options are set on the storage system with the /etc/exports file. Export options apply to the host; however, the effective permissions for the user are based on the combined export and file access controls.

Data ONTAP Security Styles:
Every volume and qtree is given a default security style at creation time. The default security style is set with the option options wafl.default_security_style [unix | ntfs | mixed] (default: unix).

Note: NEVER USE MIXED-MODE unless you determined to do so!

UNIX security style. For the UNIX security style, authorization to access directories and files is based on access allowed to the user’s UNIX UID and GIDs, with access rules following the UNIX style of file permissions through mode bits (rwxrwxrwx) or through NFSv4 ACL.

Windows security style. For the Windows security style, authorization to access folders and files is based on access allowed to the user’s Windows security identifier (SID) and Windows group SIDs, with access rules based on NTFS Windows security descriptors.

User mapping between a Windows user and a UNIX user is a fundamental part of NetApp multiprotocol access. Multiprotocol access depends on user mapping between a user’s UNIX identity and Windows identity to evaluate the user’s rights to perform file and folder operations within volumes and qtrees.

If a user accesses data in a UNIX volume through CIFS, Data ONTAP first maps the Windows user name to its corresponding UNIX UID. If there is no corresponding UNIX user, by default the Windows user is mapped to the default UNIX user. The default user is designated with the following storage system option: options wafl.default_unix_user user_name (default: pcuser)

The designated default UNIX user may be any valid UNIX user designated by the storage administrator, but the default user must exist in the storage system’s /etc/passwd file, the NIS database, or the LDAP database. If this option is set to the null string, Windows users who are not mapped to a UNIX user are not allowed to log in. Therefore, if this option is set to the null string, it is vital that each Windows user can map successfully to a specific UNIX user.

If a CIFS user accesses NTFS security style files or folders with Windows ACLs, the SIDs of the CIFS user and groups are used to determine NTFS access rights. The user and group SIDs are compared to the file’s Windows security descriptor.

If a UNIX user accesses files and folders with Windows ACLs in an NTFS qtree, Data ONTAP maps the UNIX user to the Windows user based on the user mapping policy. Upon failed identity mapping, Data ONTAP rejects the access request. Upon successful mapping, Data ONTAP grants access based on the user’s mapped Windows user. The user’s Windows user SID and Windows group SIDs are used to determine NTFS access rights.

By default, if there is no corresponding Windows user, access is denied to the NTFS qtree from a UNIX host. This is because the option that is used to configure a generic Windows account is, by default, set to null.

wafl.default_nt_user is a storage system option that can be used to allow mapping of Windows users with no corresponding UNIX account to a generic Windows account. The default for this option is null. To enable access from a default user, add a valid Windows account to this option:

options wafl.default_nt_user corp\ntuser

MultiProtocol Access and Group Mapping:
Data ONTAP user mapping maps user names. It does not map groups. Due to the fundamentally different way that Windows groups and UNIX groups are configured, it is not possible to perform a consistent, exact, and simple mapping between UNIX groups and Windows groups. However, because group membership is critically important when determining file access, as part of the mapping process the mapped user’s group membership is retrieved and cached along with the user mapping information.

After performing UNIX-to-Windows user mapping, the results, including group membership for both the UNIX user and the Windows user, are stored in the storage system’s WAFL credential cache (wcc).

Windows-user-to-UNIX-user mapping is not stored in the wcc. Instead, with Windows-to-UNIX-user mapping, the UNIX user information is kept as part of the CIFS session credential. A fresh Windows-to-UNIX user mapping is needed only when a new CIFS session is established for that user

By default, the information is cached for 20 minutes. The cache time can be increased as follows:

options wafl.wcc_minutes_valid minutes (Valid range is 1 through 20,160.)

Please click here for more on this 
Post a Comment
Read more: