Configuring the Server-Side SteelHead for Active Directory Integrated (Windows 2003/2008)

In some cases this can be an alternative to creating and using a specific replication user (described in Domain User with Replication Privileges). However, it depends on the authentication mechanism used by the Windows clients and servers.

You do not necessarily need to use the replication user to optimize secure Windows traffic if you deploy the server-side SteelHead so that it joins a domain in the Active Directory environment and authentication is NTLM only. For the server-side SteelHead to integrate into Active Directory, you must configure the role when the appliance joins the Windows domain. Depending on whether you have a Windows domain with a 2003 functional level or 2008 functional level, select the appropriate role from the Management Console or the command line of the server-side SteelHead.

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 required earliest version of RiOS and Windows configuration (delegation, Kerberos, Active Directory integrated) for the server-side SteelHead.


Client OS	Authentication Method	RiOS v7.0 (Active Directory Integrated)	RiOS v7.0 (Kerberos)	RiOS v9.0 ADI Mode
Windows 7	Negotiate authentication/SPNEGO	Optimized using NTLM	Optimized using Kerberos	Optimized transparent
Any client up to Windows 7	Kerberos	Optimized	Optimized	Optimized
Windows 8 and v8.1	NTLM	Optimized	Optimized	Optimized
Windows 8 and v8.1	Kerberos	Optimized (fallback)	Optimized	Optimized

For Windows 8 clients behavior, use Windows 7 information in the above table, and RiOS v8.5 or later. For Windows 8.1 clients, use RiOS v9.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.