Configuring domain authentication manually
The following topics describe the manual configuration on the server-side SteelHead for enabling latency optimizations in a secure environment. We recommend using the automatic configuration as described in
Configuring domain authentication automatically, because it performs these steps automatically. Use this operation instead of the automatic configuration to set up delegate users in Active Directory. After running this operation, you can enable secure protocol optimization for CIFS SMB1, SMB2, SMB3, and encrypted MAPI for all clients and servers.
For an overview of Windows Domain Authentication, see
Windows domain authentication.
Delegation (deprecated)
Historically, with earlier Windows releases, the preferred option was to have the server-side SteelHead join the domain as “Workstation” then use a Delegate User account and authenticate using constrained delegation. However, delegation requires the most administrative effort by both the SteelHead and Windows AD administrators. This configuration option has been deprecated. We strongly recommend using Active Directory Integrated mode due to its simplicity, ease of configuration, and low administrative maintenance.
To add NTLM delegate users on the SteelHead
1. On the server-side SteelHead, choose Optimization > Active Directory: Service Accounts to display the Service Accounts page.
Figure: Adding a New Delegate User
2. Under NTLM Users with Delegation Rights, complete the configuration as described in this table.
Control | Description |
Add a New User | Displays the controls to add a user with trusted delegation rights to a domain. Note: 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. |
Active Directory Domain Name | Specify the delegation domain in which you want to make the delegate user a trusted member, for example: SIGNING.TEST Note: You can’t specify a single-label domain name (a name without anything after the dot), as in riverbed instead of riverbed.com. |
Username | Specify the delegate username. The maximum length is 20 characters. The username can’t contain any of these characters: / \ [ ] : ; | = , + * ? < > @ " Note: The system translates the username into uppercase to match the registered server realm information. |
Password | Specify the user account password. |
Password Confirm | Confirm the user account password. |
Add | Adds the user. |
3. Click Apply to apply your settings to the running configuration.
To set up manual delegation (specifying each server allowed to delegate), continue to the next procedure.
To set up automatic server detection, see
Autodelegation mode (deprecated).
To specify manual delegation mode and allowed servers using NTLM
1. On the server-side SteelHead, choose Optimization > Windows Domain Auth to display the Windows Domain Auth page.
2. Under NTLM, complete the configuration as described in this table.
Control | Description |
Delegation Mode: Manual | Select to enable transparent authentication using NTLM and provide more control to specify the exact servers to perform optimization for. When you select this mode, you must specify each server on which to delegate and sign for each domain using the Delegate-Only and Delegate-All-Except controls. |
Delegation Mode: Auto | Select to enable delegate user authentication and automatically discover the servers on which to delegate and sign. Automatic discovery eliminates the need to set up the servers on which to delegate and sign for each domain. This mode requires additional configuration. For details, see autodelegation mode. A delegate user is required in each of the domains where a server is going to be optimized. |
Allow delegated authentication to these servers (Delegate-Only) | Click to intercept the connections destined for the servers in this list. By default, this setting is enabled. Specify the file server IP addresses for SMB signed or MAPI encrypted traffic in the text box, separated by commas. Note: You can switch between the Delegate-Only and Delegate-All-Except controls without losing the list of IP addresses for the control. Only one list is active at a time. |
Allow delegated authentication to all servers except the following (Delegate-All-Except) | Click to intercept all of the connections except those destined for the servers in this list. Specify the file server IP addresses that don’t require SMB signing or MAPI encryption in the text box, separated by commas. By default, this setting is disabled. Only the file servers that don’t appear in the list are signed or encrypted. Note: You must register any servers not on this list with the domain controller or be using autodelegation mode. |
3. Click Apply to apply your settings to the running configuration.
4. Click Save to Disk to save your settings permanently.
5. If you change the delegation mode, you must restart the optimization service.
Note: A delegate user with access to the CIFS and exchangeMDB (MAPI) service doesn’t have log on privileges.
Autodelegation mode (deprecated)
Historically, with earlier Windows releases, the preferred option was to have the server-side SteelHead join the domain as “Workstation,” use a Delegate User account, and authenticate using constrained delegation. However, delegation requires the most administrative effort by both the SteelHead and Windows AD administrators. This configuration option has been deprecated. We strongly recommend using Active Directory Integrated mode due to its simplicity, ease of configuration, and low administrative maintenance.
Delegation mode automatically updates the delegate user in Active Directory with delegation rights to servers. The service updates the user in real-time, eliminating the need to grant the user access to delegate on every server. Auto-delegation mode also updates the server IP address if it changes.
The following section describes the configuration on the server-side SteelHead.
1. On the server-side SteelHead, choose Optimization > Active Directory: Service Accounts to display the Service Accounts page.
Figure: Selecting Autodelegation Mode After Granting Delegate User Privileges
2. Under NTLM, select Auto.
3. Specify the IP address of any servers you don’t want to allow delegated authentication.
4. Click Apply to apply your settings to the running configuration.
5. Click Save to Disk to save your settings permanently.
6. Click Restart Services to restart the optimization service.
Troubleshooting delegate users
This section provides information on troubleshooting the delegate user set up, if necessary.
• When the CIFS or exchangeMDB service (MAPI) can’t obtain a delegate user’s credentials, this message appears:
kinit: krb5_get_init_creds: Clients credentials have been revoked
This message indicates that Login Denied is set for the delegate user for the entire day. To verify when the delegate user has permission to log in, select the Account tab in the Delegate User Properties dialog box and click Logon Hours.
• When the CIFS or exchangeMDB service can’t obtain permissions to access certain required user account attributes, this message appears:
kgetcred: krb5_get_creds: Client (delegate@SIGNING.TEST) unknown
Add the delegate user to the Windows Authorization Access group. For details, see
Configuring replication users (Kerberos)
Kerberos end-to-end authentication relies on Active Directory replication to obtain machine credentials for any servers that require secure protocol optimization. The RiOS replication mechanism requires a domain user with AD replication privileges, and involves the same AD protocols used by Windows domain controllers. These procedures explain how to configure replication to use Kerberos authentication for these features:
• SMB signing
• SMB2 or SMB3 signing
• Encrypted MAPI and encrypted Outlook Anywhere
• HTTP or HTTP-based traffic
Kerberos one-way trust in RiOS 8.5 and later provide an alternative to creating and using a specific Kerberos replication user for trust models with split resource and management Active Directory domains, such as Office 365 or other managed service providers.
To enable Kerberos authentication for restricted trust environments, see
To enable one-way trust using Kerberos. To join the server-side SteelHead as an integrated Active Directory, see
Easy domain authentication configuration.
For details about restricted trust configurations, see the SteelHead Deployment Guide.
To add Kerberos replication users on the SteelHead
1. On the server-side SteelHead, choose Optimization > Active Directory: Service Accounts to display the Service Accounts page.
Figure: Adding a replication user
SteelHeads store authentication credentials for delegate and replication users in the secure vault. To unlock the secure vault, choose Administration > Security: Secure Vault and click Unlock Secure Vault.
To migrate previously configured authentication credentials to the secure vault after upgrading from a RiOS version of 6.5.x or earlier, enter this CLI command at the system prompt:
protocol domain-auth migrate
For details, see the Riverbed Command-Line Interface Reference Manual.
2. Under Kerberos Replication Users, complete the configuration as described in this table.
Control | Description |
Add a New User | Displays the controls to add a user with replication privileges to a domain. You can add one replication user per forest. |
Active Directory Domain Name | Specify the AD domain in which you want to make the replication user a trusted member. For example: SIGNING.TEST The SteelHead replicates accounts from this domain. To facilitate configuration, you can use wildcards in the domain name: for example, *.nbttech.com. You can’t specify a single-label domain name (a name without anything after the dot), as in riverbed instead of riverbed.com. |
User Domain | Specify the domain the user belongs to, if different from the Active Directory domain name. We recommend that you configure the user domain as close to the root as possible. |
Username | Specify the replication username. The user must have privileges to change the replicate directory. For details, see Granting replication user privileges on the DC. The username can be an administrator. A replicate user that is an administrator already has the necessary replication privileges. The maximum username length is 20 characters. The username can’t contain any of these characters: / \ [ ] : ; | = , + * ? < > @ " Note: The system translates the username into uppercase to match the registered server realm information. |
Password | Specify the user account password. |
Password Confirm | Confirm the user account password. |
Enable Password Replication Policy Support | When you deploy the server-side SteelHead for optimizing traffic in a native Kerberos environment, and configure it in Active Directory integrated mode, you can optionally limit its scope when you configure a PRP in the Windows domain. In this way, the SteelHead can only replicate accounts as permitted by the PRP rules. However, this can create additional administrative overhead in managing the PRP. You can’t configure PRP in Windows 2003 domains. A Windows server using Active Directory integration caches user and computer accounts performing authentication locally. The PRP is essentially a set rules describing which accounts the server is allowed to replicate. When PRP is enabled, the server-side SteelHead only replicates accounts that it’s allowed to as determined by PRP settings for the domain. When a user account is not cached locally, the server forwards the authentication to a writeable domain controller (DC) that does the authentication. If you allow the user’s password to be cached, then the server pulls that through a replication request. After the user is authenticated, the server caches the user password and handles any subsequent logins locally. Enabling a password replication policy (PRP) requires additional configuration in Windows: • Configure the replication user on the DC. • Check the domain functional level. • Configure PRP support on the DC. |
DC Name | Specify the Windows 2008 or later DC name, which is required when enabling PRP support. |
Add | Adds the user. |
3. Click Apply to apply your settings to the running configuration.
The following topics describe additional procedures necessary to configure PRP support.
Granting replication user privileges on the DC
1. In Windows, open Active Directory Users and Computers and choose Start > Administrative Tools > Active Directory Users and Computers.
2. Select the domain name, right-click, and select Delegate Control.
3. Select one or more users to whom you want to delegate control, and click Add.
4. Click Next.
5. Select Create a custom task to delegate and click Next.
6. Select This folder, existing objects in this folder, and creation of new objects in this folder. Click Next.
7. Select General > Replicate Directory Changes.
8. Select Replicate Directory Changes All and click Next.
9. Click Finish if the correct groups and users appear with the permissions Replicating Directory Changes and Replicate Directory Changes All.
Verifying the domain functional level
Verify that the current domain functional level is Windows 2008 or later. See
Verifying the domain functional level and host settings. For details on functional level support, see the
SteelHead Deployment Guide - Protocols.
Configuring PRP on the DC
The final step in configuring replication users is to add users to either the allowed password replication group or the denied password replication group.
1. Choose Start > Administrative Tools > Active Directory Users and Computers, select the domain name, right-click, and select Users.
2. Select either the Allowed RODC Password Replication Group or the Denied RODC Password Replication Group, select the members, and click Add.
3. Click OK.
Enabling Kerberos in a restricted trust environment
This section describes an alternative to creating and using a specific Kerberos replication user for environments with restricted security. Kerberos restricted trust includes trust models with split resource and management Active Directory domains such as Office 365 or other managed service providers.
For details about restricted trust configurations, see the SteelHead Deployment Guide - Protocols.
Windows XP clients must use TCP for Kerberos in a one-way trust configuration. By default, Kerberos uses UDP. You must change UDP to TCP in a Registry setting.
To enable one-way trust using Kerberos
1. To verify that the Active Directory environment has a one-way trust configuration, open Active Directory Domains and Trusts, right-click Account/Resource Domain, select Properties, and then select Trusts. From the account domain perspective, you should see an incoming trust from the resource domain. From the resource domain perspective, you should see an outgoing trust to the account domain.
For details on one-way trust configurations, see SteelHead Deployment Guide - Protocols.
2. If you have not previously configured signing or eMAPI on the server-side SteelHead, choose Optimization > Active Directory: Config Domain Auth to walk through these configuration steps:
• Point DNS to the DNS server
• Join a domain
• Enable signing or eMAPI
• Configure transparent or delegation mode
• Configure replication
• Enable end-to-end Kerberos for signing or eMAPI
3. On the server-side SteelHead, choose Optimization > Active Directory: Service Accounts.
4. Under Kerberos, select the Enable Kerberos support for restricted trust environments check box.
5. Click Apply to apply your settings to the running configuration.
6. On the client-side SteelHead, choose Networking > App Definitions: Port Labels.
7. Because the client-side SteelHead has a default in-path rule that bypasses all traffic classified in the secure port label, remove port 88 to allow the SteelHead to intercept Kerberos traffic instead of bypassing it.
8. Click Apply to apply your settings to the running configuration.
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.
Related topics