Configuring domain authentication automatically
RiOS 8.5 and later simplify the SteelHead configuration necessary to optimize traffic in an environment where there are:
• Microsoft Windows file servers using signed SMB or signed SMB2/3 for file sharing to Microsoft Windows clients.
• Microsoft Exchange Servers providing an encrypted MAPI communication to Microsoft Outlook clients.
• Microsoft Internet Information Services (IIS) web servers running HTTP or HTTP-based web applications such as SharePoint 2007.
This section describes how to simplify configuration using these operations:
• Easy Config—Configures the server-side SteelHead to join Windows Active Directory Domain to enable secure protocol optimization for CIFS SMB1, SMB2/3, and encrypted MAPI for all clients and servers.
• Auto Config—Configures the following accounts and privileges:
– Configure Delegation Account—Configures the deployed delegation account with AD delegation privileges. This is a legacy configuration that has been deprecated.
– Configure Replication Account—Configures the deployed replication account with AD replication privileges.
– Add Delegation Servers—Configures a list of the Exchange and CIFS servers that have permission to delegate AD access privileges. We strongly recommend using Kerberos end-to-end or Integrated Active Directory mode, as delegation requires the most administration.
– Remove Delegation Servers—Removes Exchange and CIFS servers from the list of delegation server accounts with permission to delegate AD access privileges. This is a legacy configuration that has been deprecated.
Easy domain authentication configuration
Domain authentication automatic configuration simplifies the server-side SteelHead configuration for enabling latency optimizations in a secure environment. Using this widget automates the majority of the required configuration tasks, avoiding the need to perform step-by-step operations in different configuration tools and using the command line on the Windows AD platforms.
Use this to configure the server-side SteelHead to join Windows Active Directory Domain and enable secure protocol optimization for CIFS SMB1, SMB2, and SMB3 for all clients and servers. To enable secure protocol optimization for MAPI and encrypted MAPI, you need to enable MAPI protocol optimization on all clients after running the widget.
Domain Authentication Automatic Configuration performs these tasks:
1. Tests the DNS configuration.
2. Joins the server-side SteelHead to the domain.
3. Enables secure protocol optimization, such as SMB signing.
4. Configures a deployed replication user in Active Directory, with the necessary privileges.
If any of the steps fail during the configuration, the system automatically rolls back to the previous configuration.
You don’t necessarily need to use the replication user or delegate user facility to optimize secure Windows traffic if you deploy the server-side SteelHead so that it joins a domain in the Active Directory environment. To integrate the server-side SteelHead into Active Directory, you must configure the role when you join the SteelHead to the Windows domain.
When you integrate the server-side SteelHead in this way, it doesn’t provide any Windows domain controller functionality to any other machines in the domain and doesn’t advertise itself as a domain controller or register any SRV records (service records). In addition, the SteelHead doesn’t perform any replication nor hold any Active Directory objects. The server-side SteelHead has just enough privileges so that it can have a legitimate conversation with the domain controller and then use transparent mode for NTLM authentication.
To configure domain authentication using Easy Config
1. On the server-side SteelHead, choose Networking > Networking: Host Settings.
2. Under Primary DNS server, specify the DNS server IP address to use as the DNS server for the domain.
3. Under DNS domain list, add the primary DNS server name to the list.
4. Click Apply to apply your settings to the running configuration.
5. Choose Optimization > Active Directory: Auto Config.
6. Under Easy Config, select Configure Domain Auth.
7. On the server-side SteelHead, complete the configuration as described in this table.
Control | Description |
Username | Specify the username. The credentials used to join the domain must have domain join privileges. For Kerberos support, use any ordinary 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 recommended. RiOS does not cache any user credntials after the join. |
Password | Specify the password for the domain administrator account. This control is case sensitive. |
Domain/Realm | Specify the fully qualified domain name of the Active Directory domain in which to make the SteelHead a member. Typically, this is your company domain name. RiOS supports Windows 2000 or later domains. |
Domain Controller | 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.) |
Short Domain Name | Specify the short (NETBIOS) domain name. You can identify the short domain name by pressing Ctrl+Alt+Delete on any member server. You must explicitly specify the short domain name if it doesn’t match the leftmost portion of the fully qualified domain name. |
Enable Encrypted MAPI | Select to enable encrypted MAPI optimization on the server-side SteelHead. After running this widget, you must also choose Optimization > Protocols: MAPI on the client-side SteelHead and select Enable MAPI Exchange Optimization and Enable Encrypted Optimization. |
Enable SMB Signing | Select to enable optimization on SMB-signed connections on the server-side and client-side SteelHeads. |
Enable SMB2 Signing | Select to enable optimization on SMB2-signed connections on the server-side and client-side SteelHeads. |
Enable SMB3 Signing | Select to enable optimization on SMB3-signed connections on the server-side and client-side SteelHeads. |
Configure Domain Auth | Click to configure domain authentication. |
After you click
Configure Domain Auth, the status indicates whether the domain authentication was successful. For details, see
Status and logging. If the authentication succeeds, secure protocol optimization for CIFS (SMB1), SMB2, and SMB33 is enabled for all clients and servers. Encrypted MAPI is enabled for all servers. To enable encrypted MAPI for all clients, you must enable encrypted optimization on the client-side SteelHead. For details, see
Configuring MAPI optimization.
Configuring domain authentication for delegation
Replication
You can assign a restricted set of privileges to a user, known as a replication user. You can configure the replication user on a per-forest basis so that the user assigned to it can retrieve machine credentials from any domain controller in any trusted domain within the forest. Remember that a forest can comprise multiple domains with trusts between them.
Automatic configuration simplifies setting up your SteelHead for delegation or replication. Use these widgets to:
• configure delegation or replication accounts.
• add or remove delegation servers.
Delegation (deprecated)
Using delegation mode to optimize SMB-signed or encrypted MAPI traffic requires additional configuration (beyond joining the server-side SteelHead to a domain) because delegation mode uses the Active Directory constrained delegation feature. You must configure both the server-side SteelHead and the Windows domain that it joins.
Constrained delegation is an Active Directory feature that enables configured services to obtain security related information for a user. Configuring constrained delegation requires the creation of a special delegate user account in the Windows domain. The account allows the delegate user the privilege of obtaining security information for use with specific applications (like CIFS and MAPI), and then configuring the delegate user credentials on the server-side SteelHead. For details, go to Knowledge Base article
S25759.
Configuring the delegation account (deprecated)
The configure delegation account widget configures a user with trusted delegation rights for a domain.
To configure the delegation account with AD delegation privileges
1. Choose Optimization > Active Directory: Auto Config.
2. Under Auto Config, select Configure Delegation Account.
Easy Config
3. On the server-side SteelHead, complete the configuration as described in this table.
Control | Description |
Admin User | Specify the delegate username. The maximum length is 20 characters. The username can’t contain any of the following characters: / \ [ ] : ; | = , + * ? < > @ " The system translates the username into uppercase to match the registered server realm information. You can only add one delegate user per domain. A delegate user is required in each of the domains where a server is going to be optimized. |
Password | Specify the user account password. |
Delegation Domain/Realm | Select the delegation domain in which you want to make the delegate user a trusted member from the drop-down list. |
Domain Controller | 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.) |
Configure Delegation Account | Click to configure the account. |
After you click
Configure Delegation Account, the status indicates whether the configuration was successful. For details, see
Status and logging.
Configuring the Replication Account
The configure replication account widget adds a user with trusted replication rights to a domain.
To configure the replication account
1. Choose Optimization > Active Directory: Auto Config.
2. Under Auto Config, select Configure Replication Account.
Configure Replication Account
3. On the server-side SteelHead, complete the configuration as described in this table.
Control | Description |
Admin User | Specify the replication username. The maximum length is 20 characters. The username can’t contain any of the following characters: / \ [ ] : ; | = , + * ? < > @ " The system translates the username into uppercase to match the registered server realm information. You can only add one replication user per domain. A replication user is required in each of the domains where a server is going to be optimized. |
Password | Specify the user account password. |
Replication Domain/Realm | Select the replication domain in which you want to make the replication user a trusted member from the drop-down list. You must preconfigure the replication domain; it no replication domain exists, the list displays None. |
Domain Controller | 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.) |
Configure Replication Account | Click to configure the account. |
After you click
Configure Replication Account, the status indicates whether the replication account configuration was successful. For details, see
Status and logging.
Adding the delegation servers (deprecated)
The add delegation servers widget adds delegation servers from either the CIFS or Exchange MDB service.
To add delegation servers
1. Choose Optimization > Active Directory: Auto Config.
2. Under Auto Config, select Add Delegation Servers.
3. On the server-side SteelHead, complete the configuration as described in this table.
Control | Description |
Admin User | Specify the delegate username. The maximum length is 20 characters. The username can’t contain any of the following characters: / \ [ ] : ; | = , + * ? < > @ " The system translates the username into uppercase to match the registered server realm information. You can only add one delegate user per domain. A delegate user is required in each of the domains where a server is going to be optimized. |
Password | Specify the user account password. |
Delegation Domain/Realm | Select the delegation domain in which you want to make the delegate user a trusted member from the drop-down list. |
Domain Controller | 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.) |
Service | Select a service type for delegation: CIFS or Exchange MDB service. |
Server List | Specify the CIFS or MAPI servers as the local hostname, separated by commas. |
Add Delegation Servers | Click to add the servers for delegation. |
After you click Add Delegation Servers, the status indicates whether the configuration was successful.
Removing the delegation servers
The remove delegation servers widget removes delegation servers from either the CIFS or Exchange MDB service.
To remove delegation servers
1. Choose Optimization > Active Directory: Auto Config.
2. Under Auto Config, select Remove Delegation Servers.
3. On the server-side SteelHead, complete the configuration as described in this table.
Control | Description |
Admin User | Specify the domain administrator name assigned to the delegation server. The maximum length is 20 characters. The administrator name can’t contain any of the following characters: / \ [ ] : ; | = , + * ? < > @ " The system translates the administrator name into uppercase to match the registered server realm information. |
Password | Specify the user account password. |
Delegation Domain/Realm | Select the delegation domain in which you want delegate user is a trusted member. |
Domain Controller | 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.) |
Service | Select the delegation service type: CIFS or Exchange MDB service. |
Server List | Specify the CIFS or MAPI servers as the local hostname, separated by commas. |
Remove Delegation Servers | Click to remove the servers from delegation. |
After you click Remove Delegation Servers, the status indicates whether the servers were removed.
Status and logging
After you run a widget, the status indicates one of these states:
• Not Started—The operation has never executed on this SteelHead.
• Success—The last time the operation executed, it completed successfully with no errors.
• Failed—The last time the operation executed, the results were unsuccessful. The operation was not carried out because it ran into an error condition.
• In Progress—The operation is actively running. In this state, the browser constantly polls the back end to see if the operation has completed. Once the operation completes, the browser stops polling.
Last Run displays the amount of time elapsed since the last execution and then the time and date the operation completed. The time is meaningful only if the status is success or failed.
Logging Data displays log output for the operation. You might want to view the log if the status indicates an operation failure. Two log files follow an operation:
• The summary log contains the highlights of the full log.
• The full log contains a detailed record of the operation.
You can control the logging data display using the tabs.
Select Hide Log to remove the logs from the display.
Select the Summary and Full Log tabs to view the logging data. The system displays a line count for the number of lines in the logging data. The system omits the tab if the log file is empty.
• For the summary and full log tabs, an abbreviated form of the time stamp appears in the left margin of each line. Mouse over a time stamp and view the entire time stamp in a tooltip.
Not all log lines have time stamps, because some of the logging data is generated by third-party (non-Riverbed) applications.
• The log highlights line errors in red and warnings in yellow.