Using ISA Server Feature Pack 1 to Forward Basic Authentication Credentials

Using ISA Server Feature Pack 1 to Forward Basic Authentication Credentials

By Thomas W Shinder M.D.

One of the many good things ISA Server Feature Pack 1 brings to the table is the ability to forward credentials from the ISA Server to an internal Web site. This new ability of the ISA Server to forward credentials to the internal Web site allows the ISA Server to perform authentication before a request even gets to the internal network server. If the external user can’t successfully authenticate with the ISA Server, the request never gets near the Published Web server. This increases the level of security for your published Web servers.

If you’ve ever tried to use Web Publishing Rules to enforce authentication at the Incoming Web Requests listener and the Web site, you’ve probably been disappointed in the results. The problem is that you can’t authenticate with the Incoming Web Requests listener and the Web site. You must authenticate with one or the other, but not both. The reason for this is that before ISA Server Feature Pack 1, the only way you could authenticate with both the Incoming Web Requests listener and the internal network Web server was to use client certificate authentication at the Incoming Web Requests listener and then use basic, integrated or digest authentication at the Web site. Check out Publishing Web Sites using Client Certificate Authentication for more info.

For example, look at the figure below. This shows what happens when you configure your Web Publishing Rule require authentication at the Incoming Web Requests listener and at the internal Web site. The client sends credentials to the Incoming Web Requests listener. The Incoming Web Requests listener approves the user’s credentials and forwards the request to the internal Web site. The Published Web site requests credentials from the user, but the credentials are not forwarded to the site and access is denied.

The Web Proxy log for this conversation appears below. Notice that the request is first denied, which is normal when a site requires authentication. However, the next three entries show a 401 error, indicating that authentication is required. The problem is that even though you see multiple authentication dialog boxes, the credentials are never sent to the internal Web site.

The figure below shows frame taken from the internal interface of the ISA Server during this conversation. The ISA Server is ISA and the internal Web server is 192.168.10.2. Notice that the 401 error comes from the Web server and not the ISA Server. The error pages clinches the deal, since if the error came from the ISA Server, it would say so, but instead shows the error derives from Internet Information Services.

The solution to this problem is to install ISA Sever Feature Pack 1 and leverage the new authentication forwarding feature. FP1 adds a new option to your Web Publishing Rules that allows the rule to take the credentials accepted by the Incoming Web Requests listener for that Rule, and forward them to the internal network Web server. Once you enable credential forwarding, the path looks like what you see below. The credentials are accepted by the Incoming Web Requests listener, the listener then forwards the request and credentials to the Published Web server, and the Web site sends the page to the requesting host. (It’s a little more complex than this, because the Web Proxy service actual presents the credentials after the Web site asks for them). Note that this forwarding for credentials on behalf of the client works only for Basic authentication.

In order to make this all work, you need to do the following things:

You always need to configure the Incoming Web Requests listener before you can use Web Publishing Rules. The Incoming Web Requests listener accepts incoming requests for Web sites published using Web Publishing Rules. However, since you are creating a Web Publishing Rule that will require authentication to access the published Web site, you need to pay special attention how it’s configured.

The figure below shows parts of the Incoming Web Requests listeners tab, the Add/Edit Listeners dialog box, and the Select Domain dialog box. You must configure the Incoming Web Requests listener to support Basic Authentication. Put a checkmark in the Basic with this domain checkbox and click the Select domain button. Type in your domain name or click the Browse button to select your internal network domain that the internal network Web server belongs to.

Note that the Incoming Web Requests listener can be configured to support both Basic and Integrated authentication. In the example above, I described how to set up Basic authentication, but you can configure the Incoming Web Requests listener to support Integrated authentication only or both Integrated and Basic.

What happens is that Integrated credentials are sent to the listener to authenticate with the Web Proxy service on the ISA Server. After successfully authenticating with the Web Proxy service using Integrated authentication, you then authenticate with the Web site using basic authentication (assuming that you configured the Web site to support only Basic authentication). In this case, you’ll see two authentication dialog boxes (seen in the figures below), the first one representing the Integrated authentication dialog box and the second representing the Basic authentication dialog box.

It’s important to point out that if you use this configuration, the users will always have to log on twice. If you configure the Incoming Web Requests listener to support only Basic authentication, you’ll only be presented with the Basic authentication dialog box and you’ll only have to log on a single time (assuming that you configured the Web site to support only Basic authentication).

Note that the authentication options you configure for the Incoming Web Requests listener has nothing to do with requiring authentication. All you are doing here is telling the Incoming Web Requests listener what types of authentication you want to support. But these options do not force authentication. You force authentication by configuring the Web Publishing Rule to limit access to specific users or groups.

Note that you could force all users who access Web sites via a particular Incoming Web Requests listener to authenticate. I prefer not to configure the listener in this way because it reduces your options. Just set the authentication requirement in the Web Publishing Rule and you can use the same listener to accept requests for sites that require authentication and those that do not require authentication.

All Web Publishing Rules require a Destination Set. The Destination Set contains only Fully Qualified Domain Names. You must use FQDNs in your Web Publishing Rules. I know that some of you would prefer to get around this requirement, and in some circumstances you can make Web Publishing Rules work without using FQDNs and using IP addresses instead. But you should consider this an unsupported configuration and use FQDNs only in your Destination Sets that will be part of Web Publishing Rules.

Make sure the FQDN matches the FQDN the user uses to access the site. For example, suppose the name of the server on the internal network is www.domain.local. This FQDN is of no use at all to the external users. They need to be able to access via a publicly accessible name, such as www.domain.com. This is the most common reason for Web Publishing Rules to fail.

You create the Web Publishing Rule in the same way you did before you installed Feature Pack 1. Let’s go over how to create the Web Publishing Rule and see how the new Feature pack options change things.

1. Open the ISA Management console and expand your server name. Expand the Publishing node and then right click on the Web Publishing Rules nodes. Point to New and click Rule.
2. Type in the name of the rule on the Welcome to the New Web Publishing Rule Wizard and click Next.
3. On the Destination Sets page, select the name of your Destination Set and click Next.

4. On the Client Type page, select the Specific users and groups option and click Next.
5. On the Users and Groups page, click the Add button and add the users and groups that will be able to use this Web Publishing Rule to access the Web site. It is this setting that forces authentication to access this rule. Click Next after you’ve selected your users.
6. On the Rule Action page, select the Redirect the request option and type in the FQDN of your site. I strongly suggest that you use the same name the external users use, and then create a HOSTS file entry (or use a split DNS infrastructure) so that this name resolves to the internal IP address of your published Web site. Click Next.

7. Review your settings and click Finish.
8. Double click on your rule in the right pane of the console and click on the Action tab. Put a checkmark in the Allow delegation of basic authentication credentials checkbox. Click Apply and then click OK.

An interesting finding is that neither the Incoming Web Requests listener nor the internal Web site needs to be configured to support Basic Authentication. As long as you’ve selected the Allow delegation of basic authentication credentials option, you’ll be able to authenticate with the listener and the Web site. This might seem as a bit of a surprise, since the Web Publishing Rule is supposed to just add support for forwarding Basic Authentication credentials. However, if you don’t support basic credentials at the Incoming Web Requests listener and the Web site, you’ll be presented with multiple authentication dialog boxes, one for the listener and one for the site. The reason is that forwarding only works for Basic credentials. But selecting that option does seem to fix the problem, to a certain extent, you formerly encountered when authenticating with both the Listener and the Web site.

You configure Web site authentication in the Authentication Methods dialog box, which is accessible from the Directory Security tab on the Web site’s Properties dialog box. I recommend that you select only the Basic authentication option. You may want to manually set the default domain if your users don’t belong to the same domain as the server belongs to. Again, it’s important to make sure the site requires SSL since we’re using Basic credentials.

In this article we went over how you can use the new authentication delegation feature to allow you a “single sign on” to your published Web sites. Just create your Web Publishing Rules to support delegation of authentication, configure the Web listener and Web site to support Basic authentication, and you’re good to go. You also saw that while you don’t have to use Basic authentication at the listener or Web site, you’ll be presented with multiple authentication dialog boxes. The preferred configuration is to support only Basic authentication and use SSL to protect your credentials.