Web Access Policy

Overview of the Web Access Policy Wizard

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 Configure Web Access Policy link in the Tasks tab on Task Pane. This brings up the Welcome to the Web Access Policy Wizard page. Click Next.

Figure 1
On the Web Protection page, you have are given two options:

• Yes, enable the malware inspection feature
• No, do not enable the malware inspection feature

Note that we saw earlier that you can enable malware inspection by clicking the Configure Malware Inspection link on the Tasks tab in the Web Access Policy 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 Next.

Figure 2
On the Web Access Policy Type page, you have two options:

• Create a simple Web access policy for all the clients in my organization. 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
• Create customized Web access policies for users, group and computers. 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.

In this example we’ll select the Create customized Web access policies for users, groups and computers to see what options are available to us. Click Next.

Figure 3
On the Access Policy Groups page, you have three choices:

• Users and user group only. 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
• Computers, IP address, and subnets. 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.
• Any of the above. This option allows you to create rules that apply to both anonymous (connections that can’t be authenticated) and authenticated connections.

In this example, we’ll select the Any of the above option, since it seems to be the most complex one that will give us the most options to select from.

Figure 4
On the Default Web Access Policy 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 Deny the Web request 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 Allow the Web request option and click Next.

Figure 5
On the Anonymous Web Access Policies page, you define polices that apply to anonymous connections through the TMG firewall. To create the policy, you click the Add button. This brings up the Add Access Policy dialog box.
In the Add Access Policy dialog box, you first add the source of the request in the Access Groups 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 Source when creating a regular Access Rule. You use the Add button to add one or more of the following:

• Networks
• Network Sets
• Address Ranges
• Computers
• Computer Sets
• Subnets

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 Forbidden Web Sites. 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 Anonymous Web Access Policies page.
After creating your anonymous access policies, click Next.

Figure 6
On the Authenticated Web Access Policies 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 Add button on the Authenticated Web Access Policies page, you bring up the Add Access Policy dialog box.
When you click the Add button to add Access Groups 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 Administrators group and it allows this group to connect to the Forbidden Web Sites 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 Next.

Figure 7
On the Malware Inspection Setting page, you have the following options:

• Do not inspect Web content requested from the Internet. This turns off malware inspection for all the rules created in the Web Access policy ruleset.
• Inspect Web content requested from the Internet. This turns on the maware inspection feature for the rules in the Web Access Policy ruleset.
• Allow partial file delivery. 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.
• Block encrypted archives. This enables you to block .zip and other file archives (.rar, .tar, etc) that cannot be inspected by the malware inspection engine.

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 Next.

Figure 8
On the Web Cache Configuration 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 Configure Web Caching link on the Tasks tab of the Task Pane.
To enable caching, put a checkmark in the Enable Web caching checkbox. The click the Cache Drives 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.

Figure 9
After creating the cache drive, click Next.

Figure 10
That’s it! Check out your settings on the Completing the Web Access Policy page and click Finish.

Figure 11
Now let’s take a look at the Web Access Policy. Here you can see the Web Access Default Rule 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 Web Access Authenticated Policy: Allow Forbidden 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 Web Access Anonymous Policy: Deny Forbidden will trigger before the allow rule for the Administrators, and thus the administrators will be denied access.

Figure 12
However, before any of the rules trigger, you need to click the Apply button. After clicking the Apply button, you’ll see the Forefront TMG Warning dialog box. Here you have the options Save the changes, but don’t restart the services and Save the changes and restart the services. We want to Save the changes and restart the services so that the cache drive is enabled. You don’t need to restart the Microsoft Firewall service just to get the rules applied.

Figure 13
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 Malware Inspection tab, you’ll see that the Inspect content downloaded from Web servers to clients 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 All Firewall Policy pane.

Figure 14
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.

Figure 15
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 Web Access Authenticated Policy: Allow Forbidden rule and recreate this rule using the Access Rule wizard. Then put the new rule above the Deny Rule.

Figure 16