Creating a Web Access Policy using the Forefront Threat Management Gateway (TMG) Beta 1 (Part 2)

In the first part of this article series we took a look at the anti-malware configuration options and how they work with the Forefront TMG. The anti-malware feature is something new included with the TMG firewall and so it was worth taking some extra time to go over that feature. In this article, part 2 of the three part series on the TMG Web Access Policy, we’ll look at the Web Proxy and Web caching features.

In the TMG firewall console, click the Configure Web Proxy link in the Tasks tab of the Task Pane after clicking on the Web Access Policy node in the in the left pane of the TMG firewall console. This brings up the Properties dialog box for the default Internal Network. Here you can set the configuration for the Web Proxy listener on the Web Proxy tab. You use tab to set the type of authentication you want to support for outbound connections from this TMG Firewall Network.

While this is convenient, in most cases you’re going to have more than one “internal” network behind the TMG firewall, so you’ll have to go to the Networks node in the left pane of the console to configure the Web Proxy listener for those TMG firewall Networks.

Figure 1

When you click the Configure Web Caching link in the Tasks tab of the Task Pane, it brings up the Cache Settings dialog box. This is a new dialog box that brings together many configuration options that were located in several different places in previous versions of the ISA Firewall. In the Cache Settings dialog box you can configure your cache drive(s), create Cache Rules, create Content Download jobs, and configure the Advanced settings for Web caching. Consolidating all of these Web caching features into a single dialog box is a nice convenience introduced in the Forefront TMG firewall.

In this figure below, you can see the General tab. It indicates that the total cache size is 100 MB at this time. There is also a link to the Help file on how to configure cache drives. One thing I really like about the TMG dialog boxes is the comprehensive linking to Help file content. And the Help file content, even in this beta phase, is extremely good.

Figure 2

Click on the Cache Drives tab and you’ll see a list of cache drives. If you select one of the drives and click on the Configure button, you can change the size of the cache drive, or even move it to another volume if you like.

Figure 3

Click the Cache Rules tab. Here you can adjust existing Cache Rules or create new ones. The Microsoft Update Cache Rule is a special rule that allows the TMG firewall to support BITS caching. While technically the TMG firewall supports BITS caching, it really only works correctly with the Microsoft Update site, so you need to make sure that you don’t enable it for any other Cache Rules. In fact, when checking this feature on the TMG, I noticed that you aren’t even given the option to enable BITS caching on any other rules, as the option is grayed out.

The Web Access Scenario Cache Rule is one that is created when you run the Web Access Policy Wizard. It’s configuration is based on your selections when you run the Web Access Policy Wizard, which is something that we’ll do in the next article.

The Default Rule is applied to all other connections. In most cases, this rule will be the same as the Web Access Scenario Cache Rule. Remember, Cache Rules determine how content is cached by the TMG firewall when Web caching is enabled.

You also have the options on this tab to Export or Import Cache Rules.

Figure 4

If you select Microsoft Update Cache Rule and click the Edit button, and then click the Advanced tab, you can see that the Enabling caching of content received through the Background Intelligent Transfer Services (BITS) is enabled and grayed out so that you can’t disable it.

Figure 5

A Content Download Job allows you to pre-load content into the TMG firewall’s cache. For example, if there is a site that you want to download content from before users access the site on their own, you can create a Content Download Job that brings the content in and when the users later try to access the content, it will be delivered to them from cache instead of having to go to the destination Web server.

In the figure below you see a dialog box that appears when you first try to create a new Content Download Job. It allows the Local Host Network to listen for Web Proxy client requests. This is required so that the TMG firewall can be the source of the requests without depending on the configuration of the default Internal network.

I’ll go through a more detailed explanation of Content Download Jobs in a future article on ISAserver.org.

Figure 6

On the Advanced tab, you can set global cache settings, including:

• Cache objects that have an unspecified last modification time This allows the TMG firewall to cache information that does not include an expiration time. How long the information will stay in cache will be decided by the settings in a Cache Rule that applies to the particular Web object (HTML page, graphic, etc.)
• Cache objects even if they do not have an HTTP status code of 200 This allows objects to be cached even with the HTTP 200 response (OK) isn’t returned, such as when response codes 203, 300, 301 and 410 are returned (see 10 Status Code Definitions)
• Maximum size of URL cached in memory This is the maximum size of an object that can be stored in RAM cache. You want to make sure that this size isn’t too big, since you have limited RAM cache and you want to be able to get as much information as possible in it. The default is a good compromise.

There are also other options that allow you to decide how to handle expired objects if the destination Web site cannot be reached.

You can also configure the percentage of memory you want to dedicate to the cache. Remember that in-memory cache is much faster than on-disk cache, but also keep in mind that this isn’t really “free memory” and this isn’t dynamically configured. If another process needs more memory, the cache isn’t going to reduce it’s own size to free up memory for the other process that might need it.

Figure 7

When you click the Configure HTTP Compression, it brings up the HTTP Compression dialog box. Notice that this feature is enabled by default. However, there are no networks configured to Return Compressed Data or Request Compressed Data. In most cases you won’t use these feature unless you have a Web Proxy chaining scenario.

Figure 8

When you click the Configure RADIUS Server Settings or Configure LDAP Server Settings link in the Tasks tab of the Task Pane, it brings up the Authentication Servers dialog box. On the Authentication Servers dialog box, you’ll see the RADIUS Servers and the LDAP Servers tab.

You can configure the TMG firewall to use RADIUS authentication for both inbound and outbound connections. Unfortunately, RADIUS is hard to manage because you want to configure group based access controls, you have to create those group in the Active Directory. You can’t create custom TMG firewall groups (the same as the ability to create ISA Firewall groups with ISA 2004/2006).

A potentials solution to this problem is to use LDAP authentication. In previous versions of the ISA Firewall, LDAP authentication could only be used for inbound connections. I had expected that LDAP authentication would be supported for outbound connections in the TMG, but at least for the beta 1 version of the TMG, this feature is not available. So at this time, you’re only going to be able to use LDAP authentication for inbound (Web Publishing Rule) connections.

Figure 9

When you click the Configure DiffServ Preferences link in the Tasks tab of the Task Pane, you’ll see the HTTP DiffServ dialog box. DiffServ is useful if you have a routing infrastructure that supports packet prioritization using Differentiate Services Code Point (DSCP) values, which is an industry standard way of deploying Quality of Service (QoS) on routed networks.

Note that DiffServ bits can only be set for HTTP connections through the TMG firewall. You won’t be able to set them for communications using other protocols through the Forefront TMG. These values can be configured for URLs, Domains and Networks.

Also, be aware that the TMG will may not forward DiffServ bits on packets that it receives. So if there is a router behind the TMG forwarding traffic with DiffServ bits set to the TMG firewall, those bits may not be passed by the TMG.

Figure 10

When you click on the Configure Certificate Revocation link on the Tasks tab of the Task Pane, it will bring up the Certificate Revocation dialog box. By default, so settings are enabled:

• Verify that incoming client certificates are not revoked. When this setting is enabled, the TMG firewall will try to verify that User Certificates presented to the TMG firewall through Web Publishing Rules for authentication have not been revoked.
• Verify that incoming server certificate are not revoked in a Forward scenario. This settings enabled the TMG firewall to check that server certificates are not revoked when Web proxy clients are trying to connect to a secure server. There are actually two scenarios here. One is when there is a Web Proxy client behind the TMG firewall. The second scenario is when the TMG firewall is acting as a Web Proxy client itself, as is the case in a Web Proxy chaining scenario. In this case, the downstream checks to make sure that the upstream Web Proxy’s server certificate has not been revoked

There is one option that is not enabled by default:

• Verify that incoming server certificates are not revoked in a reverse scenario. When this option is enabled, the TMG firewall will check to see if the server certificate presented to the TMG firewall by a published server is revoked. Note that this is only an issue with SSL to SSL bridging, since in an SSL to HTTP bridging scenario, the back-end Web server doesn’t present a server certificate to the TMG firewall.

Figure 11

Summary

In this article, part 2 in the series on the Web Access Policy node in the TMG firewall console, we went over the options in the Tasks tab in the Task Pane. In the next and last part of the article series, we will go over the details of the Web Access Policy Wizard. See you then! –Tom.

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

• Creating a Web Access Policy using the Forefront Threat Management Gateway (TMG) Beta 1 (Part 1)
• Creating a Web Access Policy using the Forefront Threat Management Gateway (TMG) Beta 1 (Part 3)