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

[LEFT][CODE]http://www.isaserver.org/tutorials/Creating-Web-Access-Policy-Forefront-Threat-Management-Gateway-TMG-Beta-1-Part1.html[/CODE]
[B][SIZE=3]
PART-1[/SIZE][/B]

The Microsoft Forefront Threat Management Gateway is the next version of the ISA Firewall. While the ISA brand is going away, the software that we’ve come to know and love will continue under the new name of the Forefront TMG. Along with a new name come some new features and capabilities. Although the current version of the TMG firewall is likely far from feature complete, there are some changes that I think you’ll like.
[CENTER][URL="http://www.amazon.com/exec/obidos/ASIN/1597491993/isaserver1-20/"]
[/URL][/CENTER]
One of those new features shows up as a new node in the left pane of the TMG firewall console. This new node, named [B]Web Access Policy[/B] provides a location where you can configure the TMG firewall to allow outbound HTTP, HTTPS and Web proxy forwarded FTP connections to the Internet. This change also seems to represent an increased focus on HTTP for the product. While previous versions of the ISA Firewall did have a sophisticated Web proxy filter and HTTP Security Filter, the TMG firewall takes things to the next level by adding malware inspection for outbound HTTP requests.
[B]Overview of the Tasks tab on the Web Access Policy Node[/B]

One of the first things you’ll notice when you open the TMG firewall console is the cleaner look of the left pane of the console. Now we just have one level under the name of the server and the new node sticks out to any dyed in the wool ISA firewall admin. In the figure below you can see the new [B]Web Access Policy[/B] node.
[B][IMG]http://www.isaserver.org/img/upl/image0021211811143418.jpg[/IMG]
Figure 1[/B]
When you go to the [B]Web Access Policy[/B] node and click the [B]Tasks[/B] tab in the Task Pane, you’ll see that the TMG team has made things easier on us by creating a “one-stop shop” for Web Access and Web proxy filter configuration. The two main tasks are the [B]Configure Web Access Policy[/B] and [B]Configure Malware Inspection[/B], both of which are new with the Forefront TMG firewall. You can also see in the collection of [B]Related Tasks[/B] that they’ve brought together all of the Web proxy filter and HTTP configuration tasks for the serve into a single list.
[B][IMG]http://www.isaserver.org/img/upl/image0041211811143449.jpg[/IMG]
Figure 2[/B]
Let’s take a look at these tasks before we get into the details of how to create a Web Access Policy. First, we’ll click on the [B]Configure Malware Inspection [/B]link on the [B]Tasks[/B] tab in the Task Pane. This brings up the [B]Malware Inspection[/B] dialog box and the [B]General[/B] tab. Here you have the option to enable or disable malware inspection for the entire system. Note that this enables malware inspection for the system, not for any specific rule. You must first enable it here before you can enable is for any specific rule, or as we’ll see later, any collection of Web Access rules.
[B][IMG]http://www.isaserver.org/img/upl/image0061211811143449.jpg[/IMG]
Figure 3[/B]
Click on the [B]Exceptions[/B] tab. Here you can put together a list of sites that you never want to have content checked for malware. The [B]Sites Exempt from Malware Inspection[/B] group is automatically included.
[B][IMG]http://www.isaserver.org/img/upl/image0081211811539324.jpg[/IMG]
Figure 4[/B]
If you click on the [B]Site Exempt from Malware Inspection[/B] entry on the list above and click the [B]Edit[/B] button, you can see the sites that are included in the [B]Sites Exempt from Malware Inspection[/B] domain name set. These sites include [B]*.microsoft.com[/B], [B]*.windows.com[/B] and [B]*.windowsupdate.com[/B]. You can add more sites here if you like.
There’s an interesting security issue here. You can protect yourself by limiting what sites you can access, and you can protect yourself by inspecting content from malware. And you can do both. The philosophy behind inspecting connections for malware is that even if the site is trusted, there is still the chance that it may have been compromised by malware. In this case, does it make sense to exempt sites from content inspection? I don’t have a definitive answer on this issue, but it’s something that you should decide for yourself when you consider whether or not you want to exempt sites from malware inspection.
[B][IMG]http://www.isaserver.org/img/upl/image0101211811539324.jpg[/IMG]
Figure 5[/B]
On the [B]Inspection Settings[/B] page, you have many options regarding how the system will evaluate malware. The options include:

[LIST][*][B]Attempt to clean infected files[/B]. The TMG will try to clean the file. If a file cannot be cleaned, it is not saved and is removed from storage. A page will be presented to the user that the file could not be cleaned and has been deleted.[*][B]Block files with low and medium severity threats (higher level threats are blocked automatically). [/B]This increases the sensitivity of the scanner. However, how the TMG firewall determines what is a low, medium or high threat isn’t documented in the Help file.[*][B]Block suspicious files.[/B] This will block files that the TMG firewall considers suspicious. However, the method on how it determines whether a file is suspicious or not is not specified in Help at this time.[*][B]Block corrupted files.[/B] This will block files that the TMG determines are corrupted. However, the Help file at this time does not specify how the TMG firewall determines a file to be corrupted.[*][B]Block files that cannot be scanned. [/B]This will block files that the TMG cannot scan. However, how the TMG determines a file to be unscannable isn’t specified in the Help file.[*][B]Block encrypted files. [/B]This will have the TMG block files that are encrypted.[*][B]Block files if scanning time exceeds (seconds)[/B]. This option allows you to se a time limit on how long the TMG can take to scan a file before it decides to give up and delete the file. The default value is 300 seconds (5 minutes).[*][B]Block files if archive depth level exceeds.[/B] This sets a limit on how many times a file can be archived within an archive before the TMG decides to delete it. An example would be a zip file that’s zipped again. Often malware will try to hide itself by archiving itself many times. The default value is 20[*][B]Block files larger than (MB)[/B]. This sets a file size limited on what can be downloaded through the Forefront TMG firewall’s Web proxy filter. The default value is 1000 MB.[*][B]Block archive files if unpacked content if larger than (MB). [/B]This sets a size limit on unpacked files. The default value is 4095 MB.[/LIST]
As you can see, you have a lot of options here. Personally, I think some of the limits are a bit high, and can potentially stress memory and disk performance, but if you have a robust box (quad processor, 8 GB+ memory, fast hard disks), these values might not be so unreasonable.
[B][IMG]http://www.isaserver.org/img/upl/image0121211811539324.jpg[/IMG]
Figure 6[/B]
Malware scanning can be a bit disconcerting to your end users. One way to make this experience less painful for them, and to reduce your Help desk calls, you can choose to “trickle” files to the users while they’re being scanned. The users will see a progress bar as the file is downloaded, as I’ll show you later.
Note that you need to put a checkmark in the [B]Send progress notifications to clients as files are downloaded and inspected (applies to the second content types only) [/B]if you want the users to get the progress bar.
Now, this is a bit confusing. What I think is going on here is that if you select this option, you won’t get trickling of partial content. Instead, you get a progress bar on the Web page I’ll show you later, and only for the content types you select by clicking the [B]Select Content Types[/B] button. If you don’t select this option, the users see a download dialog box that might go slower than if the content wasn’t being inspected.
However, I don’t want you to quote me on this, as I haven’t tested each of the scenarios so it’s still not clear what the end user experience is for “tricked” and “non-trickled” files. I’ll keep you updated, probably in a blog post, when we get this issue figured out and well defined.
[B][IMG]http://www.isaserver.org/img/upl/image0141211811637559.jpg[/IMG]
Figure 7[/B]
Here are the list of MIME types that determine whether or not the content will be trickled or not, depending on the decision you made in the previous dialog box. As you can see, most MIME types are selected by progress notification and not for trickling.
[B][IMG]http://www.isaserver.org/img/upl/image0161211811637559.jpg[/IMG]
Figure 8[/B]
The figure below shows you what the user sees when downloading a file when we enable progress notification. In this example I showed a progress download Open Office (not that I use Open Office, but I needed a file large enough to give me time to take the screenshot).
[B][IMG]http://www.isaserver.org/img/upl/image0181211811637559.jpg[/IMG]
Figure 9[/B]
When the file download is complete, the Web browser will inform user that there is no malware detected in the file and that the user can click the [B]Download[/B] button in the browser to download the clean file.
[B][IMG]http://www.isaserver.org/img/upl/image0201211811900543.jpg[/IMG]
Figure 10[/B]
Let’s move to the last tab in the [B]Malware Inspection[/B] dialog box. This is the [B]Storage[/B] tab. Here you can configure the location where the downloaded files are stored for malware inspection.
[B][IMG]http://www.isaserver.org/img/upl/image0221211811900543.jpg[/IMG]
Figure 11[/B]
I took a look at the [B]Windows\Temp[/B] file to see if the was anything interesting in it. Turns out that the Forefront TMG firewall stores a lot of files in that folder, as the figure below shows. I don’t know what all the files in this folder do, but it appears that there are a number of log files. I believe that the .etl files are trace logs, though I can’t say for sure.
[B][IMG]http://www.isaserver.org/img/upl/image0241211811921731.jpg[/IMG]
Figure 12[/B]
The security settings on this folder are interesting. As you can see, the [B]SQLServer2005ReportingServiceWebServiceUsers$ISAS[/B] account has permissions on this folder. There is another folder under this one named [B]Emp[/B] and the [B]fwsrv[/B] account has Full control.
[B][IMG]http://www.isaserver.org/img/upl/image0261211811921731.jpg[/IMG]
Figure 13[/B]
[B]Summary[/B]

In this first part of a three part series on Web Access Policy in the Forefront Threat Management Gateway (TMG), we covered some of the anti-malware configuration options and the [B]Tasks[/B] tab entries on the [B]Web Access Policy[/B] node in the TMG firewall console. In the next part of this series, we will take a close look at the other options in the [B]Tasks[/B] tab of the [B]Web Access Policy[/B] Task Pane.
[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/Creating-Web-Access-Policy-Forefront-Threat-Management-Gateway-TMG-Beta-1-Part2.html[/CODE]

[B][SIZE=3]PART-2[/SIZE][/B]

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.
[CENTER][URL="http://www.amazon.com/exec/obidos/ASIN/1597491993/isaserver1-20/"]
[/URL][/CENTER]
In the TMG firewall console, click the [B]Configure Web Proxy[/B] link in the [B]Tasks[/B] tab of the Task Pane after clicking on the [B]Web Access Policy [/B]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 [B]Web Proxy [/B]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 [B]Networks[/B] node in the left pane of the console to configure the Web Proxy listener for those TMG firewall Networks.
[B][IMG]http://www.isaserver.org/img/upl/image0021212157885402.jpg[/IMG]
Figure 1[/B]
When you click the [B]Configure Web Caching[/B] link in the [B]Tasks[/B] tab of the Task Pane, it brings up the [B]Cache Settings[/B] 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 [B]Cache Settings[/B] 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 [B]General[/B] 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.
[B][IMG]http://www.isaserver.org/img/upl/image0041212157885402.jpg[/IMG]
Figure 2[/B]
Click on the [B]Cache Drives[/B] tab and you’ll see a list of cache drives. If you select one of the drives and click on the [B]Configure[/B] button, you can change the size of the cache drive, or even move it to another volume if you like.
[B][IMG]http://www.isaserver.org/img/upl/image0061212157885402.jpg[/IMG]
Figure 3[/B]
Click the [B]Cache Rules[/B] tab. Here you can adjust existing Cache Rules or create new ones. The [B]Microsoft Update Cache Rule [/B]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 [B]Web Access Scenario Cache Rule[/B] 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 [B]Default Rule[/B] is applied to all other connections. In most cases, this rule will be the same as the [B]Web Access Scenario Cache Rule[/B]. 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 [B]Export[/B] or [B]Import[/B] Cache Rules.
[B][IMG]http://www.isaserver.org/img/upl/image0081212157908371.jpg[/IMG]
Figure 4[/B]
If you select [B]Microsoft Update Cache Rule[/B] and click the [B]Edit[/B] button, and then click the [B]Advanced[/B] tab, you can see that the [B]Enabling caching of content received through the Background Intelligent Transfer Services (BITS)[/B] is enabled and grayed out so that you can’t disable it.
[B][IMG]http://www.isaserver.org/img/upl/image0101212157908387.jpg[/IMG]
Figure 5[/B]
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.
[B][IMG]http://www.isaserver.org/img/upl/image0121212157908387.jpg[/IMG]
Figure 6[/B]
On the [B]Advanced[/B] tab, you can set global cache settings, including:

[LIST][*][B]Cache objects that have an unspecified last modification time[/B] 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.)[*][B]Cache objects even if they do not have an HTTP status code of 200 [/B]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 [URL="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html"]10 Status Code Definitions[/URL])[*][B]Maximum size of URL cached in memory [/B]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.[/LIST]
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.
[B][IMG]http://www.isaserver.org/img/upl/image0141212158005559.jpg[/IMG]
Figure 7[/B]
When you click the [B]Configure HTTP Compression[/B], it brings up the [B]HTTP Compression [/B]dialog box. Notice that this feature is enabled by default. However, there are no networks configured to [B]Return Compressed Data[/B] or [B]Request Compressed Data[/B]. In most cases you won’t use these feature unless you have a Web Proxy chaining scenario.
[B][IMG]http://www.isaserver.org/img/upl/image0161212158005559.jpg[/IMG]
Figure 8[/B]
When you click the [B]Configure RADIUS Server[/B] [B]Settings[/B] or [B]Configure LDAP Server Settings[/B] link in the [B]Tasks[/B] tab of the Task Pane, it brings up the [B]Authentication Servers[/B] dialog box. On the [B]Authentication Servers[/B] dialog box, you’ll see the [B]RADIUS Servers[/B] and the [B]LDAP Servers[/B] 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.
[B][IMG]http://www.isaserver.org/img/upl/image0181212158005559.jpg[/IMG]
Figure 9[/B]
When you click the [B]Configure DiffServ Preferences[/B] link in the [B]Tasks[/B] tab of the Task Pane, you’ll see the [B]HTTP DiffServ[/B] 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.
[B][IMG]http://www.isaserver.org/img/upl/image0201212158021324.jpg[/IMG]
Figure 10[/B]
When you click on the [B]Configure Certificate Revocation[/B] link on the [B]Tasks[/B] tab of the Task Pane, it will bring up the [B]Certificate Revocation[/B] dialog box. By default, so settings are enabled:

[LIST][*][B]Verify that incoming client certificates are not revoked[/B]. 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.[*][B]Verify that incoming server certificate are not revoked in a Forward scenario[/B]. 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[/LIST]
There is one option that is not enabled by default:

[LIST][*][B]Verify that incoming server certificates are not revoked in a reverse scenario[/B]. 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.[/LIST]
[B][IMG]http://www.isaserver.org/img/upl/image0221212158021340.jpg[/IMG]
Figure 11[/B]
[B]Summary[/B]

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 [B]Tasks[/B] 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.
[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/Creating-Web-Access-Policy-Forefront-Threat-Management-Gateway-TMG-Beta-Part3.html[/CODE]

[B][SIZE=3]PART-3[/SIZE][/B]

In the first two parts of this three part article series we looked at some of the anti-malware and Web Proxy and caching features included with the Beta 1 version of the Forefront TMG. In this part three, and last part of the series, we’ll take a look at a completely new feature included with the TMG – the Web Access Policy Wizard.
[B]Overview of the Web Access Policy Wizard[/B]

Now let’s get to the heart of the subject, which is the Web Access Policy Wizard. The Web Access Policy Wizard is a new wizard not included in previous versions of the ISA Firewall. You can use the Web Access Policy Wizard to create all of your HTTP and HTTPS outbound access rules. The wizard will then create a Web Access Policy Group that is automatically placed into Firewall policy. While I like the idea of creating a group, we’ll see that there are some limitations to this way of creating Access Rules. Hopefully the issue we’ll find at the end of this article will be fixed by the time the TMG goes RTM.
Click the [B]Configure Web Access Policy[/B] link in the [B]Tasks[/B] tab on Task Pane. This brings up the [B]Welcome to the Web Access Policy Wizard[/B] page. Click [B]Next[/B].
[B][IMG]http://www.isaserver.org/img/upl/image0021213610268604.jpg[/IMG]
Figure 1[/B]
On the [B]Web Protection[/B] page, you have are given two options:

[LIST][*][B]Yes, enable the malware inspection feature[/B][*][B]No, do not enable the malware inspection feature[/B][/LIST]
Note that we saw earlier that you can enable malware inspection by clicking the [B]Configure Malware Inspection[/B] link on the [B]Tasks[/B] tab in the [B]Web Access Policy[/B] node. However, the wizard tries to make things a little easier for you by giving you this option here.
Note that the page says that Malware inspection works for 90 days without a license. I’m not sure if this applies to the Beta 1 product. I also don’t know if it will continue working without a license. Click [B]Next[/B].
[B][IMG]http://www.isaserver.org/img/upl/image0041213610268620.jpg[/IMG]
Figure 2[/B]
On the [B]Web Access Policy Type[/B] page, you have two options:

[LIST][*][B]Create a simple Web access policy for all the clients in my organization[/B]. This allows you to create a simple, global Web access rule that applies to all users, so authentication is not required and not supported if you choose this option[*][B]Create customized Web access policies for users, group and computers[/B]. This option allows you to create a more complex Web access policy, which will end up creating a Web access policy group. You can create rules that apply to both authenticated and anonymous connections.[/LIST]
In this example we’ll select the [B]Create customized Web access policies for users, groups and computers[/B] to see what options are available to us. Click [B]Next[/B].
[B][IMG]http://www.isaserver.org/img/upl/image0061213610268620.jpg[/IMG]
Figure 3[/B]
On the [B]Access Policy Groups[/B] page, you have three choices:

[LIST][*][B]Users and user group only[/B]. This option enables you to create Access Rules for authenticated users. If users can’t authenticate, and these are the only rules you have, the TMG firewall will default to the more secure configuration and reject the request[*][B]Computers, IP address, and subnets[/B]. This option will create a Web Access policy group that applies to clients that cannot authentication, and allows you to configure access based on the IP address of the requesting client.[*][B]Any of the above[/B]. This option allows you to create rules that apply to both anonymous (connections that can’t be authenticated) and authenticated connections.[/LIST]
In this example, we’ll select the [B]Any of the above[/B] option, since it seems to be the most complex one that will give us the most options to select from.
[B][IMG]http://www.isaserver.org/img/upl/image0081213610382807.jpg[/IMG]
Figure 4[/B]
On the [B]Default Web Access Policy[/B] page, you decide what you want the TMG firewall to do if the connection request doesn’t match any of the other rules in the Web Access rule group. In most cases, you will want to select the [B]Deny the Web request[/B] option, since this would essentially be your HTTP connection request “clean rule”. However, when testing, you might want to take a more liberal approach, since you might not be sure that the TMG is even working during your early testing. There’s always time to tighten things up later.
In this example we’ll select the [B]Allow the Web request[/B] option and click [B]Next[/B].
[B][IMG]http://www.isaserver.org/img/upl/image0101213610382807.jpg[/IMG]
Figure 5[/B]
On the [B]Anonymous Web Access Policies[/B] page, you define polices that apply to anonymous connections through the TMG firewall. To create the policy, you click the [B]Add[/B] button. This brings up the [B]Add Access Policy[/B] dialog box.
In the [B]Add Access Policy[/B] dialog box, you first add the source of the request in the [B]Access Groups[/B] frame. This was a bit confusing to me at first, since it doesn’t make it clear that what you entire into this section is the same as the [B]Source[/B] when creating a regular Access Rule. You use the [B]Add[/B] button to add one or more of the following:

[LIST][*]Networks[*]Network Sets[*]Address Ranges[*]Computers[*]Computer Sets[*]Subnets[/LIST]
The reason why only this options are available is that each of these include only IP address. They do not include users or groups, which would require authenticated connections.
After you decide what the source is for the policy, you decide what the destination would be. This is more intuitive and fits with regular Access Rule configuration, instead of calling the destination a “server group” or something similar. In addition, you need to determine if given this source and destination, should the connection be allowed or denied.
In this example, I’ve created a Access Policy that denies access from all hosts on the default Internal Network to the destination, which is an URL set I named [B]Forbidden Web Sites[/B]. I also created a rule that allows all IP addresses on the default Internal Network to all sites on the network. Then I moved the Deny rule above the allow rules by using the arrows on the [B]Anonymous Web Access Policies[/B] page.
After creating your anonymous access policies, click [B]Next[/B].
[B][IMG]http://www.isaserver.org/img/upl/image0121213610862885.jpg[/IMG]
Figure 6[/B]
On the [B]Authenticated Web Access Policies[/B] page, you create Access Policies that apply to users who can authenticate. In this case, it will be users configured as Web Proxy or Firewall clients. When you click the [B]Add[/B] button on the [B]Authenticated Web Access Policies[/B] page, you bring up the [B]Add Access Policy [/B]dialog box.
When you click the [B]Add[/B] button to add [B]Access Groups[/B] on this page, you are presented with User Groups. So, in this example, the source is more accurately thought of as a group. Note that this will only work when the TMG firewall is part of an Active Directory domain. If you choose to use RADIUS, you will have to later configure the TMG firewall to use a RADIUS server and then configure the rules manually to use the RADIUS server.
In the example below, you can see that I have created an Access Policy that applies to the [B]Administrator[/B][B]s[/B] group and it allows this group to connect to the [B]Forbidden Web Sites[/B] URL set. The goal of this policy is to allow users who members of the Administrators group access to the Forbidden Web sites group, which represents an exception on the anonymous rule I created earlier. Of course, in order for this to work, I’m going to need to put this rule above the anonymous deny rule, but we can do that later.
(Even though the user can authenticate, an anonymous rule actually applies to “All Users”, whether they can authenticate or not – that’s why we need to move the authenticated access rule above the anonymous rule in this example).
Click [B]Next[/B].
[B][IMG]http://www.isaserver.org/img/upl/image0141213610862885.jpg[/IMG]
Figure 7[/B]
On the [B]Malware Inspection Setting[/B] page, you have the following options:

[LIST][*][B]Do not inspect Web content requested from the Internet[/B]. This turns off malware inspection for all the rules created in the Web Access policy ruleset.[*][B]Inspect Web content requested from the Internet[/B]. This turns on the maware inspection feature for the rules in the Web Access Policy ruleset.[*][B]Allow partial file delivery[/B]. This enables file “trickling” like we talked about earlier. In this case, the user sees the file download instead of seeing the progress bar on the Web page.[*][B]Block encrypted archives[/B]. This enables you to block .zip and other file archives (.rar, .tar, etc) that cannot be inspected by the malware inspection engine.[/LIST]
We’ll choose the inspect option and allow for partial file delivery. Not sure what this will do to our configuration that allows for progress notification, though. Click [B]Next[/B].
[B][IMG]http://www.isaserver.org/img/upl/image0161213610862885.jpg[/IMG]
Figure 8[/B]
On the [B]Web Cache Configuration[/B] page you’re given the opportunity to configure the TMG firewall to perform Web caching. This feature is not enabled by default, so if you want to enable Web caching, you’ll need to configure a cache drive here. Actually, even if you don’t create a cache drive at this point, you can create a cache drive by clicking the [B]Configure Web Caching[/B] link on the [B]Tasks[/B] tab of the Task Pane.
To enable caching, put a checkmark in the [B]Enable Web caching[/B] checkbox. The click the [B]Cache Drives[/B] button. The cache is stored in a single file on the drive or drives that you select. The maximum cache size per volume is 64 GB. It’s considered a best practice to place the cache file on a drive different from the operating system and TMG program files. Estimates vary on the optimal cache size, but I consider 5-10MB per user to be reasonable. However, if you have a small number of users (less than 100), you might want to increase this value. One thing you have to be careful with is to make sure that you don’t make the cache too large. There is a chance that the time it takes to search a very large cache file will be longer than it would take to get the content directly from the destination Web server.
[B][IMG]http://www.isaserver.org/img/upl/image0181213610896464.jpg[/IMG]
Figure 9[/B]
After creating the cache drive, click [B]Next[/B].
[B][IMG]http://www.isaserver.org/img/upl/image0201213610896464.jpg[/IMG]
Figure 10[/B]
That’s it! Check out your settings on the [B]Completing the Web Access Policy[/B] page and click [B]Finish[/B].
[B][IMG]http://www.isaserver.org/img/upl/image0221213610896464.jpg[/IMG]
Figure 11[/B]
Now let’s take a look at the [B]Web Access Policy[/B]. Here you can see the [B]Web Access Default Rule[/B] is placed at the bottom, since this rule is the one that’s triggered if none of the other rules you created match the connection request.
Notice that the wizard has automatically placed the anonymous rules before the authenticated access rules. In general, this is a good policy, because if you put authenticated access rules above anonymous rules, the anonymous rules will never trigger, because the client is unable to authenticate. When this happens, the connection is dropped. By putting the anonymous access rules above the authenticated access rules, you insure that connections that you want to allow to anonymous users will not be dropped by the authenticated access rules.
However, in this scenario the rule order isn’t how we want it. We actually want to put the rule [B]Web Access Authenticated Policy: Allow Forbidden[/B] on the top of the list. Why? Because we want to allow Administrator access to the forbidden sites while disallowing all other users access. If we don’t put this rule on the top of the list, the [B]Web Access Anonymous Policy: Deny Forbidden[/B] will trigger before the allow rule for the Administrators, and thus the administrators will be denied access.
[B][IMG]http://www.isaserver.org/img/upl/image0241213610913885.jpg[/IMG]
Figure 12[/B]
However, before any of the rules trigger, you need to click the [B]Apply[/B] button. After clicking the [B]Apply[/B] button, you’ll see the [B]Forefront TMG Warning[/B] dialog box. Here you have the options [B]Save the changes, but don’t restart the services[/B] and [B]Save the changes and restart the services[/B]. We want to [B]Save the changes and restart the services[/B] so that the cache drive is enabled. You don’t need to restart the Microsoft Firewall service just to get the rules applied.
[B][IMG]http://www.isaserver.org/img/upl/image0261213611058214.jpg[/IMG]
Figure 13[/B]
When you double click on one of the Web Access Policy rules to see the properties of the rule, you can see that it looks like a typical Access Rule. However, if you click on the [B]Malware Inspection[/B] tab, you’ll see that the [B]Inspect content downloaded from Web servers to clients[/B] option is enabled. This won’t be the case for non-HTTP related rules.
Also, notice that the Web Access Policy is placed in a group when can be expanded and collapsed when you view it in the [B]All Firewall Policy[/B] pane.
[B][IMG]http://www.isaserver.org/img/upl/image0281213611058229.jpg[/IMG]
Figure 14[/B]
Now for the last thing we need to do – move the Authenticated Access Policy for forbidden sights up to the top of the list so that Administrators can get to the forbidden sights. There are two ways you can move a typical Access Rule: right click the rule and click the Move Up command, or click the Move Up command button in the button bar.
In the figure below you can see the options available when I right click the rule. Yikes! There’s no Move Up command available. Maybe they forgot to put this in the Beta 1 version of the product. Let’s take a look at the button bar and see if they put the Move Up button there.
[B][IMG]http://www.isaserver.org/img/upl/image0301213611058229.jpg[/IMG]
Figure 15[/B]
What’s up with this? No Move Up button here either! So, it looks like at this time that you can’t change the rule order when you create a Web Access Policy. This can be a serious problem in the example we’re using here, where we want to give a group of authenticated users access to a site that we want to deny to all users, authenticated or not. I’m assuming that this is a beta bug. However, if this is by design, the solution is to delete the [B]Web Access Authenticated Policy: Allow Forbidden[/B] rule and recreate this rule using the Access Rule wizard. Then put the new rule above the Deny Rule.
[B][IMG]http://www.isaserver.org/img/upl/image0321213611086026.jpg[/IMG]
Figure 16[/B]
[B]Summary[/B]

In this three part series on the Web Access Policy node in the beta 1 version of the Forefront Threat Management Gateway (TMG), we looked at the anti-malware feature set, the new collection of Web Proxy and Web caching tools in the [B]Tasks[/B] tab of the Web Access Policy Task Pane, and then finished up with a review of the new Web Access Policy Wizard.
As I do in all my articles on the Beta 1 version of the Forefront TMG, I want to remind you that the TMG firewall is far from feature complete. I know that many of you who are reviewing the TMG feel that Microsoft has not been listening to your requests for new features that you consider vital for future versions of the ISA Firewall (the Forefront TMG is the next version of the ISA Firewall). Be patient and wait for future betas, as I am sure that by the time the TMG goes RTM, you will be very happy with what you see. Thanks! –Tom

[/LEFT]