Windows SharePoint Services
SharePoint Portal Server 2003 is built on Windows SharePoint Services technology. Because of this, many of the known issues with exposing Windows SharePoint Services sites over an extranet also apply to SharePoint Portal Server.
For known issues with deploying Windows SharePoint Services over an extranet, see Reverse Proxy Configurations for Windows SharePoint Services and Internet Security and Acceleration Server.
In a reverse proxy configuration, the client sends HTTP or HTTPS requests to the reverse proxy server as if the reverse proxy server were the Web server. A traditional reverse proxy server approach allows the client and server URLs to differ. By default, ISA Server does not include the host header received from the client when it sends the client request to the server. By configuring host-header forwarding in ISA Server, ISA Server then forwards the HTTP or HTTPS packets to the Web server while preserving the original host header (sent by the client) in the packets. On the Web server, Windows SharePoint Services — and therefore SharePoint Portal Server — uses the host header information to generate hyperlinks on pages that will be reachable by the client. The Web server then sends HTTP or HTTPS responses through the reverse proxy server to the client.
Note As described, proper use of ISA Server host-header forwarding ensures that the URLs received by the portal site match the URLs sent by the client. This, in conjunction with other guidance provided by this paper, ensures that links contained in pages returned to the client will be reachable through the Internet. However, this does not mean that the internal NetBIOS name or FQDN for the SharePoint Portal Server deployment must match the external name used by the client to access the portal site, nor does it mean that the names on SSL certificates must match end-to-end. That is, the only requirements for SSL certificate naming are:
- The name on the certificate used by the listener on ISA Server must match the name used by the client when a connection is attempted.
- The internal name to which ISA Server will send a client request matches the name on the certificate installed on the Web site in IIS that hosts the portal site being accessed.
The ISA Server reverse proxy configurations described in this paper use an ISA Server feature called host-header forwarding to keep the URLs received by the server the same as those sent by the client.
For SharePoint Portal Server, do the following:
- Use ISA Server host-header forwarding.
- Do not use ISA Server path mapping or link translation.
- Use the SharePoint Portal Server alternate access setting feature.
- This ensures that the URL received by the SharePoint Portal Server deployment matches the URL used by the client, and that URLs contained in links on portal site pages are reachable over the Internet.
SSL Termination and SSL Bridging
SSL termination that does not occur on a front-end Web server breaks SharePoint Portal Server functionality.
In a typical SSL termination configuration, a reverse proxy server terminates the SSL connection from the client, and then forwards the request to a Web server by using HTTP. This configuration ends the SSL connection between the client and the Web server at the reverse proxy server.
For example, if an HTTPS client request comes in to the proxy server, and SSL is terminated at the proxy server and sent to the SharePoint Portal Server deployment as HTTP, links returned in portal site pages might contain HTTP prefixes instead of HTTPS prefixes.
However, because Windows SharePoint Services uses absolute URLs, the URL from the client and the URL sent to the server must match, as described in the "Absolute URLs" section earlier in this appendix. When using ISA Server, to keep the URL sent from the client to the ISA Server computer the same as the URL sent from the ISA Server computer to the Web server, a new SSL connection can be established between the ISA Server computer and the Web server. In ISA Server, this feature is called SSL bridging or SSL-to-SSL bridging.
Each scenario in this paper that provides guidance for configuring SSL connections to portal sites exposed over the extranet uses ISA Server SSL-to-SSL bridging. Moreover, the scenarios contain instructions for configuring the correct setting for the portal site in the SharePoint Portal Server alternate access settings table. This ensures that the URL received by the SharePoint Portal Server deployment matches the URL used by the client, and that URLs contained in links on portal pages are reachable over the Internet.
IP-Bound Virtual Servers
If you want to host multiple portal sites on multiple virtual servers, those virtual servers cannot be bound to discrete IP addresses. This is a limitation with Windows SharePoint Services and is therefore a limitation in SharePoint Portal Server.
Create the virtual servers using alternate TCP and SSL ports. For example, the TCP and SSL ports for the Default Web Site are 80 and 443, respectively. If you want to create a portal site on a new virtual server, create that virtual server using alternate TCP and SSL ports (for example, 8080 for TCP and 8081 for SSL). If you create a virtual server that uses alternate TCP and SSL ports, the URL used to access the portal site must contain the port number (for example, http://ServerName:8080 or https://ServerName:8081), and you must use the correct setting for the portal site in the SharePoint Portal Server alternate access settings table. This ensures that the URL received by the SharePoint Portal Server deployment matches the URL used by the client, and that URLs contained in links on portal site pages are reachable over the Internet.
SharePoint Portal Server Central Administration
SharePoint Portal Server Central Administration does not work through a reverse proxy server.
The instructions in this paper are for the content virtual servers and do not apply to the virtual server that hosts the SharePoint Portal Server Central Administration site.
None; SharePoint Portal Server Central Administration does not work through a reverse proxy server.
URLs in Alerts E-Mail Messages
Alerts e-mails sent by SharePoint Portal Server include the URL used when the alert was created. If the portal site is accessible on both the corporate intranet and over the extranet, there is no way for the system to determine where the user is when an alerts e-mail is sent. Therefore, the user might receive an e-mail hyperlink that is not reachable from their current location.
If you want to require SSL for SharePoint sites, and you only use the ISA Server "require SSL" property in a Web publishing rule for that site, links in SharePoint sites might not contain HTTPS.
In ISA Server, you need to configure the following settings:
- In ISA Server 2000, Require secure channel (SSL) for published site and Require 128-bit encryption.
- In ISA Server 2004, Notify HTTP users to use HTTPS instead and Require 128-bit encryption for HTTPS traffic.
To make links in SharePoint sites include HTTPS (instead of HTTP), you must configure the Require secure channel (SSL) setting in the IIS settings for the virtual server (that is, Web site in IIS) hosting the site. You cannot control this setting from the proxy server. The scenarios in this paper that require SSL give prescriptive guidance about how to configure this in IIS. This ensures that URLs contained in links on portal pages are reachable over the Internet.
Bypass Proxy Server Settings for SharePoint Portal Server Search
You can specify proxy server settings that are used by the search service for SharePoint Portal Server. However, it is possible to incorrectly specify the settings, resulting in the crawl failing.
You specify the settings in the Proxy Server Settings section on the Configure Server Farm Account Settings page in SharePoint Portal Server Central Administration. If you specify a proxy server for crawling external (non-intranet) content, but you do not want to crawl through the proxy server when crawling internal (intranet) content, you can specify a bypass proxy setting. If you specify a setting that begins with an asterisk, the crawl will still go through the proxy server and might fail as a result. For example, if you specify *.Perimeter.Net, the crawl will still go through the proxy server that you have specified and might fail as a result.
Each scenario in this paper provides guidance for correctly configuring a bypass proxy setting.