Allowing Intradomain Communications through the ISA Firewall (2004)

Allowing Intradomain Communications through the ISA Firewall (2004)

By Thomas W Shinder MD, MVP

Got questions? Discuss this article over at
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=29;t=000046

The new ISA firewall’s enhanced support for directly attached DMZs has led to a lot of questions on how to allow intradomain communications through the ISA firewall from one network to another. This is a great question because you can now create multiple directly attached perimeter networks and allow controlled access to and from those perimeter networks. You can now safely put domain member machines on these DMZ segments to support a variety of new scenarios, such as dedicated network services segments that enforce domain segmentation.

For example, you might want to put an Internet facing Exchange Server or an inbound authenticating SMTP relay on a network services segment. In order to take advantage of the user database in the Active Directory, you need to join these machines to the Active Directory domain on the Internal network. Since the Internal network domain controllers are located on a network controlled by the ISA firewall, you need to configure the ISA firewall to allow the protocols required for intradomain communications.

Note that we don’t “open ports” on the ISA firewall. The term “open ports” has its roots in simple packet filter based hardware firewalls. Since the ISA firewall is protocol aware, it can perform stateful filtering and stateful application layer inspection on all communications moving through the firewall. I highly recommend that you do not put your trust in only a simple packet filter hardware firewall to protect your critical corporate resources.

The basic network configuration used in this example is seen in the figure below.

Table 1 shows the protocols required for intradomain communications, as well as other details included in an Access Rule we will create to support these communications.

Table 1: Protocols Required for Intradomain Communications

Name	Member Server -> Internal DC
Action	Allow
Protocols	ADLogon/DirRep* Direct Host (TCP 445) DNS Kerberos-Adm(UDP) Kerberos-Sec(TCP) Kerberos-Sec(UDP) LDAP (TCP) LDAP (UDP) LDAP GC (Global Catalog) RPC Endpoint Mapper (TCP 135)* NTP Ping

From

DMZ Member Server

Internal Network DC

DMZ Member Server

Users

All

Schedule

Always

Content Types

All content types

*ADLogon/DirRep

:
Primary Connection: 50000 TCP Outbound (requires RPC key set on the back-end Exchange Server)

**Direct Host

:
Primary Connection: 445 TCP Outbound (required to demonstrate an issue discussed in this article

***RPC Endpoint Mapper

Primary Connection: 135 TCP Outbound (required to demonstrate an issue discussed in this article)

RPC services configure themselves in the Registry with a universally unique identifier (UUID), which is similar in function to a globally unique identifier (GUID). RPC UUIDs are well-known identifiers (at least to RPC services), and are unique for each service.

When an RPC service starts, it obtains an unused high or ephemeral port, and registers that port with the the RPC service’s UUID. Some services choose a random high port while others try to always use the same high port if that port is not in use. The high port assignment is static for the lifetime of the service and chances only after the machine or service is restarted.

When a client communicates with an RPC service, it doesn’t know in advance which high port the service is using. Instead, the RPC client application establishes a connection to the server’s RPC portmapper (endpoint mapper) service (on TCP 135) and requests the service it wants by using the service’s specific UUID. The RPC endpoint mapper returns the corresponding high port number to the client and closes the connection endpoint mapper connection.

Finally, the client makes a new connection to the server, using the high port number it received from the endpoint mapper.

Because it’s impossible to know in advance which port an RPC service will use, the firewall needs to permit all high ports through.

We want to limit the ports required for RPC to a single port. This allows us to know in advance what port to use and configure on the firewall. Otherwise, we would need to allow all high ports from the DMZ to the Internal network. We can do this by making a Registry change on each domain controller. The Registry Key is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

Note:

We actually do not need to do this, as the ISA firewall’s RPC filter can dynamically control port access. The RPC filter listens to the RPC negotiations and then dynamically opens the required high port. However, I prefer to set the port manually as it makes it a bit easier to analyze the logs and track the RPC communications moving between the DMZ segment and the Internal network. If the administrative overhead of setting a specific high port for RPC communications is too high, then you can take advantage of the RPC filter and not worry about it. This is what I mean by the ISA firewall doesn’t “open ports” – the ISA firewall actually understands the protocols required.

You need to add a DWORD value named TCP/IP Port and set the value to the port you want to use. You’ll need to carry out this procedure on each of the domain controllers in your domain.

Perform the following steps on each of the domain controllers in your domain to change the RPC replication port to 50000:

Click Start and click Run. In the Open text box enter Regedit and click OK.
Go to the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

Click the Edit menu and point to New. Click DWORD Value.

Rename the entry from New Value #1 to TCP/IP Port, then double click the entry.

In the Edit DWORD Value dialog box, select the Decimal option. Enter 50000 in the Value data text box. Click OK.

Restart the domain controller.

The ISA firewall allows you to control the route relationship between any two Networks. In this example we will use a ROUTE relationship between the DMZ and the Internal network. Note that when you apply a Network Template to create a DMZ segment, the default route relationship is set as NAT. While there are some minimal advantages to using a NAT relationship, they are outweighed by the limitations they impose in this scenario. If you used a Network Template, make sure to change the Network Rule that controls communications between the DMZ and Internal network to ROUTE.

In the following example we create a rule allowing intradomain communications between a single member server in the DMZ and a single domain controller on the Internal Network. I’m using this scenario for simplicities sake, but you are by no means limited to allowing communications between single servers.

For example, you might have several member server machines on the DMZ and multiple domain controllers on the Internal network. In this case, instead of creating computer objects representing single machines, you would create a Computer Set for the DMZ member servers and another Computer Set for the Internal Network domain controllers. You then use the Computer Sets to control the Source and Destination locations for the intradomain communications rule.

Note:

In the following exercise you will create two Protocol Definitions that are not required since there are built in Protocol Definitions to support our requirements. However, we will create these Protocol Definitions to illustrate some important points that I’ll discuss at the end of the article.

Perform the following steps to create the intradomain communications rule that will allow machines in the DMZ segment to communicate with domain controllers on the Internal network:

In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click the Firewall Policy node.
In the Firewall Policy node, click the Tasks tab on 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 will call the rule

Member Server –> Internal DC. Click Next.

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

In the This rule applies to list, select the Selected protocols option. Click the Add button.

In the Add Protocols dialog box, click the All Protocols folder. Double click the following protocols:

DNS

Kerberos-Adm (UDP)

Kerberos-Sec (TCP)

Kerberos-Sec (UDP)

LDAP

LDAP (UDP)

LDAP GC (Global Catalog)

NTP (UDP)

Ping

Click the New menu and click Protocol.
On the Welcome to the New Protocol Definition Wizard page, enter ADLogon/DirRep in the Protocol Definition name text box. Click Next.
On the Primary Connection Information page, click New.
On the New/Edit Protocol Connection page, select TCP in the Protocol type list. Select Outbound in the Direction list. In the Port Range frame, enter 50000 in the From and To text boxes. Click OK.

Click Next on the Primary Connection Information page.
Select the No option on the Secondary Connections page.
Click Finish on the Completing the New Protocol Definition Wizard page.
Click the New menu and click Protocol.
On the Welcome to the New Protocol Definition Wizard page, enter Direct Host in the Protocol Definition name text box. Click Next.
On the Primary Connection Information page, click New.
On the New/Edit Protocol Connection page, select TCP in the Protocol type list. Select Outbound in the Direction list. In the Port Range frame, enter 445 in the From and To text boxes. Click OK.
Click Next on the Primary Connection Information page.

Select the No option on the Secondary Connections page.
Click Finish on the Completing the New Protocol Definition Wizard page.
Click the New menu and click Protocol.
On the Welcome to the New Protocol Definition Wizard page, enter RPC Endpoint Mapper (TCP 135) in the Protocol Definition name text box. Click Next.
On the Primary Connection Information page, click New.
On the New/Edit Protocol Connection page, select TCP in the Protocol type list. Select Outbound in the Direction list. In the Port Range frame, enter 135 in the From and To text boxes. Click OK.
Click Next on the Primary Connection Information page.
Select the No option on the Secondary Connections page.
Click Finish on the Completing the New Protocol Definition Wizard page.
In the Add Protocols dialog box, click the User-Defined folder. Double click the ADLogon/DirRep, Direct Access and RPC Endpoint Mapper (TCP 135) protocols. Click Close.

Click Next on the Protocols page.
On the Access Rule Sources page, click Add.
In the Add Network Entities dialog box, click the New menu. Click Computer.
In the New Computer Rule Element dialog box, enter DMZ Member Server in the Name text box. Enter 172.16.0.2 in the Computer IP Address text box. Click OK.

In the Add Network Entities dialog box, click the New menu. Click Computer.
In the New Computer Rule Element dialog box, enter Internal DC in the Name text box. Enter 10.0.0.2 in the Computer IP Address text box. Click OK.

In the Add Network Entities dialog box, click the Computers folder. Double click the DMZ Member Server entry. Click Close.
Click Next on the Access Rule Sources page.
On the Access Rule Destinations page, click Add.
In the Add Network Entities dialog box, click the Computers folder. Double click the Internal DC entry. Click Close.
Click Next on the Access Rule Destinations page.
On the User Sets page, accept the default entry, All Users, and click Next.
Review the settings on the Completing the New Access Rule Wizard page and click Finish.
Click Apply to save the changes and update the firewall policy.
Click OK in the Apply New Configuration dialog box.

You can test the rule by joining a machine in the DMZ to the Active Directory domain on the Internal network and then logging into the domain after joining the domain. Note that this rule doesn’t allow all protocols through from the member servers to the domain controllers. You will need to create other Access Rules for other protocols, and additional Access Rules for communications to other machines on other networks.

The figure below shows some log file entries for communications between the member server and the domain controller on the Internal network. There are some entries in the log file that highlight some undocumented issues with the ISA firewall and its configuration.

Notice on the first line the connection to TCP port 445. In the protocol column, the name of the protocol is Microsoft CIFS (TCP) and not Direct Host, which is the name of the Protocol Definition we created for that protocol. The reason for this is that the built-in protocols will be used preferentially in the event that you create a Protocol Definition that has the same settings as a built-in Protocol Definition.

In the fifth line from the top you’ll see a connection made to TCP port 135. The Protocol column lists this as the RCP (all interfaces) protocol, instead of the RCP Endpoint Mapper protocol that we created. Again, the reason for this is that there is a built-in RPC (all interfaces) protocol and its used preferentially over the one we created. In addition, this built-in Protocol Definition automatically binds the ISA firewall’s RPC filter, which adds a significant amount of protection for the RPC communications.

We do see one of our custom Protocol Definitions being used in the fourth line from the top. The ADLogon/DirRep Protocol Definition is used to communicate on the custom RPC port we configured in the Registry of the domain controller.

Test Your Knowledge

What TCP port number is used for the RPC endpoint mapper?
When using an ISA firewall, do you need to enforce a specific high port number for the Active Directory RPC services to listen on?
Does the ISA firewall “open ports” or does the ISA firewall understand the actual protocols required?
Why did we not need to create the Protocol Definitions for Direct Host and RPC Endpoint Mapper protocols?
Would the rule we created for intradomain communications work for Windows NT DC based intradomain communications?

Find the answers to these questions at the discussion link: http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=29;t=000046

Summary

In this article we went over the procedures and protocols required to allow intradomain communication through the ISA firewall. We also discussed some issues regarding built-in Protocol Definitions and how they interact with Protocol Definitions you create yourself. We ended up this article by joining a machine in the DMZ to the domain and then logging on using a domain account.

I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=29;t=000046 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy.