In this NetApp training tutorial, I will cover CIFS and SMB on NetApp storage. Scroll down for the video and also text tutorial.
NetApp CIFS and SMB Storage Video Tutorial
NetApp CIFS SMB
The terms CIFS (Common Internet File System) and SMB (Server Message Block) are used interchangeably as meaning the same thing in most of the NetApp documentation, but they’re not exactly the same thing. SMB was developed by IBM, and CIFS is a particular implementation of SMB which was developed by Microsoft.
Most recent documentation from other sources refers to ‘SMB’, but many NetApp papers refer to ‘CIFS’, so I’ll use both terms in this post.
CIFS is a stateful protocol which maintains a session between client and server, with the server being the storage system.
A controller failover will break a CIFS session unless the Continuous Availability feature is used. That became available in SMB version 3.0 and is supported on Microsoft Hyper-V clients.
The other NAS protocol NFS (Network File System) does not maintain a session between the client and the server so it can natively handle failovers less disruptively.
SMB version 1.0, 2.x, and 3.0 support are enabled by default in ONTAP.
SMB version 2.0
Let’s talk about the different enhancements that came out with the different versions. SMB version 2.0 was released with Windows Vista. Improvements over version 1 include compounding of requests (meaning it can send multiple requests in the same message) and larger reads and writes. This results in less overhead and more efficient network use.
It also has file property and directory-property caching, and durable file handles so clients can open a file and still survive a temporary connection loss. It supports HMAC SHA-256 signing for enhanced security.
SMB version 2.1
SMB version 2.1 came out with Windows 7 and Windows Server 2008 R2. Improvements over version 2.0 include client opportunistic locks. Oplocks use client side caching, so the client can cache information from the server locally leading to better performance. It also supports larger Maximum Transmission Unit MTU sizes.
SMB version 3.0
SMB version 3.0 was released with Windows 8 and Windows Server 2012. The improvements include Continuous Availability where it can survive destructive events. This means it can survive failovers on NetApp storage systems.
It also supports persistent handles where it can survive a brief network outage without the need to construct a new session.
Remote Volume Shadow Services enables backup services like NetApp SnapManager to create application-consistent shadow copies.
The Witness Protocol gives faster failover by notifying servers when a node is unavailable without waiting for the SMB connection to time out.
ODX Copy Offload enables direct data transfers without transferring the data through the host computer. Let’s say that our NetApp storage system is in New York and we have Windows clients in Washington. If a client in Washington copied data from one folder to another on the NetApp system, that data would go from New York, down to the client in Washington, and then back up to the NetApp system in New York again. With ODX Copy Offload it doesn’t have to go over the WAN connection and then back up again. The copy happens locally in New York without traversing the WAN link. So this gives us faster copies and less bandwidth usage.
The last SMB 3.0 feature I’ll cover here is BranchCache version 2. This allows data to be cached in branch offices, either on a dedicated remote Windows server or distributed over remote Windows clients. Let’s say we’ve got that same situation with New York and Washington again, where we’ve got our NetApp system in New York and our clients in Washington. With BranchCache, we can put a Windows server in Washington and cache the data there. Whenever a client in Washington gets a file from the NetApp system in New York, it will be cached on the server in Washington. Then if another client goes to get the file, it can fetch it from the local server in Washington rather than having it to go over the Wide Area Network link to New York. This gives us better performance and reduced bandwidth usage.
SMB version 3.1
SMB version 3.1 was released with Windows 10 and Windows Server 2016. The main difference from previous versions are security enhancements.
NetApp NAS Implementation
NFS and CIFS are configured on a per Storage Virtual Machine (SVM) basis. NFS and CIFS are configured independently of each other. If you are running both, they can either be enabled on the same or separate SVMs. You can also run multiple instances of CIFS or NFS in separate SVMs.
Each SVM appears as a separate storage system to clients. The scope of a CIFS service is a Data SVM. If you have CIFS configured on multiple SVMs, each will have separate independent CIFS configurations. Each data SVM can have a single CIFS service. So if you want it to integrate with two different Active Directory domains, then you would use two different SVMs.
The SVM is joined to an Active Directory domain or we can use local user accounts on the NetApp system. Windows Workgroups are supported from ONTAP version 9. An external Active Directory domain is almost always used for scalability reasons.
The SVM can use local user accounts, NTLM or Kerberos, to authenticate users. NTLM is a legacy authentication method which was mainly used in Windows 2000 and earlier, however modern versions of Windows do still have backwards compatibility with it.
The Kerberos Time Issue
IMPORTANT: By default, Kerberos allows the clocks of participating hosts to be no more than 5 minutes apart. Active Directory uses Kerberos as its authentication method. This means that if the time on your client is more than 5 minutes out from the clock on the NetApp system, it’s not going to be able to access data. What you’ll get is a Permission Denied message which will look like the user has entered a wrong username or password. If the clocks are more than 5 minutes out, even if the user enters the correct credentials, they’re going to get that Permission Denied message. This can be very confusing if you’re troubleshooting. So the first thing to remember, when you’re doing a configuration or any kind of troubleshooting, is to make sure that the clocks on your Domain Controller and the NetApp system are set to the same time.
PCs in the domain will receive their time from the Domain Controller by default. It is highly recommended to use the Network Time Protocol NTP to make sure that your NetApp system and your Active Directory Domain Controllers have the same time.
Shares and Permissions
The SVM joins the domain and acts like a traditional Windows file server. Just like on a traditional Windows file server, clients must pass Share and Permissions security to access data. This is standard Windows access rights.
Shares and their security can be configured from the NetApp Command Line, from System Manager, or from Windows the Microsoft Management Console MMC.
The NetApp system will appear as a Member Server in the Windows Domain, so we can use our normal Windows Domain tools to configure it, such as the Windows MMC.
Folder and file permissions are managed via the MMC or Group Policy. Share Permissions can be managed from the NetApp system, Folder and File Permissions are managed from your Windows clients.
CIFS and Export Policies
NetApp Export Policies are mandatory for NFS Exports, but they do not apply to CIFS shares by default. They are optional and turned off by default.
Export Rules when enabled provide another layer of access security in addition to share and file access permissions. They work in addition to rather than replacing share and file access permissions. Export rules apply to the client machine’s IP address, not to the Windows user and group.
The command to enable Export Policies for CIFS is:
vserver cifs options modify -vserver vserver_name -is-exportpolicy-enabled true
This can be enabled or disabled at the SVM level.
Access Based Enumeration ABE
Share permissions can allow users to view the existence of shared folders or files even if they don’t have access to open them. This poses a security risk. Maybe we don’t want users seeing folders that they don’t have access to, because maybe just the name of that folder exposes sensitive information. Administrators can protect against this by using the Access Based Enumeration (ABE) option.
When ABE is enabled on a CIFS share, resources are not visible to users unless they have access permission to that resource. Say that we’ve got a volume called Volume 1 which includes the folders ‘Folder A’, ‘Folder B’, and ‘Folder Top Secret’. If ABE is not enabled, then everybody that has access to the volume will see all three folders, even if they have no rights to the Top Secret folder. If we do enable ABE then a normal user who has got access to Folder 1 and 2 will just see Folder 1 and 2. They won’t see that the Top Secret folder exists.
The command to enable this is:
vserver cifs share properties add –vserver vserver_name -share-name share_name –shareproperties access-based-enumeration
This can be enabled or disabled at the Share level, and is disabled by default.
Windows Home Directories
You can use Windows Home Directory functionality to automatically offer users a dynamic share to their home directory, without creating an individual share for each user. You configure a single share with a few parameters, and it automatically creates a separate share for each user to their home directory. This is very convenient as you are likely to have many users in your organisation.
You still create the folder for the user’s home directory, but using the NetApp home directory feature saves you having to individually configure a share for all of them. You specify the containing folder or folders which host the home folders, and then configure wildcards to match the format of the home folder names. The wildcards that you can use are:
- %w, which is the user’s Windows user name.
- %d, is the domain name.
- %u is the user’s mapped UNIX user name.
By far the most commonly used wildcard is %w.
When you set this up, a user’s home directory can be accessed only by that user and by Windows administrators by default. This is typically the desired configuration but can be changed if required.