Joining a SteelHead to a Domain
RiOS v6.1 or later supports joining domains in native or mixed modes for the following domain functional levels:
Windows 2000Windows 2003 R2Windows 2008Windows 2008 R2Windows 2012For 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:
The primary interface on a SteelHead must have IP reachability to any domain controllers, DNS servers, and other resources that a Windows server or workstation typically has in the domain that the SteelHead is joining. By default, the SteelHead uses the primary interface as the source interface for the join operation. Other interfaces, such as the auxiliary and in-path management interfaces, might work if enabled, but they are not supported for authentication traffic in general.The source interface for the SteelHead must not have its communication to the Windows domain controller blocked by a firewall or other security mechanism—for example, the RiOS Management ACL mechanism—either during the join or while optimizing connections. For information about the ports and protocols required for operation, go to http://support.microsoft.com/?id=179442.Configure the SteelHead to use the same DNS server that other members of the domain use. Active Directory uses the DNS protocol to discover domain resources. When a SteelHead is joining a domain, it needs to make DNS based requests to a DNS server that understands these Active Directory-specific operations. The source interface for the join must have an A record in the DNS domain associating the SteelHead hostname to its IP address.The SteelHead must have its clock synchronized to within a few seconds of the domain controller it communicates with. The best practice is to have the SteelHead use the NTP protocol to synchronize with the NTP server that is used for clock synchronization within the Windows domain.A clock that is not synchronized on the SteelHead is the most common cause of domain join errors.
Credentials for a domain account with sufficient privileges to join a machine to the domain must be temporarily available. Many organizations have specific accounts that are used only for the purpose of joining machines to the domain, and have no other privileges. Enter the credentials on the SteelHead to perform the join operation. The credentials are not stored 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 of all the server-side SteelHeads.If the server-side SteelHead is running a version of RiOS between v6.1 and v6.5, it can join the domain only to appear as a Workstation. In RiOS v7.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).
During the join operation to appear as a Workstation, 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:
The SteelHead performs a lookup for Domain Controllers. It uses the DNS server that is specified in the Host Settings page of the SteelHead Management Console.
The SteelHead picks a domain controller from the list—usually the one that responds quickest.
The SteelHead establishes a short-lived SMBv1 and well-known named pipe session to the chosen domain controller.
Using these two short-lived sessions, and with the authority of the temporary user account entered into the Domain Join page of the SteelHead Management Console (or CLI), the SteelHead requests the flags for the UserAccountControl attribute for its machine account.
After the machine account is successfully created, the SteelHead establishes a long-lived secure channel to the NetLogon service of the chosen domain controller.
RiOS v6.1 or later can join domains using NTLMv1, NTLMv2, or Kerberos for authentication.
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:
domain join domain-name RVBD.COM login join-account password join-password org-unit WAN-opt
One-Way Trust Configuration
You need RiOS v6.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 CLI 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:
protocol domain-auth oneway-trust dns-name SERVERS.PROVIDER.COM netbios-name SERVERS
You can view the list of configured one-way trust domains with the show protocol domain-auth oneway-trust CLI command and, if needed, you can remove domains with the no protocol domain-auth oneway-trust dns-name CLI command.
In RiOS v7.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 v8.5 or later. Versions of RiOS prior to v8.5 support only NTLM authentication in one-way trust configurations.
Enabling Kerberos in a Restricted Trust Environment
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 v8.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.
The Kerberos feature must use TCP.
Interestingly, 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.