Configuring Domain Members in a Back to Back ISA Firewall DMZ

In this, part 1 of a four part article series on configuring a back to back ISA firewall solution with a domain member in the DMZ segment, we will discuss concepts in DMZ and perimeter network design

A hot topic these days is DMZs. I’ve read lots of articles lately about the death of the DMZ, that DMZs are no longer required, that DMZs don’t provide any additional protection, that DMZs are unrealistic because the only real protection is host-based protection, and that DMZs aren’t required because firewalls themselves are ineffective and therefore aren’t required, and that there’s no difference (in a security context) between any Internet connected network (or any other network, for that matter).
I have to admit that all of these articles, talks and dissertations are interesting and sometimes even contain an idea that’s worthy of consideration. Almost all of them have entertainment value as the authors extend their wings for flights of fancy. But taken as a whole, the entire concept that DMZs (which are just security perimeters) are dead or don’t provide added vital protection and access control is 98.6% bunk. DMZs Morph into Security Perimeters

The problem these security wonks have is that all DMZs are not created equal. Not all hosts belong to the same security zone. Hosts belonging to different security zones need to be separated by network access control devices to mitigate (notice I didn’t prevent) compromises in one security zone from quickly extending to other security zones. Ignoring this reality take more than a grain of salt – it takes a willing suspension of disbelief.
For example, there’s a reason why you can’t take your friends and family into the Pentagon War Room – you and your family belong to a different security zone than the War Room attendees, and there are multiple security devices that make sure there are access controls.
One thing many of these anti-firewall guys have right is that host-based security is the holy grail of computer security. The more secure and selective the host is about sending and receiving traffic, the easier it is for access control devices in front of the host to protect that host, and the more secure that host is against hosts in different and same security zones.
However, I am confident that host-based security Nirvana will not be seen in the next two to three decades (if ever), so perimeter devices interposed between security zone will continue to be required and popular. My confidence is borne from my experience in Medicine and knowledge of law enforcement. In medicine, viruses and bacteria mutate to defeat our efforts to come up with consistently effective antimicrobials, and law enforcement has been working on eliminating crime since the murder took place. Hackers and other network criminals are no different than harmful microbes or bag-men, they will continue to exist, and the better ones will evolve their methods and techniques to subvert even the most effective host-based security systems.
That’s why we’ll always need firewalls as perimeter security devices to provide defense in depth. Firewall will continue to evolve, and the future will certainly see the features of current day firewalls meld the features of stateful packet inspection, stateful application layer inspection, IPS and IDS integrated in a single device. The major hurdle is processing power, and we know from long experience that this problem will be solved in time. Marketing guys will certainly morph the term “firewall” into something else (since firewalls will be seen an superannuated devices by then), but they will be firewalls, regardless of the name marketeers and security wankers may give them.
Keep in mind that the perimeter is not the place where the corporate network meets the Internet. There is no perimeter, there are multiple perimeters. This is often hard to communicate to 1990s firewall admin who consider packet filtering-only devices as comprehensive security solutions and who think in terms of “opening a port” or “closing a port”. All but the most simple networks have multiple perimeters and an access control device (such as an ISA firewall) must be placed inline to separate these perimeters. This is one of the major reasons why I have such distain for unihomed ISA firewalls – unihomed ISA firewall’s provide an illusion of security, but since they are not inline devices, it’s a very simple task to bypass the unihomed ISA firewall.Define Your Security Zones

A key concept in DMZ construction is to place machines in different security zones on different segments, where the segments are separated by a network security device, such as ISA firewall. Now, the trick is in defining your security zones. There are a number of methods you can use to define security zones. Some examples include:

A zone could include all services providing a similar function

A zone could include all machines belonging to the same Active Directory domain

A zone could include all services that are interdependent on one another

A zone could include all machines run by untrusted users

A zone could include all devices managed by trusted partners

A zone could include all Internet facing devices

It’s beyond the scope of this article to go into an in-depth discussion of security zone classification and segmentation, but I wanted to bring up the subject so that we could focus on one important method of defining security zone: placing Internet facing devices in a security zone separate and distinct from all devices that aren’t Internet facing.
The term Internet facing means that inbound connections can be made to these machines. Any device accepting connections from Internet hosts is considered Internet facing. Placing all Internet facing devices on network segments segregated from non-Internet facing devices is well known and universally accepted method of reducing your attack surface and mitigating some of the risks inherent in placing Internet facing devices on security zones that are not designed to accept incoming connections from Internet hosts.
There are several types of DMZ segments where you can place these Internet facing devices:

Anonymous access DMZs – These DMZs allow anonymous users to connect to Internet facing devices in the DMZ and the servers in the DMZ allow anonymous connections to them. Inbound SMTP relays and public DNS servers are often found on anonymous access DMZs.

Authenticated access DMZs – An authenticated access DMZ is significantly more secure than an anonymous access DMZ, because users are authenticated at the firewall and then authorized by the firewall before the connection is forwarded to the DMZ server. No anonymous connections are allowed to authenticated access DMZ, which eliminates the overwhelming majority of attacks that the DMZ server would otherwise be exposed to

Mixed anonymous/authenticated access DMZs – These DMZs allow anonymous connections through the firewall, but servers on the DMZ require authentication. These servers could authenticate using a local user database, an Active Directory domain located only in the DMZ, or an Active Directory domain located on the corporate network, behind a back-end firewall

The figure below depicts multiple DMZ security zones. The red zone represents the anonymous access DMZ, where the back-end ISA firewall allows anonymous connections to services located on that segment. The Authenticated access DMZ (or perimeter network) represents a security zone where only authenticated users are allowed access to the zone itself; this requires that at least ISA firewall pre-authenticate the user prior to allowing access to resources in the zone itself. The servers within the zone may require authentication as well, but the key here is that connections must be pre-authenticated and pre-authorized prior to even getting to the point of being authenticated by the server. The honeypot DMZ represents a more traditional DMZ segment, where anonymous access to virtually any protocol from internal hosts, and most common protocols from external hosts, is allowed. You might put IDS/IPS and honeypot systems on that DMZ.

Figure 1

Front-end Exchange Servers Should be Placed in a DMZ Segment

Notice that the front-end Exchange Server is placed in the authenticated access DMZ. This provides an extra layer of protection by removing the front-end Exchange Servers from the back-end Exchange Servers security zone. This is an excellent configuration because the back-end Exchange Servers are never Internet facing, while the front-end Exchange Servers often are.
A common thread that runs through each of these DMZ implementations is that Internet facing devices are segregated from devices that do not accept incoming connections from Internet hosts. It should be obvious that the attacker [sic] surface presented by the Internet is much larger than any potential attacker surface presented by hosts on only non-Internet facing networks. If for no other reason (and there are plenty of more reasons), you should always exercise due diligence and move Internet facing devices off of networks that are not strictly designed for Internet facing hosts.
One of the best examples of how to handle this problem is seen with the front-end/back-end Exchange Server solution. Because the front-end Exchange Server is typically an Internet facing host, the Internet facing front-end Exchange Server should always be in a DMZ segment, and should never be on the same network security zone or perimeter where the back-end Exchange Servers are located.
Placing the Internet facing front-end Exchange Server in a separate DMZ segment is a critical distinction and something you need to consider in your front-end/back-end Exchange Server deployments, especially in the light of some of the things I’ve read in the tech media recently which seem to imply that you can place your front-end and back-end Exchange Servers on the same security zone and have the same level of security you would have had you placed the front-end in an authenticated access DMZ. Think about it and decide which solution offers a superior security solution and I think you’ll agree with me about placing front-end Exchange Servers in a separate security zone.Scenario Description

In this article we will focus on a back to back ISA firewall configuration where the back-end ISA firewall is a member of the corporate network domain and the front-end ISA firewall is not a domain member and belongs to its own workgroup. A Web server will be placed in the DMZ segment between the front-end and back-end ISA firewalls and that Web server will be a member of the corporate network domain. The domain controllers for the corporate network domain are located behind the back-end ISA firewall and intra-domain communications will be enabled between the Web server on the corporate network and a specific domain controller on the corporate network.
The figure below provides a high-level view of the example network used in this article.

Figure 2

If you’re familiar with our book Configuring ISA Server 2004 then you’ll recognize that we’re using the typical IP addressing and naming scheme that we’ve used throughout the book and also through the last two years at ISAServer.org.
There are several components of this solution that highlight interesting and important issues in configuring and managing ISA firewalls in a variety of scenarios:

There is a route relationship between the default Internal Network behind the back-end ISA firewall and the DMZ segment

Access Rules, not publishing rules, are used to control traffic sourcing from the DMZ Network and destined for the default Internet Network located behind the back-end ISA firewall

Routing table entries are used to correctly route communications from the DMZ Network and the default Internal Network located behind the back-end ISA firewall

I will call out each of these issues within the body of this article series and provide the rationale for each of these decisions in the appropriate sections.
This article series will include four parts:

Part 1 – Concepts in design and deployment of DMZs and network security perimeters

Create Access Rules controlling outbound access from the back-end ISA firewall’s default Internal Network to the DMZ and the Internet

Configure a routing table entry on the DMZ server

Join the DMZ server to the domain located on the default Internal Network behind the back-end ISA firewall

Configure the front-end ISA firewall’s default Internal Network

Configure a routing table entry on the front-end ISA firewall

Create an All Open Access Rule on the front-end ISA firewall

Create a Web Publishing Rule on the front-end ISA firewall

Configure RADIUS authentication on the front-end ISA firewall

Test the solution

Summary

In this, part 1 of a four part article series on configuring a back to back ISA firewall solution with a domain member in the DMZ segment, we discussed concepts in DMZ and perimeter network design. One of the key concepts discussed was that there is no such thing as a perimeter network because there are now multiple perimeters in most organizations that are defined by security zone boundaries. We also identified three common DMZ segment designs: the anonymous access DMZ, the authenticated access DMZ and the mixed authenticated/anonymous access DMZ. We then finished up with a discussion on why front-end Exchange Servers should be placed on perimeter/DMZ networks that are separate and distinct from security zones inhabited by back-end Exchange Servers.

In this, part 2 of the three part series, we’ll go over the configuration of the back-end ISA firewall

In part 1 of this series on configuring a domain member server in a back to back ISA firewall network, we discussed important issues in designing security zones and network perimeters, and reinforced the importance of having a robust firewall infrastructure in place to segregate computers and other network devices belonging to different security zones.
In this, part 2 of the three part series, we’ll go over the configuration of the back-end ISA firewall and cover the following procedures:

Create Access Rules Controlling Outbound Access from the Back-end ISA Firewall’s Default Internal Network to the DMZ and the Internet

Configure the Back-end ISA firewall with a DMZ ISA Firewall Network

One of the most prevalent misconceptions regarding ISA firewall Networks and how the ISA firewall sees the network world is how the ISA firewall deals with the default External Network. Let’s set the record straight: the default External Network on the ISA firewall is defined by any IP address that isn’t part of any other ISA firewall Network configured on the ISA firewall.
What this means is you can configure any set of IP addresses that aren’t part of another ISA firewall Network to be part of a custom ISA firewall Network. This includes the IP address bound to the external interface of the ISA firewall (although the IP address on the external interface of the ISA firewall will always belong to the Local Host Network).
This allows you to create a custom ISA firewall Network that includes the IP addresses in the DMZ Network between the front-end and back-end ISA firewalls. These addresses do not need to be part of the default External Network, even though the DMZ is on the same network ID as the external interface of the ISA firewall. The term “external interface” only means that it’s the interface with the default gateway configured on it, which typically is the closest to the Internet.
The value of making the DMZ between the front-end and back-end ISA firewalls on its own ISA firewall Network is that you can control the routing relationship between that Network and any other Network defined on the ISA firewall. In the example network used in this article, configuring a custom DMZ ISA firewall Network will enable us to create a route relationship between the default Internal Network behind the back-end ISA firewall and the DMZ Network between the front-end and back-end ISA firewalls. We can also create Access Rules controlling traffic moving to and from any ISA firewall Network.
Perform the following steps on the back-end ISA firewall to create the DMZ ISA firewall Network:

In the ISA firewall console, expand the server name and then expand the Configuration node. Click the Networks node.

On the Networks node, click the Networks tab in the details pane. Click the Tasks tab in the Task Pane and then click the Create a New Network link.

On the Welcome to the New Network Wizard page, enter a name for the Network in the Network name text box. In this example we’ll name the Network DMZ. Click Next.

On the Network Type page, select the Perimeter Network option and click Next.

On the Network Address page, click the Add button.

In the IP Address Range Properties dialog box, enter the Starting address and Ending Address for the DMZ Network. In this example we’ll enter 10.0.1.0 for the Starting Address and 10.01.255 for the Ending Address. Note that you don’t have to include the entire network ID; you can include only the addresses that are actually in use on that network, or you can get even more specific and include only those addresses that you want to have a route relationship with the default Internet Network behind the back-end ISA firewall, so that you can later create another ISA firewall Network representing other addresses in the DMZ segment that you want to create a NAT relationship with. Click OK.

In the scenario discussed in this article, the Web server on the DMZ Network is a member of the Active Directory domain who’s domain controllers are located behind the back-end ISA firewall. This allows the Web server on the DMZ Network to leverage the Active Directory database to authenticate users connecting to the Web site. This scenario is very similar to that seen in a front-end/back-end Exchange Server configuration, since the front-end/back-end Exchange Servers must be members of the same Active Directory domain.
This means we need to enable intradomain communications between the Web server on the DMZ Network and the domain controllers on the default Internal Network located behind the back-end ISA firewall. Intradomain communications require that you have a Route relationship between the source and destination networks. For this reason, we will create a Network Rule that sets a Route relationship between the DMZ Network and the default Internal Network located behind the back-end ISA firewall.
It's important to note that although there will be a route relationship between the back-end ISA firewall’s default Internal Network and the DMZ Network, there will still be a NAT relationship between the back-end ISA firewall’s default Internal Network and the Internet. This is fully supported (and required), since private addresses are used on the corporate network.
It doesn’t matter if you use public or private addresses on the DMZ Network. Even if you use public addresses on the DMZ Network, you can still have a route relationship between the DMZ Network and the default Internal Network using private addresses behind the back-end ISA firewall because the ISA firewall is directly connected to both Networks and thus has full knowledge of how to reach both Networks.
Perform the following steps to create the Network Rule creating a route relationship between the DMZ Network and the default Internal Network behind the back-end ISA firewall:

In the ISA firewall console, expand the server name and then expand the Configuration node in the left pane of the console. Click the Networks node.

On the Networks node, click the Network Rules tab in the details pane of the console, then click the Create a New Network Rule link in the Tasks tab of the Task Pane.

On the Welcome to the New Network Rule Wizard page, enter a name for the rule in the Network rule name text box. In this example we’ll name the rule DMZ – Internal. Click Next.

On the Network Traffic Sources page, click the Add button.

In the Add Network Entities dialog box, click the Networks folder and then double click the DMZ Network. Click Close.

Figure 3

Click Next on the Network Traffic Sources page.

Click Add on the Network Traffic Destinations page.

Click the Networks folder and then double click the Internal entry. Click Close.

On the Network Relationship page, select the Route option and click Next.

In the Add Network Entities dialog box, click the New menu and then click Computer.

In the New Computer Rule Element dialog box, enter a name for the Web server on the DMZ Network. In this example we’ll name the Computer Object DMZ Web Server. Enter the IP address of the DMZ Web server in the Computer IP Address text box. Enter an optional Description if you like. Click OK.

Figure 6

In the Add Network Entities dialog box, click the New menu and then click Computer.

In the New Computer Rule Element dialog box, enter a name for the domain controller on the Internal Network. In this example we’ll name the Computer Object Domain Controller. Enter the IP address of the domain controller in the Computer IP Address text box. Enter an optional Description if you like. Click OK.

In the Add Network Entities dialog box, click the Computers folder and then double click on the DMZ Web Server and Domain Controller entries. Click Close.

Click Next on the Access Rule Destinations page.

Accept the default setting, All Users, on the User Sets page and click Next.

Click Finish on the Completing the New Access Rule Wizard page.

Create Access Rules Controlling Outbound Access from the Back-end ISA Firewall’s Default Internal Network to the DMZ and the Internet

Clients on the corporate network behind the back-end ISA firewall require access to both the Internet and perhaps the DMZ Network. Your access policy on a live network will be highly customized based on the principle of least privilege; so that users are allowed access to protocols and locations they require access in order to complete their work.
In the example network used in this article series, I’m going to create a simple outbound access policy that allows all hosts on the corporate network outbound access to all resources on the DMZ and the Internet. While you would never create such a rule on a production network, we can do this to simplify things a bit to demonstrate the principles we want to demonstrate in this article.
Perform the following steps to create the Access Rule:

At the back-end ISA firewall, in the ISA firewall console expand the name of the server and then click the Firewall Policy node in the left pane of the console.

Click the Create New Access Rule link on the Tasks tab in the Task Pane.

In the Welcome to the New Access Rule dialog box, enter a name for the rule in the Access Rule name text box. In this example we’ll name the rule All Open Internal to DMZ/External. Click Next.

On the Rule Action page, select the Allow option and click Next.

On the Protocols page, select the All outbound traffic option from the This rule applies to list and click Next.

On the User Sets page, accept the default entry, All Users, and click Next.

Click Finish on the Completing the New Access Rule Wizard page.

Click Apply to save the changes and update the firewall policy.

Click OK in the Apply New Configuration dialog box.

Summary

In this article we went over the step by step details on how to configure the back-end ISA firewall in a back to back ISA firewall configuration where there is a domain member server in the DMZ segment between the ISA firewalls. Procedures included creating an ISA firewall Network for the DMZ segment, creating a Network Rule creating a Route relationship between the default Internal Network behind the back-end ISA firewall and DMZ Network, creating an Access Rule controlling traffic from the back-end ISA firewall’s default Internal Network to the DMZ and the Internet, and another Access Rule controlling intradomain communications between DMZ Web server and the domain controller on the default Internal Network behind the back-end ISA firewall.
In part 3 of this article series will finish up by configuring the DMZ Web server’s network and routing table settings, and setting up the front-end ISA firewall. See you then!

This is the final part of a three part series on configuring domain members in a back to back ISA firewall DMZ

In the first two parts of this three part article series we discussed concepts in DMZ network design and deployment and went over the details of configuring the back-end ISA firewall.
In this article we’ll go through the following:

Configure a Routing Table Entry on the DMZ Server

Join the DMZ Server to the Domain located on the Default Internal Network behind the Back-end ISA Firewall

Configure the Front-end ISA Firewall’s Default Internal Network

Configure a Routing Table Entry on the Front-end ISA Firewall

Create an All Open Access Rule on the Front-end ISA Firewall

Create a Web Publishing Rule on the Front-end ISA Firewall

Test the Solution

Configure a Routing Table Entry on the DMZ Server

The default gateway on the DMZ Web server must be set for the internal interface of the front-end ISA firewall because the Web server needs to respond to connections from Internet hosts. In addition, the Web server may need to initiate connections to Internet hosts, such as the Microsoft Update Site. Note that this isn’t a hard and fast requirement, because if the Web server in the DMZ doesn’t need to initiate connections to Internet hosts, and you configure publishing rules on the front-end ISA firewall to replace the source IP address with the IP address of the ISA firewall, then you could get away with not making the default gateway on the DMZ Web server the front-end ISA firewall’s internal interface.
At the DMZ server, open a command prompt and enter the following:

route add –p 10.0.0.0 MASK 255.255.255.0 10.0.1.2

Where 10.0.0.0 is the network ID for the corporate network behind the ISA firewall, 255.255.255.0 is the subnet mask for that network ID, and 10.0.1.2 is the IP address on the external interface of the back-end ISA firewall.
The figure below shows an example of configuring the routing table entry.

Figure 1

Join the DMZ Server to the Domain Located on the Default Internal Network behind the Back-end ISA Firewall

The next step is to join the DMZ Web server to the corporate network domain. A key factor here is correct DNS configuration on the DMZ server’s network interface. The DMZ Web server must be able to find the domain controller on the corporate network. For this reason, we will use the IP address of the domain controller itself, which hosts an Active Directory integrated DNS server.
Perform the following steps to join the server to the domain (the procedure will vary with the OS the server is running; in this example the DMZ Web server is running Windows 2000).

On the DMZ Web server, right click the My Computer icon on the desktop and click Properties.

In the System Properties dialog box, click the Network Identification tab.

On the Network Identification tab, click the Properties button.

In the Identification Changes dialog box, select the Domain option and enter the FQDN for your domain. In this example, the corporate domain name is msfirewall.org so I will enter that name into the text box. Enter domain admin credentials in the authentication dialog box. Click OK in the dialog box welcoming you to the domain. Click OK in the dialog box informing you that you must reboot your computer.

Click OK in the System Properties dialog box.

Click Yes to restart your computer.

Configure the Front-end ISA Firewall’s Default Internal Network

When the front-end ISA firewall was installed, it took its definition from the routing table on the front-end ISA firewall device. The routing table entries indicated to the ISA firewall installer that the addresses 10.0.1.0-10.0.1.255 should be included in the definition of the default Internal Network. This is a correct configuration if the only network behind the front-end ISA firewall was on network ID 10.0.1.0/24. However, in our scenario this is an incorrect configuration and will cause problems with access control through the front-end ISA firewall.
The reason for the problem with the initial settings for the default Internal Network on the front-end ISA firewall is that there is a Route relationship between the DMZ network (which is the front-end ISA firewall’s default Internal Network) and the default Internal Network behind the back-end ISA firewall. Because there is a route relationship, connections from SecureNAT clients located behind the back-end ISA firewall will reach the front-end ISA firewall with their original client IP address included as the source address (this is not the case with proxied connections by Winsock [Firewall] and Web proxy clients). If we leave the front-end ISA firewall’s default Internal Network definition as it is now, then connections from SecureNAT client located behind the back-end ISA firewall will be detected as spoofed packets.
The reason for this is that ISA firewall Networks are used to determine the validity of connections reaching the interface that is the “root” of a particular ISA firewall Network. For the front-end ISA firewall, the root of the default Internal Network is the internal interface which is on network ID 10.0.1.0/24. Any connections with a source IP address on that network ID are seen as valid. However, if a connection with a source IP address that is not part of the default Internal Network’s definition is made through the interface that is the root of the front-end ISA firewall’s default Internal Network (which is the internal interface of the front-end ISA firewall), then the connection is dropped as a spoof attempt, since the ISA firewall assumes that it's not possible for an interface to accept a connection from a host on a Network that isn’t the same as that for which the interface is root.
We can easily solve this problem by adding the IP addresses included in the back-end ISA firewall’s default Internal Network to the definition of the front-end ISA firewall’s default Internal Network definition.
Perform the following steps to add the IP addresses of the back-end ISA firewall’s default Internal Network to the definition of the front-end ISA firewall’s default Internal Network:

In the ISA firewall console, expand the server name and then expand the Configuration node. Click on the Networks node.

On the Networks node, click the Networks tab in the details pane, then double click the Internal Network.

In the Internal Properties dialog box, click the Addresses tab.

On the Addresses tab, click the Add button.

In the IP Address Range Properties dialog box, enter the Starting address and the Ending address in the text boxes. In this example we’ll enter 10.0.0.0 and 10.0.0.255, respectively. Click OK.

Figure 2

Click OK in the Internal Properties dialog box.

Figure 3

Configure a Routing Table Entry on the Front-end ISA Firewall

Like the situation with the DMZ Web server, you need to configure a routing table entry on the front-end ISA firewall that will enable it to know the route to the default Internal Network located behind the back-end ISA firewall. Perform the same procedure you did on the DMZ Web server to create the routing table entry providing the route to the default Internal Network behind the back-end ISA firewall.Create an All Open Access Rule on the Front-end ISA Firewall

In the example discussed in this article, we will create an All Open access rule on the front-end ISA firewall allowing all traffic outbound from the default Internal Network to External. I’m using this only to keep the scenario simple so that we can focus on main thrust of this article, which is DMZ configuration. This is not what I would recommend you do in a production environment.
What would I do in a production environment? Some things I would consider include:

Allow outbound access through the front-end ISA firewall only for DMZ hosts that need to initiate new connections.

Not allow outbound access through the front-end ISA firewall for published servers on the DMZ and on the corporate network behind the back-end ISA firewall who do not need to make new outbound connections to the Internet

Allow outbound connections for all protocols from the primary IP address on the external interface of the back-end ISA firewall. This is the IP address that will be presented to the front-end ISA firewall for Web proxy and Firewall client located behind the back-end ISA firewall

These are just some very high level considerations, and outbound access requirements though the front-end ISA firewall will vary with the nature of communications allowed to and from the DMZ segment, as well as the internal networks located behind the back-end ISA firewall
Perform the following steps to create the All Open outbound access rule on the front-end ISA firewall:

At the front-end ISA firewall, in the ISA firewall console expand the name of the server and then click the Firewall Policy node in the left pane of the console.

Click the Create New Access Rule link on the Tasks tab in the Task Pane.

In the Welcome to the New Access Rule dialog box, enter a name for the rule in the Access Rule name text box. In this example we’ll name the rule All Open Outbound. Click Next.

On the Rule Action page, select the Allow option and click Next.

On the Protocols page, select the All outbound traffic option from the This rule applies to list and click Next.

On the User Sets page, accept the default entry, All Users, and click Next.

Click Finish on the Completing the New Access Rule Wizard page.

Click Apply to save the changes and update the firewall policy.

Click OK in the Apply New Configuration dialog box.

Create a Web Publishing Rule on the Front-end ISA Firewall

Now we’ll create a Web Publishing Rule to test the solution. The Web Publishing Rule will be a simple one and will not require authentication at the ISA firewall. The only authentication that will be required will be at the Web site itself. Again, in a production environment, I recommend that if you require authentication at the Web server in the DMZ, you should enhance security by employing pre-authentication at the ISA firewall. However, if the front-end ISA firewall is not a member of the same domain as the published Web server, or if the user accounts are not mirrored on the front-end ISA firewall, then the user will be challenged for authentication twice: once by the front-end ISA firewall and once at the Web site itself.
We will create a Web Publishing Rule that allows users who enter the URL http://dmzweb.msfirewall.org access to the Web server in the DMZ. If you want to replicate this configuration, you should make a HOSTS file entry on the front-end ISA firewall that maps the public name of the DMZ Web server to the IP address of the Web server in the DMZ. In addition, the public DNS must contain a Host (A) record for the server that maps to the IP address on the external interface of the front-end ISA firewall.
Perform the following steps to create the Web Publishing Rule:

In the ISA firewall console, expand the server name and then click the Firewall Policy node.

On the Firewall Policy node, click the Tasks tab on the Task Pane and then click the Publish a Web Server link.

On the Welcome to the New Web Publishing Rule Wizard page, enter a name for the Web Publishing Rule in the Web Publishing Rule name text box. In this example, we’ll name the rule Publish DMZ Server. Click Next.

On the Select Rule Action page, select the Allow option and click Next.

On the Define Website to Publish page, enter the name of the DMZ Web server in the Computer name or IP address text box. Remember, the ISA firewall must be able to resolve this name to the actual IP address of the DMZ Web server on the DMZ Network. We will allow access to all folders on this site, so enter a /* in the Path text box. It's usually a good idea to forward the original host header, since this enables many applications that perform server side scripting to work correctly. Click Next.

Figure 4

On the Public Name Details page, select the This domain name (type below) option from the Accept requests for drop down list. In the Public name text box, enter the name that external users will use to access the site. In this example, external users will use the name dmzweb.msfirewall.org to access the site so we will enter that value. We want to allow access to all folders on the site, so we will leave the Path (optional) setting at the default (which is based on the path setting we specified on the previous page in the Wizard). Click Next.

Figure 5

On the Select Web Listener page, click the New button.

On the Welcome to the New Web Listener Wizard page, enter a name for the Web Listener. In this example we’ll name the listener HTTP Listener. Click Next.

On the IP Addresses page, put a checkmark in the External checkbox and click Next.

Figure 6

Accept the default settings on the Port Specification page and click Next.

Click Finish on the Completing the New Web Listener Wizard page.

Click Next on the Select Web Listener page.

Accept the default setting on the User Sets page and click Next.

Click Finish on the Completing the New Web Publishing Rule Wizard page.

Click Apply to save the changes and update the firewall policy.

Click OK in the Apply New Configuration dialog box.

Test the Solution

Let’s test the configuration. On a host on the External Network, make a connection to the published Web server. In this example, we’ll connect to http://dmzweb.msfirewall.org. You should see a single log on dialog box. Enter your credentials and you’ll see the home page for the site. Table 1 below shows a sample of log file entries on the front-end ISA firewall related to the connection attempt.Table 1: Log file entries related to the external client connection to the published Web server in the DMZ (Click Table to Enlarge)
Table 2 shows a sample of log file entries related to the intradomain communications between the DMZ Web server and the domain controller on the corporate network.Table 2: Intradomain communications between the DMZ Web server and the domain controller on the corporate network behind the back-end ISA firewall (Click Table to Enlarge)Summary

In this article series we went over the concepts and procedures involved in placing a domain member computer on a DMZ segment in a back to back ISA firewall configuration. In this, part 3 of the series, we configured the front-end ISA firewall and established a connection from an external client. We then reviewed the log files on the front-end and back-end ISA firewall to see the details of the Web connection to the DMZ Web server and the intradomain communications between the DMZ Web server and the domain controller on the corporate network behind the back-end ISA firewall.

In this, part 4 of our continuing series on back to back ISA firewall configuration, we will examine how you can publish the DMZ Web server and pre-authenticate the connection at the front-end ISA firewall using RADIUS authentication

RADIUS authentication has some significant limitations (for example, you can’t leverage Active Directory Global Groups for access control and each request is re-authenticated), but may be of value in this scenario, since you might not want to make the front-end ISA firewall a domain member since it doesn’t need to authenticate outbound connections.
In this article we’ll go over the following procedures required to enable the front-end ISA firewall to pre-authenticate connections using RADIUS:

The IAS server is required for RADIUS authentication. Actually, you don’t need to use the IAS RADIUS server; you can use any RADIUS server since there are no Microsoft proprietary RADIUS components required for the solution to work.
Perform the following steps on the Windows Server 2003 machine that will be the IAS server on your corporate network (in the example used in this article, the IAS server will be installed on the domain controller located on the default Internal Network behind the back-end ISA firewall):

Click Start, point to Control Panel and click Add or Remove Programs.

In the Add or Remove Programs window, click the Add/Remove Windows Components button.

In the Windows Components dialog box, click the Network Services entry in the Components list and click Details.

Put a checkmark in the Internet Authentication Server checkbox and click OK.

Click Next in the Windows Components dialog box.

Click Finish in the Completing the Windows Components Wizard page.

Configure IAS to accept the front-end ISA firewall as a RADIUS client

After the IAS server is installed, the next step is to configure IAS to accept RADIUS client requests from the ISA firewall. Perform the following steps to configure the front-end ISA firewall as a RADIUS client:

On the IAS server, click Start, point to Administrative Tools and click Internet Authentication Services.

In the Internal Authentication Service console, right click the RADIUS Clients node in the left pane of the console and click New RADIUS Client.

On the Name and Address page, enter a friendly name in the Friendly name text box. In this example we’ll use Front-end ISA Firewall. In the Client address (IP or DNS) text box, enter the IP address of the internal interface of the front-end ISA firewall. In this example, we’ll enter 10.0.1.1. Click Next.

Figure 1

In the Additional Information page, confirm that RADIUS Standard is enter in the Client-Vendor list (if you’re using IAS). Enter a Shared secret and Confirm shared secret. Write down this value, since you will need to configure the front-end ISA firewall with the same shared secret later. Put a checkmark in the Request must contain the Message Authenticator attribute checkbox. Click Finish.

Figure 2

You should now see the front-end ISA firewall listed as a RADIUS client in the right pane of the console.

Figure 3

Configure Remote Access Policy on the IAS Server

We now need to create a Remote Access Policy (RAP) that supports Web proxy connections to the front-end ISA firewall. In contrast to forward Web proxy connections, where client systems must be explicitly configured as Web proxy clients to communicate directly with the Web proxy filter, reverse Web proxy filter connections are automatically received by the Web proxy filter via Web Publishing Rules.
Perform the following steps on the IAS server to configure the Remote Access Policy to support Web proxy client authentication to the front-end ISA firewall:

In the Internet Authentication Service console, right click on the Remote Access Policy node in the left pane of the console and click New Remote Access Policy.

Click Next on the Welcome to the New Remote Access Policy page.

On the Policy Configuration Method page, select the Set up a custom policy option. Enter a name for the policy in the Policy name text box. In this example we’ll name the policy Front-end ISA FirewallWeb proxy. Click Next.

Figure 4

On the Policy Conditions page, click Add.

In the Select Attribute dialog box, click the Authentication Type entry in the Attribute types list and click Add.

In the Select Groups dialog box, enter the name of an Active Directory Global Group that you want to allow access. In this example we’ll use the Domain Users group. Enter Domain Users in the Enter the object names to select text box and click Check Names. Click OK.

In the Edit Dial-in Profile dialog box, click the Authentication tab. On the Authentication tab, remove the checkmarks from all the checkboxes. Then put a checkmark in the Unencrypted authentication (PAP, SPAP) checkbox.

Figure 11

Click the Encryption tab. On the Encryption tab, put a checkmark in the No encryption checkbox. Click Apply and then click OK. Click No in the Dial-in dialog box.

Figure 12

Click Next on the Profile page.

Click Finish on the Completing the New Remote Access Policy Wizard page.

The new RAP appears in the right pane of the console.

Figure 13

Configure the back-end ISA firewall to allow RADIUS communications from the front-end ISA firewall to the IAS server on the default Internal Network behind the back-end ISA firewall

The back-end ISA firewall needs an Access Rule allowing RADIUS communications to pass from the front-end ISA firewall to the IAS server on the corporate network behind the back-end ISA firewall.
Perform the following steps to create the Access Rule:

In the ISA firewall console, expand the server name and click the Firewall Policy node.

On the Firewall Policy node, click the Tasks tab in the Task Pane. Click the Create a New Access Rule link.

On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example we’ll name the rule RADIUS Local Host to IAS and click Next.

On the Rule Action page, select the Allow option and click Next.

On the Protocols page, select the Selected protocols option from the This rule applies to list, then click Add.

In the Add Protocols dialog box, click the All Protocols folder. Double click the RADIUS and RADIUS Accounting entries and click Close.

Figure 14

Click Next on the Protocols page.

On the Access Rule Sources page, click the Add button.

In the Add Network Entities dialog box, click the New button and click Computer.

In the New Computer Rule Element dialog box, enter a name for the front-end ISA firewall in the Name text box. In this example we’ll name the front-end ISA firewall FE ISA Firewall. Enter the IP address of the internal interface of the front-end ISA firewall in the Computer IP Address text box. In this example, the IP address on the internal interface of the front-end ISA firewall is 10.0.1.1. Enter a description if you like. Click OK.

Figure 15

In the Add Network Entities dialog box, click the New button and click Computer.

In the New Computer Rule Element dialog box, enter a name for the IAS server in the Name text box. In this example, we’ll name the IAS server IAS Server. Enter the IP address of the IAS server in the Computer IP Address text box. In this example the IP address of the IAS server is 10.0.0.2. Enter an option description if you like. Click OK.

The front-end ISA firewall must be configured to use the RADIUS server on the corporate network located behind the back-end ISA firewall. We can then configure the Web Publishing Rule to use this RADIUS server after making this configuration change.
Perform the following steps to create the RADIUS server entry on the front-end ISA firewall:

At the front-end ISA firewall, open the ISA firewall console and expand the server name, then expand the Configuration node.

Click the General node. In the Details pane, click the Define RADIUS Servers link.

In RADIUS Servers dialog box, click the Add button.

In the Add RADIUS Server dialog box, enter the IP address of the IAS server in the Server name text box. In this example, the IP address of the IAS server is 10.0.0.2. Enter an optional description in the Server description text box. Click the Change button.

In the Shared Secret dialog box, enter the same shared secret you created when you configured the IAS server to use the front-end ISA firewall as a RADIUS client. Click OK.

Figure 18

Put a checkmark in the Always use message authenticator checkbox and click OK.

Figure 19

Click OK in the RADIUS Servers dialog box.

Configure the Web Publishing Rule on the front-end ISA Firewall to use RADIUS authentication and Forward Basic Credentials to the Web Server

Now we’ll configure the Web Publishing Rule used to publish the DMZ Web server to use RADIUS authentication to pre-authenticate users at the ISA firewall before the connections are forwarded to the DMZ Web server. This significantly increases the level of security provided by the ISA firewall to protect the published Web server.
An interesting issue regarding RADIUS authentication is that clients send credentials using basic authentication when authenticating via RADIUS. This means you can obtain single sign-on with the published Web server by delegating basic authentication in the Web Publishing Rule. You must enable basic authentication on the published Web server for this to work correctly. You cannot use integrated authentication on the Web server if you wish to avoid multiple authentication prompts.
Perform the following steps to configure the Web Publishing Rule to use basic authentication and forward basic credentials to the published Web site:

In the ISA firewall console on the front-end ISA firewall, expand the server name and then click the Firewall Policy node.

On the Firewall Policy node, double click the Web Publishing Rule you created for publish the DMZ Web server.

In the Properties dialog box for the Web Publishing Rule, click the Listener tab.

On the Listener tab, click the Properties button.

In the Listener’s Properties dialog box, click the Preferences tab.

On the Preferences tab, click the Authentication button.

In the Authentication dialog box, remove checkmarks from other authentication methods. Put a checkmark in the RADIUS checkbox. Put a checkmark in the Require all users to authenticate checkbox. Click the Select Domain button.

Figure 20

In the Select Domain dialog box, enter the name of the corporate network user domain. In this example our internal user domain is named msfirewall.org, so we’ll enter MSFIREWALL in the Domain Name text box. Click OK

At an external client, make a connection to the published Web site using the URL the ISA firewall’s Web Publishing Rule is configured to listen for. You will be presented with an authentication dialog box. Enter your credentials and click OK. You should see only a single authentication dialog box.
If you see a second authentication dialog box, then it’s likely that the Web site is not configured to support basic authentication. Check the Security tab in the Properties dialog box of the Web site and confirm that Basic authentication is enabled.
Note that since credentials are sent using basic authentication, it's critical that you use SSL to secure the information from end to end. If you plan on using RADIUS authentication on the front-end ISA firewall, then make sure your production deployment uses SSL to secure the connection from the client to the front-end ISA firewall, and SSL from the front-end ISA firewall to the published Web server in the DMZ. Alternatively, you could use IPSec to secure the connection between the ISA firewall and the published Web server, although this adds a layer of complexity that isn’t required.Summary

In this article series we went over the concepts and procedures involved in placing a domain member computer on a DMZ segment in a back to back ISA firewall configuration. In this, part 4 of the series, we went over the procedures involved with enabling RADIUS authentication on the front-end ISA firewall so that incoming connections to the DMZ Web server can be pre-authenticated by the ISA firewall before being forwarded to the Web server.