Pav Cherny

Contents

Topology Design Considerations
Authentication
Site Configuration to Support TLS
IIS Configuration for SSL Certificates
ISA Server Configuration
Ease Your Pain

Encrypting SharePoint traffic in Internet-accessible scenarios by using Transport Layer Security (TLS)/Secure Sockets Layer (SSL) is a familiar approach for securing communication. Ever since 1995 when Netscape introduced SSL as a means of securing data through cryptography implemented on top of the HTTP protocol, Web-based client/server communication has relied heavily on SSL certificates. SharePoint technologies take advantage of TLS through IIS with .NET, which provide the underlying TLS-capable Web server platform. However, enabling TLS for SharePoint sites is only one aspect of securing external communication. You must also consider other facets such as host-based and network firewalls, design topology, and the underlying Active Directory and physical network dependencies.

In the July 2009 column, I covered options for securing server communication in the internal environment by enforcing health policies through Network Access Protection (NAP) with IPSec and by following general SharePoint security best practices. One of the key premises of securing internal communication is knowing the identity of internal users and computers and, based on this, creating policies to grant and restrict access. This premise is effective in an authenticated environment such as one that uses Active Directory and Kerberos or NT Lan Manager (NTLM), but it's incomplete in environments where at least some of the users are anonymous or where a class of users, such as vendors or partners, need different policies applied. Security in the context of Internet-facing sites requires a similar approach of using multiple layers.

One of the underlying principles of securing external communication is blocking unwanted access as early as possible, while having the ability to perform security audits and logging for unauthenticated and authenticated users. The typical approach to satisfying this need is to use, at minimum, a firewall at the network edge for user authentication and stateful inspection of HTTP traffic. However, TLS poses a challenge to stateful packet inspection, because the firewall must be able to decrypt packets, inspect them, re-encrypt them, and pass them to a front-end server for processing. Moreover, the firewall (and any load-balancing solution) must preserve HTTPS sessions. Internet Security and Acceleration (ISA) Server 2006 and Intelligent Application Gateway (IAG) Server 2007 provide a firewall solution that works together with IIS and SharePoint to deliver a TLS-compatible means of securing communication.

Understanding TLS communication in SharePoint requires an understanding of how the hosting architecture and topology affect the way IIS and any firewalls handle SSL certificates. Accordingly, there are a number of considerations for designing and deploying SharePoint solutions that are accessible from the Internet. The SharePoint architecture includes some challenging configuration aspects in addition to IIS, SSL and firewall considerations, such as alternate access mappings (AAM), authentication, and SharePoint zones.

Topology Design Considerations

Developing multiple layers of security for SharePoint sites begins with defining physical network topology. If you can reduce or eliminate unwanted traffic before it hits front-end and back-end servers, you not only lessen server load but also mitigate the risks of viruses, spam, and malware that come with malicious traffic.

The network topology that accommodates TLS for SharePoint depends on the usage scenario required for your organization. Figure 1 shows a decision tree with some considerations and relevant topology decisions.

You can simplify the decisions further by separating the various topology options into three areas:

• Traffic before it hits the firewall.
• Traffic between the firewall and the internal network.
• Traffic inside the internal network.

Figure 1 Decision considerations for Internet-accessible topologies.

In terms of configuring TLS, making this distinction is vital because you must configure routing and firewall rules to bridge HTTPS connections between Internet requests and IIS front-end servers, configure IIS to serve SharePoint applications, and ensure that internal resources are protected. Depending on the topology, TLS traffic may need to be able to traverse all three of these areas through multiple routers and firewalls. Let's take a look at three topology options for Internet-accessible sites and consider how the topologies affect TLS traffic. Figure 2 shows a basic "edge" topology with one firewall securing internal servers.

Figure 2 Basic edge topology with a single firewall.

In edge topology, a single network firewall stands between external users and internal SharePoint sites. It has the advantage of using a single Active Directory environment for internal and external users, which simplifies maintenance and administration. To secure traffic via TLS, you configure the firewall to also act as a reverse proxy. The concept of an integrated reverse proxy such as ISA Server is vital for securing Internet-facing sites, because the reverse proxy intercepts incoming requests, can authenticate external users, decrypts TLS traffic, inspects it according to firewall rules, and forwards requests to front-end servers. Public URLs may differ from internal URLs, so the reverse proxy must have a means to perform link translation to convert external URLs into internal URLs. IAG Server provides additional security capabilities, such as end-point, health-based authorization through an access policy based on user identity and client computer health, and the ability to translate links for internal SharePoint URLs when using Outlook Web Access.

To add an additional layer to the topology and exercise more granular control over communication between servers, you can create a perimeter network that hosts SharePoint servers. In a perimeter network, the SharePoint servers are isolated from the Internet by a firewall and from the internal network by a firewall. This is a back-to-back topology, as shown in Figure 3.

Figure 3 A “back-to-back” topology with two firewalls.

Of course, you are not limited to just two firewalls in a back-to-back topology. You can implement additional layers separated by firewalls or routers to further separate the SharePoint roles. For example, you could use a three-layer approach, putting each layer in a DMZ, where front-end servers are first, followed by application, database and search/index server, and concluded by Active Directory/DNS servers. You can also customize a back-to-back topology to include an internal staging environment in a separate farm and publish it to the farm in the perimeter network. Another option is to split the SharePoint farm between the perimeter network and the internal network to create a split back-to-back topology, as shown in Figure 4. In keeping with the approach of using security layers in the topology, front-end servers reside in the perimeter network and the back-end servers running SQL Server reside in the internal network. The remaining roles, such as index, search, and central administration, can be in either network.

Figure 4 In a “split” back-to-back topology, server roles can be set up in either the DMZ or the internal network.

Place the search server in the internal network for optimal search and crawling performance. You can dedicate the search server to crawling. Keep in mind that the split back-to-back topology requires a one-way trust between the perimeter and internal and AD environments to support communication.

Resources

SharePoint Products and Technologies Web site

Windows SharePoint Services TechCenter

Windows SharePoint Services Developer Center

Microsoft SharePoint Products and Technologies Team Blog

Authentication

Determining the appropriate authentication configuration for securing external communication can quickly become overwhelming, due to the available options and the topology levels at which authentication and authorization take place.

For example, your environment may support RSA SecureID, incorporate Network Policy Server (NPS), or use a custom Lightweight Directory Access Protocol (LDAP)-based directory. In the end,the relevant authentication aspects of securing external SharePoint communication include authentication of external and internal users, and IIS authentication for SharePoint sites.

Let's simplify these aspects even more by tracing the communication path of requests from external users to SharePoint sites to see how authentication and authorization happen.

1. An external user makes a request that is routed to the firewall. If the firewall is an ISA Server configured to use forms-based authentication (FBA), the user is presented with a logon form and authenticated. The request is then sent to a front-end server.
2. IIS on the front-end server accepts the request; determines the site associated with the URL; checks the authentication configuration for the site; authenticates the traffic; and passes it to SharePoint for authorization.
3. SharePoint performs authorization. SharePoint site permissions and authorization are outside of the scope of this article, because TLS is configured for each site at the IIS level. For more information about SharePoint authorization and authentication, see Plan authentication methods (Office SharePoint Server).

Site Configuration to Support TLS

SharePoint relies heavily on IIS and the underlying topology and authentication configuration to provide the necessary functionality to support TLS. By the time traffic is routed to SharePoint, it has already passed through the firewall and been handled by IIS. Configuring SharePoint sites to support TLS is more a task of informing SharePoint of the underlying environment for each site than directly specifying SSL certificates, creating service account, and so on. Still, it's important to consider two SharePoint-specific details when deploying TLS: zones and Alternate Access Mapping (AAM). Both are configured in the Central Administration site under Application Management.

When creating or extending a Web application, you can specify zones and enter details about the environment that SharePoint uses to create an initial set of AAMs (see Figure 5). The key considerations from a security perspective are the authentication provider and whether the ISA Server uses TLS to communicate with the front-end server, or terminates the HTTPS requests from external users at the firewall and communicates via HTTP.

Figure 5 SSL and other confi guration options for a SharePoint site.

Although using TLS for communication from ISA Server to front-end servers creates additional processing overhead, it provides an end-to-end encrypted solution and is my preferred method. Terminating TLS at the ISA Server may also break some usage scenarios, such as when using custom Web Parts that store URLs in a SQL Server database. The process is similar for enabeing an existing site for TLS. You must check the Use Secure Sockets Layer (SSL) radio button, configure the other options, and then navigate to the AAM settings and verify that they are configured properly.

Zone and AAM configuration is interrelated. SharePoint uses the idea of zones to allow logical distinctions between parts of your topology, such as Internet, extranet, and intranet and the URLs available to those parts. AAM definitions specify how the URL header should look to users of various zones when the URL is different from the internal URL. If your internal URL is the same as a public URL that uses a fully qualified domain name (FQDN), you do not need to configure AAM ; SharePoint does that automatically. For other scenarios, configure AAMs for your SharePoint sites. Troy Starr posted a comprehensive overview of AAMs for Sharepoint on the SharePoint Team blog, which you can find at What every SharePoint administrator needs to know about Alternate Access Mappings (Part 1 of 3). It is well worth a look; AAM misconfiguration is one of the most prevalent causes of extranet scenario issues. 

IIS Configuration for SSL Certificates

As mentioned, enabling SSL for a SharePoint site is done at the IIS level. In IIS7, SSL certificates are configured via Server Certificates. They are located under the Properties page of IIS Server. Microsoft has already published instructions, considerations and usage scenarios to keep in mind when enabling IIS sites to use SSL; remember that certificate authority and IP address/port binding are especially relevant for securing Internet-accessible sites. There are several options for generating an SSL certificate. You can use selfssl.exe, deploy a PKI with a trusted Windows Certification Authority (CA), or use a commercial provider. For lab environments and development purposes, a self-signed certificate works well, but you may run into user issues for production environments. Unless users accept the certificate in their browsers, they will be prompted when accessing an SSL-enabled site that the certificate comes from an untrusted source. This may lead to support calls and confusion, making it easier to deploy a production certificate from a root CA.

It is possible to use the same IP address or the same port for multiple SSL-enabled sites. The straightforward way is to use a fixed IP address and the same port for each site, so IIS can bind the site to the IP address and port. Alternatively, if your configuration uses one root domain and multiple subsites, you can use a wildcard certificate or certificate with multiple site alternative names (SANs). The process is mostly the same as for a regular certificate, but you cannot configure it in the IIS 7e screen under Site Bindings. Instead, use appcmd and run the following command to bind SSL to the site and set the host header: C:\Windows\System32\inetsrv\appcmd set site /site.name:<CustomSiteName> /+bindings.[protocol='https',bindingInformation='*:443:<FQDN>]. If done properly, you will see an SSL binding with the host header you specified under Site Bindings.

ISA Server Configuration

Regardless of whether you want to secure an existing or new SharePoint site with TLS, you must ensure that the traffic can traverse the firewall. ISA Server provides several mechanisms that work with SharePoint and make traversal possible: FBA, HTTPS bridging, link translation through reverse proxy, and SharePoint publishing rules.

ISA Server uses a wizard to help you publish SharePoint sites. This wizard creates a listener and an "allow" rule to enable SharePoint traffic. Before running the wizard, export the SSL certificate installed via IIS on the front-end server hosting the site and import it to ISA Server using the Certificates MMC snap-in. Import the certificate to the local computer account personal store. Doing this enables the listener you create in ISA Server to decrypt incoming traffic, inspect it, and re-encrypt it. For more details about configuring ISA Server for SharePoint, see Authentication in ISA Server 2006 and Configure ISA 2006 for Sharepoint 2007.

By the time you configure ISA Server to publish your SSL-enabled SharePoint sites, internal and external URLs are resolvable through DNS; user accounts and permissions have been configured; SharePoint zones and AAMs are configured; and you have installed the SSL certificate for the site through IIS. At this point, enter the relevant details in the ISA Server. When you configure the listener and publishing rule, keep the following in mind:

• AAM:  For alternate access mapping to work properly, you must configure the publishing rule to forward the original host header. Also, make sure you specify the proper FQDN addresses for the internal and external URLs.
• FBA: Make sure you select HTML Form Authentication and Windows (Active Directory) from the Authentication tab, unless you're using Kerberos or a custom authentication solution.
• Deny access for non-authenticated users. For enhanced security, make sure you add All Authenticated Users. Alternativelyr select specific users under User Sets and make sure All Users is removed.

Ease Your Pain

Securing your SharePoint sites by using TLS can be full of issues. Your firewall may not properly direct traffic as a reverse proxy or may do a poor job of link translation. The routing configuration may not be configured properly in more complex topologies. Or the AAM and zone configurations may not match the DNS or firewall settings. The good news is that if you approach external security with a multi-layer approach, you can isolate issues and resolve them. You can make your life even easier if you use ISA Server with FBA and Windows authentication. Pick the appropriate topology, configure the site in SharePoint, enable it for SSL in IIS, bring it all together with ISA Server, and you have secured external communication through TLS.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corporation, a company that specializes in managed documentation and localization services.