Joining a SteelHead to a Windows domain

Follow these guidelines when joining a Windows domain server to a SteelHead. For details, go to Knowledge Base article S25759.

• Make sure that the SteelHead time is synchronized with the domain time and is in the same time zone (for example, Americas/Denver). The time on the SteelHead should be within a few seconds of the domain time; synchronizing the time to an NTP server sets the time on the SteelHead to within a few milliseconds of the Windows domain time. The SteelHead time must be within 5 minutes of the Windows server’s time if using NTLM, and within 30 seconds for Kerberos. See About the date and time settings to configure an NTP server.

• Ensure that the Primary (management) interface of the SteelHead is connected to your LAN and has connectivity to DNS, NTP, and the Active Directory domain. All domain join and delegation features use the Primary interface.

– Verify that there is an A record and reverse look-up record present on the DNS server for the primary interface of the SteelHead (which itself must be connected to the LAN).

– Make sure that an Active Directory DNS server is configured that allows the SteelHead to perform lookups. The DNS service must also be able to return domain controller names for each domain. Set or verify the DNS server in the DNS Settings area of the Networking > Networking: Host Settings page. See About Host, Interface, and General Service Settings for details.

– Verify that the Active Directory domain suffix (for example, domain.riverbed.com) is added to the DNS Settings area of the Networking > Networking: Host Settings page. See About Host, Interface, and General Service Settings for details.

– Make sure that all Windows client computers point to the DNS server that you configure on the SteelHead. To use SMB signing, the server-side SteelHead must be in the DNS. For details, see DNS.

If you have issues with SteelHeads attempting to join domains that were not requested or authorized, configure the server-side SteelHead to ignore all trusted domains, and then specify the domains to join. For details, go to Knowledge Base article S27002.

• Be sure that the SteelHead hostname is no more than 15 characters. Windows does not allow computer names that exceed 15 characters in Active Directory.

• Verify that the SteelHead hostname does not currently exist in the Computers container from the Active Directory Users and Computers snap-in (adsc.msc). If the SteelHead computer hostname has been retargeted from the default Computers container into an Organizational Unit (OU), verify that container for an existing SteelHead account.

• Be sure to specify a fully qualified domain name (FQDN). This FQDN must be the configured domain name for all Windows desktop computers.

• For RiOS release 9.5 and earlier, make sure that SMB1 (CIFS) is enabled on the domain controller. Starting with RiOS release 9.6, SMB2/3 is supported for the SteelHead domain join operation. Go to Knowledge Base article S30252 for more information.

• Joining the SteelHead to the active directory domain to support Kerberos authentication requires a Windows user with the privilege to add a workstation to the domain. Joining the SteelHead to the active directory domain to support NTLM authentication requires a Windows user with the privilege to add a domain controller to the domain.

Do not use an account that’s only able to join a workstation to a domain; these accounts can’t place the SteelHead’s account in the proper group or OU and can’t modify the userAccountControl account attribute in Active Directory for the SteelHead machine account. Go to Knowledge Base article S22468 for details.

The SteelHead deletes the domain administrator credentials after the domain join is compete; no Windows username or password is retained on the SteelHead.

Do not prepend the domain with the domain name; for example, for a domain of username, specify username not DOMAIN\username.

To use a Windows username without administrative privileges, first create a workstation (computer) account for the SteelHead and assign it additional privileges. Go to Knowledge Base article S18097 for details.

• If you use Kerberos to join a domain, use these guidelines:

– To verify or add a Kerberos replication user on the server-side SteelHead, display the Service Accounts page and check the field for the Kerberos replication user.

– To enable Kerberos authentication for restricted trust environments, use a one-way trust configuration. For details, see the SteelHead Deployment Guide - Protocols. This configuration is typically required for environments with restricted security: for example, for a trust model that has split resource and management Active Directory domains such as Office 365 or other managed service providers.

• Be sure that the following ports are open to all domain controllers.

Protocol	Port
SMB1, SMB2/3	TCP 139 (legacy Windows implementations) 445 (more recent Windows implementations)
LDAP	TCP/UDP 389
Kerberos	TCP/UDP 88
DNS	UDP 53
SMB1-Named-Pipes, SMB2/3-Named-Pipes	TCP 445
EPM/RPC	TCP 135