Joining a Windows domain or workgroup
A server-side SteelHead can join a Windows domain or workgroup in the Optimization > Active Directory: Domain Join page. This page provides a central place for a SteelHead to join a Windows domain or workgroup.
The SteelHead can join a single Windows domain to use these features:
RiOS 8.5 and later include an automatic way to join the domain and deploy the server-side SteelHead in Active Directory. For details, see
Configuring domain authentication automatically.
You can also use the WinSec Controller appliance to manage Windows Active Directory Domain Controllers. For details, see the
WinSec Controller User Guide. To add a WinSec Controller appliance, see
Adding a WinSec Controller appliance.
Domain and local workgroup settings
You can choose between two user authentication modes: domain or local workgroup. Creating a local workgroup eliminates the need to join a Windows domain and simplifies the configuration process, but a workgroup doesn’t support SMB signing, MAPI 2007 encrypted traffic optimization authentication, or MAPI Exchange as a hosted service.
Domain mode
In Domain mode, you configure the SteelHead to join a Windows domain (typically, the domain of your company). When you configure the SteelHead to join a Windows domain, you don’t have to manage local accounts in the branch office, as you do in Local Workgroup mode.
Domain mode allows a domain controller (DC) to authenticate users accessing its file shares. The DC can be located at the remote site or over the WAN at the main data center. The SteelHead must be configured as a Member Server or Active Directory integrated in the Windows 2000 or later Active Directory Services (ADS) domain. Domain users are allowed to use the Kerberos delegation trust facility and NTLM environments for MAPI 2007 encryption or SMB signing based on the access permission settings provided for each user.
Support for one-way trusts include Windows 7 clients without requiring a registry change on the Windows 7 client. You must join the server-side SteelHead to the domain using the Active Directory integrated (Windows 2008 and later) mode. This mode allows the SteelHead to use authentication within the Active Directory environment on the Exchange Servers that provide Microsoft Exchange online services. The domain that the server-side SteelHead joins must be either the same as the client user or any domain that trusts the domain of the client user.
Local Workgroup mode
In Local Workgroup mode, you define a workgroup and add individual users that have access to the SteelHead. The SteelHead doesn’t join a Windows domain.
Use Local Workgroup mode in environments where you don’t want the SteelHead to be a part of a Windows domain. Creating a workgroup eliminates the need to join a Windows domain and simplifies the configuration process.
If you use Local Workgroup mode, you must manage the accounts and permissions for the branch office on the SteelHead. The Local Workgroup account permissions might not match the permissions on the origin-file server.
To configure a Windows domain in Local Workgroup mode
1. Select Optimization > Active Directory: Domain Join to display the Domain Join page.
Domain Join page
2. Under Domain/Local, select Local Workgroup Settings, click Select, and then click OK when a dialog asks if you really want to change the setting or reminds you to leave the domain before changing the setting.
3. Complete the configuration as described in this table.
Control | Description |
Workgroup Name | Specify a local workgroup name. If you configure in local workgroup mode, the SteelHead doesn’t need to join a domain. Local workgroup accounts are used by clients when they connect to the SteelHead. Starting with RiOS 9.5, this name is not case sensitive. |
Add a New User | Displays the controls to add a new user to the local workgroup. |
User | Specify the login to create a local workgroup account so that users can connect to the SteelHead. |
Password/Password Confirm | Specify and confirm the user account password. |
Add | Adds users to the local workgroup. |
Remove Selected | Removes the selected names. |
4. Click Apply to apply your settings to the running configuration.
5. Click Save to Disk to save your settings permanently.
Preconfiguration checklist for 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
Configuring the date and time 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.
In addition, check these DNS settings:
– 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
Modifying general host 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
Modifying general host 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
To specify DNS settings.
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. See the 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. See the 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. See the Knowledge Base article
S18097 for details.
• If you use Kerberos to join a domain, use these guidelines:
– 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 |
To configure a Windows domain in Domain mode
1. Select Optimization > Active Directory: Domain Join to display the Domain Join page.
2. Under Domain/Local, click Domain Settings, click Select, and then click OK when a dialog asks if you really want to change the setting.
3. Complete the configuration as described in this table.
Control | Description |
Active Directory Domain Name/Realm | Specify the domain in which to make the SteelHead a member. Typically, this is your company domain name. RiOS supports Windows 2000 or later domains. RiOS doesn’t support nondomain accounts other than administrator accounts. If you create Local mode shares on a nonadministrator account, your security permissions for the share aren’t preserved on the origin-file server. |
Primary DNS IP Address | By default, this field displays the primary DNS IP set in the DNS Settings page. To modify this entry, click the IP address. |
Joining the Domain for | Kerberos Authentication—We recommend integration with WinSec Controller to follow Microsoft’s tiered security model NTLM Authentication—We recommend you do not enable this feature. This feature may be deprecated in the future. |
Username | The credentials used to join the domain must have domain join privileges. For Kerberos support, use any user account that has permission to join a workstation to the domain. For NTLM support, use any user account that has permission to join a domain controller to the domain. Domain administrator credentials are not strictly required but we recommend using them. Domain administrator credentials are required when you join the domain as an Active Directory integration. The system does not cache user credentials after the join operation; credentials are deleted after the operation. |
Password | Specify the password. This control is case sensitive. |
Domain Controller Name(s) | Specify the hosts that provide user login service in the domain, separated by commas. (Typically, with Windows 2000 Active Directory Service domains, given a domain name, the system automatically retrieves the DC name.) We recommend specifying the domain controller names in environments where there’s varying latency between the SteelHead and the domain controllers. |
Short Domain Name | Specify the short domain (NetBIOS) name if it doesn’t match the first portion of the Active Directory domain name. Case matters; NBTTECH is not the same as nbttech. |
Join/Leave | Joins the domain or leaves the domain. If you are in domain mode and have joined a domain, you can’t change to local workgroup mode until you leave the domain. |
Rejoin | Rejoins the domain. |
Cancel | Cancels any current domain action that is in progress, such as joining or leaving a domain. |
4. Click Apply to apply your settings to the running configuration.
5. Click Save to Disk to save your settings permanently.
When you have successfully joined the domain, the status updates to In a Domain.
Troubleshooting a domain join failure
This section describes common problems that can occur when joining a Windows domain.
RiOS 8.5 and later feature a domain health tool to identify, diagnose, and report possible problems with a SteelHead within a Windows domain environment. For details, see
Checking domain health.
System time mismatch
The number one cause of failing to join a domain is a significant difference in the system time on the Windows domain controller and the SteelHead. When the time on the domain controller and the SteelHead don’t match, this error message appears:
lt-kinit: krb5_get_init_creds: Clock skew too great
We recommend using NTP time synchronization to synchronize the client and server clocks. It is critical that the SteelHead time is the same as on the Active Directory controller. Sometimes an NTP server is down or inaccessible, in which case there can be a time difference. You can also disable NTP if it isn’t being used and manually set the time. You must also verify that the time zone is correct. For details, see
Configuring the date and time.
Select the primary DNS IP address to view the Networking: Host Settings page.
Invalid domain controller IP
A domain join can fail when the DNS server returns an invalid IP address for the Domain Controller. When a DNS misconfiguration occurs during an attempt to join a domain, these error messages appear:
Failed to join domain: failed to find DC for domain <domain name>
Failed to join domain: No Logon Servers
Additionally, the Domain Join alarm triggers and messages similar to these appear in the logs:
Oct 13 14:47:06 bravo-sh81 rcud[10014]: [rcud/main/.ERR] - {- -} Lookup for bravo-sh81.GEN-VCS78DOM.COM Failed
Oct 13 14:47:06 bravo-sh81 rcud[10014]: [rcud/main/.ERR] - {- -} Failed to join domain: failed to find DC for domain GEN-VCS78DOM.COM
When you encounter this error, choose Networking > Networking > Host Settings and verify that the DNS settings are correct.
Related topics