Signed SMB and encrypted MAPI traffic use techniques to protect against unauthorized man-in-the-middle devices from making modifications to their exchanged data. Additionally, encrypted MAPI traffic and encrypted SMB3 traffic ensure data confidentiality by transmitting data with protection across the network. To securely accelerate this traffic, a properly configured client-side and server-side SteelHead:

SteelHead obtains cryptographic information from the Windows domain controller to accelerate this traffic. Communication between the SteelHead and the domain controller can be configured in different ways. We recommend using WinSec Controller, which complies with Microsoft’s tiered security model. However, the SteelHead must be joined to the Windows domain if NTLM authentication is used. You can use WinSec Controller or domain independent SteelHead Kerberos optimization (DISKO) if you are using Kerberos authentication. This cryptographic information is only useful for the lifetime of an individual connection or session. The information is obtained at the beginning of a connection and transferred to the client-side SteelHead as needed, using the secure inner channel feature. You must configure the secure inner channel to ensure maximum security.

Only the server-side SteelHead is required to join the domain, and it does so using a machine account in the same way that a Windows device joins the domain using a machine account. The SteelHead joins the domain this way to obtain a client user session key (CUSK) or server user session key (SUSK), which allows the SteelHead to sign and/or decrypt MAPI on behalf of the Windows user that is establishing the relevant session.

The server-side SteelHead must join a domain that is either:

The domain that the server-side SteelHead is joined to might include some or all of the Windows application servers (file server, Exchange server) for SteelHead acceleration. The server-side SteelHead can only be a member of one domain, but where suitable domain trusts exist, it can also accelerate connections for Windows application servers that reside in other domains.

Production deployments can have multiple combinations of client and server Windows operating system versions, and they can include different configuration settings for signed SMB and encrypted MAPI. Therefore, the security authentication between clients and servers can use NT LAN Manager (NTLM) or Kerberos, or a combination of the two. This chapter includes more information about authentication types and SteelHead configuration requirements.

The Windows security framework is based on a formal structure known as a domain. Inside the domain is a logical group of host resources (primarily clients and servers, but also printers and other peripherals) that share a central directory database. The database resides on one or more servers known as domain controllers and contains user accounts and security information for all the resources in the domain. Other domains can coexist alongside and are joined together through a Trust Relationship to allow resources to securely communicate between each other even though they are in different domains with their own domain controllers.

When users and clients are accessing server resources (like file servers and Exchange servers), their credentials are validated against the database on the domain controller. This validation ensures that the client and the user have the correct security privileges to be able to access resources that provide signed SMB traffic or encrypted MAPI traffic.

Several techniques and protocols are used to validate the credentials of the user and client. These techniques vary according to the Windows operating system version and application configuration (for example, Microsoft Outlook and Microsoft Exchange) on both the client and server. Example protocols include Kerberos, NTLMv1, and NTLMv2. The earliest suitable SteelHead version required to perform acceleration in a Windows security environment is based on the authentication protocol used. Because Riverbed has added more capabilities in newer versions of SteelHead, we recommend that you use the most recent version that meets your needs.

Some organizations might have more than one Windows domain in use in their environment. A SteelHead, like a Windows server, can only join a single domain. Therefore, the choice of which domain the SteelHead should join depends on the domain where the file or mail servers are located, the type of trust relationship between the SteelHeads potential domain, the file or mail server’s domain, and the domain containing a user's credentials.

Figure: Single domain structure shows an example of a simple, single domain structure. All resources (such as clients and servers) that have joined the same domain are subject to the domain permissions and authentications, and they can access the other available resources. Only a single domain controller is required in this case, although you can have more than one domain controller for resilience. The SteelHead must join the one available domain as a precursor to secure Windows protocol acceleration.

Figure: Two domains and one-way trust structure shows an example where clients are in one domain and servers are in a second domain. There is a trust relationship between the two domains that allow the clients and servers to access each other. The trust relationship is a one-way trust. The client domain is described as the Trusted Domain and the server domain is described as the Trusting Domain. The arrow that indicates the direction of trust is from the trusting domain to the trusted domain. Because of the one-way trust, only the resources in the client domain are allowed to access the resources in the server domain and not the other way around. Each of the two domains has its own domain controller, each with their own database for the resources in its domain.

Figure: Multiple domains with two-way trust structure shows an example of a configuration where there are multiple domains. In a two-way trust, each of the resources in the child domains can access the other domains through the top-level (parent) domain as long as the correct permissions have been set up within the child domains.

There can be a mixture of domains with domain controllers with different Windows operating system versions and a mixture of trust types. Native mode is when all domain controllers run the same version of operating system, and mixed mode is when there are different versions of the operating system.

There are many combinations and settings for the Windows client operating system, Windows domain level, Windows authentication method, and SteelHead version. You can choose from several different configuration options on the server-side SteelHead. In some cases, you can select multiple options to provide the best possible flexibility for your deployment. The options are as follows:

A deployment that successfully accelerates SMB signing and encrypted MAPI traffic requires gathering information about the Windows environment, configuring the SteelHeads with the appropriate SteelHead version and configuration; when using delegation mode or end-to-end Kerberos, this same deployment potentially requires more configuration in the Windows domain.

Microsoft created an update to the SMB protocol with the release of Microsoft Windows 8 and Server 2012 operating systems. This new version is officially known as SMB3, but in some early documentation it might be referred to as SMB 2.2.

The following new features included in SMB3 are relevant to your SteelHead deployment:

You can use all three features only if the client and server are Windows 8 and Windows 2012 servers respectively. If the client is Windows 7 or earlier, or the server is Server 2008-R2 or earlier, the client and server do not use the new features for reasons of backward compatibility—except for secure dialect negotiation.

Secure dialect negotiation is enabled and used by default in Windows 8 and Server 2012 connections. You can optionally use secure dialect negotiation with SMB2 when you are setting up a connection to a server running Server 2008-R2, but this is not normally enabled for compatibility reasons.

With the release of Windows 8.1 and Windows Server 2012 R2, Microsoft has added support for SMB 3.02.

For SMB3 and SMB 3.02 specifications, go to http://msdn.microsoft.com/en-us/library/cc246482.aspx.

You can provide full acceleration for signed SMB3 traffic between Windows 8 clients and Server 2012 servers, as well as other client-server combinations that result in the use of signed SMB3 traffic.

Additionally, you can accelerate SMB3 traffic that is encrypted at the file share or file server level.

To accelerate SMB3 traffic, you must join the server-side SteelHead to the domain. Additionally, you must enable SMB3 acceleration on both the client-side and server-side SteelHeads.

If you correctly configure the SteelHeads to accelerate signed SMB3 traffic, there is no additional configuration required to support the acceleration of signed SMB3 traffic that is encrypted at the share or server level.

For more information about:

Further updates to the SMB protocol were included with Microsoft's release of Windows 10 and Windows Server 2016 operating systems. The default SMB protocol used between combinations of client and server running these operating system versions is SMB 3.1.1. Like SMB3 and SMB 3.02, encryption for SMB 3.1.1 can be enabled at the share or fileserver level. The default cipher is AES-128-GCM, but SMB 3.1.1 can negotiate with AES-128-CCM to support older configurations. The ability to negotiate the cipher (unlike SMB 3.02) means that Microsoft can chose to include additional crypto algorithms in the future.

Along with signing, encryption, and secure dialect negotiation included with previous SMB3 dialects, an additional mechanism was introduced with SMB 3.1.1 called preauthentication integrity. This is a form of integrity check that occurs between two hosts when establishing an SMB 3.1.1 session. This check is a mandatory feature with SMB 3.1.1 and is designed to protect against any tampering of the client-server session setup by using SHA-512 cryptographic hashing. The hash is used as one of the inputs to the key derivation function from which the session's secret keys are obtained.

To provide full Layer-7 latency acceleration for SMB 3.1.1 connections, both the client-side and server-side SteelHeads must be running SteelHead 9.2 or later and must have SMB2 and SMB3 latency acceleration settings enabled. The server-side SteelHead must also be configured with the following items:

Except for the service accounts, you can complete all of the above settings on the server-side SteelHead by using the Configure Domain Auth Easy Config.

When you have the client-side and server-side SteelHeads running SteelHead 9.2 or later, and have problems with the preauthentication integrity hash or negotiated encryption algorithm, then the connection between the client and server is blacklisted and subsequent sessions between the two hosts are passed through with no acceleration.

SteelHeads support joining domains that are operating in native or mixed modes for the following domain functional levels:

For more information about maximum latency between a SteelHead and a domain controller, go to Knowledge Base article S22110.

Before you join a SteelHead to a domain, perform the following prerequisite verifications:

During the join operation, the SteelHead communicates with domain controllers and other entities related to the Windows domain, including the DNS server. The exact operations performed depend on the domain functional level, but are like the operations made when a new Windows server joins the domain.

The following process occurs during the domain join:

By default, the SteelHead appears in the Computers Organizational Unit (OU) in the domain. This is the default for Windows member servers joining a domain. You can use the CLI for a domain join and specify a different OU.

The following example shows a SteelHead joining the domain RVBD.COM and placing the SteelHead in the WAN-opt OU:

When the user is in a different domain from the servers, and when the server domain has a one-way trust relationship with the user domain, the user domain is the trusted domain, and the server domain is the trusting domain. This setup is occasionally deployed in organizations that have a number of subsidiary companies or between two companies that have recently merged but wish to keep their IT separate for a period of time.

More typically this configuration is found when the user organization has file or mail services hosted by an external service provider. For example, with Microsoft Office 365 Dedicated service, this setup enables the SteelHead to use authentication of the Exchange servers that provide Microsoft Exchange online services.

In environments in which there is a one-way trust between server domains and user domains, the server-side SteelHead is joined to the user domain, or any domain that trusts the domain of the client user. Because of the one-way trust, the server-side SteelHead cannot automatically build a list of domains on the other side of the trust. Therefore, you must explicitly configure the server domains that trust the user domain on the server-side SteelHead, using the protocol domain-auth oneway-trust command.

For example, if the users in the RVBD.COM domain use file or mail servers in the SERVERS.PROVIDER.COM domain (whose shortened NetBIOS domain name is SERVERS), you first ensure that the server-side SteelHead is joined to the RVBD.COM domain and then use this command on the server-side SteelHead:

You can view the list of configured one-way trust domains with the show protocol domain-auth oneway-trust command and, if needed, you can remove domains with the no protocol domain-auth oneway-trust dns-name command.

Support for Kerberos authentication through a one-way trust is included in SteelHead.

When you use Kerberos authentication, there are some additional one-way trust restrictions if you use external managed services such as Microsoft Office 365 Dedicated. These restricted trust models are deliberately designed with split resource and management Active Directory domains.

Within a hosted services deployment, or any other deployment in which there is a restricted one-way trust, the server-side SteelHead cannot use the replication user account to contact the resource domain controller for the session key.

The server-side SteelHead joins the user account domain and uses the replication user account to communicate with the domain controller in the user domain.

In addition, the client-side and server-side SteelHeads use a Kerberos feature to intercept traffic over TCP port 88, the port most used by Kerberos.

By intercepting the Kerberos exchanges (which are initiated by the client when setting up an authenticated connection to a server), the server-side SteelHead can obtain a copy of the session key used between the client and server. This action enables the SteelHeads to accelerate the signed SMB or encrypted MAPI session in a restricted trust deployment.

The Kerberos feature must use TCP.

Windows XP clients, by default, use UDP for Kerberos authentication. You must reconfigure Windows XP clients to use TCP, if necessary.

Kerberos is a network authentication protocol. In a Microsoft Windows environment, the Active Directory domain controller maintains user account and login information to support the Kerberos service. From a corporate perspective, you can think of Kerberos as guarding against unauthorized access to your IT assets.

The three components of Kerberos are the key distribution center (KDC), the client user, and the server resource with the service that the client user wants to access. The KDC is a part of the Windows domain controller and performs two service functions: the authentication service (AS) and the ticket-granting service (TGS).

To enable the client user to access a server resource (for example, a Windows file server), three exchanges are involved:

When users initially log in to a Microsoft Windows network, they must provide a login name and password for access. These credentials are verified in the AS exchange of a KDC within the domain of the user. The KDC has access to Active Directory user account information. When a user is successfully authenticated, the authentication server grants the user a ticket to get tickets (TGT) that is valid for the local domain—you are first approved to get tickets, and next you are approved for each ticket as you ask for them. The TGT (sometimes referred to as the AS reply, although the AS reply actually contains more parts) has a default lifetime of 10 hours and can be renewed during the user's session without requiring the user to reenter a password.

The AS reply includes two components: the TGT itself, which is encrypted with a key that only the KDC (TGS) can decrypt, and the first of two session keys encrypted with the user's password hash. Any future communication with the KDC uses this initial session key (SK1). The client uses the TGT, which is cached in volatile memory space on the client machine, to request sessions with services throughout the network.

The client sends a request to the TGS and asks for credentials of the desired server. The client first creates an authenticator using the SK1. The authenticator contains the username, IP address, and a time stamp—all encrypted using SK1. The client next sends a copy of the TGT and authenticator to the TGS. The TGS responds with the server credentials in the form of a service ticket that also has two components: one encrypted in the server's key, which the client cannot read, and the other encrypted with the client's key, which is temporary. The encryption key is the second of the two session keys (SK2) issued during the sequence of exchanges. The SK2 is valid only for communicating with the desired server and lasts for the lifetime of the session with the desired server. A second or subsequent session with the same server needs a completely new SK2 session key requested by the client from the TGS.

Next, the client creates another authenticator, this time using SK2 for encryption. The client transmits the authenticator with the service ticket, which contains the client identity and a copy of the session key—SK2—all encrypted with the server's key, to the server. As a result of this exchange, the SK2 is now held by the client and server. SK2 authenticates the client and can optionally authenticate the server. The SK2 can also be used to encrypt further communication between the two hosts or to exchange a separate subsession key used for encrypting further communication.

The AP exchange is also known as the client-server exchange because the exchange is often completed with whatever application protocol is required between the client and server: for example, SMB and SMB2 for file sharing, MAPI for email, or HTTP for SharePoint.

The Kerberos exchange process is shown in Figure: Kerberos exchanges.

The Kerberos exchange occurs when the client user, KDS, and resource server are in the same Windows domain. Where there are multiple domains, there are steps that include referral tickets.

The AS and TGS functions are separate within the key distribution center. This enables the user to use the TGT obtained from the AS in the domain to obtain service tickets from a TGS in other domains. This is accomplished through referral tickets. A referral ticket is like the service ticket that is granted during the TGS exchange described earlier. The difference between the two is that the referral ticket contains a ticket for the KDC in the adjoining domain rather than the server.

If there is a trust established between two domains, referral tickets are granted to clients that request authorization for services in other domains. Because of the trust relationship between the two domains, an interdomain key, based on the trust password, is available for authenticating KDC functions.

For example, consider a client user in the local domain who seeks services in a foreign domain. The two domains are directly linked through a two-way trust. The basic steps are as follows:

In a multiple domain configuration where the client is in one domain and the server is in a foreign domain, communication between the two can only be through an intermediate domain. Again, assume that there are transitive two-way trusts between the local domain and the intermediate domain, and the intermediate domain and the foreign domain.

The process is like the two-domain example. The basic steps are as follows:

For more details and reference material on Kerberos that are beyond the scope of this guide, go to:

From a Riverbed perspective, the acceleration of secure protocols in a Microsoft Windows environment includes the following protocols:

You must understand how SteelHead performs acceleration on these protocols when the authentication is end-to-end Kerberos before you proceed to more specific details. Remember the following points:

Therefore, the only way for SteelHead to legitimately accelerate these encrypted, or digitally signed, secure protocols is to obtain the machine credentials for any servers that require acceleration. SteelHead uses Active Directory replication by using the same protocols and tools as the Windows domain controllers do and by employing a domain user that has replication privileges.

When the server-side SteelHead uses this replication capability, it can transparently participate in the key exchange between the client and server, maintain security, and accelerate relevant traffic.

Although a user with generic domain administrator privileges meets the requirements for replication, these privileges could have some security implications.

Instead, you can assign a restricted set of privileges to a user, known as a replication user. You can configure the replication user on a per forest basis so that the user assigned to it can retrieve machine credentials from any domain controller in any trusted domain within the forest. Remember that a forest can comprise of multiple domains with trusts between them.

The replication user begins with a generic user account created by a Windows domain administrator, which might or might not be you. After this is done, you can apply the privileges and restrictions for the account to become a replication user on the SteelHead. If you have multiple SteelHeads in the data center (for example, in a high-availability configuration), then you can add the same replication user account to the configuration for all the server-side SteelHeads.

The replication user has enough rights to calculate the S1 and S2 Kerberos session keys for the SteelHead to properly terminate the session and perform acceleration. These rights are given by granting Replicate Changes and Replicate Changes All.

After the configuration is complete, the SteelHead retains the replication user account details by encrypting them in its secure vault.

The secure vault is locked on a new SteelHead. You must unlock the secure vault to view, add, remove, or edit any replication or delegate user configuration details that are stored on the SteelHeads.

You can enable Kerberos authentication support for HTTP for SharePoint, encrypted MAPI, signed SMB, and signed SMB2. When you enable the Kerberos setting on the server-side SteelHead, you enable the SteelHead to use the relevant domain user privileges and to access to the session key used by the client and server.

There are many ways to configure the server-side SteelHead to support the different secure Windows application options. The following is a list of best practices to ensure that the majority, if not all, of the secure Windows traffic in your environment is fully accelerated: