SteelHead™ Deployment Guide - Protocols : Signed SMB and Encrypted MAPI Optimization : Kerberos
  
Kerberos
Kerberos is a network authentication protocol. In a Microsoft Windows environment, the Active Directory domain controller maintains user account and login information to support the Kerberos service. From a corporate perspective, you can think of Kerberos as guarding against unauthorized access to your IT assets.
This section includes the following topics:
  • Overview of Kerberos
  • Optimization in a Native Kerberos Environment
  • Domain User with Replication Privileges
  • Configuring Traffic Optimization for HTTP (SharePoint), Encrypted MAPI, and Signed SMB/SMB2/SMB3
  • Kerberos authentication is not unique to a Microsoft Windows environment. This guide contains explanations and details limited to a Windows configuration.
    Overview of Kerberos
    The three components of Kerberos are the key distribution center (KDC), the client user, and the server resource with the service that the client user wants to access. The KDC is a part of the Windows domain controller and performs two service functions: the authentication service (AS) and the ticket-granting service (TGS).
    To enable the client user to access a server resource (for example, a Windows file server), three exchanges are involved:
  • The AS exchange
  • The TGS exchange
  • The AP (application protocol) exchange
  • When users initially log in to a Microsoft Windows network, they must provide a login name and password for access. These credentials are verified in the AS exchange of a KDC within the domain of the user. The KDC has access to Active Directory user account information. When a user is successfully authenticated, the authentication server grants the user a ticket to get tickets (TGT) that is valid for the local domain—you are first approved to get tickets, and next you are approved for each ticket as you ask for them. The TGT (sometimes referred to as the AS reply, although the AS reply actually contains more parts) has a default lifetime of 10 hours and can be renewed during the user's session without requiring the user to reenter a password.
    The AS reply includes two components: the TGT itself, which is encrypted with a key that only the KDC (TGS) can decrypt; and the first of two session keys encrypted with the user's password hash. Any future communication with the KDC uses this initial session key (SK1). The client uses the TGT, which is cached in volatile memory space on the client machine, to request sessions with services throughout the network.
    The client sends a request to the TGS, and asks for credentials of the desired server. The client first creates an authenticator using the SK1. The authenticator contains the username, IP address, and a time stamp—all encrypted using SK1. The client next sends a copy of the TGT and authenticator to the TGS. The TGS responds with the server credentials in the form of a service ticket that also has two components: one encrypted in the server's key, which the client cannot read; and the other encrypted with the client's key, which is temporary. The encryption key is the second of the two session keys (SK2) issued during the sequence of exchanges. The SK2 is valid only for communicating with the desired server and lasts for the lifetime of the session with the desired server. A second or subsequent session with the same server needs a completely new SK2 session key requested by the client from the TGS.
    Next, the client creates another authenticator, this time using SK2 for encryption. The client transmits the authenticator with the service ticket, which contains the client identity and a copy of the session key—SK2—all encrypted with the server's key, to the server. As a result of this exchange, the SK2 is now held by the client and server. SK2 authenticates the client and can optionally authenticate the server. The SK2 can also be used to encrypt further communication between the two hosts or to exchange a separate subsession key used for encrypting further communication.
    The AP exchange is also known as the client-server exchange because the exchange is often completed with whatever application protocol is required between the client and server: for example, SMB and SMB2 for file sharing, MAPI for email, or HTTP for Sharepoint.
    The Kerberos exchange process is shown in Figure 3‑4.
    Figure 3‑4. Kerberos Exchanges
    Multiple Domain Environments and Referral Tickets
    The Kerberos exchange occurs when the client user, KDS, and resource server are in the same Windows domain. Where there are multiple domains, there are steps that include referral tickets.
    The AS and TGS functions are separate within the key distribution center. This enables the user to use the TGT obtained from the AS in the domain to obtain service tickets from a TGS in other domains. This is accomplished through referral tickets. A referral ticket is similar to the service ticket that is granted during the TGS exchange described earlier. The difference between the two is that the referral ticket contains a ticket for the KDC in the adjoining domain rather than the server.
    If there is a trust established between two domains, referral tickets are granted to clients that request authorization for services in other domains. Because of the trust relationship between the two domains, an interdomain key, based on the trust password, is available for authenticating KDC functions.
    For example, consider a client user in the local domain who seeks services in a foreign domain. The two domains are directly linked through a two-way trust. The basic steps are as follows:
    The client performs a TGS exchange with its local domain KDC. The KDC recognizes a request for a session with a foreign domain server and responds by returning a referral ticket for the KDC in the foreign domain.
    The client contacts the KDC of the foreign domain with the referral ticket. This ticket is encrypted with the interdomain key. Given that the decryption works, the TGS service for the foreign domain returns a service ticket for the server service in the foreign domain.
    The client performs the client-server exchange with the server in the foreign domain and begins the user session with the service.
    In a multiple domain configuration where the client is in one domain and the server is in a foreign domain, communication between the two can only be through an intermediate domain. Again, assume that there are transitive two-way trusts between the local domain and the intermediate domain, and the intermediate domain and the foreign domain.
    The process is similar to the two-domain example. The basic steps are as follows:
    The client performs a TGS exchange with its local domain KDC. The KDC recognizes a request for a session with a foreign domain server and responds by returning a referral ticket for the KDC in the intermediate domain.
    The client contacts the KDC of the intermediate domain with the referral ticket. This ticket is encrypted with the interdomain key. The TGS service for the intermediate domain returns a referral ticket for the foreign domain.
    The client contacts the KDC of the foreign domain with the intermediate domain referral ticket. The TGS service for the foreign domain returns a service ticket for the server service in the foreign domain.
    The client performs the client-server exchange with the server in the foreign domain and begins the user session with the service.
    For more details and reference material on Kerberos that are beyond the scope of this guide, go to:
  • http://technet.microsoft.com/en-us/library/bb742516.aspx
  • http://web.mit.edu/kerberos/
  • http://www.ietf.org/rfc/rfc4120.txt
  • Optimization in a Native Kerberos Environment
    From a Riverbed perspective, the optimization of secure protocols in a Microsoft Windows environment includes the following protocols:
  • Signed SMB
  • Signed SMB2
  • Signed SMB3
  • Encrypted MAPI
  • Encrypted Outlook-Anywhere
  • SharePoint
  • You must understand how RiOS performs optimization on these protocols when the authentication is end-to-end Kerberos before you proceed to more specific details. Remember the following points:
  • Secure protocols use a session key to encrypt or digitally sign protocol packets. This session key is exchanged during the authentication phase between the client and server.
  • In the case of Kerberos, the session key is extracted from the service ticket by the target server.
  • Decrypting the service ticket requires the server machine account password, which is set up during the domain join process and might be periodically refreshed.
  • The servers machine account password is only known to the target server and domain controller.
  • Active Directory supports account replication between domain controllers for high availability.
  • Therefore, the only way for RiOS to legitimately optimize these encrypted, or digitally signed, secure protocols is to obtain the machine credentials for any servers that require optimization. RiOS uses Active Directory replication by using the same protocols and tools as the Windows domain controllers do, and by employing a domain user that has replication privileges.
    When the server-side SteelHead uses this replication capability, it can transparently participate in the key exchange between the client and server, maintain security, and optimize relevant traffic.
    Domain User with Replication Privileges
    Although a user with generic domain administrator privileges meets the requirements for replication, this could have some security implications.
    Instead, you can assign a restricted set of privileges to a user, known as a replication user. You can configure the replication user on a per forest basis so that the user assigned to it can retrieve machine credentials from any domain controller in any trusted domain within the forest. Remember that a forest can comprise of multiple domains with trusts between them.
    The replication user begins with a generic user account created by a Windows domain administrator, which might or might not be you. After this is done, you can apply the privileges and restrictions for the account to become a replication user on the SteelHead. If you have multiple SteelHeads in the data center (for example, in a high-availability configuration), then you can add the same replication user account to the configuration for all the server-side SteelHeads. For information about how to configure the replication user, see the Riverbed Command-Line Interface Reference Manual and the SteelHead Management Console User’s Guide.
    The replication user has enough rights to calculate the S1 and S2 Kerberos session keys for the SteelHead to properly terminate the session and perform optimization. These rights are given by granting Replicate Changes and Replicate Changes All.
    After the configuration is complete, the SteelHead retains the replication user account details by encrypting them in its secure vault.
    In RiOS v7.0 or later, the secure vault is locked on a new SteelHead. The secure vault is also locked on a SteelHead that is upgraded to RiOS v7.0 or later. You must unlock the secure vault to view, add, remove, or edit any replication or delegate user configuration details that are stored on the SteelHeads.
    In Windows 2008 domains, you can apply further restrictions to the replication user by using a password replication policy (PRP). A PRP is a set of rules that describe a list of accounts that you can replicate between domain controllers. When you enable PRP in a Windows domain, the SteelHead is restricted, specifically to using the replication user to replicate accounts as determined by the PRP settings. Therefore, you can use the PRP to limit the accounts known to the replication user. This configuration can create additional administrative overhead in managing the PRP; however, it might be worth the additional security.
    PRP is not available in Windows domains with a functional level lower than Windows 2008. For information about how to configure PRP, see the SteelHead Management Console User’s Guide.
    Configuring Traffic Optimization for HTTP (SharePoint), Encrypted MAPI, and Signed SMB/SMB2/SMB3
    In RiOS v7.0 or later, you can enable Kerberos authentication support for HTTP for SharePoint, encrypted MAPI, signed SMB, and signed SMB2. To fully optimize signed SMB3 traffic, you must use RiOS v8.5 or later. When you enable the Kerberos setting on the server-side SteelHead, you enable the SteelHead to use the relevant domain user privileges and to access to the session key used by the client and server.
    You must have RiOS v7.0 or later on both the server-side and client-side SteelHeads. You must use RiOS v8.5 or later for SMB3.
    For information about how to configure each application, see the SteelHead Management Console User’s Guide and HTTP Optimization for SharePoint.