About 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. 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.
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 accelerating 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, we recommend 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 Knowledge Base article
S22110.
About domain controller load balancing
Windows domains often contain more than one domain controller for redundancy and scalability. 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 the protocol domain-auth configure load-balancing command on the server-side SteelHead.
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.
About domain health check and domain authentication
To accelerate secure Windows traffic using SteelHeads, you:
• need to configure NTP-related and DNS-related settings.
• optionally, join the server-side SteelHead to the Windows domain.
• must configure the necessary SteelHead features based on the type of protocols you want accelerate: for example, encrypted MAPI, signed SMB, signed SMB2, and signed SMB3.
• must deploy one or more service accounts configured for delegation (if using constrained delegation) or replication (if using end-to-end Kerberos).
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.
About domain health checks
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.
We recommend that you use domain health check from the Management Console rather than the CLI.
Using the Management Console to test domain health check
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.
The following examples describe several ways to confirm that the domain health check feature is functioning correctly.
To test the DNS setting using the Management Console
From the Management Console, choose either Reports > Diagnostics: Domain Health Check or Accelerate > Active Directory: Domain Join.
To test Domain Join using the Management Console
From the Management Console, choose either Reports > Diagnostics: Domain Health Check or Accelerate > Active Directory: Domain Join.
Using CLI commands to test domain health check
To use the 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.
Task | CLI commands |
---|
Check DNS settings | protocol domain-auth test dns show protocol domain-auth test dns |
Confirm that the SteelHead is correctly joined to the Windows domain. | protocol domain-auth test join show protocol domain-auth test join |
Ensure that the SteelHead can authenticate client connections | protocol domain-auth test authentication username * password * show protocol domain-auth test authentication |
Auto-configure a previously created account in Active Directory with replication privileges over the entire domain | protocol domain-auth auto-conf replication adminuser * adminpass * domain * dc * show protocol domain-auth auto-conf replication |
Determine if end-to-end Kerberos replication is correctly configured | protocol domain-auth test replication try-repl domain * shortdom * rserver * show protocol domain-auth test replication try-repl |
The following example describes how to confirm that the domain health check feature is functioning correctly.
To check the DNS settings using the CLI, connect to the SteelHead CLI in and enter the following commands:
protocol domain-auth test dns
show protocol domain-auth test dns
About domain authentication automatic configuration
Domain authentication automatic configuration is a powerful set of widgets designed to help you easily configure the server-side SteelHead and Active Directory.
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 User Guide.
About single domain example configuration
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 accelerated 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.
Single domain example

The following is true for this configuration:
• We recommend that all the SteelHeads are time synchronized for SteelHead deployments that involve some form of Windows authentication. This is especially true where Kerberos is involved in the authentication process. Consider using NTP to make the time synchronization task easier to maintain.
• SteelHead A on the client side supports signed SMB; no further client-side configuration is required.
• SteelHead B on the server side needs to join the RVBD.COM domain.
• SteelHead B needs to have transparent mode configured.
• Secure inner channel is optional for this configuration.
To configure a data center and branch office in the same domain
• SteelHead A does not need configuration.
• On SteelHead B, connect to the CLI in configuration mode and enter the following commands:
domain join domain-name RVBD.COM login Administrator password ******** dc-list 192.168.0.70 short-name RVBD
protocol cifs smbv1-mode enable
protocol cifs smb signing enable
protocol cifs smb signing mode-type transparent
write memory
restart
Confirm the correct configuration settings display in the Current Connections report, For information about the Current Connection Report, see the SteelHead User Guide.