Riverbed Windows Security Guide
Riverbed Windows Security Guide
September 2013
September 2013
September 2013
Automatic configuration
Starting with RiOS v8.5, there is the ability to configure a lot of the settings described in this document by using the Domain Auth
Easy Config and Auto Config widgets. The Domain Auth Easy Config widget is a single point of configuration allowing the
Steelhead appliance administrator to enter some Active Directory details along with desired optimization requirements. Then by
pressing a button, the widget completes the join domain, customizes the delegate user or replication user account settings in AD
and selects the correct Steelhead appliance optimization settings for relevant signed/encrypted SMB versions and encrypted
MAPI.
It is still the Steelhead appliance administrators responsibility to decide which settings are required. The Domain Auth Easy
Config widget will not automatically choose the correct settings, but once the settings are selected, the widget will do all the
configuration tasks automatically. This can significantly reduce the number of manual tasks required thereby minimizing the
potential for typographical errors. The Domain Auth Easy Config widget provides feedback in the form of an activity log as the
tasks progress to completion.
2 If you configure the Steelhead appliance to join with Windows 2003 mode or Windows 2008 mode, it does not provide any
Windows domain controller functionality to any machines in the domain, does not respond to requests, does not advertise itself as a
domain controller and does not register any SRV records. In addition, the Steelhead appliance does not perform any replication nor
hold any AD objects. For more details, consult the relevant section of the Riverbed Deployment Guide Protocols edition.
September 2013
In each of the configuration sections (sections 1, 2 and 3) of this document, all the manual tasks are described. If you are planning
to use the Domain Auth Easy Config widget, a few manual tasks are still needed to ensure the widget is successful. At the
beginning of each section is a list of the tasks needed before using Domain Auth Easy Config.
For the reader who would like to take a quick look at the graphical interface of the widget, there is an example screenshot in the
appendix of this document. Detailed information on how to use the widget is described in the Riverbed Steelhead Management
Console User Guide for RiOS v8.5.
September 2013
1.2 - Associate the Delegate User with the CIFS or Exchange service and enable delegation for the user
Still on the Windows Domain Controller, create a Service Principal Name (SPN) for the delegate user using the [Link]
command-line tool. Once the setspn command has been executed for the delegate user, it makes the Delegation configuration
tab available in the user account properties. It is via this configuration tab that delegation is enabled for the delegate user. The
Windows support tools must be installed on the Domain Controller in order for the [Link] utility to be available. 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 [Link] tool is installed by default.
To access the [Link] tool, open a command window (cmd) on the Domain Controller. Then use the following command
syntax to add an SPN for the Delegate User
C:\> setspn A <service name>/delegate <delegate user name>
Where <service name> is either cifs for signed SMB, or exchangeMDB for encrypted MAPI, and <delegate user
name> is the name of the Delegate User created in the previous step for example delegate_rvbd.
Figure 1-2-1 shows an example screenshot of running the setspn command for both types of service.
1.2.1
Returning to the Active Directory Users and Computers > Domain Name > Users admin tool that was used in
task 1.1, open the Properties for the user and select the Delegation tab
September 2013
September 2013
1.2.2
Enable the two settings; Trust this user for delegation services to specified services only and Use any
authentication protocol
At this point the Delegate User is ready to be used. If the requirement is for Manual Delegation, the Service field in the lower half
of this Delegation tab needs to be populated with a list of all the signed SMB, signed SMB2, signed SMB3 and encrypted
Exchange servers for this domain. This can be done using the Add button.
If Auto Delegation is to be used, this list does not need to be populated, however, due to the way that this Windows admin tool
works, it is not possible to select Apply and OK to close this Properties tool without adding at least one service. Therefore the
next steps must be performed at least once to add a service regardless of whether Manual or Auto delegation is to be used.
1.2.3
For Auto delegation, the easiest thing to do is choose any one of the servers. In this example, we will select a
signed SMB (cifs) server called BW-W2K8EXDC1.
September 2013
1.2.4
1.2.5
As shown in Figure 1-2-4, select Add in the Delegation tab, then Users or Computers.
Enter the hostname of the server, in this example it is called BW_W2K8EXDC1
1.2.6
September 2013
Select the cifs service (Figure 1-2-5), click OK, and the task is complete as shown in Figure 1-2-6.
1.3 - Configure Delegate User permissions to automatically delegate only with the chosen services
Still on the Windows Domain Controller, use the Group Policy Management tool to add the Delegate user to the Group Policy
Object (GPO) for the domain.
1.3.1
Navigate to Start Menu > Administrative Tools > Group Policy Management Editor
1.3.2
Navigate to the Domain Controllers Policy.
1.3.3
Open the Default Domain Controller Policy or your policy for the domain controllers.
1.3.4
Navigate down through Computer Configuration > Policies > Windows Settings > Security Settings > Local
Policies
1.3.5
Select User Rights Assignment
1.3.6
In the right-hand window, select and right-click on Enable computer and user accounts to be trusted for
delegation to open the properties dialogue box.
1.3.7
In the Security Policy Setting tab, select Add User or Group
1.3.8
Enter the Delegate User name into the User and group names field.
1.3.9
Click OK out of the Group Policy Management tool.
Figures 1-3-1, 1-3-2a and 1-3-2b below show an example series of screenshots for the above sequence of steps.
September 2013
September 2013
Figure 1-3-2a: Group Policy Management tool screenshots. Add User, in progress
Figure 1-3-2b: Group Policy Management tool screenshots. Add User, completed
10
September 2013
Continuing the Delegate User configuration, the Delegate User now needs to be granted Allow access to modify the Active
Directory attribute msDS-AllowedToDelegateTo. Use the Active Directory Service Interfaces (ADSI) edit utility to achieve this.
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
Figures 1-3-3 and 1-3-4 show an example series of screenshots for the above sequence of steps.
11
September 2013
If you need help troubleshooting, please also refer to the Troubleshooting Delegate Users section in the latest version of the
Steelhead Management Console Users Guide.
_______________________________________________________________________________________________________
Note: Section 1.2 and section 1.3 above will need to be completed for each Delegate User created in each domain.
_______________________________________________________________________________________________________
12
Setting
September 2013
Value
Step conpleted
Once the prerequisites are completed, join the server-side Steelhead to the AD domain.
To complete this step you will need a Windows user account with rights to join a host to the AD domain. NOTE: This account has
nothing to do with the Delegate User account set up in the previous sections. The credentials of the account used to join the
domain are not stored on any Steelhead appliance and are only used for the purposes of joining the Steelhead appliance to the
domain.
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
On the server-side Steelhead(s) navigate to Configure > Networking > Windows Domain.
Enter the Active Directory Domain name, user id (of the user account with Join Domain
privileges), password and optionally the DC name and Short Domain Name.
Select the Join Account Type. Depending on the version of RiOS running on the Steelhead appliance there may be
several options available. When configuring for constrained delegation, any join type is suitable.
Next click the Join button at the bottom of the page and wait for feedback. If an error appears, take appropriate
action.
Once successfully joined you will see the statement In Domain Mode, status: In a domain in the top frame of the
page.
13
September 2013
Figure 1-4-1: Example screenshot, Windows Domain page of Steelhead appliance GUI
Further details on joining a Windows Domain are available in the Steelhead Management Console Users Guide in the chapter
Configuring Network Integration Features.
More recent versions of RiOS include tools to test the configuration settings and ensure a join is successful as well as a status log
to show progress and any errors encountered during the join process.
On the server-side Steelhead(s) navigate to Configure > Optimization > Windows Domain Auth.
14
September 2013
1.5.2
Click the Add a New User tab. Enter the AD domain, delegate user account name, and password.
Figure 1-5-2: Add New Delegate User section on Windows Domain Auth page of Steelhead appliance GUI
1.5.3
Figure 1-5-3: Add New Delegate User section on Windows Domain Auth page of Steelhead appliance GUI
1.5.4
1.5.5
Repeat steps 1.5.2 and 1.5.3 for each delegate user that has been created ensuring that the correct domain name
is included in each case.
In the Server Rules section, select the Auto Delegation Mode radio button and enter any server names that
should not allow delegated authentication. This field can be left blank unless there is an explicit need to prevent the
use of delegation to some servers.
15
September 2013
Figure 1-5-4: Delegation Mode setting on Windows Domain Auth page of Steelhead appliance GUI
1.5.6
1.6 - Configure the Steelhead appliance to optimize Signed SMB and Encrypted MAPI
1.6.1
- Configuration steps for Signed SMB, Signed SMB2 and Signed SMB3
On the server-side Steelhead appliance, navigate to Configure > Optimization > CIFS (SMB1).
For RiOS versions prior to v6.5 if there are connections between Vista/Win7 clients and Windows 2008 R2 servers,
select the Enable SMBv1 Backward Compatibility check box. This will revert SMBv2 connections between
Vista/Win7 clients and Windows 2008 R2 servers back to SMBv1 allowing the Steelhead appliances to provide full
application layer acceleration for CIFS. This will provide a better experience for remote users compared to native
SMBv2 without optimization.
_______________________________________________________________________________________________________
[Link]
[Link]
Note: Consider upgrading to RiOS v6.5 for native optimization of SMB2. It is also worth noting that SMB2 provides extra security
for signing as it uses HMAC SHA-256 instead of MD5.
_______________________________________________________________________________________________________
[Link]
[Link]
[Link]
If the Steelhead appliance is running RiOS v6.5 or later, there is a separate SMB2 configuration page located at
Configure > Optimization > SMB2. With optimization for SMB2 enabled there is no need to select the Backward
Compatibility option indicated in step [Link] above. If the Steelhead is running RiOS v8.5 or later, there is the
option to enable SMB3 optimization. This setting is included on the SMB2 configuration page of the GUI.
Under the SMB Signing, check the Enable SMB Signing checkbox.
Next select the Delegation Mode radio button.
Figure 1.6.1-1: Enable SMB Signing section on CIFS Optimization page of Steelhead appliance GUI
[Link]
[Link]
16
September 2013
On all Steelhead appliances (client-side and server-side) navigate to Configure > Optimization > MAPI.
On Steelhead appliances running RiOS earlier than v6.5, select Enable MAPI Exchange 2000 Optimization
Enable MAPI Exchange 2003 Optimization and Enable MAPI Exchange 2007+ Optimization checkboxes.
_______________________________________________________________________________________________________
[Link]
NOTE: On Steelhead appliances running RiOS 7.0 or later, these individual checkboxes have been replaced with a single Enable
MAPI Exchange Optimization checkbox.
_______________________________________________________________________________________________________
[Link]
[Link]
[Link]
[Link]
17
September 2013
Once deployed successfully, monitor performance and health of the Steelhead appliance(s) to ensure proper optimization is
occurring and full acceleration is being achieved for the appropriate clients and servers. Keep in mind AD and Windows
administrators may make changes without notifying the networking team, so remain vigilant. Consider incorporating some of this
configuration information into a Change Control Process that enables both the Windows Server Administration team and the
Networking team to coordinate future updates and changes.
Appendix B in this document has some outline guidance for troubleshooting as well as pointers to other sources of help.
18
September 2013
2.2 - Configure the Replication User with limited privileges for replication
Once the replication user account has been created, it can then be assigned the limited privileges needed to perform replication.
This task is performed on the Domain Controller using the Delegation of Control Wizard. The steps are illustrated in this next
section using example screenshots.
2.2.1 On the Domain Controller, navigate to Start Menu > Administrative Tools > Active Directory Users and Computers
then select the domain name where the replicate user account resides.
2.2.2 - Right-click on the domain name and select Delegate Control. This launches the Delegation of Control Wizard.
19
September 2013
2.2.3 Click Next and Add to add the replication account user name as shown in the next three screenshots. Note that the
example below includes the replication user account name replicate_rvbd in the domain [Link]. These values may be
different for your specific configuration.
20
September 2013
.
Figure 2-2-3: Delegation of Control Wizard, Users or Groups
21
September 2013
2.2.4 Click Next to be able to configure the replication user account with the limited privileges needed to perform its task.
Notice by default that the wizard offers a list of common tasks. These are too generic for the requirements of the replication user
account and therefore as shown in figure 2-2-6 select Create a custom task to delegate.
22
September 2013
2.2.5 Click Next to be able to select the delegation control. Keep the default option; Delegate control of: This folder, existing...
2.2.6 Click Next to select the delegation permissions. By default, the wizard shows the General permissions. Scroll down the
Permissions: window and select Replicating Directory Changes and Replicating Directory Changes All as indicated in the next
two screenshots, figures 2-2-8 and 2-2-9.
23
September 2013
Figure 2-2-9: Delegation of Control Wizard, permissions, Replicating Directory Changes All
2.2.7 Click Next to complete the replication user account configuration and display a summary. The screenshot in figure 2-2-10
shows the final stage of the Delegation of Control Wizard. It displays the user account name and the permissions allocated to it.
There should only be two permissions. This restricts the replication user to a very limited range of capability but is sufficient for the
Steelhead appliance to perform its functions.
24
September 2013
Notice in the above screenshot that the replication user account and domain name are for illustration purposes only. Your account
name and domain will be different, but the permissions will be the same as shown here.
2.2.8 Click Finish to close the wizard.
25
September 2013
2.3.2 Depending on the type of PRP you wish to create, select either the Allowed or Denied group and right-click to open up
the group properties.
Then click Add and enter in the user(s) or computer(s) that you wish to exclude or include. When you have completed the list
click OK to complete the task.
See example screenshots in figure 2-3-2.
26
September 2013
Setting
Value
Step conpleted
Once the prerequisites are completed, join the server-side Steelhead to the AD domain.
To complete this step you will need a Windows user account with rights to join a host to the AD domain. NOTE: This account has
nothing to do with the Replication User account set up in the previous sections. The credentials of the account used to join the
domain are not stored on any Steelhead appliance and are only used for the purposes of joining the Steelhead appliance to the
domain
2.4.1
2.4.2
On the server-side Steelhead(s) navigate to Configure > Networking > Windows Domain.
Enter the Active Directory Domain name, user id (of the user account with Join Domain
27
2.4.3
2.4.4
2.4.5
September 2013
privileges), password and optionally the DC name and Short Domain Name.
Select the Join Account Type as either Workstation, Active Directory Integrated Windows 2003, or Active
Directory Integrated Windows 2008. Whether you choose 2003 or 2008 mode depends on the domain functional
level. If you choose Workstation it will not be possible to perform NTLM pass-through authentication.
Next click the Join button at the bottom of the page and wait for feedback. If an error appears, take appropriate
action.
Once successfully joined you will see the statement In Domain Mode, status: In a domain in the top frame of the
page.
Figure 2-4-5: Example screenshot, Windows Domain page of Steelhead appliance GUI
Further details on joining a Windows Domain are available in the Steelhead Management Console Users Guide in the chapter
Configuring Network Integration Features.
More recent versions of RiOS include tools to test the configuration settings and ensure a join is successful as well as a status log
to show progress and any errors encountered during the join process.
28
September 2013
On the server-side Steelhead(s) navigate to Configure > Optimization > Windows Domain Auth.
2.5.2
In the Kerberos Replication Users section, click the Add a New User tab. Enter the AD domain, User Domain,
replication user account name, and password.
Figure 2-5-2: Add New Replication User section on Windows Domain Auth page of Steelhead appliance GUI
2.5.3
Figure 2-5-3: Add New Delegate User section on Windows Domain Auth page of Steelhead appliance GUI
2.6
Configuration steps for Signed SMB, Signed SMB2 and Signed SMB3
2.6.1
2.6.2
2.6.3
On the server-side Steelhead navigate to Configure > Optimization > CIFS (SMB1).
Under the SMB Signing section, check the Enable SMB Signing checkbox.
Next check the Enable Kerberos Authentication checkbox.
29
September 2013
Figure 2-6-3: Enable SMB Signing section on CIFS Optimization page of Steelhead appliance GUI
2.6.4
2.6.5
2.6.6
2.6.7
Figure 2-6-8: Enable SMB2 Signing section on SMB2 Optimization page of Steelhead appliance GUI
30
September 2013
31
September 2013
32
September 2013
Section 3 Configuring the server-side Steelhead with limited domain controller privileges
Overview of required configuration tasks for providing limited domain controller privileges
There are a number of tasks to be performed and parameters to be configured. They are listed here;
3.1 Join server-side Steelhead appliance to Windows Domain
3.2 Configure the Steelhead appliance to optimize Signed SMB and Encrypted MAPI
If you are planning to use the Domain Auth Easy Config widget, complete the following tasks first..
DNS and NTP configuration as outlined in Table 3-1
The Domain Auth Easy Config widget will complete tasks 3.1 and 3.2 with the exception of any client-side Steelhead appliance
configuration. Any configuration on the client-side Steelhead appliance(s), for example enabling encrypted MAPI, will need to be
done as a separate task.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------NOTE: If you have already completed the configuration tasks in Section 2 (End to end Kerberos authentication) and, when
performing the join domain task, you joined as Active Directory integrated you do not need to complete any of the steps in this
section.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Setting
Value
Step conpleted
Once the prerequisites are completed, join the server-side Steelhead to the AD domain.
This task will require administrator level access (an account that is a member of the Domain Admins group, or a preconfigured
account with sufficient privileges) to a Windows Domain controller and admin level access to the Riverbed Steelhead appliance.
Therefore the appropriate personnel with the relevant access privileges will need to be on hand to perform the task. Administrator
credentials are not stored on any Steelhead appliance. While this task is all that is needed to meet the basic requirements, there
may be other steps to enable proper functionality with, for example; one-way trusts, organisational unit, password expiration, etc.
Information on these additional items is to be found in the appendices of this document.
For more details on what capabilities the server-side Steelhead has when joined in this role, please consult the section at the
33
September 2013
beginning of this guide entitled What configuration options are available and how do I choose?.
On the server-side Steelhead(s) navigate to Configure > Networking > Windows Domain.
Enter the Active Directory Domain name, user id [for the user account with Join Domain
Privileges] and its password.
3.1.3
Select the Join Account Type as either Active Directory Integrated Windows 2003, or Active Directory Integrated
Windows 2008. Whether you choose 2003 or 2008 mode depends on the domain functional level . Figure 3.1.3 below
shows an example screenshot.
3.1.1
3.1.2
Figure 3-1-3: Example screenshot, Windows Domain page of Steelhead appliance GUI
3.1.4
3.1.5
3.1.6
Enter the Domain Controller names or IP addresses of the nearest DCs. This ensures a quicker join especially in
high latency networks. For 2008 or greater, and mixed domain types, the DCs must be the 2008(-R2) instances in
the domain. When joining in 2008 mode it is strongly advised to provide one or more DCs in this field. If the
domain is a mix of 2003 and 2008, then the Domain Controllers specified must be the 2008 type and not 2003 type.
-------------------------------------------------------------------------------------------------------------------------------------------------------NOTE: Although, the Steelhead will probably perform a successful join without having the domain controllers
specified (a discovery is used), it is very strongly recommended that the correct details are entered in this field.
Failure to do so can lead to intermittent but persistent authentication failures, especially in large domain structures.
-------------------------------------------------------------------------------------------------------------------------------------------------------Next click the Join button at the bottom of the page and wait for feedback. If an error appears, take appropriate
action.
Once successfully joined you will see the statement In Domain Mode, status: In a domain in the top frame of the
page.
34
September 2013
Figure 3-1-6: Example screenshot, Windows Domain page of Steelhead appliance GUI
Further details on joining a Windows Domain are available in the Steelhead Management Console Users Guide in the chapter
Configuring Network Integration Features.
More recent versions of RiOS include tools to test the configuration settings and ensure a join is successful as well as a status log
to show progress and any errors encountered during the join process.
On the server-side Steelhead navigate to Configure > Optimization > CIFS (SMB1).
Under the SMB Signing section, check the Enable SMB Signing checkbox
Ensure the NTLM Transparent Mode option is selected
35
September 2013
Figure 3-2-3: Enable SMB Signing section on CIFS Optimization page of Steelhead appliance GUI
3.2.4
3.2.5
3.2.6
3.2.7
3.2.8
Figure 3-2-8: Enable SMB2 Signing section on SMB2 Optimization page of Steelhead appliance GUI
3.2.9
3.2.10
36
September 2013
3.2.12
3.2.13
37
September 2013
# domain join domain-name <domain> login <username> password <********> org-unit <OU>
Where <domain> is the domain name for the Steelhead to join, <username> is the user with joindomain privileges,
<********> is the users password and <OU> is the name of the Organisational Unit.
For example, the following command would have the Steelhead join the [Link] domain and be placed into the WAN-opt
Organisational Unit.
# domain join domain-name [Link] login Administrator password ****** org-unit WAN-opt
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------Note: Joining to a specific organizational unit when the server-side Steelhead is joined in Active Directory integrated mode is not
supported.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
A.1.2 - Support the Domain Controller request for password refresh on the Steelhead appliance Machine Account
Some Windows administrators require that Machine Accounts are refreshed at regular intervals, for example, every 30 days. By
default the Steelhead appliance doesnt have this setting enabled. To have the Steelhead appliance respond to the password
refresh request, execute the following command via the RiOS cli on the Steelhead appliance;
# domain settings pwd-refresh-int <number of days>
Where <number of days> is the interval in days between password refresh requests.
For example, the following command would be suitable for a 30-day refresh interval;
# domain settings pwd-refresh-int 30
38
September 2013
Referring to figure A.2-1 we can see the initial connection setup between the Outlook client and the Exchange server when there
are Steelhead appliances attempting to optimize the connection.
The five steps shown begin with the Outlook client sending a request to the Exchange server End Point Mapper (EPM) on wellknown port 135.
The second step is the EPM response back to the client with a dynamic port number to use for the MAPI session. This reply is
picked up by the C-SH (client-side Steelhead applaince). The C-SH remaps the dynamic port and responds to the client with port
7830. The client finishes the setup with the C-SH, the C-SH and S-SH (server-side Steelhead appliance) setup an optimized
connection between themselves and finally, the S-SH talks to the Exchange server using the dynamic port that was supplied in the
original EPM response.
This ensures the S-SH and C-SH can optimize the MAPI connection at the same time as maintaining transparency to the
Exchange server (by using the dynamic port assigned for the client).
Its the job of the Steelhead appliance to maintain a list that includes the IP addresses and dynamic ports for each client and
which Exchange servers are being used.
A.2.2 - Exchange cluster
With an Exchange cluster that comprises of multiple nodes the process is essentially the same as before except that the client
initially sends the EPM request to the Exchange server cluster name. The EPM response to the client is supplied by one of the
nodes in the cluster and includes the IP address of the node.
39
September 2013
Because of this, the S-SH is able to establish the server-side connection with the correct Exchange server node in the cluster. The
same node in the cluster is used for the entire duration of the connection with the client. This Exchange node to client mapping is
just the same as would occur in an un-optimized configuration. Once again, the Steelhead is able to maintain a list of the relevant
MAPI connections between clients and server nodes.
For the server-side Steelhead appliance to correctly perform its optimization using the Delegate User account and the
exchangeMDB SPN, it needs to be able to contact each node specifically rather than using the cluster name.
This requires that each node in the Exchange cluster is associated with the exchangeMDB Service Principal Name. Over time, as
more capacity is required, more nodes are added to the cluster. But sometimes the configuration tasks may not be fully performed
leaving some nodes in a cluster without have this setting configured. As a result, this can lead to Outlook users with an optimized
connection occasionally being prompted for their account name and password when connecting to the Exchange cluster.
This is particularly relevant with Exchange clusters running Exchange 2003 and Exchange 2007.
Using the Windows command setspn L <node_name> on the Domain Controller [in the domain where the Exchange
server is located] will show a list of the SPNs for each node and whether exchangeMDB is included.
To add an SPN for a node of the Exchange cluster simply use the following command;
C:\> setspn A exchangeMDB/<node_name> <node_name>
Where <node_name> is the name of the node in the Exchange cluster. For example, in an Exchange cluster of three nodes called
exnode1, exnode2 and exnode3 the following commands are needed;
C:\> setspn A exchangeMDB/exnode1 exnode1
C:\> setspn A exchangeMDB/exnode2 exnode2
C:\> setspn A exchangeMDB/exnode3 exnode3
Be careful to ensure that these commands are executed with the correct syntax using the same node name for each part of the
command. Running the command incorrectly, for example setspn A exchangeMDB/exnode1 exnode3 will cause
40
September 2013
41
September 2013
So the use of the name Exchange Server can now quite often mean a configuration that contains many separate components
often running on separate server instances. For the purposes of this overview explanation we are just going to look at two roles
within the Exchange Server, the Client Access Server Array and the Mailbox Server.
A.2.5 - Client Access Server Array
The Client Access Server (CAS) Array serves as a single point of contact for all client connections within an Active Directory
location. Although called an Array and usually configured as two or more servers for resiliency and scalability, it can comprise of
just a single server. The CAS Array does not provide load balancing itself, so a separate load balancing solution would be
needed. This is quite often taken care of by installing Microsoft Network Load Balancer (NLB) on the CAS Array but could be
provided by separate 3rd party load balancing products.
A.2.6 - Mailbox Server
The Mailbox server is simply the back-end server used for hosting Mailboxes and public folders. Any client requiring access to
email messages located on the Mailbox server connects to the CAS Array and it is the service in the CAS Array which
communicates with the Mailbox server.
A.2.7 - Basic architectures
As mentioned above, there are other functions in the Exchange 2010 architecture as well as the CAS Array and Mailbox server,
but the following diagrams are to help illustrate the basic combinations of these two roles as part of an Exchange server.
Figure A.2-4
CAS and Mailbox
sharing same hardware
Figure A.2-5
CAS and Mailbox
using separate hardware
Figure A.2-6
Multiple CAS and Mailbox servers as part
of one Exchange 2010 server configuration
42
September 2013
Figure A.2-7 Client EPM request to VIP of Exchange server CAS Array
For the purposes of illustration this example (shown in Figure A.2-7) makes use of Microsoft Network Load Balancer (NLB).
NLB software is installed on all members of the CAS Array and one Virtual IP (VIP) is presented for clients. Clients open a
connection to the VIP and send an EPM request which is responded to by one of the servers in the CAS Array.
Similarly, when Steelhead appliances are used to optimize MAPI traffic between the clients and Exchange server in this type of
configuration, the server-side Steelhead appliance is communicating with the VIP and needs to ensure it keeps track of each
individual EPM request per client and the CAS that responds. As described in section A.2.3 (Exchange Cluster with Load
Balancer) this is achieved by the server-side Steelhead appliance tracking the IP address in the EPM response. Failure to do so
can result in the Outlook client showing random and intermittent disconnection events with the Exchange server. Note that the
server-side Steelhead appliance is not communicating with the Mailbox server(s), just the CAS.
Figure A.2-8 shows an example of an Exchange server with multiple CAS and Mailbox servers, with the Steelhead appliances
providing optimization. Support for optimized connections in this type of configuration is included with later versions of RiOS
starting with v6.1.4 and v6.5.1.
As previously mentioned, NLB is used as an example, but the principle is the same if other 3 rd party load-balancers are used.
43
September 2013
One final point on this type of deployment scenario. There is sometimes the question about optimizing traffic between the CAS
array and the Mailbox server. Normally these two components are network connected via LAN-latency rather than across a WAN
so the thought of optimizing the traffic using Steelhead appliances isnt a factor. However, even if the CAS array and Mailbox
server were separated by a WAN link, optimizing with Steelhead appliances is a configuration that is currently un-tested.
Figure A.3-1: Transparent Mode setting on SMB page of Steelhead appliance GUI
44
September 2013
Figure A.3-2: Transparent Mode setting on MAPI page of Steelhead appliance GUI
When Transparent Mode is used, the server-side Steelhead appliance still needs to join a Windows Domain that has the 1-way
trust to the Resource Domain where the server(s) are located. However, there is no need to create Delegate Users.
In addition to setting up Transparent Mode, the server-side Steelhead appliance needs to know the resource domain(s) that have
the 1-way trust where the server(s) are located.
This setting is performed via the cli using the following command;
# protocol domain-auth oneway-trust dns-name <FQDN> netbios-name <NetBIOS>
Where <FQDN> is the Fully Qualified Domain Name of the delegation domain and <NetBIOS> is the NetBIOS name of the
delegation domain.
The settings can be displayed using the command;
# show protocol domain-auth oneway-trust
The only other requirement for a server-side Steelhead appliance running a RiOS version prior to v7.0 is that any Windows7
clients will need to have LmCompatibility level set to 2 or lower (this is via a registry setting). Additional details can be found at this
location [Link]
For server-side Steelhead appliance(s) that are running RiOS v7.0 or later, the Steelhead appliance should join the Windows
domain using Active Directory Integrated Windows 2003 Mode or Windows 2008 Mode (depending on the domain functional
level). Although the resource domains with the one-way trusts still need to be added to the Steelhead appliance configuration,
45
September 2013
A.6 Joining the Steelhead appliance to the domain without using administrator privileges
In some cases, for security reasons, it is not possible to make use of an account with administrator privileges to enable the
Steelhead appliance to join the domain. Within a Windows Active Directory environment it is possible to perform the domain join
using a pre-created account. Full details and example screenshots are provided in the following knowledgebase article available
on the Riverbed support site.
[Link]
46
September 2013
As can be seen in figure A.6-1 the Domain Auth Easy Config widget contains a number of fields. The first five are for Active
Directory tasks (joining the domain, configuring replication user account).The next four are check-boxes for configuring the secure
Windows settings on the Steelhead appliance. The last option is a drop-down to choose the desired domain join type.
Finally, below the button to actually tell the widget to perform the tasks, there is the status window and the feedback log which are
dynamically updated as the widget proceeds through its tasks.
A full explanation of the settings and capabilities of this feature can be found in the Riverbed Steelhead Management Console
Users Guide.
47
September 2013
Appendix B Troubleshooting
To confirm full acceleration of the signed SMB and encrypted MAPI applications use the Reports > Networking > Current
Connections report in the Steelhead appliance GUI.
Confirm the application flow is optimized by verifying the Established (Optimized) symbol ( ) is present in the Type column of
the report. If in the Notes column the triangular symbol is grey ( ) no error is present and full acceleration is applied to the CIFS
or MAPI session. This should be further confirmed by checking that the Application column is stating CIFS-SIGNED or MAPIENCRYPT, and there should be some degree of data reduction indicated in the Reduction column. See Figure B-2 below for an
example.
If there are authentication problems with signed SMB or encrypted MAPI traffic a Protocol Error icon ( ) is displayed in the far
right hand column of the report and full acceleration is not applied. See Figure B-1 below for an example.
Confirm full acceleration for CIFS with signed SMB and encrypted MAPI:
1.
On both Steelhead appliance(s) navigate to Reports > Networking > Current Connections.
2.
In the regular expression filter, insert the test clients IP address and click Update Display.
3.
To test CIFS with signed SMB on the test client, map a network drive on the test server. To test encrypted MAPI open
the Outlook client. It is helpful to move files or send emails during the testing to generate more connections.
4.
While the application sessions are open go the Steelheads and update the Current Connections report. Confirm the
application flow type is optimized, verify it is the proper host pair, verify it is the proper application and verify the Protocol
Error icons color. If grey, it is fully accelerated. If red, a protocol error is present. If red, click the details icon ( ) for the
connection to see if more information is available. Figure B-1 shows an encrypted MAPI flow with a protocol error
indicating the Steelhead was unable to decrypt the conversation. Figure B-2 shows an encrypted MAPI flow that was
properly optimized. One other item which indicates the MAPI flow was properly optimized is the designation of MAPIENCRYPT in the Application column.
5.
If a protocol error is present and more details are not available in the details view ( ) of the connection you will need
to look at the system logs for more information. Navigate to Reports > Diagnostics > System Logs. It is also worth
changing the logging level to INFO for a period of time, but remember to restore the level to NOTICE once you have
finished.
6.
In the regular expression filter enter the test client IP address and click Go. You may also find it helpful to filter on
keywords like; smb, cifs, cifs-auth, domain, krb or mapi.
48
September 2013
7.
Be on the lookout for messages indicating authentication errors, servers or clients being blacklisted, etc. if there are
any errors that cause clients or servers to become blacklisted, this can be confirmed by using the following cli
commands.
# show protocol cifs smb signing blacklist
# show protocol smb2 signing blacklist
# show protocol mapi encrypted blacklist
These commands show the current entries on the blacklist for each of the three protocols. If you have SMB3 traffic
being optimized, protocol errors will be entered into the SMB2 blacklist. This is because the SMB2 optimization feature
in RiOS is also used to optimize SMB3 traffic. If the error causing the blacklist event is transient, the entry on the list will
clear automatically after time. If the error is more persistent, or you wish to manually clear the blacklist, please make
contact with Riverbed Support via the normal process to request help and guidance.
8.
Analyze the findings and take appropriate action. If assistance is required search the Knowledge Base at
([Link] and if you have a valid support contract, you could contact Riverbed Support (877-4837233 or [Link]
With RiOS v7.0 and later, there is a new feature known as Windows Domain Health Status. This feature comprises of several cli
commands which can be used to test and display various settings and configurations on the server-side Steelhead. An overview is
included in the latest version of the Riverbed Deployment Guide (Protocols edition) and full details of the commands and their
syntax are provided in the latest version of the Riverbed Steelhead appliance cli manual.
With RiOS v8.5 and later the Windows Domain Health Status command have been brought out into the Steelhead appliance
management console as a series of graphical tools.
An example screenshot of the Domain Health Check page is shown below.
49
September 2013
Figure B-4: Domain Health Check page in Steelhead appliance Management Console
For more details on the use of the tests, consult the latest version of the Riverbed Steelhead Management Console Users Guide.
50