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 v8.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 v8.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 v8.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 (signed SMB, encrypted MAPI, and so on), 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 v8.6 or later.

Windows domains often contain more than one domain controller for redundancy and scalability. With RiOS v8.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.