Configuring Optimization Features : Configuring CIFS optimization : Optimizing SMB2/3
  
Optimizing SMB2/3
This section describes the SMB support changes with recent versions of RiOS.
Delegation mode signing is deprecated in SteelHead. Use NTLM Transparent Mode on the SteelHead for SMB optimization.
SMB3 support
Enabling SMB3 on a SteelHead also enables support for SMB 3.1.1 to accelerate file sharing among Windows 10 clients to Windows Server 16 or Windows VNext (server). RiOS supports latency and bandwidth optimization for SMB 3.1.1 when SMB2/3 and SMB2 signing is enabled and configured. SMB 3.1.1 adds these encryption and security improvements:
Encryption—The SMB 3.1.1 encryption ciphers are negotiated per-connection through the negotiate context. Windows 10 now supports the AES-128-CCM cipher in addition to AES-128-GCM for encryption. SMB 3.1.1 can negotiate to AES-128-CCM to support older configurations.
Encryption requires that SMB2 signing is enabled on the server-side SteelHead in NTLM-transparent (preferred) mode, and/or end-to-end Kerberos mode. Domain authentication service accounts must be configured replication as needed.
Preauthentication Integrity—Provides integrity checks for negotiate and session setup phases. The client and server maintain a running hash on all of the messages received until there’s a final session setup response. The hash is used as input to the key derivation function (KDF) for deriving the session secret keys.
Extensible Negotiation—Detects man-in-the-middle attempts to downgrade the SMB2/3 protocol dialect or capabilities that the SMB client and server negotiate. SMB 3.1.1 dialect extends negotiate request/response through negotiate context to negotiate complex connection capabilities such as the preauthentication hash algorithms and the encryption algorithm.
The server-side SteelHeads must be joined to the domain in Active Directory Integrated Windows 2008 or later.
With the exception of service accounts configuration, you can complete all of the above settings on the server-side SteelHead by using the Configure Domain Auth widget. See Easy domain authentication configuration.
Enabling SMB3 on a SteelHead also enables support for the SMB 3.02 dialect introduced by Microsoft in Windows 8.1 and Windows Server 2012 R2. SMB 3.02 is only negotiated when systems of these operating system versions are directly connected. SMB 3.02 is qualified with SMB3.02 signed and unsigned traffic over IPv4 and IPv6, and encrypted connections over IPv4 and IPv6. Authenticated connections between a server-side SteelHead and a domain controller are only supported over IPv4.
SteelHead supports SMB3 traffic latency and bandwidth optimization for native SMB3 clients and servers.
Windows 8 clients and Windows 2012 servers feature SMB3, an upgrade to the CIFS communication protocol. SMB3 adds features for greater resiliency, scalability, and improved security. SMB3 supports these features:
Encryption—If the server and client negotiate SMB3 and the server is configured for encryption, all SMB3 packets following the session setup are encrypted on the wire, except for when share-level encryption is configured. Share-level encryption marks a specific share on the server as being encrypted; if a client opens a connection to the server and tries to access the share, the system encrypts the data that goes to that share. The system doesn’t encrypt the data that goes to other shares on the same server.
Encryption requires that you enable SMB signing.
New Signing Algorithm—SMB3 uses the AES-CMAC algorithm instead of the HMAC-SHA256 algorithm used by SMB2 and enables signing by default.
Secure Dialect Negotiation—Detects man-in-the-middle attempts to downgrade the SMB2/3 protocol dialect or capabilities that the SMB client and server negotiate. Secure dialect negotiation is enabled by default in Windows 8 and Server 2012. You can use secure dialect negotiation with SMB2 when you are setting up a connection to a server running Server 2008-R2.
SMB 3.0 dialect introduces these enhancements:
Allows an SMB client to retrieve hashes for a particular region of a file for use in branch cache retrieval, as specified in [MS-PCCRC] section 2.4.
Allows an SMB client to obtain a lease on a directory.
Encrypts traffic between the SMB client and server on a per-share basis.
Uses remote direct memory access (RDMA) transports, when the appropriate hardware and network are available.
Enhances failover between the SMB client and server, including optional handle persistence.
Allows an SMB client to bind a session to multiple connections to the server. The system can send a request through any channel associated with the session, and sends the corresponding response through the same channel previously used by the request.
To optimize signed SMB3 traffic, you must run RiOS 8.5 or later and enable SMB3 optimization on the client-side and server-side SteelHeads.
For additional details on SMB 3.0 specifications, go to
http://msdn.microsoft.com/en-us/library/cc246482.aspx
SMB2 support
RiOS supports for SMB2 traffic latency optimization for native SMB2 clients and servers. SMB2 allows more efficient access across disparate networks. It is the default mode of communication between Windows Vista and Windows Server 2008. Microsoft modified SMB2 again (to SMB 2.1) for Windows 7 and Windows Server 2008 R2.
SMB2 brought a number of improvements, including but not limited to:
a vastly reduced set of opcodes (a total of only 18); in contrast, SMB1 has over 70 separate opcodes. Note that use of SMB2 doesn’t result in lost functionality (most of the SMB1 opcodes were redundant).
general mechanisms for data pipelining and lease-based flow control.
request compounding, which allows multiple SMB requests to be sent as a single network request.
larger reads and writes, which provide for more efficient use of networks with high latency.
caching of folder and file properties, where clients keep local copies of folders and files.
improved scalability for file sharing (number of users, shares, and open files per server greatly increased).
To display optimization settings for SMB2 and SMB3
1. Choose Optimization > Protocols: SMB2/3 to display the SMB2/3 page.
SMB2/3 page
2. Under Optimization, complete the configuration on both the client-side and server-side SteelHeads as described in this table.
Control
Description
None
Disables SMB2 and SMB3 optimization.
Enable SMB2 Optimization
Performs SMB2 latency optimization in addition to the existing bandwidth optimization features. These optimizations include cross-connection caching, read-ahead, write-behind, and batch prediction among several other techniques to ensure low-latency transfers. RiOS maintains the data integrity, and the client always receives data directly from the servers.
By default, SMB2 optimization is disabled.
You must enable (or disable) SMB2 latency optimization on both the client-side and server-side SteelHeads.
After enabling SMB2 optimization, you must restart the optimization service.
Enable SMB3 Optimization
Performs SMB3 latency optimization in addition to the existing bandwidth optimization features. This optimization includes cross-connection caching, read-ahead, write-behind, and batch prediction among several other techniques to ensure low-latency transfers. RiOS maintains the data integrity and the client always receives data directly from the servers.
By default, SMB3 optimization is disabled.
You must enable (or disable) SMB3 latency optimization on both the client-side and server-side SteelHeads.
You must enable SMB2 optimization to optimize SMB3.
To enable SMB3, both SteelHeads must be running RiOS 8.5 or later. After enabling SMB3 optimization, you must restart the optimization service.
Enable DFS Optimization
Enables optimization for Distributed File System (DFS) file shares.
You must upgrade both your server-side and client-side SteelHeads to RiOS 9.5 or later to enable DFS optimization. However, this box only needs to be checked on the client-side SteelHead.
3. Under Down Negotiation, complete the configuration on the client-side SteelHead as described in this table.
Control
Description
None
Don’t attempt to negotiate the CIFS session down to SMB1.
SMB2 and SMB3 to SMB1
Enable this control on the client-side SteelHead. Optimizes connections that are successfully negotiated down to SMB1 according to the settings on the Optimization > Protocols: CIFS (SMB1) page.
RiOS bypasses down-negotiation to SMB1 when the client or the server is configured to use only SMB2/3 or the client has already established an SMB2/3 connection with the server. If the client already has a connection with the server, you must restart the client.
Down-negotiation can fail if the client only supports SMB2 or if it bypasses negotiation because the system determines that the server supports SMB2. When down-negotiation fails, bandwidth optimization is not affected. .
4. Click Apply to apply your settings to the current configuration.
5. If you have enabled or disabled SMB1, SMB2, or SMB3 optimization, you must restart the optimization service.
For appliances with feature-tier licensing, you can configure and enable CIFS SMB2/3 optimization even if the feature is not licensed; however, the feature needs to be both enabled and licensed to work. If the feature is not licensed, the interface displays an alert. For more information, see Feature-tier licensing.
Related topics
Configuring CIFS prepopulation
Enabling SMB signing
Configuring SMB signing
You display and modify SMB signing settings in the Optimization > Protocols: CIFS (SMB1) and (SMB2/3) pages.
When sharing files, Windows provides the ability to sign CIFS messages to prevent man-in-the-middle attacks. Each CIFS message has a unique signature that prevents the message from being tampered with. This security feature is called SMB signing.
You can enable the RiOS SMB signing feature on a server-side SteelHead to alleviate latency in file access with CIFS acceleration while maintaining message security signatures. With SMB signing on, the SteelHead optimizes CIFS traffic by providing bandwidth optimizations (SDR and LZ), TCP optimizations, and CIFS latency optimizations—even when the CIFS messages are signed.
RiOS 8.5 and later include support for optimizing SMB3-signed traffic for native SMB3 clients and servers. You must enable SMB3 signing if the client or server uses any of these settings:
SMB2/SMB3 signing set to required. SMB3 signing is enabled by default.
SMB3 secure dialect negotiation (enabled by default on the Windows 8 client).
SMB3 encryption.
SteelHeads include support for optimizing SMB2-signed traffic for native SMB2 clients and servers. SMB2 signing support includes:
Windows domain integration, including domain join and domain-level support.
Secure inner-channel SSL support. For details, see Configuring secure peers.
Domain security
The RiOS SMB signing feature works with Windows domain security and is fully compliant with the Microsoft SMB signing version 1, version 2, and version 3 protocols. RiOS supports domain security in both native and mixed modes for:
Windows 2000
Windows 2003 R2
Windows 2008
Windows 2008 R2
The server-side SteelHead in the path of the signed CIFS traffic becomes part of the Windows trust domain. The Windows domain is either the same as the domain of the user or has a trust relationship with the domain of the user. The trust relationship can be either a parent-child relationship or an unrelated trust relationship.
RiOS optimizes signed CIFS traffic even when the logged-in user or client machine and the target server belong to different domains, provided these domains have a trust relationship with the domain the SteelHead has joined. The trust relationships include:
a basic parent and child domain relationship. Users from the child domain access CIFS/MAPI servers in the parent domain. For example, users in ENG.RVBD.COM accessing servers in RVBD.COM.
a grandparent and child domain relationship. Users from grandparent domain access resources in the child domain. For example, users from RVBD.COM accessing resources in DEV.ENG.RVBD.COM.
a sibling domain relationship. For example, users from ENG.RVBD.COM access resources in MARKETING.RVBD.COM.
Authentication
The process RiOS uses to authenticate domain users depends upon its version.
RiOS features these authentication modes:
NTLM transparent mode—Uses NTLM authentication end to end between the client-side and server-side SteelHeads and the server-side SteelHead and the server. This is the default mode for SMB1 and SMB2/3 signing starting with RiOS 9.6. Transparent mode supports all Windows clients and servers, including Windows 2008 R2, that have NTLM enabled. We recommend using this mode.
Kerberos authentication support mode—Uses Kerberos authentication end to end between the client-side and server-side SteelHead and the server-side SteelHead and the server. Kerberos authentication requires additional configuration of Windows domain authentication.
Transparent mode doesn’t support the following configurations; instead, use Kerberos authentication support mode:
Windows 2008 R2 domains that have NTLM disabled.
Windows servers that are in domains with NTLM disabled.
Windows 7 clients that have NTLM disabled.
You can enable extra security using the secure inner channel. The peer SteelHeads using the secure channel encrypt signed CIFS traffic over the WAN. For details, see Configuring secure peers.
SMB signing prerequisites and recommendations
This section describes prerequisites and recommendations for using SMB signing.
With RiOS Server Message Block (SMB) signing enabled, SteelHeads sign the traffic between the client and the client-side SteelHead and between the server and the server-side SteelHead. The traffic isn’t signed between the SteelHeads, but the SteelHeads implement their own integrity mechanisms. Whether SteelHeads are used or not, SMB-signed traffic is only signed, not encrypted. For maximum security, we recommend that you configure the SteelHeads as SSL peers and use the secure inner channel to secure the traffic between them. For details, see Configuring secure peers.
If you already have a delegate user and are joined to a domain, enabling SMB2 signing will work when enabled with no additional configuration.
SMB signing requires joining a Windows domain. It is vital to set the correct time zone for joining a domain. The most common reason for failing to join a domain is a significant difference in the system time on the Windows domain controller and the SteelHead. When the time on the domain controller and the SteelHead don’t match, this error message appears:
lt-kinit: krb5_get_init_creds: Clock skew too great
We recommend using Network Time Protocol (NTP) time synchronization to synchronize the client and server clocks. It is critical that the SteelHead time is the same as on the Active Directory controller. Sometimes an NTP server is down or inaccessible, in which case there can be a time difference. You can also disable NTP if it isn’t being used and manually set the time. You must also verify that the time zone is correct. For details, see Configuring the date and time. For more troubleshooting, see Troubleshooting a domain join failure.
Both the client and the server must support SMB2 and SMB3 to use RiOS SMB2 and SMB3 signing.
Verifying the domain functional level and host settings
This section describes how to verify the domain and DNS settings before joining the Windows domain and enabling SMB signing.
To verify the domain functional level (replication users)
1. If you are configuring replication users, verify that the Windows domain functionality is at the Windows 2003 level or higher. In Windows, open Active Directory Users and Computers on the domain controller, choose Domain Name, right-click, and select Raise Domain functionality level. If the domain isn’t already at the Windows 2003 level or higher, manually raise the domain functionality.
If replication users are configured to use password replication policy (PRP), the domain functional level must be Windows 2008 or higher. See Enabling SMB signing. For details about replication users, see Configuring replication users (Kerberos).
After you raise the domain level, you can’t lower it.
Verifying the domain level before enabling SMB signing
2. Identify the full domain name, which must be the same as DNS. You must specify this name when you join the server-side SteelHead to the domain.
3. Identify the short (NetBIOS) domain name by pressing Ctrl+Alt+Delete on any member server. You must explicitly specify the short domain name when the SteelHead joins the domain if it doesn’t match the far left portion of the fully qualified domain name.
4. Make sure that the primary or auxiliary interface for the server-side SteelHead is routable to the DNS and the domain controller.
5. Verify the DNS settings.
You must be able to ping the server-side SteelHead, by name, from a CIFS server joined to the same domain that the server-side SteelHead joins. If you can’t, you must manually create an entry in the DNS server for the server-side SteelHead and perform a DNS replication prior to joining the Windows domain. The SteelHead doesn’t automatically register the required DNS entry with the Windows domain controller.
You must be able to ping the domain controller, by name, whose domain the server-side SteelHead joins. If you can’t, choose Networking > Networking: Host Settings to configure the DNS settings.
Verifying the DNS settings for SMB signing
For details, see Modifying general host settings.
The next step is to join a Windows domain.
To join a Windows domain
Choose Optimization > Active Directory: Auto Config on the server-side SteelHead and join the domain.
Auto Config page
For details, see Easy domain authentication configuration. After you have joined the domain, the next step is to enable SMB signing.
Enabling SMB signing
After you have joined a Windows domain, you can enable SMB signing.
When SMB signing is set to Enabled for both the client-side and server-side SMB component (but not set to Required), and the RiOS Optimize Connections with Security Signatures feature is enabled, it takes priority and prevents SMB signing. You can resolve this by disabling the Optimize Connections with Security Signatures feature and restarting the SteelHead before enabling this feature.
The RiOS Optimize Connections with Security Signatures feature can lead to unintended consequences when SMB signing is required on the client but set to Enabled on the server. With this feature enabled, the client concludes that the server doesn’t support signing and might terminate the connection with the server as a result. You can prevent this condition by performing one of these actions before enabling this feature:
Uncheck the Optimize Connections with Security Signatures check box in the Optimization > Protocols: CIFS (SMB1) page, then restart the SteelHead.
Apply a Microsoft Service pack update to the clients (recommended). You can download the update from the Microsoft Download Center:
http://support.microsoft.com/kb/916846
To enable SMB1 signing
1. On the server-side SteelHead, choose Optimization > Protocols: CIFS (SMB1) to display the CIFS (SMB1) page.
CIFS SMB1 page
2. Under SMB Signing, complete the configuration as described in this table.
Control
Description
Enable SMB Signing
Enables CIFS traffic optimization by providing bandwidth optimizations (SDR and LZ), TCP optimizations, and CIFS latency optimizations, even when the CIFS messages are signed. By default, this control is disabled. You must enable this control on the server-side SteelHead.
If you enable this control without first joining a Windows domain, a message tells you that the SteelHead must join a domain before it can support SMB signing.
NTLM Transparent Mode
Provides SMB1 signing with transparent authentication. The server-side SteelHead uses NTLM to authenticate users. We recommend using this mode for the simplest configuration. Transparent mode is the default for RiOS 9.6 and later.
Enable Kerberos Authentication Support
Provides SMB signing with end-to-end authentication using Kerberos. The server-side SteelHead uses Kerberos to authenticate users.
In addition to enabling this feature, you must also join the server-side SteelHead to a Windows domain and add replication users on the Optimization > Active Directory: Auto Config page.
No configuration is needed on the client-side SteelHead.
If you want to use password replication policy (PRP) with replication users, Kerberos authentication requires additional replication user configuration on the Windows 2008 Domain Controller.
3. Click Apply to apply your settings to the running configuration.
4. Click Save to Disk to save your settings permanently.
To enable SMB2/3 signing
1. On the server-side SteelHead, choose Optimization > Protocols: SMB2/3 to display the SMB2/3 page.
CIFS page for SMB2/3 signing
2. Under Signing, complete the configuration as described in this table.
Control
Description
Enable SMB2 and SMB3 Signing
Enables SMB2/3 traffic optimization by providing bandwidth optimizations (SDR and LZ), TCP optimizations, and SMB2/3 latency optimizations, even when the SMB2/3 messages are signed. By default, this control is disabled. You must enable this control on the server-side SteelHead.
If you are upgrading and already have a delegate user, and the SteelHead is already joined to a domain, enabling SMB2/3 signing works when enabled with no additional configuration.
If you enable this control without first joining a Windows domain, a message tells you that the SteelHead must join a domain before it can support SMB2/3 signing.
You must enable SMB2/3 latency optimization before enabling SMB2/3 signing. To enable SMB2/3 latency optimization, choose Optimization > Protocols: SMB2/3.
NTLM Transparent Mode
Provides SMB2/3 signing with transparent authentication. The server-side SteelHead uses NTLM to authenticate users. We recommend using this mode for the simplest configuration. Transparent mode is the default for RiOS 9.6 and later.
Enable Kerberos Authentication Support
Provides SMB2/3 signing with end-to-end authentication using Kerberos. The server-side SteelHead uses Kerberos to authenticate users.
In addition to enabling this feature, you must also join the server-side SteelHead to a Windows domain and add replication users:
1. Choose Optimization > Active Directory: Domain Join to join the server-side SteelHead to a Windows domain.
2. Choose Optimization > Active Directory: Auto Config.
3. Choose Configure Replication Account to add the replication users.
For SMB3, the server-side SteelHead must be running RiOS 8.5 or later.
No configuration is needed on the client-side SteelHead.
If you want to use password replication policy (PRP) with replication users, Kerberos authentication requires additional replication user configuration on the Windows 2008 domain controller.
3. Click Apply to apply your settings to the running configuration.
4. Click Save to Disk to save your settings permanently.
5. If you enable or disable SMB2 or SMB3, you must restart the optimization service. For details, see Starting and stopping the optimization service.
Related topics
Configuring CIFS prepopulation
Viewing SnapMirror connections
Adding QoS profiles
Viewing Connection History reports
Encrypting SMB3
If the SMB server and client negotiate SMB3 and the server is configured for encryption, you can configure share-level encryption. Share-level encryption marks a specific share on the server as encrypted so that if a client opens a connection to the server and tries to access the share, RiOS encrypts the data that goes to that share. RiOS doesn’t encrypt the data that goes to other shares on the same server.
RiOS 9.5 and later support the SMB 3.1.1 dialect when SMB3 is enabled. RiOS 9.0 and later support the SMB 3.0.2 dialect when SMB3 is enabled.
To encrypt SMB3 traffic
1. Choose Optimization > Active Directory: Domain Join on the server-side SteelHead and join the domain.
2. Choose Optimization > Protocols: SMB2/3 and enable SMB3 optimization on the client-side and server-side SteelHead.
3. Enable SMB2/3 signing on the server-side SteelHead.
4. Restart the optimization service.
Viewing SMB traffic on the Current Connections report
The Current Connections report displays the SMB traffic using these labels:
SMB 2.0 and SMB 2.0.2 connections show as SMB20 or SMB21-SIGNED.
SMB 2.1 connections show as SMB21 or SMB21-SIGNED.
SMB 3.0 and SMB 3.0.2 connections show as SMB30 if there are protocol errors, or SMB30-ENCRYPTED or SMB30-SIGNED.
SMB 3.1.1 connections show as SMB31 if there are protocol errors, or SMB31-ENCRYPTED or SMB31-SIGNED.
When some shares are marked for encryption and others aren’t, if a connection accesses both encrypted and nonencrypted shares, the report shows the connection as SMB30-ENCRYPTED or SMB31-ENCRYPTED.
All unsupported SMB dialects show as SMB-UNSUPPORTED.
For details, see Viewing Connection History reports.