Configuring Domain Members in a Back to Back ISA Firewall DMZ

[LEFT][CODE]http://www.isaserver.org/tutorials/Configuring-Domain-Members-Back-to-Back-ISA-Firewall-DMZ-Part1.html[/CODE]

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

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 [I]real [/I]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.
[B]DMZs Morph into Security Perimeters[/B]

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 [I]is[/I] 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 [I]same[/I] 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 [I]will be firewalls[/I], regardless of the name marketeers and security wankers may give them.
Keep in mind that the [I]perimeter[/I] is [B]not[/B] the place where the corporate network meets the Internet. There is [I]no perimeter[/I], there are [I]multiple[/I] 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.
[B]Define Your Security Zones[/B]

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:

[LIST][*]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[/LIST]
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 [I]inbound[/I] connections can be made to these machines. Any device accepting connections from Internet hosts is considered [I]Internet facing[/I]. 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:

[LIST][*]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 [I]at the firewall[/I] and then [I]authorized[/I] 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[/LIST]
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 [I]pre-authenticated[/I] and [I]pre-authorized[/I] 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.
[INDENT] [IMG]http://www.isaserver.org/img/upl/Fig11146558377074.JPG[/IMG]
[B]Figure 1[/B]
[B] [CENTER]

[URL="http://www.amazon.com/gp/product/1931836191/104-4782402-9827902?v=glance&n=283155"]
[/URL][/CENTER]
[/B][/INDENT][B]Front-end Exchange Servers Should be Placed in a DMZ Segment[/B]

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 [I]attacker [sic] surface [/I]presented by the Internet is much larger than any potential [I]attacker surface[/I] 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 [I]off[/I] 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 [I]always[/I] be in a DMZ segment, and should [I]never[/I] 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 [I]critical distinction[/I] 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.
[B]Scenario Description[/B]

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.
[INDENT] [IMG]http://www.isaserver.org/img/upl/Fig21146558377074.JPG[/IMG]
[B]Figure 2[/B][/INDENT]If you’re familiar with our book [B]Configuring ISA Server 2004[/B] 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:

[LIST][*]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[/LIST]
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:

[LIST][*][B]Part 1[/B] – Concepts in design and deployment of DMZs and network security perimeters[*][B]Part 2[/B] – Configuring the back-end ISA firewall[*][B]Part 3[/B] – Configuring the DMZ Web server and front-end ISA firewall[*][B]Part 4 [/B]– Using RADIUS authentication on the front-end ISA firewall[/LIST]
The article series will discuss in detail the following topics:

[LIST][*]Configure the back-end ISA firewall with a DMZ ISA firewall Network[*]Configure the back-end ISA firewall with a Network Rule setting a Route relationship between the back-end ISA firewall’s default Internal Network and the DMZ ISA firewall Network[*]Create Access Rules enabling intra-domain communications between the DMZ server and the domain controller on the back-end ISA firewall’s default Internal Network[*]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[/LIST]
[CENTER]
[URL="http://www.amazon.com/gp/product/1931836191/104-4782402-9827902?v=glance&n=283155"]
[/URL][/CENTER]
[B]Summary[/B]

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 [I]a perimeter[/I] 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.
[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/Configuring-Domain-Members-Back-to-Back-ISA-Firewall-DMZ-Part2.html[/CODE]

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

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:

[LIST][*]Configure the Back-end ISA firewall with a DMZ ISA Firewall Network[*]Configure the Back-end ISA Firewall with a Network Rule Setting a Route relationship between the back-end ISA Firewall’s Default Internal Network and the DMZ ISA Firewall Network[*]Create Access Rules Enabling Intra-domain Communications between the DMZ Server and the Domain Controller on the Back-end ISA Firewall’s Default Internal Network[*]Create Access Rules Controlling Outbound Access from the Back-end ISA Firewall’s Default Internal Network to the DMZ and the Internet[/LIST]
[B]Configure the Back-end ISA firewall with a DMZ ISA Firewall Network[/B]

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 [I]do not[/I] 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:

[LIST=1][*]In the ISA firewall console, expand the server name and then expand the [B]Configuration[/B] node. Click the [B]Networks[/B] node.[*]On the [B]Networks[/B] node, click the [B]Networks[/B] tab in the details pane. Click the [B]Tasks[/B] tab in the Task Pane and then click the [B]Create a New Network[/B] link.[*]On the [B]Welcome to the New Network Wizard[/B] page, enter a name for the Network in the [B]Network name[/B] text box. In this example we’ll name the Network [B]DMZ[/B]. Click [B]Next[/B].[*]On the [B]Network Type[/B] page, select the [B]Perimeter Network[/B] option and click [B]Next[/B].[*]On the [B]Network Address[/B] page, click the [B]Add[/B] button.[*]In the [B]IP Address Range Properties[/B] dialog box, enter the [B]Starting address [/B]and [B]Ending Address[/B] for the DMZ Network. In this example we’ll enter [B]10.0.1.0[/B] for the [B]Starting Address[/B] and [B]10.01.255[/B] for the [B]Ending Address[/B]. 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 [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021147077565253.jpg[/IMG]
[B]Figure 1[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Network Addresses[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041147077565269.jpg[/IMG]
[B]Figure 2[/B][/INDENT]
[LIST=1][*]Click [B]Finish[/B] on the [B]Completing the New Network Wizard[/B] page.[/LIST]
[B]Configure the Back-end ISA Firewall with a Network Rule Setting a Route relationship between the back-end ISA Firewall’s Default Internal Network and the DMZ ISA Firewall Network[/B]

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 [I]Route[/I] 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:

[LIST=1][*]In the ISA firewall console, expand the server name and then expand the [B]Configuration[/B] node in the left pane of the console. Click the [B]Networks[/B] node.[*]On the [B]Networks[/B] node, click the [B]Network Rules[/B] tab in the details pane of the console, then click the [B]Create a New Network Rule[/B] link in the [B]Tasks[/B] tab of the Task Pane.[*]On the [B]Welcome to the New Network Rule Wizard[/B] page, enter a name for the rule in the [B]Network rule name[/B] text box. In this example we’ll name the rule [B]DMZ – Internal[/B]. Click [B]Next[/B].[*]On the [B]Network Traffic Sources[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder and then double click the [B]DMZ[/B] Network. Click [B]Close[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061147077565269.jpg[/IMG]
[B]Figure 3[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Network Traffic Sources[/B] page.[*]Click [B]Add[/B] on the [B]Network Traffic Destinations[/B] page.[*]Click the [B]Networks[/B] folder and then double click the [B]Internal[/B] entry. Click [B]Close[/B].[*]On the [B]Network Relationship[/B] page, select the [B]Route[/B] option and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0081147079068138.jpg[/IMG]
[B]Figure 4[/B][/INDENT]
[LIST=1][*]Click [B]Finish[/B] on the [B]Completing the New Network Rule Wizard[/B] page.[/LIST]
[CENTER] [/CENTER]


[B]Create Access Rules Enabling Intra-domain Communications between the DMZ Server and the Domain Controller on the Back-end ISA Firewall’s Default Internal Network[/B]

Multiple protocols are required to allow intradomain communications between the DMZ host and the domain controllers on the corporate network. Table 1 provides the details of this Access Rule.
[INDENT]
[B]Name[/B]
Intradomain Communications
[B]Action[/B]
Allow
[B]Protocols[/B]
Microsoft CIFS (TCP)
Microsoft CIFS (UDP)
DNS
Kerberos-Adm(UDP)
Kerberos-Sec(TCP)
Kerberos-Sec(UDP)
LDAP
LDAP (UDP)
LDAP GC (Global Catalog)
RPC (all interfaces)
NTP (UDP)
Ping
[B]From[/B]
DMZ Web Server
Domain Controller
[B]To[/B]
Domain Controller
DMZ Web Server
[B]Users[/B]
All
[B]Schedule[/B]
Always
[B]Content Types[/B]
All content types
[B]Table 1:[/B] Access Rule allowing intradomain communications between the DMZ host and the DC on the default Internal Network behind the back-end ISA firewall[/INDENT]Perform the following steps to create this Access Rule:

[LIST=1][*]In the ISA firewall console, expand the server name and then click the [B]Firewall Policy[/B] node in the left pane of the console.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab in the Task Pane and click the [B]Create New Access Rule [/B]link.[*]On the [B]Welcome to the New Access Rule Wizard[/B] page, enter the name of the rule in the [B]Access Rule name[/B] text box. In this example, we’ll name the rule [B]Intradomain DMZ—Internal[/B] and click [B]Next[/B].[*]Select the [B]Allow[/B] option on the [B]Rule Action[/B] page.[*]On the [B]Protocols[/B] page, select the [B]Selected protocols[/B] option from the [B]This rule applies to[/B] list. Click [B]Add[/B].[*]Click the [B]Add Protocols[/B] folder and then double click the following protocols:[/LIST]
[INDENT] [B]Microsoft CIFS (TCP)
[/B][B]Microsoft CIFS (UDP)
[/B][B]DNS
[/B][B]Kerberos-Adm(UDP)
[/B][B]Kerberos-Sec(TCP)
[/B][B]Kerberos-Sec(UDP)
[/B][B]LDAP
[/B][B]LDAP (UDP)
[/B][B]LDAP GC (Global Catalog)
[/B][B]RPC (all interfaces)
[/B][B]NTP (UDP)
[/B][B]Ping
[/B]Click [B]Close[/B] in the [B]Add Protocols[/B] dialog box.[/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Protocols[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101147079068138.jpg[/IMG]
[B]Figure 5[/B][/INDENT]
[LIST=1][*]On the [B]Access Rule Sources[/B] page, click the [B]Add [/B]button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]New[/B] menu and then click [B]Computer[/B].[*]In the [B]New Computer Rule Element[/B] dialog box, enter a name for the Web server on the DMZ Network. In this example we’ll name the Computer Object [B]DMZ Web Server[/B]. Enter the IP address of the DMZ Web server in the [B]Computer IP Address[/B] text box. Enter an optional [B]Description[/B] if you like. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121147079068138.jpg[/IMG]
[B]Figure 6[/B][/INDENT]
[LIST=1][*]In the [B]Add Network Entities[/B] dialog box, click the [B]New[/B] menu and then click [B]Computer[/B].[*]In the [B]New Computer Rule Element[/B] dialog box, enter a name for the domain controller on the Internal Network. In this example we’ll name the Computer Object [B]Domain Controller[/B]. Enter the IP address of the domain controller in the [B]Computer IP Address[/B] text box. Enter an optional [B]Description[/B] if you like. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0141147079314249.jpg[/IMG]
[B]Figure 7[/B][/INDENT]
[LIST=1][*]Click the [B]Computers[/B] folder and double click the [B]DMZ Web Server[/B] and [B]Domain Controller [/B]entries.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0161147079314249.jpg[/IMG]
[B]Figure 8[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*]Click [B]Add[/B] on the [B]Access Rule Destinations[/B] page.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Computers[/B] folder and then double click on the [B]DMZ Web Server[/B] and [B]Domain Controller[/B] entries. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[*]Accept the default setting, [B]All Users[/B], on the [B]User Sets[/B] page and click [B]Next[/B].[*]Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[/LIST]
[B]Create Access Rules Controlling Outbound Access from the Back-end ISA Firewall’s Default Internal Network to the DMZ and the Internet[/B]

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:

[LIST=1][*]At the back-end ISA firewall, in the ISA firewall console expand the name of the server and then click the [B]Firewall Policy[/B] node in the left pane of the console.[*]Click the [B]Create New Access Rule [/B]link on the [B]Tasks[/B] tab in the Task Pane.[*]In the [B]Welcome to the New Access Rule [/B]dialog box, enter a name for the rule in the [B]Access Rule name[/B] text box. In this example we’ll name the rule [B]All Open Internal to DMZ/External[/B]. Click [B]Next[/B].[*]On the [B]Rule Action[/B] page, select the [B]Allow[/B] option and click [B]Next[/B].[*]On the [B]Protocols[/B] page, select the [B]All outbound traffic[/B] option from the [B]This rule applies to[/B] list and click [B]Next[/B].[*]On the [B]Access Rule Sources[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder and double click the [B]Internal[/B] entry. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*]On the [B]Access Rule Destinations[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder. Double click both the [B]DMZ[/B] and [B]External[/B] Networks. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[*]On the [B]User Sets[/B] page, accept the default entry, [B]All Users[/B], and click [B]Next[/B].[*]Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[*]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]
[CENTER]
[URL="http://www.amazon.com/gp/product/1931836191/104-9818113-9909525?v=glance&n=283155"]
[/URL][/CENTER]
[B]Summary[/B]

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!


[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/Configuring-Domain-Members-Back-to-Back-ISA-Firewall-DMZ-Part3.html[/CODE]

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


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:

[LIST][*]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[/LIST]
[B]Configure a Routing Table Entry on the DMZ Server[/B]

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:
[INDENT] route add –p 10.0.0.0 MASK 255.255.255.0 10.0.1.2[/INDENT]Where [B]10.0.0.0[/B] is the network ID for the corporate network behind the ISA firewall, [B]255.255.255.0[/B] is the subnet mask for that network ID, and [B]10.0.1.2[/B] 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.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021147438454441.jpg[/IMG]
[B]Figure 1[/B][/INDENT][B]Join the DMZ Server to the Domain Located on the Default Internal Network behind the Back-end ISA Firewall[/B]

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

[LIST=1][*]On the DMZ Web server, right click the [B]My Computer[/B] icon on the desktop and click [B]Properties[/B].[*]In the [B]System Properties[/B] dialog box, click the [B]Network Identification [/B]tab.[*]On the [B]Network Identification [/B]tab, click the [B]Properties [/B]button.[*]In the [B]Identification Changes[/B] dialog box, select the [B]Domain[/B] option and enter the FQDN for your domain. In this example, the corporate domain name is [I]msfirewall.org[/I] so I will enter that name into the text box. Enter domain admin credentials in the authentication dialog box. Click [B]OK[/B] in the dialog box welcoming you to the domain. Click [B]OK[/B] in the dialog box informing you that you must reboot your computer.[*]Click [B]OK[/B] in the [B]System Properties[/B] dialog box.[*]Click [B]Yes[/B] to restart your computer.[/LIST]
[B]Configure the Front-end ISA Firewall’s Default Internal Network[/B]

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 [B]10.0.1.0-10.0.1.255[/B] 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:

[LIST=1][*]In the ISA firewall console, expand the server name and then expand the [B]Configuration[/B] node. Click on the [B]Networks[/B] node.[*]On the [B]Networks [/B]node, click the [B]Networks[/B] tab in the details pane, then double click the [B]Internal[/B] Network.[*]In the [B]Internal Properties[/B] dialog box, click the [B]Addresses[/B] tab.[*]On the [B]Addresses[/B] tab, click the [B]Add[/B] button.[*]In the [B]IP Address Range Properties[/B] dialog box, enter the [B]Starting address[/B] and the [B]Ending address[/B] in the text boxes. In this example we’ll enter [B]10.0.0.0[/B] and [B]10.0.0.255[/B], respectively. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041147438454457.jpg[/IMG]
[B]Figure 2[/B][/INDENT]
[LIST=1][*]Click [B]OK[/B] in the [B]Internal Properties[/B] dialog box.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061147438454472.jpg[/IMG]
[B]Figure 3[/B][/INDENT][B]Configure a Routing Table Entry on the Front-end ISA Firewall[/B]

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.
[B]Create an All Open Access Rule on the Front-end ISA Firewall[/B]

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 [I]not[/I] what I would recommend you do in a production environment.
What would I do in a production environment? Some things I would consider include:

[LIST][*]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[/LIST]
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:

[LIST=1][*]At the front-end ISA firewall, in the ISA firewall console expand the name of the server and then click the [B]Firewall Policy[/B] node in the left pane of the console.[*]Click the [B]Create New Access Rule [/B]link on the [B]Tasks[/B] tab in the Task Pane.[*]In the [B]Welcome to the New Access Rule [/B]dialog box, enter a name for the rule in the [B]Access Rule name[/B] text box. In this example we’ll name the rule [B]All Open Outbound[/B]. Click [B]Next[/B].[*]On the [B]Rule Action[/B] page, select the [B]Allow[/B] option and click [B]Next[/B].[*]On the [B]Protocols[/B] page, select the [B]All outbound traffic[/B] option from the [B]This[/B][B] rule applies to[/B] list and click [B]Next[/B].[*]On the [B]Access Rule Sources[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder and double click the [B]Internal[/B] entry. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*]On the [B]Access Rule Destinations[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Networks[/B] folder. Double click the [B]External[/B] Network. Click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[*]On the [B]User Sets[/B] page, accept the default entry, [B]All Users[/B], and click [B]Next[/B].[*]Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[*]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]
[CENTER]
[URL="http://www.amazon.com/gp/product/1931836191/104-9818113-9909525?v=glance&n=283155"]
[/URL][/CENTER]
[B]Create a Web Publishing Rule on the Front-end ISA Firewall[/B]

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 [B][url]http://dmzweb.msfirewall.org[/url][/B] 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:

[LIST=1][*]In the ISA firewall console, expand the server name and then click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab on the Task Pane and then click the [B]Publish a Web Server[/B] link.[*]On the [B]Welcome to the New Web Publishing Rule Wizard[/B] page, enter a name for the Web Publishing Rule in the [B]Web Publishing Rule name[/B] text box. In this example, we’ll name the rule [B]Publish DMZ Server[/B]. Click [B]Next[/B].[*]On the [B]Select Rule Action[/B] page, select the [B]Allow[/B] option and click [B]Next[/B].[*]On the [B]Define Website to Publish[/B] page, enter the name of the DMZ Web server in the [B]Computer name or IP address[/B] 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 [B]/*[/B] in the [B]Path[/B] 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 [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0081147438742894.jpg[/IMG]
[B]Figure 4[/B][/INDENT]
[LIST=1][*]On the [B]Public Name Details[/B] page, select the [B]This[/B][B] domain name (type below)[/B] option from the [B]Accept requests for[/B] drop down list. In the [B]Public name[/B] text box, enter the name that external users will use to access the site. In this example, external users will use the name [B]dmzweb.msfirewall.org[/B] 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 [B]Path (optional) [/B]setting at the default (which is based on the path setting we specified on the previous page in the Wizard). Click [B]Next.[/B][/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101147438742972.jpg[/IMG]
[B]Figure 5[/B][/INDENT]
[LIST=1][*]On the [B]Select Web Listener[/B] page, click the [B]New[/B] button.[*]On the [B]Welcome to the New Web Listener Wizard[/B] page, enter a name for the Web Listener. In this example we’ll name the listener [B]HTTP Listener[/B]. Click [B]Next[/B].[*]On the [B]IP Addresses[/B] page, put a checkmark in the [B]External[/B] checkbox and click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121147438743051.jpg[/IMG]
[B]Figure 6[/B][/INDENT]
[LIST=1][*]Accept the default settings on the [B]Port Specification[/B] page and click [B]Next[/B].[*]Click [B]Finish[/B] on the [B]Completing the New Web Listener Wizard[/B] page.[*]Click [B]Next[/B] on the [B]Select Web Listener[/B] page.[*]Accept the default setting on the [B]User Sets[/B] page and click [B]Next[/B].[*]Click [B]Finish[/B] on the [B]Completing the New Web Publishing Rule Wizard[/B] page.[*]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]
[B]Test the Solution[/B]

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 [B][url]http://dmzweb.msfirewall.org[/url][/B]. 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.
[B][URL="http://www.isaserver.org/img/upl/Table1-1147679731172.gif"][IMG]http://www.isaserver.org/img/upl/Table1small1147679731172.gif[/IMG][/URL]
[/B][B]Table 1:[/B] 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.
[B][URL="http://www.isaserver.org/img/upl/Table2-1147683308820.gif"][IMG]http://www.isaserver.org/img/upl/Table2small1147683308820.gif[/IMG][/URL]
[/B][B]Table 2:[/B] 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)
[B]Summary[/B]

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.

[/LEFT]

[LEFT][CODE]http://www.isaserver.org/tutorials/Configuring-Domain-Members-Back-to-Back-ISA-Firewall-DMZ-Part4.html[/CODE]

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


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:

[LIST][*]Install IAS on the default Internet Network behind the back-end ISA firewall[*]Configure IAS to accept the front-end ISA firewall as a RADIUS client[*]Configure Remote Access Policy on the IAS server[*]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[*]Configure the front-end ISA firewall to use the RADIUS server[*]Configure the Web Publishing Rule on the front-end ISA firewall to use RADIUS authentication and forward basic credentials to the Web server[*]Test the solution[/LIST]
[B]Install IAS on the default Internet Network behind the back-end ISA firewall[/B]

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):

[LIST=1][*]Click [B]Start[/B], point to [B]Control Panel[/B] and click [B]Add or Remove Programs[/B].[*]In the [B]Add or Remove Programs[/B] window, click the [B]Add/Remove Windows Components[/B] button.[*]In the [B]Windows Components[/B] dialog box, click the [B]Network Services[/B] entry in the [B]Components[/B] list and click [B]Details[/B].[*]Put a checkmark in the [B]Internet Authentication Server [/B]checkbox and click [B]OK[/B].[*]Click [B]Next[/B] in the [B]Windows Components[/B] dialog box.[*]Click [B]Finish[/B] in the [B]Completing the Windows Components Wizard[/B] page.[/LIST]
[B]Configure IAS to accept the front-end ISA firewall as a RADIUS client[/B]

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:

[LIST=1][*]On the IAS server, click [B]Start[/B], point to [B]Administrative Tools[/B] and click [B]Internet Authentication Services[/B].[*]In the [B]Internal Authentication Service[/B] console, right click the [B]RADIUS Clients[/B] node in the left pane of the console and click [B]New RADIUS Client[/B].[*]On the [B]Name and Address[/B] page, enter a friendly name in the [B]Friendly name[/B] text box. In this example we’ll use [B]Front-end ISA Firewall[/B]. In the [B]Client address (IP or DNS)[/B] text box, enter the IP address of the internal interface of the front-end ISA firewall. In this example, we’ll enter [B]10.0.1.1[/B]. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0021148305503000.jpg[/IMG]
[B]Figure 1[/B][/INDENT]
[LIST=1][*]In the [B]Additional Information[/B] page, confirm that [B]RADIUS Standard[/B] is enter in the [B]Client-Vendor[/B] list (if you’re using IAS). Enter a [B]Shared secret[/B] and [B]Confirm shared secret[/B]. 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 [B]Request must contain the Message Authenticator attribute[/B] checkbox. Click [B]Finish[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0041148305503000.jpg[/IMG]
[B]Figure 2[/B][/INDENT]
[LIST=1][*]You should now see the front-end ISA firewall listed as a RADIUS client in the right pane of the console.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0061148305503000.jpg[/IMG]
[B]Figure 3[/B][/INDENT][B]Configure Remote Access Policy on the IAS Server[/B]

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:

[LIST=1][*]In the [B]Internet Authentication Service [/B]console, right click on the [B]Remote Access Policy[/B] node in the left pane of the console and click [B]New Remote Access Policy[/B].[*]Click [B]Next[/B] on the [B]Welcome to the New Remote Access Policy[/B] page.[*]On the [B]Policy Configuration Method[/B] page, select the [B]Set up a custom policy[/B] option. Enter a name for the policy in the [B]Policy name[/B] text box. In this example we’ll name the policy [B]Front-end ISA Firewall[/B] [B]Web proxy[/B]. Click [B]Next[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0081148305669797.jpg[/IMG]
[B]Figure 4[/B][/INDENT]
[LIST=1][*]On the [B]Policy Conditions[/B] page, click [B]Add[/B].[*]In the [B]Select Attribute[/B] dialog box, click the [B]Authentication Type[/B] entry in the [B]Attribute types[/B] list and click [B]Add[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0101148305669797.jpg[/IMG]
[B]Figure 5[/B][/INDENT]
[LIST=1][*]In the [B]Authentication Type[/B] dialog box, click the [B]PAP[/B] entry and click [B]Add[/B]. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0121148305669797.jpg[/IMG]
[B]Figure 6[/B][/INDENT]
[LIST=1][*]Click [B]Add[/B] on the [B]Policy Conditions[/B] page.[*]In the [B]Select Attribute[/B] dialog box, click the [B]NAS-IP-Identifier[/B] entry in the [B]Attribute types[/B] list. Click [B]Add[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0141148305843750.jpg[/IMG]
[B]Figure 7[/B][/INDENT]
[LIST=1][*]In the [B]NAS-IP-Address[/B] dialog box, enter the IP address on the internal interface of the front-end ISA firewall. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0161148305843766.jpg[/IMG]
[B]Figure 8[/B][/INDENT]
[LIST=1][*]Click [B]Add[/B] on the [B]Policy Conditions[/B] page.[*]In the [B]Select Attribute[/B] dialog box, click the [B]Windows-Groups[/B] entry in the [B]Attribute types[/B] list. Click [B]Add[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0181148305843766.jpg[/IMG]
[B]Figure 9[/B][/INDENT]
[LIST=1][*]In the [B]Groups[/B] dialog box, click the [B]Add[/B] button.[*]In the [B]Select Groups[/B] dialog box, enter the name of an Active Directory Global Group that you want to allow access. In this example we’ll use the [B]Domain Users[/B] group. Enter [B]Domain Users[/B] in the [B]Enter the object names to select[/B] text box and click [B]Check Names[/B]. Click [B]OK[/B].[*]Click [B]OK[/B] in the [B]Groups[/B] dialog box.[*]Click [B]Next[/B] on the [B]Policy Conditions[/B] page.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0201148306100078.jpg[/IMG]
[B]Figure 10[/B][/INDENT]
[LIST=1][*]On the [B]Permissions[/B] page, select the [B]Grant remote access permission[/B] option and click [B]Next[/B].[*]On the [B]Profiles[/B] page, click the [B]Edit Profile[/B] button.[*]In the [B]Edit Dial-in Profile[/B] dialog box, click the [B]Authentication[/B] tab. On the [B]Authentication[/B] tab, remove the checkmarks from all the checkboxes. Then put a checkmark in the [B]Unencrypted authentication (PAP, SPAP)[/B] checkbox.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0221148306100094.jpg[/IMG]
[B]Figure 11[/B][/INDENT]
[LIST=1][*]Click the [B]Encryption[/B] tab. On the [B]Encryption[/B] tab, put a checkmark in the [B]No encryption[/B] checkbox. Click [B]Apply[/B] and then click [B]OK[/B]. Click [B]No[/B] in the [B]Dial-in [/B]dialog box.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/New%20Image1148369702906.JPG[/IMG]
[B]Figure 12[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Profile[/B] page.[*]Click [B]Finish[/B] on the [B]Completing the New Remote Access Policy Wizard[/B] page.[*]The new RAP appears in the right pane of the console.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0241148306449000.jpg[/IMG]
[B]Figure 13[/B][/INDENT][B]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[/B]

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:

[LIST=1][*]In the ISA firewall console, expand the server name and click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, click the [B]Tasks[/B] tab in the Task Pane. Click the [B]Create a New Access Rule [/B]link.[*]On the [B]Welcome to the New Access Rule Wizard[/B] page, enter a name for the rule in the [B]Access Rule name[/B] text box. In this example we’ll name the rule [B]RADIUS Local Host to IAS[/B] and click [B]Next[/B].[*]On the [B]Rule Action[/B] page, select the [B]Allow[/B] option and click [B]Next[/B].[*]On the [B]Protocols[/B] page, select the [B]Selected protocols[/B] option from the [B]This rule applies to[/B] list, then click [B]Add[/B].[*]In the [B]Add Protocols[/B] dialog box, click the [B]All Protocols[/B] folder. Double click the [B]RADIUS[/B] and [B]RADIUS Accounting[/B] entries and click [B]Close[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0261148306449016.jpg[/IMG]
[B]Figure 14[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Protocols[/B] page.[*]On the [B]Access Rule Sources[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]New[/B] button and click [B]Computer[/B].[*]In the [B]New Computer Rule Element[/B] dialog box, enter a name for the front-end ISA firewall in the [B]Name[/B] text box. In this example we’ll name the front-end ISA firewall [B]FE ISA Firewall[/B]. Enter the IP address of the internal interface of the front-end ISA firewall in the [B]Computer IP Address[/B] text box. In this example, the IP address on the internal interface of the front-end ISA firewall is [B]10.0.1.1[/B]. Enter a description if you like. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0281148306449016.jpg[/IMG]
[B]Figure 15[/B][/INDENT]
[LIST=1][*]In the [B]Add Network Entities[/B] dialog box, click the [B]New[/B] button and click [B]Computer[/B].[*]In the [B]New Computer Rule Element[/B] dialog box, enter a name for the IAS server in the [B]Name[/B] text box. In this example, we’ll name the IAS server [B]IAS Server[/B]. Enter the IP address of the IAS server in the [B]Computer IP Address[/B] text box. In this example the IP address of the IAS server is [B]10.0.0.2[/B]. Enter an option description if you like. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0301148306718594.jpg[/IMG]
[B]Figure 16[/B][/INDENT]
[LIST=1][*]In the [B]Add Network Entities[/B] dialog box, click the [B]Computers[/B] folder. Double click on the [B]FE ISA Firewall[/B] entry and click [B]Close[/B].[*]Click [B]Next[/B] on the [B]Access Rule Sources[/B] page.[*]On the [B]Access Rule Destinations[/B] page, click the [B]Add[/B] button.[*]In the [B]Add Network Entities[/B] dialog box, click the [B]Computers[/B] folder. Double click the [B]IAS Server[/B] entry. Click [B]Close[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0321148306718594.jpg[/IMG]
[B]Figure 17[/B][/INDENT]
[LIST=1][*]Click [B]Next[/B] on the [B]Access Rule Destinations[/B] page.[*]Click [B]Next[/B] on the [B]User Sets[/B] page.[*]Click [B]Finish[/B] on the [B]Completing the New Access Rule Wizard[/B] page.[/LIST]
[B]Configure the front-end ISA firewall to use the RADIUS server[/B]

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:

[LIST=1][*]At the front-end ISA firewall, open the ISA firewall console and expand the server name, then expand the [B]Configuration[/B] node.[*]Click the [B]General[/B] node. In the [B]Details[/B] pane, click the [B]Define RADIUS Servers[/B] link.[*]In [B]RADIUS Servers[/B] dialog box, click the [B]Add[/B] button.[*]In the [B]Add RADIUS Server[/B] dialog box, enter the IP address of the IAS server in the [B]Server name[/B] text box. In this example, the IP address of the IAS server is [B]10.0.0.2[/B]. Enter an optional description in the [B]Server description [/B]text box. Click the [B]Change [/B]button.[*]In the [B]Shared Secret[/B] 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 [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0341148306718594.jpg[/IMG]
[B]Figure 18[/B][/INDENT]
[LIST=1][*]Put a checkmark in the [B]Always use message authenticator[/B] checkbox and click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0361148306962688.jpg[/IMG]
[B]Figure 19[/B][/INDENT]
[LIST=1][*]Click [B]OK [/B]in the [B]RADIUS Servers[/B] dialog box.[/LIST]
[B]Configure the Web Publishing Rule on the front-end ISA Firewall to use RADIUS authentication and Forward Basic Credentials to the Web Server[/B]

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 [I]before[/I] 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:

[LIST=1][*]In the ISA firewall console on the front-end ISA firewall, expand the server name and then click the [B]Firewall Policy[/B] node.[*]On the [B]Firewall Policy[/B] node, double click the Web Publishing Rule you created for publish the DMZ Web server.[*]In the [B]Properties[/B] dialog box for the Web Publishing Rule, click the [B]Listener[/B] tab.[*]On the [B]Listener[/B] tab, click the [B]Properties[/B] button.[*]In the Listener’s [B]Properties[/B] dialog box, click the [B]Preferences[/B] tab.[*]On the [B]Preferences[/B] tab, click the [B]Authentication[/B] button.[*]In the [B]Authentication[/B] dialog box, remove checkmarks from other authentication methods. Put a checkmark in the [B]RADIUS[/B] checkbox. Put a checkmark in the [B]Require all users to authenticate [/B]checkbox. Click the [B]Select Domain[/B] button.[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0381148306962688.jpg[/IMG]
[B]Figure 20[/B][/INDENT]
[LIST=1][*]In the [B]Select Domain[/B] dialog box, enter the name of the corporate network user domain. In this example our internal user domain is named [B]msfirewall.org[/B], so we’ll enter [B]MSFIREWALL[/B] in the [B]Domain Name [/B]text box. Click [B]OK[/B][/LIST]
[INDENT] [B][IMG]http://www.isaserver.org/img/upl/image0401148306962688.jpg[/IMG]
Figure 21[/B][/INDENT]
[LIST=1][*]Click [B]OK[/B] in the [B]Authentication[/B] dialog box.[*]Click [B]OK[/B] in the Listener’s [B]Properties[/B] dialog box.[*]Click the [B]Users[/B] tab in the Web Publishing Rule’s [B]Properties[/B] dialog box.[*]Pub a checkmark in the [B]Forward Basic authentication credentials (Basic delegation)[/B] checkbox. Click [B]OK[/B].[/LIST]
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0421148307212734.jpg[/IMG]
[B]Figure 22[/B][/INDENT]
[LIST=1][*]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]
Our firewall policy looks like that in the figure below.
[INDENT] [IMG]http://www.isaserver.org/img/upl/image0441148307212734.jpg[/IMG]
[B]Figure 23[/B][/INDENT][B]Test the solution[/B]

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 [B]OK[/B]. 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 [B]Security[/B] tab in the [B]Properties[/B] 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.
[B]Summary[/B]

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.

[/LEFT]