SteelHead™ Deployment Guide - Protocols : Signed SMB and Encrypted MAPI Optimization
  
Signed SMB and Encrypted MAPI Optimization
This chapter discusses high-level techniques and guidance for configuring signed Service Message Block (SMB) and encrypted MAPI traffic to ensure data integrity. This chapter includes the following sections:
  • Windows Security Concepts
  • Domain Relationships
  • Choosing an Authentication Mode for the Server-Side SteelHead
  • Overview of Configuring SMB Signing and Encrypted MAPI
  • SMB3 Optimization with Windows 8 Clients and Windows 2012 Server
  • Joining a SteelHead to a Domain
  • Kerberos
  • Configuring the Server-Side SteelHead for Active Directory Integrated (Windows 2003/2008)
  • Best Practices for the SteelHead in a Secure Windows Deployment
  • Domain Authentication Scaling
  • Domain Health Check and Domain Authentication Automatic Configuration
  • Single Domain Example Configuration
    • Signed SMB and encrypted MAPI traffic use techniques to protect against unauthorized man-in-the-middle devices from making modifications to their exchanged data. Additionally, encrypted MAPI traffic and encrypted SMB3 traffic ensure data confidentiality by transmitting data with protection across the network. To securely optimize this traffic, a properly configured client and server-side SteelHead:
  • decrypts and removes signatures on received LAN side data from the client or server.
  • performs bandwidth and application layer optimization.
  • uses the secure inner channel feature to maintain data integrity and confidentiality of data transmitted over the WAN.
  • converts the received optimized data back to its native form.
  • encrypts and applies signatures for LAN side transmission of data to the client or server.
    • To query the Windows domain controller for the necessary cryptographic information to optimize this traffic, the server-side SteelHead must join a Windows domain. The SteelHead can require other configurations, both on the SteelHead, and in the Windows domain. This cryptographic information is only useful for the lifetime of an individual connection or session. The information is obtained at the beginning of a connection, and transferred to the client-side SteelHead as needed, using the secure inner channel feature. You must configure the secure inner channel to ensure maximum security.
    Only the server-side SteelHead is required to join the domain, and it does so using a machine account in the same way that a Windows device joins the domain using a machine account. The SteelHead joins the domain this way to obtain a client user session key (CUSK) or server user session key (SUSK), which allows the SteelHead to sign and/or decrypt MAPI on behalf of the Windows user that is establishing the relevant session.
    The server-side SteelHead must join a domain that is either:
  • the user domain. The domain must have a trust with the domains that include the application servers (file server, Exchange server, and so on) you want to optimize.
  • a domain with a bidirectional trust with the user domain. The domain might include some or all of the Windows application servers (file server, Exchange server) for SteelHead optimization.
    • Production deployments can have multiple combinations of client and server Windows operating system versions, and can include different configuration settings for signed SMB and encrypted MAPI. Therefore it is possible that the security authentication between clients and servers can use NT LAN Manager (NTLM) or Kerberos, or a combination of the two. This chapter includes more information about authentication types and SteelHead configuration requirements.