In this NetApp tutorial, I will cover NetApp Multiprotocol configuration for CIFS and NFS NAS. NetApp Multiprotocol allows both Windows and UNIX based clients to access the same files and folders. Scroll down for the video and also text tutorial.
NetApp Multiprotocol Tutorial Part 1 – Video Tutorial
I bought your course and think it is outstanding, exactly what I needed. I was able to stand up a pair of NetApp FAS systems with your content.
Here in Part 1 I'll cover the fundamentals of NetApp multiprotocol. Part 2 covers name mapping configuration and security style best practice.
Security Style Options
There are four different security styles in NetApp ONTAP:
- Unified (used only on infinite volumes)
We specify the security style when we configure a volume. Different volumes on the same storage system can have different security styles.
Security styles can be set at the volume and at the qtree level. By default, qtrees will inherit the security style of their containing volume. For example, if you create volume-1 with the NTFS security style and add qtree-1 to the volume, qtree-1 will also have the NTFS security style by default. You can override the volume’s security style at the qtree level though – you could configure qtree-1 with the UNIX security style.
Infinite volumes always use the unified security style and you can't configure or change their security style.
Security Style Operation
Security styles determine the types of permissions that ONTAP uses to control data access and what client type can modify those permissions. The security styles do NOT determine what client types can or cannot access data.
Windows and UNIX clients can both access volumes with any security style as long as they're allowed to by the authentication and authorization settings. UNIX users can access volumes with NTFS style permissions while Windows users can access volumes with UNIX style permissions, as long as multiprotocol is configured correctly.
If the security style is set to UNIX, UNIX permissions are always used on the files and folders in that volume or qtree. You can’t set NTFS permissions on a volume that has the UNIX style.
If the security style is set to NTFS, then NTFS permissions are always used.
If the security style is set to mixed or unified, then either permission style can be used on directories and files. Whichever type of client last modified the permissions that will be the style used.
For example, if a user on a Windows PC created a file in a Mixed security style volume and set permissions on it, then that file will have Windows style permissions. Then if a user on a Linux platform opens the same file, edits and changes the permissions, then that file will now have UNIX-based permissions.
The file doesn’t have both Windows and UNIX style permissions at the same time, it’s one or the other.
Security Style Defaults
UNIX style permissions are used by default on all data in ‘UNIX’, ‘Mixed’ and ‘Unified’ security style volumes. The default permissions are UNIX mode bits 0755. Meaning ‘owner’ gets read/write execute, the ‘group’ gets read and execute, and ‘other’ also gets read and execute.
By default, the effective security style on all data in NTFS security style volumes is (not surprisingly) NTFS. A Windows ACL allowing Full Control to Everyone is applied by default.
You can of course change the permissions on the files and folders in the volume for tighter security.
Data Access from Windows Hosts
If a Windows user tries to access an NTFS security style volume or qtree, it will be tested against NTFS security style ACLs as standard. If a Windows user tries to access a UNIX security style volume or qtree, their Windows username must be mapped to a UNIX UID because a UNIX security style volume will not understand its Windows username.
Data Access from UNIX Hosts
If a UNIX user tries to access a UNIX security style volume or qtree, it will be tested against the UNIX file permissions as standard. If a UNIX user tries to access an NTFS security style volume or qtree, its UNIX user and group must be mapped to a Windows user.
Let’s refer to the above flowchart to see how the authentication of Windows users works. Windows users can either be authenticated by an Active Directory Domain Controller, or by local user accounts on the NetApp storage system. They will be authenticated if they've entered a valid username and password. In the real world Active Directory integrations are used far more often than local user accounts because they're a lot more scalable and convenient.
The flowchart above shows what happens when a user is successfully authenticated.
The NetApp administrator can configure a manual mapping from a Windows user to a UNIX user. For example, you could map the Windows username ‘Joe Bloggs’ to a UNIX user ‘JBLoggs’. If a mapping exists the storage system will check to see if the UNIX user has access to the data.
If a Windows user is explicitly mapped to a null string by the NetApp administrator in the mapping rules, they will be regarded as an invalid user (see the next slide below for what happens with invalid users).
If there's no manual mapping for the Windows username in the mapping rules, then the system will try to access the data using a matching UNIX user. Meaning, if the Windows username is ‘JoeBloggs’, it will check to see if there's a matching UNIX user also named ‘JoeBloggs’, and see if that user has access to the data.
The UNIX user will be verified by ‘files’ (local authentication), NIS, or LDAP.
If the user is not verified, the system will check to see if the rule that says that ‘Windows Domain Admin accounts are mapped to UNIX root’ is enabled. This option is enabled by default which means that if the Windows username does NOT match any of the configured mapping rules AND there's no UNIX user with the same name as the Windows user AND if the Windows username is a Windows Domain Admin, they will be mapped to the UNIX root user.
If there's no administrator defined mapping AND their Windows username is not the same as a valid UNIX username with access AND they're not a Windows Domain Admin or the Domain Admin is mapped to root option is turned off, then they will be assigned the default UNIX account. Just like the Domain Admins being mapped to root option, this is also enabled by default. The default UNIX user is "pcuser" with the UID and GID 65534.
Next, let's consider what happens with Windows unauthenticated or invalid users who are trying to access data in a volume or qtree with a UNIX security style. First, the system checks to see if the guest account has been configured. If not (it is disabled by default) then they will be rejected.
If the guest account has been configured, the system will try the UID that is set as the guest account. The guest account will be verified by files, NIS, or LDAP. Depending on the result, the user will either get access to the data or be rejected.
Data Access from UNIX Hosts
That covers the Windows to UNIX mapping. Next, let's see what happens in the other direction with UNIX to Windows mapping. When a UNIX client accesses a NetApp storage system, the storage system receives the UID and the GID. The storage system resolves the UID to the UNIX username by files, NIS, or LDAP. It will be either a success or failure depending on if there’s a matching user and password. If the credentials are valid then the system checks the mapping rules.
The storage system will first check if an administrator has explicitly mapped the UNIX user to a Windows user.
If a mapping does exist, for example, the UNIX user JoeBloggs to the Windows user JBLoggs, then the system will check to see if JBloggs has permission to access the data.
If the UNIX user is mapped to a null string then they're considered as an invalid user.
If there's no manual mapping for the UNIX user in the mapping rules, then the system will try to access the data using a matching Windows username. Meaning, if the UNIX user is ‘JoeBloggs’, it will check to see if there's a matching Windows username also named ‘JoeBloggs’, and see if that user has access to the data.
The Windows user is verified by the local storage system user database or by a Windows Domain Controller. If the client is mapped to a valid Windows username with permissions to access the data, then they will be accepted.
If they're not verified, then we can use a default Windows account and see if that Windows account has access to the data. The default Windows account is a null string which basically means that the feature is disabled by default. You can optionally set a valid Windows username as the default account that UNIX users will be mapped to if they don't match a more specific mapping.
What happens to the failed UID to UNIX username or to an invalid user is very simple - they'll be rejected and won’t have access to the data.
NetApp Multiprotocol Tutorial Part 2
Best practice and how to configure the name mappings will be covered in the upcoming Part 2.