XP/Vista

Password authentication/NTLM

Optimized

Optimized

Optimized

Windows 7

Password authentication/NTLM

Optimized in delegation mode

Optimized in delegation mode

Optimized

XP/Vista

Negotiate authentication/Simple And Protected Negotiate (SPNEGO)

Optimized using NTLM

Optimized using Kerberos

Optimized using NTLM

Windows 7

Negotiate authentication/SPNEGO

Optimized using NTLM in delegation mode

Optimized using Kerberos

Optimized using NTLM

Any client

Kerberos

Passthrough

Optimized

Passthrough

Add a New User

Displays the controls to add a user with trusted delegation rights to a domain.

Active Directory Domain Name

Specify the delegation domain in which you want to make the delegate user a trusted member, for example

Username

Specify the delegate username. The maximum length is 20 characters. The username cannot contain any of these characters:

/ \ [ ] : ; | = , + * ? < > @ "

Password

Specify the user account password.

Password Confirm

Confirm the user account password.

Add

Adds the user.

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.

This is the default setting in RiOS 6.0 and later.

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.

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 do not require SMB signing or MAPI encryption in the text box, separated by commas. By default, this setting is disabled. Only the file servers that do not appear in the list are signed or encrypted.

Apply

Applies your settings.

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:

 

The SteelHead replicates accounts from this domain.

To facilitate configuration, you can use wildcards in the domain name; for example, *.nbttech.com.

You cannot 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. Riverbed recommends 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.

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 cannot contain any of these characters:

/ \ [ ] : ; | = , + * ? < > @ "

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 cannot 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 is 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 that does the authentication. If you allow the users 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:

DC Name

Specify the Windows 2008 or later DC name, which is required when enabling PRP support.

Add

Adds the user.

Enable Kerberos support for restricted trust environments

Enables Kerberos support for restricted trust environments. 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.