Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 3)

If you would like to read the other parts in this article series please go to:

Introduction

In the first parts of this series on Web and Server Publishing Rules, I went over some of the details involved in web publishing and the value it can provide you. In this Part 3, we’ll go over a sample Web Publishing Rule and show how the Web Publishing Rule Wizard works. We’ll also highlight and expand on some of the issues that were mentioned in part 1 of this series. Let’s get started!

Creating Web Publishing Rules

To create a Web Publishing Rule, the first step is to open the TMG firewall console and then click on the Firewall Policy node in the left pane of the console, as seen in the figure below.


Figure 1

After clicking on Firewall Policy, you click on the Tasks Tab in the Task Pane on the right side of the TMG firewall console. There you will see Firewall Policy Tasks. Click on the Publish Web Sites link in order to start the Web Publishing Rule Wizard.


Figure 2

This brings us to the Welcome to the New Web Publishing Rule Wizard page. Enter a name for the rule here in the Web Publishing Rule name text box. This name will appear in the list of firewall policy rules. Click Next.


Figure 3

On the Select Rule Action page, you will be given the choice of whether to make this an Allow or Deny rule. It might seem strange at first to think of creating a Deny rule. What’s the point of even creating a rule if all you’re going to do is deny the connection? Wouldn’t it be a lot easier to deny a connection by creating no rule at all? That is true, but there are scenarios where you might want to create an explicit Deny rule. One such scenario would be if you want to deny an HTTP connection to a certain site and create a redirection to an HTTPS connection. In this example, though, we’re going to create an Allow rule so select that option. Click Next.


Figure 4

On the Publishing Type page, you are given a number of choices. You can publish a single site, publish multiple sites or publish a web farm. If you publish a web farm, the TMG firewall will perform load balancing for you so that you will not need to use an external load balancer. This works very well and it is cost effective. If you publish multiple web sites, the wizard will make it easy for you to create multiple Web Publishing Rules at the same time for multiple sites. In this example, we’re going to publish a single site so we will select the Publish a single Web site or load balancer option. Click Next.


Figure 5

On the Server Connection Security page, you can choose to secure the connection between the TMG firewall and the published web server if you like. If you choose this option, an SSL connection will be established between the TMG firewall on the published server. The published server will need a web site certificate installed and the TMG firewall will need to trust that certificate. This option typically is used when you are using SSL to SSL bridging; in that case, the external user will establish an SSL connection to the TMG firewall and then the TMG firewall will forward that connection to the published web server, using a new SSL connection. This is the method by which the TMG firewall performs SSL inspection, that is, by decrypting the sessions and then re-encrypting it.

In this example, however, we will not be performing SSL bridging, so we are going to select the Use non-secured connections to connect the published Web server or server farm option and click Next.


Figure 6

On the Internal Publishing Details page, you are prompted to enter the name of the internal web site. This needs to be a name that the TMG firewall can resolve on the internal network, using your internal network DNS servers. It can be either a single label name or a fully qualified domain name. Note that if the TMG firewall cannot resolve the name (such as in a case where you are using an SSL connection to the published server and the common/subject name on the certificate is not resolvable), you can enable the Use a computer name or IP address to connect to the published server option by checking the box at the bottom of the page, and then enter the name or IP address of the web server you want to publish in the Computer name or IP address text box. Click Next after entering this information.


Figure 7

On the Internal Publishing Details page, you can enter the path that you want to be accessible to external users. As you can see in the screenshot, this entry is option. This is useful is you don’t want to publish all folders on the web server but just want to make a selected tree of folders available. You don’t have to enter anything on this page if you want to publish the entire site. In this case, we want to publish all folders under the root, so we’ll enter /*. Click Next


Figure 8

On the Public Name Details page, you set the name that you want the external users to use when connecting to the site. At this point, you can see that the external name that is used to connect to the site and the internal name used to connect to the site do not have to be the same. If you use a split DNS infrastructure, the names will be the same. If you have not deployed a split DNS infrastructure, then the names will be different in most cases. In either case, the TMG firewall has to be able to resolve the name of the internal name of the site and the external clients need to be able to resolve the public name that you configure on this page.

In the Accept requests for drop down box, you have the choice to accept connections for a single name (single site) or multiple sites. If you select the multiple sites option, you can add multiple public names, but the connections will be forwarded to the same internal server. This can be useful if you have changed domains over time but you still want users to be able to access the site using one of the older domain names. In this example, we’re going to select the This domain name (type below) option. Then we will enter the name of the domain in the Public name text box. We also can control which paths the user can access, as we did on the previous page. Note that in most cases, the external access path is going to be the same as the path that you entered on the previous page. That’s why you see the path already auto-populated with the same information you entered on the previous page. Click Next.


Figure 9

On the Select Web Listener page, you configure the rule to specify the Web Listener that you want to use. A Web Listener is a software construct that is responsible for accepting the connection from the web client that requests to access the published site through the TMG firewall. The Web Listener is configured with the ports on which you want to accept the connections and this page also enables you to define what type of authentication you want to force on the connection before a user is authorized to access the web site (if you want to enable authentication at all). The Web Listener is fairly complex and we’ll discuss in Part 3 of this article the details of the Web Publishing Rule and the Web Listener. In this example, we’re going to select an existing Web Listener and click Next.


Figure 10

The TMG firewall has the ability to perform authentication delegation. What this means is that if you enable authentication delegation, the TMG firewall will authenticate the user first. After the firewall authenticates the user, it will then authenticate on behalf of the user to the web site. After that authentication attempt is successful, the TMG firewall will then forward the user session to the published web site. This helps to prevent anonymous users from ever being able to touch your web site. In this example, we are not going to be performing authentication at the TMG firewall; this is a setting that must be configured on the Web Listener. We will take a look at how you do this later on in this series, when we look more closely at the Web Listener construction and configuration. Click Next.


Figure 11

On the User Sets page, you can configure which users are to be authorized to access the published web site. This is useful if you have sites that you only want a subset of your users to be able to access. In that case, even if a user successfully authenticates, if that user isn’t included in the set of allowed users, the user won’t be authorized to access the site. The default setting here is All Users. We will use the default setting in the current example because we are not enabling authentication yet and of course, if we aren’t authenticating, there is no way we can enable authorization. Click Next.


Figure 12

The rule is almost complete! On the Completing the New Web Publishing Rule Wizard page, you should carefully review the selections you made. Also, you can use the Test Rule button to have the TMG firewall perform a collection of basic tests to make sure the rule works as configured. Once that’s done, click Finish to complete the rule.


Figure 13

You can now see the new rule listed in the Firewall Policy section of the console.


Figure 14

Summary

In this, part 3 of our series on Web and Server Publishing Rules, we went over the steps involved in using the Web Publishing Rule Wizard and discussed some of the key options in the wizard and the implications of the choices. In the next part of this series, we’ll dive deeper into the rule that we have created and see some of the additional options that are available, as well as what options are not available in the Web Publishing Rule Wizard. As part of that deep dive, we’ll go into the inner workings of the Web Listener, which is the component that enables you to pre-authenticate users before allowing them access to your published web server. See you then! –Deb.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top