Configuring Network Integration Features : Joining a Windows domain or workgroup
  
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.
Domain Join page
The SteelHead can join a single Windows domain to use these features:
SMB signing trust for CIFS optimizations. For details, see Configuring SMB signing.
MAPI 2007 encrypted traffic optimization authentication. For details, see Configuring MAPI optimization.
MAPI Exchange as a hosted service.
SteelHead includes an automatic way to join the domain and deploy the server-side SteelHead in the Active Directory. For details, see Configuring domain authentication automatically.
We recommend you 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.
For more information about configuring and joining a domain, see Preconfiguration checklist for joining a SteelHead to a Windows domain.
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.
Configuring a Windows domain in Local Workgroup mode
1. Select Optimization > Active Directory: Domain Join to display the 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.
Domain Join page displaying local workgroup settings
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 Specifying 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 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. See Perform this task to add Kerberos replication users on the SteelHead: for details.
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
Configuring 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.
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.
If NTLM Authentication is not checked and if there are SMB connections with NTLM authentication in the network, they will be blacklisted by Steelhead. Also, if Kerberos Authentication fails, the fallback to NTLM Authentication will not be attempted by the Steelhead.
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.
The next step is to enable protocol optimization for CIFS (SMB) or encrypted MAPI. See Configuring CIFS optimization and Configuring MAPI optimization.
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
Configuring SMB signing
Configuring MAPI optimization