In this NetApp training 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 videos (part 1 and part 2) and also text tutorial.
NetApp Multiprotocol Tutorial Part 1 – Video Tutorial
Just completed NetApp Storage training! I found the instructor Neil Anderson to be amazing. He’s extremely competent, has spent time in the industry, and knows the platform very well. He colors the materials with some real world examples, which is always helpful to understand the differences between doing something in the lab and doing it in the real world.
I manage several NetApp arrays, and found myself going to the real platform to see how we’ve implemented the concepts presented here. Very happy I picked up this course!
Security Style Options
There are four different security styles in NetApp ONTAP:
- Unified (used only on legacy 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.
Legacy 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 Video Tutorial
Part 1 covered the fundamentals of NetApp multiprotocol. Part 2 covers name mapping configuration and security style best practice.
NetApp Multiprotocol Name Mappings
Client access to NAS volumes on a NetApp storage system is controlled by either NTFS (Windows) or UNIX style permissions (different volumes on the same storage system can have different security styles.) If a Windows user wants to access data with UNIX style permissions then the Windows user account has to be mapped to a UNIX user account. And vice versa if a UNIX user wants to access data with Windows style permissions.
Name mappings are used to map the Windows user accounts to UNIX or vice versa. They can be configured either in the GUI or in the command line. In both cases we use regular expressions to configure the mappings.
Regular expressions (often known as ‘regex’) are used to match strings of characters and/or numbers. They're used regularly in lots of different areas in IT, like in IP telephony when configuring dial plan rules; and in firewalls and Intrusion Prevention Systems when looking for a string that would signify an attack. Regular expressions are very flexible when it comes to matching strings. This is the reason why we use them to configure the name mappings in NetApp multiprotocol.
Always specify the direction when configuring a mapping. The system needs to know whether it is for Windows user to UNIX user or the other way around. Then configure the string that you are looking for and what that stringed is going to be changed (mapped) to. Let’s go through it step-by-step using the below examples.
NetApp MultiProtocol Name Mapping Example 1A – Windows to UNIX
For our first example, we need to allow a Windows user to access some files and folders that have UNIX security style configured. The user will log into Windows as FLACKBOX\bob, and they should access the data as the UNIX user bobjones.
First we specify the text string we want to match on. Enter this in the ‘Pattern’ field in ONTAP System Manager:
Next, we specify the string which will replace that. Enter it in the ‘Replacement’ field in System Manager, and we’re done.
NetApp MultiProtocol Name Mapping Example 1B – UNIX to Windows
If the UNIX user bobjones will be accessing folders with NTFS security style as FLACKBOX\bob, then we need to configure a mapping in the opposite direction, from UNIX to Windows. The pattern we're looking for is bobjones and the replacement will be Flackbox\\bob.
NetApp MultiProtocol Name Mapping Example 2A – Windows to UNIX
Adding a separate mapping for every single user is not scalable, so for our second example, we’re going to map all Windows users in the FLACKBOX domain to a UNIX user with the same name (e.g. if the Windows username is FLACKBOX\bobjones, the UNIX username will also be bobjones – with the domain name stripped off).
The storage system will actually do this by default anyway, but I want to show you how you would configure the mapping rules here.
With just one name mapping we can configure a rule that will work for all of our users. We need to configure the pattern that we are looking for first. In this example, it’s FLACKBOX\ (the domain name) and then the username which could be anything.
The first part of the string we’re looking for is ‘FLACKBOX\’. Because the backslash is a wildcard in regex, we need to include another backslash before it to say ‘look for literally a backslash. The next character is not a wildcard’.
The first part looks like this: FLACKBOX\\ and it means look for FLACKBOX\
For the next part we need to match the username which could be anything. Since we want to match any random string, we use the dot ‘.’ regular expression wildcard which means any character (a-z,0-9). Then after the dot we add a plus ‘+’ sign which means one or more repetitions of the previous character.
This will match any string of any length following ‘FLACKBOX\’, as long as there is at least one character.
The second part looks like this: .+
When we put the two parts together, it looks this: FLACKBOX\\.+
There’s one more thing we need to do. Because we need to copy the 2nd part (the username) back into the replacement string, we need to highlight it. We do that by including it inside parentheses.
This is what the final pattern string looks like:
We copy the 2nd part of the matched pattern (.+) back into the replacement string. The way we do that is by specifying \1 as the replacement string. \1 means copy whatever is in the first set of parentheses in the pattern string here. (We only have one set of parentheses in this example, so \2 wouldn’t match anything.)
So if a Windows user was logged in as FLACKBOX\bobjones that would match the FLACKBOX\\(.+) pattern. ‘bobjones’ would be caught by the (.+) and because we've put that in parentheses, that is what is copied into a replacement field.
So FLACKBOX\bobjones is replaced with bobjones.
FLACKBOX\janesmith would be replaced with janesmith.
What we're doing is stripping off the domain portion of the username.
NetApp MultiProtocol Name Mapping Example 2B – UNIX to Windows
If the UNIX users will also be accessing folders with the NTFS security style, configure a mapping in the opposite direction. In the previous case we were looking for Windows users, stripping off the domain name and then using the resulting username as their UNIX username when they were accessing files and folders with a UNIX security style.
Here, we will be looking for any UNIX user and we're going to prefix their UNIX username with the Windows domain name when they access files and folders with an NTFS security style.
We will be using .+ as the pattern again since we are looking for a username that could be any string of text. And since we will be copying this into the replacement pattern, we will put the .+ inside parentheses.
On the replacement the string will start as FLACKBOX followed by two backslashes - we need to put two backslashes since we literally mean backslash (not the wildcard). Then we followed it with another backslash one to copy the pattern.
So it’s the Flackbox domain name: FLACKBOX
Followed by literally a backslash: \\
Followed by whatever is in the first set of parentheses in the original pattern: \1
This is how it looks:
So if the UNIX username is bobjones, that would be changed to FLACKBOX\bob jones.
If the UNIX username is janesmith, that would be changed to FLACKBOX\janesmith.
So that’s how you can map a Windows username to a matching UNIX username and vice versa.
As mentioned earlier above and in Part 1, if there’s no explicitly configured mapping to override it, the system will try matching usernames for multiprotocol access. So you don’t actually need to configure Example 2 as it is done by the system anyway. The last example was just used to show how to configure mappings and how regular expressions works.
Recommended Security Styles – Windows or UNIX Only
Lastly, we will talk about the recommended security styles. Basically, if you have data that will only be accessed by Windows clients, then set the security style to NTFS. And if you have data that will only be accessed by UNIX style clients, then set the security style to UNIX.
In other words, if you have data that will only be accessed by Windows clients, put it in a dedicated CIFS SVM, or put it in a mixed SVM and set the volume security style to NTFS. If you have data that will only be accessed by UNIX clients, put it in a dedicated NFS SVM, or put it in a mixed SVM and set the volume security style to UNIX.
This setup is typical in a real world deployments.
Recommended Security Styles – Mixed Volume Access
If you need both Windows and Linux clients to have access to the same data, then you will need to configure mixed volume access. Use ‘UNIX’ if the file system is managed by a UNIX administrator and most of the users are NFS clients. In that case, the data will sometimes be accessed by Windows clients, but the security style will always be UNIX.
Use ‘NTFS’ if the file system is managed by a Windows administrator and most of the users are SMB clients. In that case, it is sometimes being accessed by Linux clients, but the security style is always going to be NTFS.
Finally, use ‘mixed’ if the file system is managed by both UNIX and Windows administrators and users consist of a fairly even mix of both NFS and SMB clients. The security permission can be either style. It will be whichever client last set their permissions on that file or folder (as explained in Part 1).
With all three of the options, remember that you need to have multiprotocol configured correctly for all your clients for them to be able to access the data.
If the data in a particular volume or qtree is always going to be accessed by only Windows or UNIX style clients, then you don't need to worry about configuring multiprotocol. You just need to worry about your Export Policies and your standard UNIX or Windows file security.