This chapter discusses high-level techniques and guidance for configuring signed Service Message Block (SMB) and encrypted MAPI traffic to ensure data integrity. This chapter includes the following sections:

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 optimize this traffic, a properly configured client-side and server-side SteelHead:

To query the Windows domain controller for the necessary cryptographic information to optimize this traffic, the server-side SteelHead must join a Windows domain. The SteelHead can require other configurations, both on the SteelHead and in the Windows domain. 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 optimization. The server-side SteelHead can only be a member of one domain, but where suitable domain trusts exist, it can also optimize connections for Windows application servers that reside in other domains. For more information, see Domain Relationships.

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 it is possible that 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 RiOS version required to perform optimization in a Windows security environment is based on the authentication protocol used. Because Riverbed has added more capabilities in newer versions of RiOS, Riverbed recommends 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 servers 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 optimization.

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 RiOS 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 optimizes SMB signing and encrypted MAPI traffic requires gathering information about the Windows environment, configuring the SteelHeads with the appropriate RiOS version and configuration; when using delegation mode or end-to-end Kerberos, this same deployment potentially requires more configuration in the Windows domain.

The following is a general overview on how to configure a typical SMB signing and MAPI encrypted deployment (for complete details, see the SteelHead Management Console User’s Guide):

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—with the exception of 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.

RiOS versions prior to 8.5 provide some limited optimization of SMB3, but in some cases there is no optimization at all. For more information about SMB3 and releases prior to RiOS 8.5, go to https://supportkb.riverbed.com/support/index?page=content&id=S16547.

In RiOS 8.5 or later, you can provide full optimization 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, in RiOS 8.5 or later, you can optimize SMB3 traffic that is encrypted at the file share or file server level.

To optimize SMB3 traffic, you must run RiOS 8.5 or later on both the client-side and server-side SteelHeads and join the server-side SteelHead to the domain. Additionally, you must enable SMB3 optimization on both the client-side and server-side SteelHeads.

If you correctly configure the SteelHeads to optimize signed SMB3 traffic, there is no additional configuration required to support the optimization 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. Similar to 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 to 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 pre-authentication 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.

For more information on pre-authentication integrity, go to http://blogs.msdn.com/b/openspecification/archive/2015/08/11/smb-3-1-1-pre-authentication-integrity-in-windows-10.aspx. This page also discusses the use of WAN accelerators in the Proxy and traffic accelerator section.

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

With the exception of 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 RiOS 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 optimization.

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 http://supportkb.riverbed.com/support/index?page=content&id=S22110.

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

If the server-side SteelHead is running a version of RiOS between 6.1 and 6.5, it can join the domain only to appear as a Workstation. In RiOS 7.0 or later, the SteelHead can join the domain and appear as one of three different roles: Workstation, Active Directory integrated (Windows 2003), or Active Directory integrated (Windows 2008 and later).

Regardless of the domain functional level, as long as there is at least one domain controller running Windows 2008 or later, Riverbed recommends joining with the role of Active Directory integrated (Windows 2008 and later). As well as enabling the server-side SteelHead to communicate with domain controllers running Windows 2008 and later, this join type provides the broadest coverage of NTLM dialects used by clients and the ability for the SteelHead to operate more easily across multi-domain environments.

For more details, see Configuring the Server-Side SteelHead for Active Directory Integrated (Windows 2003/2008).

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 similar to 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:

You need RiOS 6.1 or later 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. In this scenario, 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 the following commands 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.

In RiOS 7.0 or later, the support for one-way trusts is further enhanced to include Windows 7 clients without requiring a registry change on the client. You must join the server-side SteelHead to the domain using the Active Directory integrated (Windows 2003/2008) mode and then execute the CLI command as indicated previously.

Support for Kerberos authentication through a one-way trust is included in RiOS 8.5 or later. Versions of RiOS prior to 8.5 support only NTLM authentication in one-way trust configurations.

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 in RiOS 8.5 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 optimize the signed SMB or encrypted MAPI session in a restricted trust deployment.

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

For more information about configuring SteelHeads for restricted one-way trusts, see Configuring the Server-Side SteelHead for Active Directory Integrated (Windows 2003/2008) and the SteelHead Management Console User’s Guide.

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.

This section includes the following topics:

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 similar to 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 similar to 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 optimization of secure protocols in a Microsoft Windows environment includes the following protocols:

You must understand how RiOS performs optimization 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 RiOS to legitimately optimize these encrypted, or digitally signed, secure protocols is to obtain the machine credentials for any servers that require optimization. RiOS 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 optimize 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. For information about how to configure the replication user, see the Riverbed Command-Line Interface Reference Manual and the SteelHead Management Console User’s Guide.

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 optimization. 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.

In Windows 2008 domains, you can apply further restrictions to the replication user by using a password replication policy (PRP). A PRP is a set of rules that describe a list of accounts that you can replicate between domain controllers. When you enable PRP in a Windows domain, the SteelHead is restricted, specifically to using the replication user to replicate accounts as determined by the PRP settings. Therefore, you can use the PRP to limit the accounts known to the replication user. This configuration can create additional administrative overhead in managing the PRP; however, it might be worth the additional security.

PRP is not available in Windows domains with a functional level lower than Windows 2008. For information about how to configure PRP, see the SteelHead Management Console User’s Guide.

In RiOS 7.0 or later, you can enable Kerberos authentication support for HTTP for SharePoint, encrypted MAPI, signed SMB, and signed SMB2. To fully optimize signed SMB3 traffic, you must use RiOS 8.5 or later. 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.

You must have RiOS 7.0 or later on both the server-side and client-side SteelHeads. You must use RiOS 8.5 or later for SMB3.

For information about how to configure each application, see the SteelHead Management Console User’s Guide and HTTP Optimization for SharePoint.

Regardless of the client-server authentication type, the server-side SteelHead must join the Windows domain. But depending on the authentication type, you may not need to use the replication user to optimize secure Windows traffic. If you are using NTLM authentication, so long as the server-side SteelHead join type is Active Directory integrated Windows 2003 or, preferably, Active Directory integrated Windows 2008, the SteelHead can use NTLM Transparent Mode to ensure the secure Windows traffic is fully optimized.

For the server-side SteelHead to integrate into Active Directory, you must configure the role when the appliance joins the Windows domain. Irrespective of the domain functional level (2003, mixed, 2008, and so on), select the SteelHead join type based on the operating system version running on the domain controllers. For example, if you only have domain controllers running 2003 or 2003-R2, then select the join type of Active Directory integrated Windows 2003. If you have domain controllers with a mixture of 2003, 2003-R2, 2008, or later, then select Active Directory integrated Windows 2008 as the join type.

For information about how to configure Active Directory integration, see the Riverbed Command-Line Interface Reference Manual and the SteelHead Management Console User’s Guide.

Be aware, that when you integrate the server-side SteelHead in this way, it does not provide any Windows domain controller functionality to any other machines in the domain and does not advertise itself as a domain controller or register any SRV records (service records). In addition, the SteelHead does not participate in an active replication nor does it write any Active Directory objects to persistent storage. The server-side SteelHead has just enough privileges so that it can read necessary attributes of servers you want to optimize and then use transparent interception.

This scenario is successful only for servers and clients that can make use of NTLM authentication. If you configure any clients and servers exclusively to use Kerberos authentication, they cannot use NTLM authentication. Therefore, the only way to optimize secure Windows traffic between such hosts is to configure the server-side SteelHead for end-to-end Kerberos support with a replication user account. However, in the event of a Kerberos authentication failure, unless explicitly configured, the session falls back to NTLM. Also, any service requested by IP address or a name that cannot be validated by Active Directory falls back to NTLM authentication.

For information about replication users, see Domain User with Replication Privileges.

The following table shows the different combinations of Windows clients and authentication methods with the earliest required version of RiOS and Windows configuration (delegation, Kerberos, Active Directory integrated) for the server-side SteelHead.

For Windows 8 clients behavior, use Windows 7 information in the above table, and RiOS 8.5 or later. For Windows 8.1 and Windows 10 clients, use RiOS 9.0 or later.

Remember, if you configure the server-side SteelHead to support end-to-end Kerberos authentication, you can also join it to the domain in Active Directory integrated mode to support other clients that might be using NTLM authentication. This configuration can provide flexible and broad support for multiple combinations of Windows authentication types in use within the Active Directory environment.

For advice and suggestions on configuration best practices, see Best Practices for the SteelHead in a Secure Windows Deployment.

There are many possible 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 optimized:

This section describes the ability of the SteelHeads to scale the authentication communications that occur between the server-side SteelHead and the Windows domain controller. This section includes the following topics:

In releases previous to RiOS 8.6, the server-side SteelHead communicates only with a single domain controller at a time. Even if the domain that the SteelHead is part of contains additional domain controllers, the SteelHead can choose to communicate only with one. If the domain controller fails or is unavailable for some reason, then the SteelHead automatically discovers an alternative domain controller.

While this process works well in most deployments, the following are examples of environments in which an individual SteelHead can be limited by this single-instance approach and can benefit from domain authentication scaling. Domain authentication scaling is available in RiOS 8.6 and later.

A large-scale deployment (with tens of thousands of users) typically involves a larger number of authentication requests between clients and servers. Because the server-side SteelHead is involved in so many requests when optimizing secure Windows traffic, lightening its communication to an individual domain controller is important.

In another scenario, there might not be a large number of requests but there might be a high degree of latency between the server-side SteelHead and the single domain controller it is communicating with. For example, with a deployment to Microsoft Office 365, there might be non-LAN latency between the domain controller and the server-side SteelHead.

In general, Riverbed recommends deployment in which the latency between domain controllers and the server-side SteelHead is no more than a few milliseconds.

For more information about maximum latency between a SteelHead and a domain controller, go to http://supportkb.riverbed.com/support/index?page=content&id=S22110.

With RiOS 8.6 or later, the server-side SteelHead can manage higher quantities of communication with the Windows Active Directory (AD) environment it is requesting authentication details from. This has no direct benefit to the optimization of the secure Windows traffic (such as signed SMB and encrypted MAPI), but it can improve the authentication workload that the server-side SteelHead is part of. These general improvements include multithreading the RiOS code associated with AD interaction, which enables the server-side SteelHead to respond to more requests in a shorter time. Because these improvements are embedded within the RiOS code, you do not need to configure any additional settings other than to have the server-side SteelHead running RiOS 8.6 or later.

Windows domains often contain more than one domain controller for redundancy and scalability. With RiOS 8.6 or later you can configure the server-side SteelHead to communicate simultaneously with multiple domain controllers in the same domain. This enables the server-side SteelHead to:

To enable the server-side SteelHead to load balance domain controllers, enter this command on the server-side SteelHead:

You can configure this setting only on the CLI. For more information about this command, see the Riverbed Command-Line Interface Reference Manual.

When you enable domain controller load balancing, the server-side SteelHead balances the traffic load across up to six domain controllers within the same domain. You can configure load balancing across more domain controllers by specifying the desired number as part of the command. The following example shows how to configure the SteelHead to load balance traffic across six domain controllers:

You can balance traffic across a maximum of eight domain controllers. Use the show protocol domain-auth load-balancing command to display the current status.

You do not need to specify the individual domain controllers to which the SteelHead load balances traffic. After the SteelHead is joined to a domain it automatically discovers any domain controllers that exist by performing a DNS lookup. The results from the DNS lookup enable the server-side SteelHead to automatically build its own list of domain controllers to balance traffic across. However, if you have already configured the SteelHead with a static list of domain controllers, then the static list takes precedence over an automatically discovered list. You can create a static list either by specifying one or more domain controllers on the server-side SteelHead during the join domain procedure or by using the domain settings dc-list * command.

This section describes domain health check and domain authentication automatic configuration and includes the following topics:

To optimize secure Windows traffic using SteelHeads, you:

The domain health check comprises of a series of tests related to Active Directory configuration settings. These tests and checks provide troubleshooting help for domain-related problems that might occur between the server-side SteelHead and the Active Directory environment.

The domain authentication automatic configuration includes a series of graphical widgets to assist you in performing the relevant configuration tasks associated with both the SteelHead and the Active Directory setup.

In RiOS 8.5 or later, the domain health check feature is available in the SteelHead Management Console and the CLI. Prior to RiOS 8.5, domain health check was only available in the CLI. You can use the domain health check feature to execute a variety of tests that provide diagnostic reports about the status of domain membership, end-to-end Kerberos replication, both manual and automatic constrained delegation, and DNS resolution. This information enables you to resolve issues quickly.

Riverbed recommends that you use domain health check from the SteelHead Management Console rather than the CLI.

For a full description of how to use domain health check, see the SteelHead Management Console User’s Guide and the Riverbed Command-Line Interface Reference Manual.

Use the Domain Health Check page to run tests on domain health. You can create test parameters by entering specific information into certain fields. Click Test to run the relevant test. You receive feedback on whether the test succeeds or fails, along with the option to display a detailed log file of the test as it progresses. The output of the log file can aid in troubleshooting issues that might be found during testing.

You can access the same tests by choosing Optimization > Active Directory: Domain Join and Optimization > Active Directory: Service Accounts pages of the SteelHead Management Console.

The following examples describe several ways to confirm that the domain health check feature is functioning correctly.

To use the RiOS domain health check CLI commands, you must understand that each command performs a test or configuration task, but the result of the command is displayed only by executing a follow-on command. This second command is displayed as part of the output of the previous command and is usually a show command.

For example, the protocol domain-auth test dns command is followed by the show protocol domain-auth test dns command to display the results of the test.

The main reason for this two-stage process is that the tests themselves perform a request or look-up that is outside of the SteelHead: for example, a DNS query to a DNS server can take a few moments to complete. The two-stage process means the SteelHead CLI does not hang while waiting for the test to execute. As each test is executed, the results are saved to a temporary log file on the SteelHead. After a test is complete, the contents of the log file are displayed in a more user-friendly format when you use the relevant show command.

The following table lists the test or configuration tasks and the associated commands.

The following example describes how to confirm that the domain health check feature is functioning correctly.

Figure: Successful DNS Test in the CLI shows a successful DNS test and Figure: Failed DNS Test in the CLI shows a failed DNS test.

Domain authentication automatic configuration is available in the SteelHead Management Console in RiOS 8.5 or later. Domain authentication automatic configuration is a powerful set of widgets designed to help you easily configure the server-side SteelHead and Active Directory. In RiOS versions prior to 8.5, you can configure the server-side SteelHead and Active Directory using only the CLI.

For example, Figure: Domain Authentication Automatic Configuration shows how, in RiOS 8.5 or later, the domain authentication automatic configuration guides you through the steps to join the SteelHead to the domain and enable the relevant Windows features (encrypted MAPI, signed SMB, signed SMB2, and signed SMB3).

You can use the domain authentication automatic configuration to configure a Windows user account that you can use for delegation or replication purposes. The domain authentication automatic configuration on the SteelHead does not create the delegate or replication user; the Windows domain administrator must create the account in advance, using the preferred standard Active Directory procedures.

After you create the basic user account in Active Directory, you can complete the remaining configuration steps using domain authentication automatic configuration on the SteelHead.

Along with configuring the delegation and replication user accounts, domain authentication automatic configuration enables you to add and remove entries in the lists of delegation servers.

For information about how to use domain authentication automatic configuration, see the SteelHead Management Console User’s Guide.

Figure: Single Domain Example shows a data center and a branch office that are both in the RVBD.COM domain hosted by a domain controller running Windows 2008-R2. The Windows 7 clients in the remote office want optimized CIFS access to the file servers in the Data Center. The file servers are configured with Signing Required. For ease of management, transparent mode is preferred by the customer.

The following is true for this configuration:

Confirm the correct configuration settings display in the Current Connections report, shown in Figure: MAPI-ENCRYPTS and Figure: CIFS-SIGNED. For information about the Current Connection Report, see the SteelHead Management Console User’s Guide.