This NetApp tutorial is the 2nd of a 2 part series on NetApp Multiprotocol configuration for CIFS and NFS NAS. NetApp Multiprotocol allows both Windows and UNIX based clients to access the same files and folders on the storage system. Scroll down for the video and also text tutorial.
NetApp Multiprotocol Tutorial Part 2 Video Tutorial
I have never seen any training course in Netapp the way Neil conducted this and the way he breaks down every concept is like watching a movie…I am feeling so motivated and pumped up to retain all this knowledge…thank you!
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.