Requiring Strong Authentication Only for Specific Published Paths or Sites

Requiring Strong Authentication Only for Specific Published Paths or Sites

  • Comments 2
  • Likes

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:

image

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”:

image

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”:

image

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

image

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.

Comments
  • Hi Roman, I guess I am going to regret asking this but as the rules are executed top-down, won't the All Users rule match the traffic profile everytime and therefore effectively make the following rule redundant in the sense that it would never be reached?

  • Rule matching will compare public name on rule vs. hostname in url. If the names are different on your rules, you won't encounter the problem, you mentioned

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment