About Windows domain authentication

Enabling secure traffic optimization requires communication between server-side SteelHeads and domain controllers. When properly configured, SteelHead can accelerate secure connections in Microsoft environments where:

We recommend WinSec Controller for controller-to-SteelHead communication. However, if you’re using NTLM authentication, you’ll need to join your server-side SteelHead as a trusted entity on the relevant domains.

Active Directory automatic configuration provides a set of Management Console widgets that help simplify the SteelHead configuration necessary to accelerate traffic in a secure environment, and a set of domain health status commands help to troubleshoot and report possible problems with an appliance within a Windows domain environment.

Easy Config configures the appliance to join the Windows Active Directory Domain.

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 Exchange and CIFS servers with permission to delegate AD access privileges.

• Remove Delegation Servers—Removes Exchange and CIFS servers from the list. This is a legacy configuration that has been deprecated.

Kerberos trust authentication, as an alternative to creating and using a specific Kerberos replication users, is useful in trust models with split resource and management Active Directory domains such as Office 365 or other managed service providers.

SteelHeads protect authentication credentials for delegate and replication users by storing them in the appliance’s secure vault. You must unlock the secure vault to view, add, remove, or edit any replication or delegate user configuration details stored on the appliance. New appliances initially lock their secure vault with a default password known only to it. The appliance automatically unlocks the vault during system start up. You can change the password, but the secure vault won’t automatically unlock on start up.

Before you join SteelHead to a domain, verify these items:

• Fully qualified domain name (FQDN), which must be the same as the name that appears in your domain name service (DNS).

• Domain’s short (NetBIOS) name. You must explicitly specify the short name if it doesn’t match the far left portion of the FQDN.

• Primary or auxiliary interface for the server-side SteelHead is routable to the DNS and the domain controller.

• For CIFS, you can ping the server-side SteelHead, by name, from a CIFS server joined to the same domain that the SteelHead has joined. If you can’t, you must manually create an entry in the DNS server for the SteelHead and perform a DNS replication prior to joining it to the domain. The SteelHead won’t automatically register the required DNS entry with the domain controller.

• For CIFS, You must be able to ping the domain controller, by name, from the server-side SteelHead. If you can’t, ensure that the appliance’s host settings for DNS are correct.

• For replication users, verify that the Windows domain functionality is at the Windows 2003 level or higher. If replication users are configured to use password replication policy (PRP), the domain functional level must be Windows 2008 or higher.

When joining an appliance to a domain, it is vital to set the correct time zone. The most common reason for failing to join a domain is a significant difference in the system time between the Windows domain controller and the SteelHead. When the time on the domain controller and the appliance don’t match, this error message appears: