Requiring Strong Authentication Only for Specific Published Paths or Sites

Introduction

Recently we’ve encountered a number of cases where customers wanted to use TMG to require strong authentication for some parts of a published web site (e.g. Outlook Web Access, OWA) but not for others (e.g. Exchange Active Sync, EAS).

This post will describe how to configure TMG for similar scenarios.

Background

The TMG authentication process, as described here, has three phases:

• Receipt of client credentials.
• Validation of client credentials against an authentication provider such as Active Directory, RADIUS, or SecurID Authentication Manager.
• Delegation of authentication to Web servers that are behind TMG Server, such as Exchange.

The first two phases are configured on the TMG Web listener while the third is configured on the specific publishing rules.

This fact can be used to use the same Web listener for different publishing rules with different authentication requirements.

Example

In the following example we will show how to publish two different internal Web sites on the same IP address and port (i.e. the same Web listener). One site will require authentication and the other will not. The technique used in this example can also be used for different paths instead of different sites.

Configuring the Web listener

The “trick” is that only for some rules the Web listener will require authentication. This means that even though authentication is configured on the Web listener, it will not require users to authenticate if they are using a path or site associated with an “All users” rule (as “All users”, including non-authenticated users, are allowed). Here is an example of the Web listener configuration:

Configuring the Web publishing rules

Next we configure a Web publishing rule for the sites or paths that do not require authentication. We use the Web listener defined above and set the rule’s “Users” tab to apply to “All Users”:

Then we configure a Web publishing rule for the sites or paths that require authentication. We use the same Web listener as in the above rule, but here we set the rule’s “Users” tab to apply to “All Authenticated Users”:

We end up with two rules on the same listener (and the same IP address/port), one requiring authentication while the other doesn’t:

If a request matches the first, “No auth” rule, it will be allowed through without being prompted for authentication. However, if the request is matched to the second, “Auth” rule, it will be prompted for authentication and will only be allowed through if the authentication succeeds.

Authors:

Roman Golubchyck,  Senior Development Engineer.

Ori Yosefi, Senior Program Manager.