ISA Server 2006: Installing ISA 2006 Enterprise Edition (beta) in a Unihomed Workgroup Configuration

[LEFT][LEFT][CODE]http://www.isaserver.org/tutorials/ISA-Server-2006-Installing-ISA-2006-Enterprise-Edition-beta-Unihomed-Workgroup-Configuration.html[/CODE][/LEFT]

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

SA Server 2006 is the next version of the ISA firewall product line. In the past we’ve focused on the ISA firewall’s firewall components and how you can deploy the ISA firewall in a number of firewall roles, such as edge firewall, back-end firewall, services segment firewall, and wireless LAN firewall. We’ve been promoting the ISA firewall deployment concept for almost six years, and we’ll continue to do that.

However, we’ll change our approach a little bit now with the release of ISA Server 2006. The reason for this is that the new ISA firewall, ISA Server 2006, has new features and improvements that are primarily focused on the Web proxy filter components that support Web Publishing Rules. These components include:

[LIST][*]Improved OWA, OMA, ActiveSync and RPC/HTTP publishing support[*]Improved SharePoint Portal Server support[*]Improved Windows SharePoint Services support[*]Support for publishing Web farms[*]Support for binding multiple certificates to a single Web listener[*]Support for wildcard certificates bound to the published Web server[*]Support for multiple new authentication delegation scenarios[*]Support for LDAP authentication for Web Publishing Rules[*]And many more![/LIST]
I won’t go through an entire review of what’s new and improved in the new ISA firewall product at this time. I’ll prepare another article on that topic for you and publish here on ISAserver.org in the near future. At this point I just want to make it clear that the major thrust of the new ISA firewall product is on secure Web Publishing scenarios.
[B]Apologia for Unihomed ISA Firewall Deployments[/B]

One advantage of the Web Publishing scenario is that you can place the ISA firewall just about anywhere on the network. And one of the most popular deployment scenarios in a Web publishing only scenario is placement of a unihomed ISA firewall in Web proxy only mode in an existing firewall’s DMZ segment. The existing firewall can be a multihomed ISA firewall, or it can be any other kind of network firewall.
I’ve already gone into the details of how to configure a unihomed ISA firewall in a DMZ segment over at [URL="http://www.isaserver.org/articles/2004pixwebproxy.html"][B]http://www.isaserver.org/articles/2004pixwebproxy.html[/B][/URL] so I won’t repeat that effort here. What I will do in this article is demonstrate how to install ISA Server 2006 on a single NIC server on the corporate network. In an article that follows this one, I’ll describe how to install ISA Server 2006 Enterprise Edition on an array of single NIC servers.
This article also represents a major departure from how I usually configure the ISA firewall in another way: the unihomed ISA firewall won’t be a member of an Active Directory domain. While domain membership significantly enhances the overall security the ISA firewall can provide when deployed in full firewall mode, this isn’t necessarily true when the ISA firewall is installed as a unihomed Web proxy server dedicated to Web publishing. This is especially the case with ISA Server 2006, given that we now have integrated support for LDAP authentication.
[B]Procedure for Installing ISA Server 2006 Enterprise Edition on a Unihomed Computer[/B]

Before you get started installing ISA Server 2006 Enterprise Edition on a new computer, make sure you have done the following:

[LIST][*]Install Windows Server 2003 and installed Windows Server 2003 SP1 and all current updates[*]Do not join the unihomed computer to the domain[*]Configure a static IP address on the network interface[*]Configure a DNS server address on the network interface that enables the unihomed ISA firewall to resolve its own name and the names of the published servers. You should configure the device to use a domain name suffix that matches your Active Directory domain so that the machine can resolve its own name.[*]If you are not allowing dynamic DNS registrations on your internal DNS servers, manually enter a Host (A) record for the unihomed ISA firewall device into your DNS[*]Configure the unihomed ISA firewall’s network interface with a gateway address that allows it to reach both the Internet and the published servers[*]Obtain the ISA Server 2006 Enterprise Edition beta trial software at [URL="http://www.microsoft.com/isaserver/2006/beta.mspx"][B]http://www.microsoft.com/isaserver/2006/beta.mspx[/B][/URL][/LIST]
Once you’ve performed those actions, you’ll be ready to install ISA Server 2006 Enterprise Edition on your unihomed computer.
Perform the following steps to install ISA Server 2006 Enterprise Edition:

[LIST=1][*]Copy the installation files for ISA Server 2006 Enterprise Edition to the unihomed ISA firewall device. Then double click on the [B]isaautorun.exe[/B] to bring up the installation dialog box.[*]In the [B]Microsoft ISA Server 2006 beta [/B]installation dialog box, click the [B]Install ISA Server 2006 [/B]link.[*]Click [B]Next[/B] on the [B]Welcome to the Installation Wizard for Microsoft ISA Server 2006 Beta[/B] page.[*]On the [B]License Agreement[/B] page, select the [B]I accept the terms in the license agreement[/B] option and click [B]Next[/B].[*]On the [B]Customer Information [/B]page, enter your [B]User Name[/B], [B]Organization[/B] and [B]Product Serial Number[/B] and click [B]Next[/B].[*]On the [B]Setup Scenarios[/B] page, select the [B]Install both ISA Server services and Configuration Storage server[/B] option. Note that this option implies that you can install both ISA Server firewall services and the CSS at the same time, and then later install additional array members once you have this installed. [I]This is not true[/I]. Use this option [I]only if you plan to deploy a single member ISA Server 2006 Enterprise Edition array[/I]. If you plan to add additional array members later, then [I]do not select this option[/I]. Since this article is focused on installing a single ISA Server 2006 Enterprise Edition unihomed device as a single member array, we will use this option. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021142596116593.jpg[/IMG]
[B]Figure 1[/B][/INDENT]
[LIST=1][*]On the [B]Component Selection[/B] page, accept the default settings. Note that you don’t have the option to install the Firewall client. I’m not sure where or how we’ll end up doing this in the future, as its also not an option on the initial setup page. This will likely be worked out by the time the product releases. Note that [B]Advanced Logging [/B]is MSDE logging. If you prefer to use SQL logging or text based logging, then do not select this option Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041142596116609.jpg[/IMG]
[B]Figure 2[/B][/INDENT]
[LIST=1][*]On the [B]Enterprise Installation Options[/B] page, select the [B]Create a new ISA Server enterprise [/B]option. Since this will be the only machine in the array, we need to create a new ISA enterprise. Note that the option [B]Create a replica of the enterprise configuration[/B] option is not available to workgroup configurations. This is something to keep in mind in the future if you want to have a backup CSS for your enterprise array. However, its not an issue for us, since this is a single machine array. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061142596116609.jpg[/IMG]
[B]Figure 3[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]New Enterprise Warning[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0081142596468515.jpg[/IMG]
[B]Figure 4[/B][/INDENT]
[LIST=1][*]On the [B]Internal Network [/B]page, click the [B]Add[/B] button.[*]In the [B]Addresses[/B] dialog box, click the [B]Add Adapter[/B] button. In the [B]Select Network Adapters[/B] dialog box, put a checkmark in the checkbox next to the single interface installed on the computer. Note that in a typical firewall installation, this NIC would be used to define the default Internal network. In a unihomed ISA firewall Web proxy configuration, this is not the case, since all addresses are considered internal. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101142596468515.jpg[/IMG]
[B]Figure 5[/B][/INDENT]
[LIST=1][*]In the [B]Addresses[/B] dialog box, click [B]OK[/B]. Note that the addresses listed in this dialog box will have no meaning in the unihomed ISA firewall configuration scheme. In a normal ISA firewall setup with multiple interfaces, these addresses would define the default Internal ISA firewall Network. However, as I mentioned in the last step, with a unihomed ISA firewall in Web proxy mode, [I]all addresses are considered part of the default Internal ISA firewall Network[/I].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121142596468531.jpg[/IMG]
[B]Figure 6[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Internal Network [/B]page. Note again that the IP addresses listed here do not represent the default Internal Network on a unihomed ISA firewall as we'll see later when we apply the single NIC ISA firewall template.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0141142596764125.jpg[/IMG]
[B]Figure 7[/B][/INDENT]
[LIST=1][*]On the [B]Firewall Client Connections[/B] page, click [B]Next[/B]. We don’t have to worry about Firewall client connections because both Firewall and SecureNAT clients are [I]not supported[/I] on a unihomed ISA firewall in Web proxy configuration. Only Web proxy clients are supported.[*]Click [B]Next[/B] on the [B]Services Warning[/B] page.[*]Click [B]Install[/B] to being the installation.[*]On the [B]Installation Wizard Completed [/B]page, put a checkmark in the [B]Invoke ISA Server Management when the wizard closes[/B] checkbox and click [B]Finish[/B].[*]Close the [B]Internet Explorer [/B]window entitled [B]Protect the ISA Server Computer[/B].[/LIST]

[B]Post Installation Review[/B]

The first thing you’ll notice when the console opens is a link entitled [B]Click here to learn about the Customer Experience Improvement Program[/B]. Click that link.[INDENT] [IMG]http://www.isaserver.org/img/upl/image0161142596764125.jpg[/IMG]
[B]Figure 8[/B][/INDENT]This brings up the [B]Customer Feedback[/B] dialog box. I highly recommend that you participate in the Customer Experience Improvement Program. No personal data is sent to Microsoft and the result of your participation is to make the ISA firewall product more flexible and provide even higher levels of security to your network. Select the [B]Yes[/B] option to participate in the program.[INDENT] [IMG]http://www.isaserver.org/img/upl/image0181142596764140.jpg[/IMG]
[B]Figure 9[/B][/INDENT]After you select an option and click [B]OK[/B], the link disappears from the middle pane of the console.
Expand all the nodes in the left pane of the ISA firewall console. Then perform the following steps to see the definition of the default Internal ISA firewall Network:

[LIST=1][*]In the left pane of the ISA firewall console, click the [B]Networks[/B] node under the [B]Configuration[/B] node.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0201142600593671.jpg[/IMG]
[B]Figure 10[/B][/INDENT]
[LIST=1][*]In the [B]Networks[/B] node, click the [B]Networks[/B] tab in the middle pane of the ISA firewall console. Double click on the [B]Internal[/B] entry.[*]In the [B]Internal Properties[/B] dialog box, click the [B]Addresses[/B] tab. Here you see the addresses that define the default Internal ISA firewall Network at this time. However, this will change when we configure this ISA firewall to act as a Web proxy only unihomed ISA firewall. Click [B]Cancel[/B] to leave this dialog box.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0221142601479734.jpg[/IMG]
[B]Figure 11[/B][/INDENT]What we need to do now is apply the unihomed ISA firewall template to configure this machine as a unihomed Web proxy only ISA firewall. Perform the following steps to apply the template:

[LIST=1][*]In the Task Pane, click the [B]Templates[/B] tab. Scroll down the list of templates and click the [B]Single Network Adapter[/B] template.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0241142601479734.jpg[/IMG]
[B]Figure 12[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Welcome to the Network Template Wizard[/B] page.[*]Click [B]Next[/B] on the [B]Export the ISA Server Configuration[/B] page. Note that you have the option to export the current configuration, but we’ll not use that option because we haven’t made any configuration changes from the default setting.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0261142601479750.jpg[/IMG]
[B]Figure 13[/B][/INDENT]
[LIST=1][*]On the [B]Internal Network IP Addresses[/B] page, you’ll see the addresses that will be configured to define the default ISA firewall Internal Network. Notice that all IP addresses except the local host network range are considered part of the default Internal network. For this reason, SecureNAT and Firewall clients are not supported in a unihomed Web proxy mode ISA firewall configuration. You do not need to make any changes on this page. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0281142602410687.jpg[/IMG]
[B]Figure 14[/B][/INDENT]
[LIST=1][*]On the [B]Select a Firewall Policy[/B] page, you are offered a single firewall policy to select from. Click on the [B]Apply default Web proxying and caching configuration[/B] option. This will apply the default Deny rule to the firewall policy for the array. No Network Rules are created because the Web proxy always replaces its own IP address for the IP address of the Web proxy client connecting to the Internet through the unihomed Web proxy mode ISA firewall. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0301142602410687.jpg[/IMG]
[B]Figure 15[/B][/INDENT]
[LIST=1][*]On the [B]Completing the Network Template Wizard[/B] page, click [B]Finish[/B].[*]Click [B]Apply [/B]to save the changes and update the firewall policy.[*]Click [B]OK[/B] in the [B]Apply New Configuration[/B] dialog box.[/LIST]
At this point you’re ready to start configuring firewall policy and customizing the installation.


[B]Summary[/B]

In this article we went over the concepts involved with deploying and installing a unihomed Web proxy mode ISA firewall. We then went over the step by step details of installing a unihomed Web proxy mode ISA firewall. At the end of the process the ISA firewall was ready for configuration and customization. I’ll follow up on this article with one on what I consider to be key post configuration tasks that you should perform before configuring ISA firewall policy.


[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/ISA-Server-2006-Installing-Enterprise-Edition-beta-Unihomed-Workgroup-Configuration-Post-Installation-Part2.html[/CODE][SIZE=3][B]PART-2[/B][/SIZE]

In part 1 of this series on post-installation tasks for single member ISA Server 2006 Enterprise Edition Arrays configured in workgroup mode, I provided a comprehensive list of post-installation tasks. In this, part 2 of the series, I’ll continue to move through that list.

[B]Configure Connectivity Monitors[/B]

Connectivity Monitors are a useful tool you can use to alert you when connectivity to key network infrastructure services becomes unavailable. For example, you can set connectivity monitors for your Internet gateway, published Web servers, DHCP servers, domain controllers and DNS servers. When the ISA firewall detects that connectivity to these services is broken, an e-mail alert can be sent to you notifying you of this condition.
Click on the [B]Connectivity Verifiers[/B] tab. Then perform the following steps to create a connectivity verifier:

[LIST=1][*] On the [B]Tasks[/B] tab in the Task Pane, click the [B]Create a New Connectivity Verifier[/B] link.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021144059651390.jpg[/IMG]
[B]Figure 1[/B][/INDENT]
[LIST=1][*]On the [B]Welcome to the New Connectivity Verifier Wizard[/B] page, enter a name for the connectivity verifier. In this example we’ll configure a connectivity verifier that pings the WAN interface of our Internet gateway router, so we’ll name it [B]Internet Gateway[/B]. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041144059651437.jpg[/IMG]
[B]Figure 2[/B][/INDENT]
[LIST=1][*]On the [B]Connectivity Verification Details[/B] page, enter the IP address or the URL for the device for which you want to test connectivity. In this example we want to test the connectivity status of the WAN interface of our Internet gateway router, so we’ll enter the IP address. If you’re testing Web site connectivity, you might wish to enter a URL. In the [B]Group type used to categorize this connectivity verifier[/B] drop down box, select the type of connectivity verifier group this belongs to. I selected [B]Other[/B] since none of the groups provided neatly fit into Internet gateway testing. In the [B]Verification method[/B] section, select the method used to test connectivity. You can choose [B]Send an HTTP “GET” request[/B], [B]Send a Ping request[/B], or [B]Establish a TCP connection to port[/B]. In this example we’ll select the [B]Send a Ping request [/B]option. If you want to test for Web services, use the HTTP GET option. If you’re publishing a TCP based service, use the [B]Establish a TCP connection to port[/B] option. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061144059651437.jpg[/IMG]
[B]Figure 3[/B][/INDENT]
[LIST=1][*] Click [B]Finish[/B] on the last page of the wizard.[/LIST]
[B]Configure Firewall and Web Proxy Logging[/B]

Right out of the box, the ISA firewall is ready to log all connections moving to and through the ISA firewall. However, there are still several options you might want to consider before accepting the out of the box logging configuration. To start configuring these options, click the [B]Logging [/B]tab in the middle pane of the console and then perform the following steps:

[LIST=1][*]Click the [B]Tasks[/B] tab in the Task Pane and then click the [B]Configure Firewall Logging [/B]link.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0081144059957234.jpg[/IMG]
[B]Figure 4[/B][/INDENT]
[LIST=1][*]In the [B]Firewall Logging Properties[/B] dialog box, click the [B]Log[/B] tab. Here you have the option to change the log storage format. If you used the default options when installing the ISA firewall software, MSDE logging will be your log storage format. You have the option to change to either [B]SQL Database [/B]or text [B]File[/B] format logging.

MDSE logging provides you the opportunity to get the most out of the ISA firewall’s built in log query feature, file based logging gives you the best performance, and SQL logging provides for off-box logging, but the worst performance.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101144059957234.jpg[/IMG]
[B]Figure 5[/B][/INDENT]
[LIST=1][*]Click the [B]Fields[/B] tab. Most of the fields are selected and enabled as part of the default logging configuration. However, there are still a number of fields that are not selected. You should examine the unselected fields to see if you might want to have those enabled so that you capture this information. If the field isn’t enabled, then the ISA firewall will not log and store the data in that field. Click [B]OK[/B] to save the changes.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121144059957250.jpg[/IMG]
[B]Figure 6[/B][/INDENT]
[LIST=1][*] Click the [B]Configure Web Proxy Logging[/B] link on the [B]Tasks[/B] tab. Here you’ll see the same log storage options you had for the Firewall service logging. One thing to make note here that I didn’t point out earlier is the [B]Enable logging for this service option[/B]. If you want to completely turn off logging for the Firewall service, or Web proxy filter, then you can remove the checkmark from this checkbox. I don’t recommend doing this, but I suppose if you’re trying to do something illicit and you don’t want anyone to find out what you’ve done, you can turn off logging. Of course, someone will later come back to you and ask for an explanation of the “gaps” in the log files. Honesty and accountability is the best policy, so don’t disable logging.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0141144060156031.jpg[/IMG]
[B]Figure 7[/B][/INDENT]
[LIST=1][*]If you choose to deploy MSDE logging, then click the [B]Options[/B] button to the right of that option. Here you can choose where to save the ISA firewall’s log files. The default location is the [B]ISALogs[/B] folder in the [B]Microsoft ISA Server 2006[/B] folder hierarchy. You can change the folder location, but in circumstances where you have a multiple server array (a situation we’re not confronted with in our current single server array example), then you must make sure the same folder location is available on all array machines.

You also have the option to set [B]Log file storage limits[/B]. The default total size of all log files is [B]8 GB[/B]. You can also set a limit on the minimum free disk space, which is [B]512 MB[/B] by default. You might want to set this a little higher if you have available disk space, as you might need more than that under certain disaster recovery operations. To maintain your storage limits, you can choose either [B]Deleting older log files as necessary[/B] or [B]Discarding new log entries[/B]. I highly recommend that you accept the former option, as its likely that you already have log summaries created to enable report creation.[/LIST]


[INDENT] [IMG]http://www.isaserver.org/img/upl/image0161144060156062.jpg[/IMG]
[B]Figure 8[/B][/INDENT]This is just a basic overview of the logging features and functions. Make sure to check the Help file, future articles, and of course our book (when it comes out later this year) for much more comprehensive coverage of these subjects. Keep in mind that logging is a key post-installation task, so the sooner you know about the options, the better.
[B]Create and Export Frequently Used Filter Definitions[/B]

One thing that hasn’t received enough attention on the ISAserver.org Web site is how to use ISA firewall filter definitions to query the MSDE logs. Filter Definitions make it easy to drill down on the log data you’re interested in and get answers you need fast. This is one of the major advantages you have with MSDE logging over file based logging and SQL logging. While you can use third party tools to query the text files, or SQL queries to query the SQL database, neither of these approaches are as intuitive or as user friendly as using the ISA firewall’s built-in log query functions.
To get to the ISA firewall’s log query interface, click on the [B]Logging[/B] tab and then click the [B]Edit Filter[/B] link on the [B]Tasks[/B] tab of the Task Pane.[INDENT] [IMG]http://www.isaserver.org/img/upl/image0181144060156078.jpg[/IMG]
[B]Figure 9[/B][/INDENT]This brings up the [B]Edit Filter[/B] dialog box. In the [B]Edit Filter[/B] dialog box you chose the following options:

[LIST][*]Filter by[*]Condition[*]Value[/LIST]
For example, suppose we want to “eyeball” a live logging session to see what’s happening on the wire, but we want to filter out “noisy” protocols and communications. NetBIOS protocols are aboutthe biggest noise makers on your network. How about removing all references to NetBIOS protocols while you’re watching the real time log viewer? You can do that by filtering by Protocol, setting the Condition as Not Contains, and set the Value as NetBIOS.
You also probably aren’t interested in any communications sent to the limited broadcast address (255.255.255.255). You can filter out those entries by filtering by Destination IP, setting the Condition as Equals, and enter 255.255.255.255 as the Value. The figure below shows the result of this configuration.[INDENT] [IMG]http://www.isaserver.org/img/upl/image0201144060361750.jpg[/IMG]
[B]Figure 10[/B][/INDENT]Now that you’ve taken the time to create a log Filter Definition, how about saving it so that you don’t have to configure the Filter Definition every time you want to filter the logs? That’s easy to do. All you need to do is click the [B]Export Filter Definition [/B]link in the [B]Tasks[/B] tab of the Task Pane, save the Filter Definition with a name that you’ll be able to easily recognize, and save it, as seen in the figure below.[INDENT] [IMG]http://www.isaserver.org/img/upl/image0221144060361750.jpg[/IMG]
[B]Figure 11[/B][/INDENT]I have a couple dozen Filter Definitions defined that I use on a regular basis. Whenever you create a Filter Definition to query the ISA firewall’s log files, think about whether you’ll ever want to use that Definition again. If so, save it. It’ll save you a lot of time in the future.
[B]Enter IP Addresses of Remote Management Computers[/B]

Remote Management computers are machines that have the ISA firewall console installed on them. Remote Management computers must have access to a number of protocols when connecting to the ISA firewall’s array member’s Local Host ISA firewall Network. Examples of these protocols include MS Firewall Control Protocol, NetBIOS datagram, NetBIOS Name Service, NetBIOS Session Service, and all RPC interfaces.
In addition, Remote Management computers must also be able to access MS CIFS, and MS Firewall Storage. For this reason, you must be extremely careful as to what computers are allowed to remotely manage the ISA firewall array. The remote management station must be exceptionally secure to prevent potential compromise by an otherwise trusted machine.
You can get a good view of what protocols and services Remote Management computers need to access on the ISA firewall’s Local Host ISA firewall Network by viewing the System Policy Rules in the [B]Firewall Policy [/B]node in the left pane of the ISA firewall console.
To enter the IP addresses of the Remote Management computers, click on the [B]Firewall Policy [/B]node in the left pane of the console, then click the [B]Toolbox[/B] tab. On the [B]Toolbox[/B] tab, click the [B]Computer Sets[/B] folder and then double click on the [B]Remote Management Computers[/B] entry. You’ll see the [B]Remote Management Computer Properties[/B] dialog box as it appears in the figure below. Note that the IP address of the ISA firewall itself is automatically included in the list.[INDENT] [IMG]http://www.isaserver.org/img/upl/image0241144060361765.jpg[/IMG]
[B]Figure 12[/B][/INDENT]Click the [B]Add[/B] button and select [B]Computer[/B]. In the [B]new Computer Rule Element[/B] dialog box, enter a name for the Remote Management station computer, and the IP address and a description. Click [B]OK[/B] and then click [B]OK[/B] again. Remember that configuration isn’t saved to the CSS until you hit the [B]Apply[/B] button.
[B]Configure Direct Access List[/B]

Direct Access, when it comes to Web proxy deployments, is a bit of a misnomer. The reason for this is that it's unlikely that you’ll ever “directly access” any computers on the Internet. Instead, the Web proxy Direct Access list is a list of IP addresses and Internet host names for which you want to bypass the Web proxy client configuration. When the Web proxy client configuration is bypassed, the client computer must use a method other than its Web proxy client configuration to reach the destination site.
In the example of the unihomed Web proxy only ISA firewall that were covering in this article series, that means clients must leverage the default gateway configuration to reach the destination site (since the Firewall client configuration is not supported in a unihomed Web proxy only ISA firewall configuration).
The Direct Access list should be populated with sites that are well known for being non-compliant with authenticating Web proxies. Unfortunately, most of the Microsoft Web properties are non-compliant and need to be configured for Direct Access. This includes, but is not exclusive to: hotmail.com, passport.com, passport.net, Windows updates sites, and msn.com. While this may be true of this writing, there’s always a chance that Microsoft will update their network infrastructure to support clients located behind authenticating Web proxies.
For more information on Direct Access for both Web proxy and Firewall clients, see my articles at:
[URL="http://www.isaserver.org/articles/2004directaccessp1.html"][B]http://www.isaserver.org/articles/2004directaccessp1.html[/B][/URL]
and
[URL="http://www.isaserver.org/articles/2004directaccessp2.html"][B]http://www.isaserver.org/articles/2004directaccessp2.html[/B][/URL]
To configure the Web proxy Direct Access list, click the [B]Networks[/B] node located under the [B]Configuration [/B]node in the left pane of the ISA firewall console. Click the [B]Networks[/B] tab in the middle pane of the console, and then double click the [B]Internal[/B] entry. In the [B]Internal Properties[/B] dialog box, click the [B]Web Browser[/B] tab. You’ll see something that looks like the figure below.
On the [B]Web Browser[/B] tab, you have the following options:

[LIST][*][B]Bypass proxy for Web servers in this network[/B] This is a very deception description for this setting, as it implies that the ISA firewall magically knows the servers “on this network”. That is not the case. What happens when this setting is enabled is that access to servers via single label name will be done via Direct Access. For example, [URL]https://OWASERVER[/URL] is a single label name. On this other hand, [URL]https://owa.msfirewall.org[/URL] is [I]not[/I] a single label name.[*][B]Directly access computers specified in the Domains tab[/B] The Domains tab is used by the Firewall client to configure Direct Access connections for Firewall clients. In the unihomed Web proxy only ISA firewall configuration, you would never use the Domains tab, so you can ignore this setting. It is useful in a full ISA firewall deployment.[*][B]Direct access these servers or domains[/B] This section allows you to add servers and IP addresses to the Direct Access list. Here is where you add the names of servers that do not support Web proxy or authenticating Web proxy connections. As I mentioned earlier, Microsoft Web properties are notorious for not supporting connections through authenticating Web proxy or Web proxies at all. Java sites are also well known for breaking when clients are located behind Web proxy servers. Use the [B]Add[/B] button to bring up the [B]Add Server[/B] dialog box to add these entries. Note that you can use wildcards if you need to configure an entire domain for Direct Access.[*][B]If ISA is unavailable, use this backup route to connect to the Internet[/B] This option enables the Web proxy client to bypass the unihomed Web proxy only ISA firewall when the ISA firewall is unavailable. In this case, the Web proxy client can reach the Internet via its default gateway configuration. However, if the clients are not configured with a default gateway configuration that will allow them Internet access, then you have the alternative to configure the Web proxy clients to use an alternate ISA firewall as a Web proxy.[/LIST]
Note that all of these options apply only to machines configured as Web proxy clients, and those Web proxy clients must be able to access the ISA firewall’s autconfiguration script. You can assign the autoconfiguration script via Group Policy, via wpad autodiscovery, by manually configuring the clients to use it, or by setting Web proxy client configuration settings during Firewall client installation (note that this option is not available in the unihomed Web proxy only ISA firewall configuration.
[IMG]http://www.isaserver.org/img/upl/image0261144060361765.jpg[/IMG]
[B]Figure 13[/B]


[B]Summary[/B]

In this article we continued our review of post-installation tasks for unihomed Web proxy only ISA firewalls configured in a single member ISA Server 2006 Enterprise Edition array. In part 3 of this article series we’ll complete our review of post installation tasks.


[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/ISA-Server-2006-Installing-Enterprise-Edition-beta-Unihomed-Workgroup-Configuration-Post-Installation-Part3.html[/CODE]

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

This is part 3 of a four part article on post-installation tasks for unihomed Web proxy only ISA firewall deployments.

[B]Configure Web Chaining Rules[/B]

Web Chaining Rules allow you to chain downstream ISA firewalls to upstream ISA firewalls, or even non-ISA firewall-based Web proxy servers. Web proxy chaining allows you to configure a [I]hierarchical caching[/I] solution. In contrast, a multi-server ISA firewall array allows you to create a [I]parallel caching[/I] solution. You can combine hierarchical and parallel caching solutions to significantly improve performance and reduce the total amount of bandwidth used on Internet links, WAN links, and even on the intranet.
The most popular use for Web Chaining is to chain branch office ISA firewalls with main office ISA firewalls. This has several advantages:

[LIST][*]Content requested from all branch offices and the main office is cached on the main office ISA firewall array. This reduces overall Internet link bandwidth utilization[*]Content requested from each branch office is cached on the local ISA firewall array. This reduces bandwidth utilization on the branch office WAN and/or Internet link[*]Content hosted on main office Web servers can be dynamically cached or pre-loaded into the caches of branch offices. This allows this content to be available to branch offices even when the WAN or Internet link is down[/LIST]
With the increasing popularity of branch office deployments of the ISA firewall, you can expect to see even greater use of Web Chaining Rules.
To create a Web Chaining Rule, click the [B]Networks[/B] node in the left pane of the ISA firewall console and then click the [B]Web Chaining Rules[/B] tab in the middle pane. Then perform the following steps to create the Web Chaining Rule:

[LIST=1][*]Click the [B]Tasks[/B] tab in the Task Pane and then click the [B]Create New Web Chaining Rule[/B] link.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021144419469453.jpg[/IMG]
[B]Figure 1[/B][/INDENT]
[LIST=1][*]On the [B]Welcome to the New Web Chaining Rule Wizard[/B] page, enter a name for the rule in the [B]Web chaining rule name[/B] text box. In this example we’ll chain the ISA firewall at a branch office to a ISA firewall Web caching array at the main office, so we’ll name the rule [B]Branch to Main Array[/B] and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041144419469453.jpg[/IMG]
[B]Figure 2[/B][/INDENT]
[LIST=1][*]On the [B]Web Chaining Rule Destination[/B] page, click the [B]Add[/B] button. In the [B]Add Network Entities[/B] dialog box, select the destinations to which this Web Chaining Rule will apply. Since we want all requests for Web content regardless of where that Web content is located to be forwarded to the main office array, we’ll select the [B]All Networks (and Local Host)[/B] entry in the [B]Add Network Entities[/B] dialog box. Click [B]Close[/B] in the [B]Add Network Entities[/B] dialog box and then click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061144419469500.jpg[/IMG]
[B]Figure 3[/B][/INDENT]
[LIST=1][*]On the [B]Request Action [/B]page, you configure how you want the Web requests to that particular destination routed by the ISA firewall. The default setting is to route the request directly to the destination Web site. However, in a Web Chaining configuration, you want the request forwarded to another Web proxy device. In this case, you would select the [B]Redirect requests to the specified upstream server[/B] option. When you select this option, the next page of the wizard will ask you for details regarding the upstream Web proxy. Select this option and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0081144419810250.jpg[/IMG]
[B]Figure 4[/B][/INDENT]
[LIST=1][*]On the [B]Primary Routing[/B] page, enter the name of the upstream ISA firewall array. You can leave the default ports in place if you haven’t changed them on the upstream array. In this example, the name resolves to one of the members of the main office array. Once the branch office ISA firewall receives the autoconfiguration script from the main office array, it will have a list of names of all the servers in the array and forward requests to the appropriate main office array member based on the CARP algorithm (CARP allows the branch office ISA firewall to perform client side routing of Web requests to the Web caching array member responsible for the URL).

If the upstream array member requires credentials for Web access, click the [B]Set Account[/B] button to enter the credentials the downstream array member should use to authenticate with the upstream. Click [B]OK[/B] to save the account information and then select the authentication protocol from the [B]Authentication[/B] drop down list. Since we always join ISA firewalls to the domain (an ISA firewall best practice), we can use integrated authentication. This prevents us from having to use SSL to secure the communications between the branch office ISA firewall and the main office array. Click [B]Next[/B] on the [B]Primary Routing [/B]page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101144419810281.jpg[/IMG]
[B]Figure 5[/B][/INDENT]
[LIST=1][*]On the [B]Backup Action[/B] page you select how Web requests are routed when the upstream ISA firewall Web proxy isn’t available. In this example, we’ll assume that the branch office has its down Internet connection. Since the branch office has its own Internet connection, we can select the [B]Retrieve requests directly from the specified destination[/B] option and connections will be forwarded directly to the Internet servers from the branch office ISA firewall, instead of routing them to the main office ISA firewall Web caching array. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121144419810281.jpg[/IMG]
[B]Figure 6[/B][/INDENT]
[LIST=1][*]Click [B]Finish[/B] on the [B]Completing the New Web Chaining Rule Wizard[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0141144420130843.jpg[/IMG]
[B]Figure 7[/B][/INDENT]I should note here that Web Chaining Rules give you a lot of flexibility in how requests from Web proxy clients are processed by the ISA firewall. The example above represents just one possible scenario out of many. In our upcoming book on the ISA Server 2006 firewall we’ll spend a lot of time going over the myriad of Web proxy chaining scenarios so that you are fully aware of your options. Of course, the book will also cover the many options available in configuring Web Chaining Rules that I didn’t have a chance to discuss in the above example.


[B]Enable and Configure the Web Cache[/B]

Even in a unihomed Web proxy only ISA firewall configuration, the Web caching feature is not enabled by default. This reminds me of a very important distinction you should make: the difference between [I]Web proxy[/I] and [I]Web caching[/I]. Unfortunately, many people in our industry confuse the two terms and treat them synonymously. This is a grave error in the use of language and leads to many misunderstandings that could otherwise be avoided.
A [I]Web proxy[/I] server is a machine that is able to proxy Web requests from Web proxy clients. The proxy component can authenticate users, perform URL rewrites, perform normalization on Web requests, bridge protocols, and much more. In contrast, a [I]Web caching[/I] server does one thing: it caches Web content. In most cases, Web proxy servers also perform Web caching duties, although this is not required. By default, the ISA firewall is configured as a Web proxy server via its Web proxy filter hook into the ISA firewall’s Firewall Services. However, the ISA firewall is [I]not[/I] a Web caching server by default. If you want Web caching, you’ll have to enable a cache drive.
Perform the following steps to enable the ISA firewall’s Web caching feature:

[LIST=1][*]In the ISA firewall console, click the [B]Cache[/B] node that lies under the [B]Configuration[/B] node in the left pane of the console. Click the [B]Cache Drives[/B] tab in the middle pane, and then click the [B]Properties [/B]command.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0161144420130843.jpg[/IMG]
[B]Figure 8[/B][/INDENT]
[LIST=1][*]In the server’s [B]Properties[/B] dialog box, select the drive where you want to place the cache. Ideally, the cache drive will be on a separate spindle from the OS and logging drives. Thus, in an optimized configuration, the ISA firewall will have at least three drives: an OS drive with the ISA firewall software installed on it, a logging drive, where text or MSDE logging is performed, and a cache drive, where cached content is stored. Additional drives are required if you want to implement RAID for fault tolerance, but RAID is not required for the cache drive since the content is expendable. Make sure to check out our ISA Server 2006 book later this year for optimal disk and RAID configurations.

After selecting the drive, enter the amount of disk space you want to dedicate to the on disk cache. Estimates vary for how much disk space you should dedicate to the cache, and for the most part, these estimates are SWAGs at best. In my experience, 5-10MB per user is reasonable, but a better estimate of optimal cache size should be based on your own deployment.

For example, if you’re using the ISA firewall to only publish Web sites, you should have a disk cache large enough to cache all the content available on your published sites. For forward proxy scenarios, it's best to limit the size of the cache based on the speed of your disks. You should also use information gained from the ISA firewall’s Web Cache performance counters. Click [B]Set [/B]after adding the value and then click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0181144420130859.jpg[/IMG]
[B]Figure 9[/B][/INDENT]For a detailed account of how to optimize ISA firewall and Web caching behavior, check out Microsoft’s performance Best Practices document at [URL="http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/bestpractices.mspx"][B]http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/bestpractices.mspx[/B][/URL]
[B]Disable Unused Application and Web Filters[/B]

Application and Web Filters extend the ISA firewall’s core firewall feature set. They can do many things, such as securely manage complex protocols, perform stateful application layer inspection on application protocols, secure services from buffer overruns, add enhanced authentication support, and much more. However, Application and Web Filters can take up memory and processor resources that can be better used elsewhere.
For this reason, you should disable any filters you’re not using. In a unihomed ISA firewall configuration, there a many filters that you have no use for, since the unihomed Web proxy only ISA firewall supports only HTTP, HTTPS (SSL) and Web proxy tunneled FTP. You can turn off all Web filters that support and secure other protocols, since the ISA firewall won’t be servicing requests for those protocols.
To disable filters, click the [B]Add ins[/B] node situated under the [B]Configuration [/B]node in the left pane of the ISA firewall console. Click on the [B]Application Filters[/B] tab and you’ll see something like what appears in the figure below. Right click the filter that you don’t need and then click [B]Disable[/B]. The figure below has disabled all filters that are of no value in a unihomed Web proxy only configuration. You should disable the same filters on your unihomed Web proxy only ISA firewall.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0201144420130859.jpg[/IMG]
[B]Figure 10[/B][/INDENT]Click the [B]Web Filters[/B] tab in the middle pane of the ISA firewall console. Web Filters are essentially ISAPI plug-ins to the ISA firewall’s Web proxy filter. They’re “filters bound to a filter”. Notice that the default configuration is to enable all filters except for the DiffServ filter. You should review each of these filters to see if they’ll be in use in your organization. If you identify one or more filters that you definitely won’t be using (for example, the RADIUS authentication filter), then disable them.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0221144420477656.jpg[/IMG]
[B]Figure 11[/B][/INDENT][B]Configure Compression Preferences[/B]

The ISA firewall can be configured to support requests for compressed content. The feature was first introduced with ISA 2004 SP2. You need to be careful with compression, because the ISA firewall doesn’t support all methods of compression and this feature has a tendency to generate a large number of errors related to alternate compression methods. However, one scenario where you’ll find compression especially useful is in a branch office scenario, where the branch office ISA firewalls are in a Web proxy chaining configuration with upstream ISA firewalls in a Web caching array.
To access the HTTP compression preferences, click the [B]General[/B] node under the [B]Configuration[/B] node in the left pane of the ISA firewall console. In the middle pane of the console, click the [B]Define HTTP Compression Preferences [/B]link. This will bring up the [B]General[/B] tab as seen in the figure below.
The [B]Enable HTTP compression[/B] option is enabled by default. If you want to disable support for HTTP compression, then remove the checkmark from that checkbox.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0241144420477656.jpg[/IMG]
[B]Figure 12[/B][/INDENT]Click the [B]Return Compressed Data[/B] tab in the [B]HTTP Compression[/B] dialog box. Here you configure the ISA firewall to compress HTTP responses when requested by client from network elements you determine here. For example, if you want the clients to be able to request compressed content from Internet hosts, then you could configure the Internal ISA firewall Network here. Note you also have the options to create exceptions and set what [B]Content Types[/B] will be compressed.
It's important to note once again, that when Microsoft developed support for compressed content, what they had in mind was a branch office scenario where the branch office ISA firewall requests compressed content from a main office ISA firewall array.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0261144420477671.jpg[/IMG]
[B]Figure 13[/B][/INDENT]Click the [B]Request Compressed Data[/B] tab in the [B]HTTP Compression [/B]dialog box. Here you configure what network elements request compressed HTTP content when requests are sent to these network elements. For example, if you want the ISA firewall to request compressed content from Internet Web servers, then you would add the default External ISA firewall Network to this list. Once again, things are a little more complex than this and this functionality was designed for branch office/main office Web proxy chaining configuration.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0281144420477671.jpg[/IMG]
[B]Figure 14[/B][/INDENT]I realize that I’ve been a little obtuse regarding how to configure compression support for the ISA firewall. The issue is potentially complex and there are a number of possible scenarios, each requiring a custom configuration. For more information on HTTP compression support for ISA firewalls, check out the ISA 2004 SP2 White Paper at [URL="http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/sp2.mspx"][B]http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/sp2.mspx[/B][/URL]


[B]Summary[/B]

In this article we continued our trek through post-installation tasks for unihomed Web proxy only ISA firewalls configured in a single server array configuration. We’re almost done! In the next article, part 4 of the series, we’ll complete our post installation tasks and then move on to more interesting topics, such as publishing front-end Exchange Server Web farms!



[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/ISA-Server-2006-Installing-Enterprise-Edition-beta-Unihomed-Workgroup-Configuration-Post-Installation-Part4.html[/CODE]

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

This is the final part of a four part article on post-installation tasks for unihomed Web proxy only ISA firewall deployments.

[B]Specify Certificate Revocation Settings[/B]

The ISA firewall can be configured to verify that incoming certificates are not included in a CRL. You have the following options:

[LIST][*][B]Verify that incoming client certificates are not revoked - [/B]I’ve often found the term “client certificate” to be an unfortunate one, because it lacks intuitive precision. What do I mean by that? What I mean is that you should use terms that provide clear and distinct meanings, and help create contrast for similar terms. Do you know what a client certificate is? If there was actually an entity called a “client certificate”, then you should be able to request one from a Certificate Server. Unfortunately, you can’t request a client certificate from a Certificate Server because there is no such thing as a client certificate. The term “client certificate” is a misnomer for a [I]User Certificate[/I]. When you enable this option, the ISA firewall will check the CRL to determine if the User Certificate presented to the ISA firewall is revoked. Note that this option only applies when you have enabled User Certificate authentication on the ISA firewall’s Web listener for Web Publishing Rules.[*][B]Verify that incoming server certificates are not revoked in a forward scenario - [/B]This option applies when the ISA firewall, acting as a Web proxy, initiates a secure connection to an upstream ISA firewall or Web server. In the upstream Web proxy scenario, the ISA firewall can provide HTTP to SSL bridging, where the client behind the downstream ISA firewall sends the request via HTTP and the downstream ISA firewall forwards the request to the upstream ISA firewall using HTTPS (SSL secured HTTP). Note that SSL is used only for the Web proxy connection. The original HTTP request is then forwarded by the upstream ISA firewall as an HTTP connection request to the destination server.[*][B]Verify that incoming server certificates are not revoked in a reverse scenario - [/B]This setting applies when the ISA firewall publishes a Web site. When the ISA firewall creates the second SSL session (between itself and the published Web site on the corporate network), it will check the CRL for the certificate presented by the published Web site.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021145279620078.jpg[/IMG]
[B]Figure 1[/B][/INDENT]The default settings are fine. However, if you want to make sure that connections are not made to a published Web server that sports a revoked certificate, then you should enable the last option in the dialog box above.
[B]Specify Diffserv Preferences[/B]

Diffserv is a method used to provide Quality of Service (QoS) to packets moving over a network. Diffserv is short for Differentiated Services. Diffserv uses bit settings in the TOS IP header to mark packets for different levels of service. That is to say, Diffserv marks packets at different levels of priority. Those with higher priority are handled by Diffserv enabled network devices (routers and switches) first and lower priority packets are held in queue for a period of time determined by the algorithm used by the network device manufacturer.
You can access the Diffserv options on the [B]General[/B] node under the [B]Configuration[/B] node in the left pane of the ISA firewall console. Click the [B]Specify Diffserv Preferences[/B] link in the middle pane and you’ll see what appears in the figure below.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041145279620078.jpg[/IMG]
[B]Figure 2[/B][/INDENT]I’m not going to spend much time with Diffserv, as it’s a complex topic that requires you understand both how the ISA firewall handles Diffsrv bits and how your current network infrastructure is configured to support Diffserv. If you have never heard of Diffserv, then you can comfortably ignore the ISA firewall’s support for it. If you have heard of Diffserv, and you know that your corporate networking infrastructure supports Diffserv based levels of service, then you can benefit from it. Keep in mind that Diffserv bits are added only to HTTP communications and no other protocols. That’s fine for our unihomed Web proxy only ISA firewall, but hopefully in the future we’ll see QoS support of some kind for all protocols (including VoIP).
For more information about Diffserv and how it works, check out [URL="http://www.rhyshaden.com/qos.htm"][B]http://www.rhyshaden.com/qos.htm[/B][/URL]
[B]Define LDAP and RADIUS Servers[/B]

The ISA firewall supports a variety of authentication mechanisms. These include:

[LIST][*][B]Integrated authentication -[/B] Integrated authentication is available when the ISA firewall is a domain member. When the ISA firewall is a domain member, you can take full advantage of all authentication protocols supported by Active Directory. The ISA firewall communicates directly with the domain controllers to authenticate users. This option provides by the highest level of authentication support for all protocols and access scenarios[*][B]RADIUS authentication -[/B] RADIUS authentication requires that you have one or more RADIUS servers deployed on your network. The ISA firewall forwards the user credentials in clear text to the RADIUS server and then the RADIUS server forwards them to the Active Directory authentication server. RADIUS authentication support is used only for Web proxy filter mediated requests, which include forward and reverse (Web Publishing) proxy scenarios. There are significant performance and administrative overhead costs you pay when using RADIUS authentication[*][B]LDAP authentication -[/B] This is a new feature included in ISA Server 2006. Now you can configure an ISA firewall that is not a domain member to use LDAP calls to the domain controller. This allows you to take advantage of Active Directory users and groups, unlike RADIUS authentication, where you cannot use Active Directory groups.[/LIST]
The figures below show how to configure both RADIUS and LDAP servers. You should configure your RADIUS and LDAP servers before creating Access Rules, because at this time (Beta 1), you can’t create these servers “on the fly” when configuring an Access Rule or Publishing Rule.
To access the RADIUS and LDAP server configuration interface, click the [B]General[/B] node located under the [B]Configuration[/B] node in the left pane of the ISA firewall console. In the middle pane of the console, click the [B]Define LDAP and RADIUS Servers[/B] link.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061145279620093.jpg[/IMG]
[B]Figure 3[/B][/INDENT][INDENT] [IMG]http://www.isaserver.org/img/upl/image0081145279620093.jpg[/IMG]
[B]Figure 4[/B]


[B]Configure Intrusion Detection and DNS Attack Detection[/B]

The ISA firewall includes a built-in IDS/IPS system for basic network level and DNS attacks. To reach the configuration interface for the ISA firewall’s IDS feature set, click the [B]General[/B] node located under the [B]Configuration[/B] node in the left pane of the ISA firewall console. Click the [B]Enable Intrusion Detection and DNS Attack Detection[/B] link in the middle pane of the console.
The [B]Enable intrusion detection[/B] option is enabled by default. Detection for all of the attacks except for port scans is enabled by default. I highly recommend that you do [B]not[/B] enable the port scan attack detection unless you have a network intrusion analyst on your staff who understands the nature of port scans and how to perform follow up investigations on these events. If you do not have an intrusion analyst available, the only thing you gain by enabling port scan detection is undue anxiety in your customer base without achieving any higher level of security.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101145279739140.jpg[/IMG]
[B]Figure 5[/B][/INDENT]The ISA firewall can also detect common DNS related attacks. The DNS attack detection is enabled by default, the [B]DNS host name overflow[/B] and [B]DNS length overflow[/B] attacks are automatically selected. The [B]DNS zone transfer[/B] attack is not selected by default. If you don’t want to allow zone transfers from your published DNS servers, then enable this option. Remember to configure an Alert Definition for DNS attacks if you want to be notified when these take place.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121145279739140.jpg[/IMG]
[B]Figure 6[/B][/INDENT][B]Define IP Preferences[/B]

The ISA firewall’s IP Preferences configuration interface includes a loose collection of options aimed at customizing support for IP level communications. To reach the IP Preferences configuration dialog box, click the [B]General[/B] node located under the [B]Configuration[/B] node in the left pane of the ISA firewall console.
In the [B]IP Preferences[/B] dialog box, click the [B]IP Options[/B] tab. The [B]Enable IP options filtering[/B] option is enabled by default, and the [B]Deny packets with the selected IP options[/B] is automatically selected with a number of IP options to block pre-selected by the ISA firewall. Do not change these default IP Options settings unless you have a specific reason to do so.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0141145279739140.jpg[/IMG]
[B]Figure 7[/B][/INDENT]Click the [B]IP Fragments[/B] tab. The [B]Block IP fragments[/B] option is disabled by default. The reason for this is blocking IP fragments from traversing the ISA firewall can interfere with L2TP/IPSec communications and also can adversely affect performance and reliability for streaming media.
In a unihomed Web proxy only ISA firewall configuration, L2TP/IPSec VPN connections is not an issue, since the unihomed Web proxy only ISA firewalls do not support VPN connections. Streaming media over HTTP may be less affected by fragmentation than streaming media over their native protocols, so you should enable this option for the unihomed Web proxy only ISA firewall and follow up on issues with streaming media, if any.
When you enable blocking of IP fragments, you’ll see a dialog box warning you that [B]Enabling[/B][B] this option may result in the blocking of protocols that use large packets. For example, VPN connections that are based on L2TP or IPSec, and request for RADIUS authentication requiring certificates, may also be blocked[/B]. This brings up a good point that I should have mentioned earlier. IP Fragment blocking might interfere with EAP based communications with a RADIUS server. However, since this is primarily an issue with VPN certificate based EAP authentication, you shouldn’t have any problems in a unihomed Web proxy only configuration.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0161145280098390.jpg[/IMG]
[B]Figure 8[/B][/INDENT]The [B]IP Routing[/B] tab is perhaps one of the most confused options in the entire ISA firewall configuration. This has nothing to do with what you might consider IP Routing. Instead, this has to do with communications for complex protocols are handled by the ISA firewall.
For example, when you establish an active mode FTP connection, the data connection from the FTP server to the ISA firewall represents a secondary connection established by the FTP server to the ISA firewall. This session can be run in user or kernel mode. When IP Routing is enabled, performance for the secondary connection is much better.
The downside of enabling IP Routing on the ISA firewall is you won’t be able to enforce IPSec between Web proxy clients and the ISA firewall.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0181145280098406.jpg[/IMG]
[B]Figure 9[/B][/INDENT][B]Configure Flood Mitigation Settings[/B]

While the bulk of improvements included in ISA Server 2006 are squarely focused on the ISA firewall’s Web proxy filter, there is one firewall oriented improvement you should definitely know about. This is the enhanced Flood Mitigation feature that allows you to configure and fine tune how the ISA firewall handles situations where it’s under worm and related network flood attacks.
The 2006 ISA firewall allows you to configure protection based on the following settings:

[LIST][*][B]TCP connect requests per minute, per IP address -[/B] Mitigates worm propagations that occur when an infected host scans the network for vulnerable hosts. Also mitigates flood attacks that occur when an attacker sends numerous TCP connect messages[*][B]TCP concurrent connections per IP address -[/B] Mitigates TCP flood attacks that occur when an offending host maintains numerous TCP connections with ISA Server or with victim servers behind ISA Server[*][B]TCP half-open connections -[/B] Mitigates SYN attacks where an offending host sends numerous TCP SYN messages without completing the TCP handshake. Note that the default limit for this mitigation is automatically calculated as half the limit set for concurrent TCP connections per IP address[*][B]HTTP requests per minute, per IP address -[/B] Mitigates HTTP DoS attacks where an offending host sends numerous HTTP requests to victim Web sites[*][B]Non-TCP new sessions per minute, per rule -[/B] Mitigates non-TCP DDoS (distributed denial of service) attacks that occur when numerous zombie hosts participate in an attack against a victim server or throttle the network by sending numerous non-TCP packets[*][B]UDP concurrent sessions per IP address -[/B] Mitigates UDP flood attacks that occur when an offending host sends numerous UDP messages to victim hosts behind ISA Server[*][B]Set event trigger for denied packets -[/B] Triggers an event notifying the ISA Server administrator about an offending IP address that has flooded ISA Server with numerous TCP and non-TCP packets denied by ISA Server policy. Also reduces logging and system resource consumption when ISA Server settings specify that traffic should not be logged.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0201145280098406.jpg[/IMG]
[B]Figure 10[/B][/INDENT]The default settings are good to start with, but you’ll likely want to create exceptions for some servers, such as busy published Web servers and mail servers. You should keep a close watch on the ISA firewall alerts regarding these flood mitigation settings and then create exceptions based on the results of your inquires.
The figure below shows the [B]IP Exceptions[/B] tab and the [B]Computer Sets[/B] dialog box you’ll see after clicking the [B]Add[/B] button. Here you can select an existing Computer Set, or create a new set for which there should be exceptions to the Flood Mitigation settings.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0221145280098406.jpg[/IMG]
[B]Figure 11[/B]


[B]Summary[/B]

In this article we concluded our post-installation tasks for unihomed Web proxy only mode ISA firewalls configured in a single server array. Now that we’ve finished that up, we’ll get to more interesting tasks, such as publishing SharePoint Portal Servers and Exchange Web services, using the new ISA Server 2006 feature set! See you then.[/INDENT][/INDENT]


[/LEFT]