SteelHeadā„¢ Deployment Guide - Protocols : Signed SMB and Encrypted MAPI Optimization : Domain Authentication Scaling
Domain Authentication Scaling
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:
  • When to Use Domain Authentication Scaling
  • General Improvements in RiOS v8.6
  • Domain Controller Load Balancing
  • When to Use Domain Authentication Scaling
    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
    General Improvements in RiOS v8.6
    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.
    Domain Controller Load Balancing
    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:
  • sustain higher quantities of authentication requests.
  • tolerate the loss of a domain controller much more efficiently.
  • reduce the load it places on an individual domain controller.
  • To enable the server-side SteelHead to load balance domain controllers, enter this command on the server-side SteelHead:
    protocol domain-auth configure load-balancing
    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:
    protocol domain-auth configure load-balancing 6
    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.