Configuring domain authentication manually
The following sections 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.
For details about configuring domain authentication manually, see the white paper Optimizing in a Secure Windows Environment.
Delegation
Follow the procedures in this section after joining a Windows domain and enabling the SMB Signing, HTTP, or MAPI optimization features. For details, see
Configuring SMB signing,
Configuring MAPI optimization, or
Configuring HTTP optimization.
Delegation mode requires that you manually grant the user access to delegate. A delegate user is required in each of the domains where a server is going to be optimized.
To set up the domain controller
• In Windows, create a user in the domain controller responsible for the domain of which the CIFS or MAPI server is a member. Choose Active Directory Users and Computers > Domain Name > Users and create the user (for example, with the name delegate_user). Alternatively, you can select an existing user.
The next step is to create a Service Principal Name for the delegate user.
To create the Service Principal Name (SPN)
• In Windows, create an SPN for the user using the setspn.exe command-line tool. The Windows Server 2003 SP1 Support Tools product CD includes this tool or you can download it from the Microsoft Download Center. With Windows Server 2008 or later, the setspn.exe tool is installed by default. The SPN:
• must be unique because the domain controller (DC) assigns the Kerberos ticket for it.
• cannot be used by another service.
• cannot be cifs/<hostname of domain controller>, or mapi/<hostname of domain controller>, which are used by the CIFS and MAPI services.
To access the setspn.exe tool, open a command window on the domain controller. Then enter the command to add an SPN for the delegate user. For example:
c:\> setspn.exe -A cifs/delegate delegate_user
where
-A
adds the specified SPN to the specified account
cifs/delegate
is the name of the SPN, and
delegate_user
is the name of the delegate user account.
The next step is to grant the user access to delegate for the CIFS or MAPI service in Windows. You must perform this procedure for every server on which you want to enable RiOS SMB signing or Encrypted MAPI.
To grant the user access to delegate
1. Open Active Directory Users and Computers, and select the Delegate User > Properties > Delegation tab.
Note: If the Delegation tab does not appear, raise the Windows domain functionality to the Windows 2003 level or higher and create a Service Principal Name for the delegate user.
2. Select Trust this user for delegation to specified services only and Use any authentication protocol.
3. Click Add.
4. Click Users or Computers.
5. In the Select Users or Computers dialog box, enter the CIFS or MAPI server as the local hostname and click OK.
6. In the Add Services dialog box, select either the CIFS or exchangeMDB service (MAPI) type for delegation and click OK.
After you have performed Steps 1 through 6 for every server on which you want to enable RiOS SMB signing or Encrypted MAPI, the next step is to add delegate users to the server-side SteelHead.
Note: For automatic delegation mode, you do not need to perform Steps 1 through 6 for all servers but you must still configure one CIFS or exchangeMDB service, because one service is required by the Active Directory interface. Also continue with the SteelHead delegate user configuration steps that follow.
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.
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 cannot 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 cannot 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.
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. This is the default setting. |
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 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. 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 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 does not have log on privileges.
Autodelegation mode
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.
This section describes how to grant special privileges to the delegate user so they have automatic delegation rights to servers. The first step is to create a Delegate User with a Service Principal Name (SPN). The procedure to create a delegate user with an SPN is the same for both Windows DC R2 2003 and Windows DC R2 2008. Next, you must grant the delegate user the right to delegate on the domain controller. Because the procedures to grant the delegate user rights on the domain controller (DC) is different for Windows DC R2 2003 and Windows DC R2 2008, the procedures to do so are separate. Next, you must grant the user access to delegate for the CIFS or MAPI service in Windows for at least one server.
Note: A delegate user that is an Administrator already has the correct delegation rights for autodelegation mode.
Note: A delegate user is required in each of the domains where a server is going to be optimized.
Note: If you update the password for the delegate user in Active Directory, you must also update the account information on the SteelHead. To do this, delete the old account and add a new one with the updated password.
To create a delegate user with an SPN
• In Windows, create an SPN for the user using the setspn.exe command-line tool. The Windows Server 2003 SP1 Support Tools product CD includes this tool or you can download it from the Microsoft Download Center. With Windows Server 2008 or later, the setspn.exe tool is installed by default. The SPN:
• must be unique because the domain controller (DC) assigns the Kerberos ticket for it.
• cannot be used by another service.
• cannot be cifs/<hostname of domain controller>, or mapi/<hostname of domain controller>, which are used by the CIFS and MAPI services.
To access the setspn.exe tool, open a command window on the domain controller. Then enter the command to add an SPN for the delegate user. For example:
c:\> setspn.exe -A cifs/delegate delegate_user
where
-A
adds the specified SPN to the specified account
cifs/delegate
is the name of the SPN, and
delegate_user
is the name of the delegate user account.
To grant the delegate user rights in the Controlling Security Group Policy Object (GPO) for Windows DC R2 2008
1. Choose Start > Administrative Tools > Group Policy Management to display the Group Policy Management viewer.
2. Locate the Default Domain Controllers Security Policy and choose Edit to display the Group Policy Management editor.
3. Choose Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
4. In the right pane, Under Policy, right-click Enable computer and user accounts to be trusted for delegation policy.
5. Click Add to display the Add User or Group dialog box.
6. Specify the delegate username and click OK.
7. Click OK to close the Group Policy Management editor.
Now that the delegate user has rights in the Windows 2008 GPO, you must grant the delegate user more privileges to use autodelegation mode. For details, see
To grant the delegate user rights to modify the msDS-AllowedToDelegateTo Active Directory attribute on itself.
To grant the delegate user rights in the Controlling Security Group Policy Object (GPO) in Windows 2003
1. Choose Start > Administrative Tools > Domain Controller Security Policy.
The GPO viewer appears.
2. Choose Security Settings > Local Policies > User Rights Assignment.
3. Right-click Enable computer and user accounts to be trusted for delegation policy.
4. Click Properties.
5. Specify the delegate username.
6. Click OK to add the username.
7. Close the Group Policy Management editor.
8. Click OK to close the Group Policy Management viewer.
Now that the delegate user has rights in the Windows 2008 GPO, the next step is to grant the user access to delegate for the CIFS or MAPI service in Windows. You must perform the procedure for at least one server on which you want to enable RiOS SMB signing or Encrypted MAPI. For details, see
To grant the user access to delegate.
After granting the user access to delegate for at least one server, you must grant the delegate user more privileges to use autodelegation mode. For details, see
To grant the delegate user rights to modify the msDS-AllowedToDelegateTo Active Directory attribute on itself.
To grant the delegate user rights to modify the msDS-AllowedToDelegateTo Active Directory attribute on itself
1. Open the ADSI Edit utility.
2. Choose Start > Run, and open adsiedit.msc.
3. Select Default naming context > Domain DN > CN=Users > CN=<Delegate User>.
4. Right-click CN=<Delegate User> and select Properties.
5. Select the Security tab, select Advanced, and then click Add.
6. Specify the delegate username and click OK.
7. Select the Properties tab in the Permission Entry dialog box.
8. Select the Allow check box next to these privileges:
• Read msDS-AllowedToDelegateTo
• Write msDS-AllowedToDelegateTo
9. Click OK.
10. On the server-side SteelHead, choose Optimization > Active Directory: Service Accounts to display the Service Accounts page.
11. Under NTLM, select Auto.
12. Specify the IP address of any servers you do not want to allow delegated authentication.
13. Click Apply to apply your settings to the running configuration.
14. Click Save to save your settings permanently.
15. Click Restart 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) cannot 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 cannot obtain permissions to access certain required user account attributes, this message appears:
kgetcred: krb5_get_creds: Client (delegate@SIGNING.TEST) unknown
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 provides 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.
RiOS stores 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.
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 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. For details, see Granting replication user privileges on the Domain Controller. 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: / \ [ ] : ; | = , + * ? < > @ " 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 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 of 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: • Configure the replication user on the domain controller (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 sections describe additional procedures necessary to configure PRP support.
Granting replication user privileges on the Domain Controller
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 Domain Controller
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 appliance, choose Networking > App Definitions: Port Labels.
7. Because the client-side appliance has a default in-path rule that bypasses all traffic classified in the secure port label, remove port 88 to allow the appliance to intercept Kerberos traffic instead of bypassing it.
8. Click Apply to apply your settings to the running configuration.
RiOS features 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