You must add the CloudBridge appliance to the Windows security infrastructure before you can optimize the signed Windows file system and encrypted MAPI Outlook/Exchange traffic.
As a result of enhancements to the Windows security system in the recent Windows releases, clients and servers secure the traffic by authenticating and encrypting data. This requires the CloudBridge appliance be a trusted member of the Windows security infrastructure before it can optimize signed Windows file system and encrypted MAPI Outlook/Exchange traffic.
Joining the appliance to a Windows domain requires administrator credentials. When it joins the Windows domain, the appliance becomes a trusted member of the domain. This allows the appliance to be declared a member of the domain's security infrastructure.
After the appliance has become a part of the Windows security infrastructure, users have to be authenticated before they can access resources. To avoid the difficulty of configuring a large number of users in the domain, you can delegate the authentication responsibility to a delegate user.
You create a delegate user in the active directory. This user is similar to a normal user, but with special privileges. After creating the delegate user, you must configure this user on the CloudBridge appliance. The appliance uses the delegate user to authenticate on behalf of users when they access authenticated and encrypted data streams using Windows protocols, such as CIFS and MAPI.
For accelerating CIFS and MAPI traffic, the standard Windows delegation mechanism allows you to limit security delegation to the relevant services. This constrained delegation has been available since the release of Windows Server 2003.
After becoming a part of the domain, the appliance accelerates the secure Windows traffic. A datacenter appliance that joins a Windows domain must have a secure peer relationship with the remote appliance or CloudBridge Plug-in, but only the datacenter appliance joins the Windows domain. For purposes of CIFS or MAPI acceleration, the remote appliance acts as a slave to the datacenter appliance, being controlled over the secure SSL tunnel between the two. Therefore, the delegate user credentials do not leave the datacenter.
The following figure shows a sample topology diagram for this setup.
In Figure 1, a branch office client accesses resources of the datacenter. The branch office client, being in another domain, uses NTLM authentication as a part of the Windows security system. As with all accelerated connections between two CloudBridge appliances in a secure peer relationship, the CIFS or MAPI connections and NTLM authentications over the WAN are encrypted. Depending on the Windows domain controller version, the user request from the datacenter CloudBridge appliance is authenticated using NTLM or Kerberos authentication protocol. After the domain authenticates the user, subsequent access requests to the Exchange server and file servers use Kerberos authentication protocol. The CloudBridge appliance then optimizes the connections established between the client and the server.
If the appliances do not have a secure peer relationship, or if the datacenter appliance has not successfully joined the domain, the connections use TCP flow-control acceleration, which performs no security operations, compression, or data transformations. The connections between the client and server are established as if the CloudBridge appliances were not there.
You can configure different client authentication modes on Windows operating systems. The types of connections that the CloudBridge appliance optimizes depend on the client authentication mode that you configure.
The following table list the Windows client-authentication modes on Windows, and the corresponding CloudBridge optimizations.
|Client Operating System||Client Authentication Mode||Optimization||Comments|
|Windows XP/Windows Vista/Windows7/Windows 8||Negotiate Authentication (SPNEGO)||
||Default setting used for all Windows releases.|
|Windows XP/Windows Vista/Windows 7/Windows 8||NTLM only or Kerberos only||
||Non-default authentication modes|
To optimize secure Windows traffic, the CloudBridge appliance must be a part of the Windows security system and must authenticate itself with the security system or domain. As shown in Figure 2, to make the appliance a part of the Windows security system, you must make the appliance join a domain (using administrative credentials). Additionally, you need to configure a new or existing user as a delegate user by associating CIFS and Exchange services with that user. You then have to configure this delegate user on the CloudBridge appliance.
You can use the Pre Domain Check utility to find out if there are any issues with joining the appliance to a domain.
When the appliance joins the domain, it exchanges a shared secret with the domain controller, allowing the appliance to remain part of the domain indefinitely. When joining an appliance to a domain, make sure that you have administrator credentials for the domain controller.
To make sure that the CloudBridge appliance optimizes the CIFS and MAPI traffic (including traffic encapsulated as RPC over HTTPS), you must make the appliance part of the domain that the Windows fileserver and Exchange server are a part of. You need to join the server-side appliance to the domain.
Setting up user authentication by using Kerberos delegation involves two tasks——configuring a delegate user on the domain controller and then adding this user to the CloudBridge appliance.
Before you configure a delegate user on a CloudBridge appliance, you must configure a delegate user with the required properties on the domain controller. You can either create a delegate user account or use an existing user account as a delegate user account.
After creating an account or selecting an existing account, enable delegation for this user. You then associate the delegate user with the CIFS and Exchange services, so that the traffic for these services can be accelerated. After you add this user to the CloudBridge appliance, the appliance presents delegated credentials for the services associated with this account.
If, after adding the appliance to the domain, you notice that the appliance is not optimizing secure Windows traffic, some error might have prevented the appliance from joining the domain. You can use the Pre Domain Check utility to find out if there are any issues with the appliance joining the domain. You can even run this utility to identify possible issues before you attempt to join the appliance to a domain.