Microsoft Internet Security and Acceleration Server 2000 SharePoint Portal Server Deployment Kit

Chapter 7

Extending the Functionality of Published Web Sites by Using Delegation of Basic Authentication Credentials and Link Translation

Martin Grasdal

Dr. Thomas W Shinder

December 2003

Table of Contents

Abstract 3

Overview and Configuration of Delegation of Basic Authentication Credentials. 4

Step-by-Step How To: Configuring Delegation of Basic Authentication Credentials. 6

Overview and Configuration of Link Translation. 11

Step-by-Step How To: Configuring Link Translation. 15

Determining Custom Dictionary Entries. 17

Summary. 21

Abstract

Delegation of basic authentication credentials and link translation are two components of Feature Pack 1 that greatly extend the security, usability, and functionality of a SharePoint Portal Server 2003 Web site made available to external clients through a Web Publishing Rule. Web Publishing rules enhances the productivity and experience of remote users connecting to the SharePoint site over the Internet. This document shows you how to configure delegation of basic authentication credentials and link translation. Also included are detailed guidelines and useful suggestions for determining custom link translation dictionaries.

Providing a high level of security, while at the same time providing a high degree of functionality and usability to external users who connect to resources located behind firewalls, is frequently a challenge for administrators. Enabling connectivity to complex Web-based applications behind firewalls involves trade-offs. These trade offs include either loosening security to provide greater functionality, or providing a high degree of security at the expense of functionality and productivity.

ISA Server 2000 delegation of basic authentication credentials and link translation are two features that can be implemented on ISA Server 2000 with Feature Pack 1 to eliminate the need for this kind of trade off in many circumstances.

This chapter explains the benefits of delegation of basic authentication credentials and link translation. It then demonstrates how to configure these features to provide both a high level of security and a high level of functionality when external users connect to a SharePoint Portal 2003 Web site through an ISA Server 2000 firewall.

After installing Service Pack 1 and Feature Pack 1 for ISA Server 2000, the steps for implementing delegation of basic authentication credentials and link translation are as follows:

· Delegation of basic authentication credentials

o Configuring authentication settings on the Incoming Web Requests listener.

o Enabling delegation of basic authentication credentials on individual Web Publishing Rules.

· Link translation

o Enabling the link translation Web application filter

o Determining dictionary entries for link translation

o Enabling link translation on Web Publishing Rules

o Configuring link translation dictionary entries for published Web sites

Overview and Configuration of Delegation of Basic Authentication Credentials

Delegation is a method whereby a service is able to impersonate a user and connect to another service on behalf of and in the security context of that user. Delegation is an important security mechanism in any multi-tiered environment because it ensures that front-end applications will connect to back-end services, such as SQL, in the security context of the user requesting information.

In addition, delegation reduces the possibility of a back-end service allowing unauthorized viewing or manipulation of data. In order for delegation to work, the underlying authentication mechanism must support it. For example, Windows Integrated Authentication using Kerberos supports delegation, whereas Windows Integrated Authentication using NTLM does not. The problem with NTLM is that the entities involved in the authentication process must have a local copy of a hashed password. It is not desirable for the services that the user is communicating with to have a copy of the user’s hashed password.

Note:

By default, when you extend a SharePoint Site into a virtual Web site, Kerberos authentication is disabled for the Web site, and it will use only NTLM authentication. If you need Kerberos authentication for the default intranet SharePoint, you must make a number of configuration changes. For more information on this topic, please see the Microsoft Knowledge Base article, HOW TO: Configure Windows SharePoint Services to Use Kerberos Authentication.

Delegation of basic authentication credentials solves a difficult problem administrators face when they wish to authenticate external users at both the firewall and the web site. It is not possible to use Windows Integrated Authentication at the ISA Server 2000 firewall and the Web site because this requires the using NTLM. The ISA Server 2000 firewall cannot impersonate the user because it does not have (and should not have) a local copy of the user’s hashed password.

If, as an alternative, administrators configure the ISA Server 2000 firewall to require basic authentication at both the firewall and the Web site, users will be presented with multiple sign-on prompts while they are using the published Web sites and will end up not being able to successfully authenticate. This occurs because ISA Server 2000 (without Feature Pack 1) does not have a mechanism for impersonating the authenticated user and forwarding those credentials to another service.

Delegation of basic authentication credentials can make a published Web site easier to use and can enhance security of the Web site when combined with Secure Sockets Layer (SSL) protection. When delegation of basic authentication credentials is enabled on a Web Publishing Rule, the ISA Server 2000 firewall will first authenticate the external user and then, if the authentication is successful, forward the basic authentication credentials to the internal Web site for authentication.

Delegation of credentials provides some significant advantages.

· First, users must be authenticated at the ISA Server 2000 firewall before any traffic associated with their request is forwarded to the Web server. This provides a greater degree of protection to the internal Web server because the firewall will drop any anonymous requests that are not subsequently authenticated using basic authentication before sending the traffic to the internal Web site.

· Second, ISA Server logs contain username credentials of external users. This makes the ISA Server logs easier to analyze and use. One of the issues firewall administrators often grapple with when using Web publishing rules is that Web server logs of the published Web server show only the IP address of the internal interface of the ISA Server 2000 firewall, and not the IP address of the external client. The IP address of the external clients is recorded in the ISA Server logs; however, if the logs show only anonymous connections, analysis of these logs is more difficult if it is necessary to examine the logs for activity based on particular users. Because administrators often want logs to show both the username and the IP address, they forsake the advantages of Web Publishing Rules and instead use Server Publishing rules. Delegation of basic authentication credentials makes Web Publishing a more desirable solution when it is necessary to capture both the username and IP address in the logs.

· Third, delegation of basic authentication credentials makes “single sign-on” possible for external clients. Users will not be prompted to provide the same user credentials multiple times while they are using Web site resources requiring them to be authenticated. If delegation of basic credentials is not enabled for a published SharePoint Web site, and both the ISA Server 2000 firewall and Web server require authentication using basic authentication, users will be prompted 3 times for credentials and then denied access. When basic delegation of basic authentication is enabled, it is possible to authenticate users at both the firewall and the Web site to allow access. However, in some instances, users may be prompted for credentials, such as when they try to open an Office document from the portal site.

Step-by-Step How To: Configuring Delegation of Basic Authentication Credentials

This section shows you the steps required to enable delegation of basic authentication credentials for published Web sites. The test lab used to demonstrate this feature in the following steps has a similar configuration to environment used to demonstrate SSL bridging. For information on the details of that configuration, please see Chapter 6, Using SSL Bridging to Protect SharePoint Web Sites.

The first step to enable delegation is to configure the Incoming Web Requests Listener to support basic authentication.

Note:
During the following steps, you may be presented with a number of messages indicating that, for example, basic authentication is insecure if not implemented in combination with SSL or that authentication will fail as a result of the rules you have set. In these cases, click OK or Yes as appropriate and proceed with the steps to enable basic authentication.

Open the ISA Management console, right click on the server name, and click on Properties. The <Name-of-ISA-Server> Properties dialog box appears.
Click the Incoming Web Requests tab.

In the Connections frame, select the check box to Ask unauthenticated users for identification, as in the figure below.

Note:
The setting to Ask unauthenticated users for identification is a global one and applies to all incoming listener configurations.

Figure 1 Requiring Authentication for All Incoming Web Requests

In the Identification frame, highlight the appropriate listener and click the Edit button. The Add/Edit Listeners page appears.

In the Authentication frame, click the check box for Basic with this domain. If necessary, clear all the check boxes for other authentication mechanisms, as in the figure below.

Figure 2 Configuring Listener To Support Basic Authentication Only

It is possible to enable Client certificate (secure channel only) authentication at the same time as Basic with this domain. Such a configuration results in a stronger two-factor authentication, in which users are asked to provide something they have (a digital certificate) and something they know (a password). However, setting up client digital certificate authentication requires additional steps that are not covered in this document.

As an optional step, click the Select domain button for the basic authentication setting, enter the default domain for the user credentials, and click OK. This setting removes the need to enter the username in the DomainName\UserName format in the logon dialog box. The user will only need to enter his user name and password and not the domain when logging into the domain entered in this dialog box.

Figure 3 Specifying Default Domain for Basic Authentication

Click OK to accept changes on the Add/Edit Listeners and the Incoming Web Requests pages.
You will be asked whether you want ISA Server to save the settings and restart the Web proxy service automatically or if you want ISA Server to save the changes but not restart the services. Click an appropriate choice, and click OK. You can manually restart the Web proxy service by navigating to the Monitoring | Services node in the ISA Management MMC console.

At this point, it necessary to configure the Web publishing rule to use delegation of basic authentication credentials.

In the ISA Management console, expand the Servers and Arrays node, expand your server name, and then expand the Publishing node. Click Web Publishing Rules.
Right click on the appropriate Web publishing rule, and click Properties.

Click on the Action tab, select the check to Allow delegation of basic authentication credentials, and then click OK. Note that you will not see this choice if you have not installed Feature Pack 1.

Figure 4 Configuring Delegation on a Per-Rule Basis

This completes the steps for configuring delegation of basic authentication credentials. A quick way to test the operation of the delegation of basic authentication is to sign on to the Web site from an external client and review the log files. The figure below shows what the Web proxy log file looks like before and after enabling delegation of basic authentication.

Figure 5 Web Proxy Log File Showing Authenticated User Credentials

Overview and Configuration of Link Translation

Link Translation solves a number of issues that may arise for external users connecting through any firewall to an internal SharePoint site.

One critical issue is the links that the SharePoint Web site returns in responses to search queries the external user performs. When an external user enters a search term on the SharePoint Web site, the response to that search includes links pointing to the internal server name of the SharePoint server, and not the external name used for the published site.

Another critical issue concerns the use of SSL and the links included in responses to external clients. In many cases, the URIs returned to external clients use an http:// prefix, and not https://.

The figure below reveals both problems:

Figure 6 Incorrect URIs Returned by Internal SharePoint Web Site to External Client

In the figure above the external user has connected to https://extranet.external.net/, which is the FQDN used by the Web Publishing Rule to provide access to the internal server. However, the links returned to the external user point to http://sps/, which is the internal name of the SharePoint server.

If the user were to click on any of these links, the request would fail. First of all, there is no Web Publishing rule that would allow users to connect to http://sps. Even if there were, http://sps is the intranet virtual Web site, which has been configured to use integrated authentication, not basic authentication. If a user authenticated with the ISA Server using basic authentication, the connection to the Web site will fail if it using integrated authentication. Second, if the Web publishing rule has been configured to require an SSL connection, a connection request using http:// will fail.

While these are serious problems, perhaps a more serious problem is the fact that the page returned to the external user contains the server names used on the organization’s intranet. As a part of prudent and cautious security practices, it is desirable to never reveal the internal server names used on the intranet to external users. The reason for this is to prevent hackers, competitors, and others from inferring information about the network and the organization from the internal names of resources used on the network. Because servers are often named with informative labels that help internal users and administrators identify their purpose, quite a lot of information can be gleaned by an interested 3^rd-party whose motives may be suspect.

Link translation solves these problems by mapping text strings contained in the returned URIs to other text strings that the administrator configures in a link translation dictionary used by the Web publishing rule.

Note:

SharePoint Portal Server 2003 allows you to customize the URL that is returned on search result pages using a feature called Alternate Portal Access Settings. So, for example, it is possible to configure the SharePoint Server to return the domain name “extranet.external.net” in the search results for external clients. This feature might eliminate the need for link translation of the search result URLs for external clients. However, it is not possible for the alternate portal access settings to transform the http prefix to https, and you will still need to perform link translation when you are bridging HTTPS to HTTP connections using Web publishing rules. In the interests of completeness and to provide alternative solutions, the demonstration of link translation in this chapter does not take into account the alternate portal access settings, which will likely appeal to you as a preferred method for displaying the correct search result URLs for external clients. Chapter 8, Using Server Publishing Rules to Publish SPS Web Sites, shows you how to use this feature when you are publishing a SharePoint Web site using server publishing rules.

Link translation is part of Feature Pack1 and installs as a Web application filter. Because of the link translation filter’s built-in functionality and because it uses a limited default dictionary, simply enabling it will solve a number of problems in simple publishing scenarios. For example, when pages on the internal Web site contains absolute URIs that point to itself, the link translation filter will return the appropriate links to the external user, even when those URIs contain http:// prefixes and the external user connects to the Web site using https://.

In addition, the default link translation dictionary will appropriately translate requests made to non-standard ports. For example, if users connect to a Web site that is published on a non-standard port on the ISA Server, such as http://extranet.external.net:8181, link translation will include the port number in the URIs sent back to the external client.

For more complex publishing scenarios or when complex ASP code is involved (as is the case with SharePoint services), however, it is necessary to configure dictionary definitions that map to the names returned by the internal Web site. The dictionary name mappings are configured on a per-Web publishing rule basis.

The link translation application filter extends the already present link translation capability of ISA Server. Even without the link translation filter installed, ISA Server 2000 performs link translation on the Content-location and location headers that are used in various HTTP response codes. (This always occurs when Web publishing rules are used.)

When link translation is installed and enabled, the ISA Server 2000 firewall also checks the Content-type header of the response to determine whether link translation should be applied to the body of the message. (By default, link translation operates only on MIME types belonging to the HTLM documents content group, but other content groups can be specified).

The link translation filter works by first looking for a Content-type header to determine if it needs to perform translation. If no Content-type header is present, the filter will look for a Content-location header to perform translation. If neither header is present, the filter will look at the file extension.

When link translation dictionaries are used in Web publishing rules, the link translation filter maps text strings according to the following rules:

· The filter searches for the longest strings, then shorter strings, and finally the default strings

· If the filter finds a match to a text string, it will then look at the next character to the right to see if it is a terminating character. The following are considered terminating characters:

;

)

[

]

{

}

· If the filter finds a terminating character immediately to the right of string, it will perform translation.

For example, consider a scenario where the link translation dictionary is configured to replace “sps” with “extranet.external.net” and a response page includes a link to http://Sps/SpsDocs/. The filter translates the string as http://extranet.external.net/SpsDocs/. However, if the response page includes a link to http://sps/sps-isa/, both instances of “sps” would be translated because they are both followed by a terminating character, resulting in http://extranet.external.net/extranet.external.net-isa/ being sent to the external client. Needless to say, an understanding of the behavior of link translation mapping is important to prevent potential problems with custom dictionaries. Furthermore, the behavior of link translation should be a consideration when developing guidelines for naming SharePoint sites and workspaces.

Step-by-Step How To: Configuring Link Translation

The link translation Web application filter is installed with Feature Pack 1 for ISA Server by default. However, the filter is disabled. After enabling the filter, a number of potential problems may be solved by the default behavior of the link translation filter.

If simply enabling the filter solves the problems that external clients are experiencing, no other configuration is necessary. However, if a custom dictionary is necessary, you will have to do some analysis to determine what entries to put in the dictionary and then add these entries to the dictionary. Dictionary entries are dependent on the underlying code of the returned pages and vary according to individual circumstances. Determining the appropriate strings to replace is, therefore, somewhat of an art and may require the assistance of a developer who understands any client-side scripts that are returned to the external client.

The steps for configuring the link translation Web application are as follows:

Open the ISA Management console, expand the Servers and Arrays node and then expand your server name. Expand the Extensions node, and click on the Web Filters node.
Right-click on the Link Translation Filter in the right pane of the console, and click Enable in the context menu, as in the figure below.

Figure 7 Enabling Link Translation Web Application Filter

You will be asked whether you wish to restart the Web proxy service manually or have ISA Server restart it automatically for you after enabling the filter. Select the desired choice and click OK. You can manually restart the Web proxy service from the Monitoring | Services node in the ISA Management console.

By default, the only content group that link translation operates on is the HTML Documents content group. If you wish use link translation on other content groups, access the properties of the link translation filter object, click on the Content Groups tab, and select the content groups as appropriate.

Figure 8 Selecting Content Groups for Link Translation

The next step is to enable link translation for the Web Publishing Rule. To do this,

In the ISA Management MMC console, expand the Servers and Arrays node, expand your server name, and then expand the Publishing node. Expand the Web Publishing Rules node.
Right click on the appropriate Web publishing rule, click Properties, and then click on the Link Translation tab.

In the Link Translation tab, click on the check boxes to Perform link translation and to Prevent caching of responses on external proxy servers, as in the figure below, and click OK.

Figure 9 Enabling Link Translation on Web Publishing Rule

Determining Custom Dictionary Entries

You should test the default behavior of the link translation filter to see if any custom dictionary entries are required. You do this by connecting to the published SharePoint site using an external client and testing the functionality of the published site. Specifically, you should look for links pointing to internal server names and that use the wrong prefix (ie, http, rather than https). You should be aware that some of these links will be included in client-side scripts that are returned to the browser for processing, so you should therefore also view the HTML source code that is returned, not just the rendered HTML in the browser.

In the case of the published SharePoint site used for this demonstration, it was necessary to add custom dictionary entries. For example, even though the link translation filter was enabled, the search function on the SharePoint site returned results with both the wrong prefix (http instead of https) and internal server names.

Furthermore, after adding some dictionary entries to fix these problems, the source code of the search results page contained JavaScript that included references to the wrong prefix that caused errors to be returned to the browser when trying to perform an additional search from the search results page.

For example, after adding two dictionary entries to replace “http://” with “https://” (as per the Feature Pack 1 help files) and to replace “sps” with “extranet.external.net”, the returned source code included the following strings in the client-side JavaScript code:

f.action='http:\/\/extranet.external.net\/Search.aspx', and

http:\\\/\\\/extranet.external.net\\\/Search.aspx

To fix this problem, it was necessary to map the shorter string “http:” to “https:” Importantly, it is necessary to include the colon (:) in the dictionary entry mapping. Simply mapping “http” to “https” (without the colon) causes the entire site to be inaccessible.

As you can see, finding optimal custom dictionary entries may involve extensive and repetitive testing. Incorrect link translation mappings can break the Web site for external clients, so it is a good idea to test out configurations in a test lab before deploying link translation in a production environment.

To add a custom dictionary entry, click the Add button on the Link Translation tab of the Properties of the Web Publishing Rule and enter the original and replacement strings in the appropriate text boxes, as in the figure below. When finished click OK, and add other entries as necessary.

Figure 10 Adding a Dictionary Item

Keep in mind that this string will be too long to prevent all problems with incorrect links being returned by the published SharePoint site and that you may have to conduct some trial-and-error experimentation in a test lab to determine string mappings for your environment.

The Feature Pack 1 help files recommend that you also add mappings that include the port number for the Web site, for example, http://sps:80. Also, you should not include terminating characters at the end of the mappings you create.

In the test lab, the following minimum configuration, as indicated in the figure below, appeared to provide an optimal solution, at least for search results returned by the SharePoint Web site. However, please be aware that not every SharePoint feature was tested and that your solution will likely differ.

Figure 11 Custom Translate Link Dictionary Entries

After configuring dictionary entries, the results returned from the search function were correct from the point of view of the external client. Keep in mind that the entries in the figure above appear to be contrary to recommendations in the Feature Pack 1 help files. However, they do provide the desired functionality. The figure below shows the search results.

Figure 12 Link Translation Providing Correct Responses to Search Queries

Summary

Delegation of basic authentication credentials and link translation are two components of Feature Pack 1 that greatly extend the security, usability, and functionality of a SharePoint Portal Server 2003 Web site that is made available to external clients through a Web Publishing Rule. Their implementation enhances the productivity and experience of external users connecting to the SharePoint site over the Internet. This chapter showed you how to configure delegation of basic authentication credentials and link translation. It also provided some guidelines and hints for determining custom link translation dictionaries.