Introduction to Reverse Proxy Configurations (Windows SharePoint Services 2.0)

Organizations that want to expose Microsoft Windows SharePoint Services sites (or any Web-based applications) to the Internet must address standard security concerns. Most such environments use a reverse proxy server and firewall server to address some of these concerns. Microsoft Internet Security and Acceleration (ISA) Server includes proxy and firewall server capabilities and can address issues such as:

• Prevention of potential disclosure of internal network-specific information, such as IP addresses, NetBIOS computer names, Domain Name System (DNS) computer names, network domain names, and so on.

  Reverse proxy configurations help protect this information by processing client queries on the proxy server instead of on a Web server internal to the network.

• Prevention of unauthorized traffic either into or out of the internal network.

  Reverse proxy servers allow the client system to perceive the reverse proxy server as the Web server — the proxy server contacts the Web server in response to client requests, receives the response from the Web server, and then sends that request to the client. Reverse proxy servers can be configured to allow only authorized traffic in or out.

• Detection and prevention of hacking attempts.

  Microsoft Internet Security and Acceleration Server, provides application-layer filtering to allow or deny requests based on defined access policies as well as to detect and prevent hacking attempts.

• Avoiding excessive internal network traffic.

  Content caching allows reverse proxy servers to cache Web content so that the reverse proxy server can respond to some client requests from the cache without contacting the Web server. This minimizes internal network traffic.

• Avoiding excessive secure sockets layer (SSL) overhead on the Web server.

  A reverse proxy configuration can terminate incoming SSL sessions in front of the Web server, thus removing the overhead of SSL termination and decryption from the Web servers.

ISA Server can address all of these issues. ISA Server also includes a feature known as SSL bridging, which allows the following:

• Redirecting incoming HTTPS requests to Web servers as HTTP requests. Before packets are forwarded, they can be filtered all the way up to the application layer.

• Redirecting incoming HTTPS requests to Web servers as HTTPS requests to help ensure maximum security. Before packets are forwarded, they can be filtered all the way up to the application layer.

This paper covers the supported and tested reverse proxy configurations for Windows SharePoint Services. The configurations use and were tested with Microsoft ISA Server 2000, Service Pack 1, and Microsoft ISA Server 2004, but should be applicable to most third-party reverse proxy solutions.

The following illustration shows an example reverse proxy configuration:

The traditional reverse proxy server approach allows the client and server URLs to differ. This requires that none of the hyperlinks in the Web pages be absolute. Windows SharePoint Services relies on absolute hyperlinks, so the reverse proxy configurations described here keep the URLs on the client the same as those on the server.

Some reverse proxy configurations use a URL fix-up approach to find and fix absolute URLs. Because of the way Windows SharePoint Services uses absolute URLs, a URL fix-up approach does not work for Windows SharePoint Services. Some of the absolute URLs used by Windows SharePoint Services are easy to find and fix. For example, it is fairly easy for the reverse proxy server to rewrite enough URLs to get the home page of a SharePoint site to render and function correctly. However, other absolute URLs are much harder to find and fix. For example, there are absolute URLs in ActiveX controls, form post bodies, URL parameters, and SOAP messages where most reverse proxy servers cannot find them for rewriting. The absolute URLs can be outbound from Windows SharePoint Services, inbound from client applications, or round-tripped from Windows SharePoint Services to the client and back. Furthermore, the absolute URLs can be encoded when used as a parameter — for example, the URL https://server_name can look like http%2f%3a%3a server_name in the form post body.

The following sections describe two reverse proxy configurations that do work with Windows SharePoint Services — host-header forwarding and SSL bridging (HTTPS to HTTPS). In host-header forwarding, the reverse proxy server translates the IP address of the page that the client requests into the IP address of the page that the server returns. The SSL bridging (HTTPS to HTTPS) configuration relies on two separate SSL connections — one between the client and the reverse proxy server and one between the reverse proxy server and the server running Windows SharePoint Services. If you are running a reverse proxy server that requires that SSL connections end at the reverse proxy, you must use the SSL bridging (HTTPS to HTTPS) configuration.