ISA Server Branch Office Policies Best Practices: ISA Server co-location with a domain controller

Authors:

Jim Harrison - Program Manager, Forefront Edge

Contributors and Tech Reviewers:

Yuri Diogenes - Security Support Engineer, CSS Security

Mohit Saxena - Security Tech Lead, CSS Security

Nathan Bigman - Content Publishing Manager, Forefront Edge

Rayne Wiselman - Content Writer, Forefront Edge

Abstract

The Windows Server Branch Office deployment scenario has quickly become a very popular Windows deployment following the release of Windows Server 2003 R2. Many customer and solution providers alike have demonstrated that the concept of a drop-in, self-protecting, general-purpose server similar to, but more functional and flexible than Small Business Server was not only desired, but a business-critical need. ISA Server 2004 and ISA Server 2006 have each been employed to protect the one-server solution and take advantage of three features that ISA Server 2004 Service Pack 2 brought into play; BITS caching, DiffServ and HTTP compression & caching. Adding these three features to Windows 2003 R2 Distributed File System Remote Differential Compression creates a very compelling, network-efficient Windows Server deployment. ISA Server 2006 also improved its configuration storage mechanisms to make more efficient use of limited WAN bandwidth.

Unfortunately, the difficulties involved with understanding and mapping domain and custom application traffic has caused many customers and solution providers to deploy ISA Server in the Branch Office server using a very insecure traffic profile using an “allow all from anywhere to anywhere” rule, thereby seriously weakening the security of the Branch Office and potentially the overall network.

Goals

This whitepaper will focus on defining the traffic profile, proper ISA network configuration and ISA policies required to securely support traffic used during common domain activity in accordance with ISA Server policy best practices as defined in ref (a) and ref (b). These profiles defined will support the traffic generated during:

  • Domain join / disjoin

  • User and machine logon / logoff

  • Active Directory replication

  • ISA Server storage access and replication

  • ISA Server remote management

Non-Goals

Other aspects of domain controller activity that is generally not relevant to most common Branch Office scenarios:

  • Domain create / destroy

  • Domain trust create / destroy

  • Forest create / destroy

  • Forest trust create / destroy

  • Custom applications

  • Single-DC child domains in the Branch Office

Branch Office Deployment Overview

ISA Server is typically deployed on the branch office server to accomplish one or more of three primary goals:

  1. General Internet access for the branch users (may be chained to the Central Office)

  2. Web caching and HTTP traffic optimization

  3. Firewall services

When ISA Server also performs as a firewall, special consideration must be given to the network definition applied to the traffic which flows across the WAN. In particular, several domain protocols cannot successfully traverse NAT relationships. As mentioned in Domain Controller Traffic Profile, RPC and DCOM are problematic protocols for firewalls and ISA Server is no exception. In fact, ref (i) was written to help illustrate the problems inherent with DCOM across ISA boundaries.

If the group designing the Branch Office server deployment lacks a full understanding of the traffic profile for the domain and LOB applications, the difficult in determining the this profile frequently results in the team defining an “allow all” rule to and across the Branch office server. Needless to say, this violates the most basic of ISA Server traffic policy best practices; creating the smallest possible attack surface.

If ISA Server Enterprise Edition is deployed on the branch office server, consideration must also be given to the inclusion, context and deployment of ISA Server Configuration Storage Services on that machine. Actual deployment of CSS on a domain controller is addressed in ref (i).

Branch Office Scenarios

Branch office servers are typically deployed with the end-goal of extending Central Office domain and application services across slow WAN links while simultaneously minimizing the traffic that must cross that link. Branch Office deployments tend to sift down to two basic scenarios; single-homed and multi-homed servers. In either case, the Branch Office may connect to the Internet directly or across the WAN.

Single-homed Server

Single-homed servers will either have a direct connection to the Central Office via dedicated line or an external VPN termination, but the Branch Office server does not perform traffic routing between the Branch and Central Office. ISA policies in support of domain traffic are comparatively simple in this scenario, since they need only be concerned with traffic between the ISA and the remote DC/GC and between the Branch Office hosts and ISA.

Cc891503.4498b602-ef03-4a56-a8cb-2a3daa41ab26(en-us,TechNet.10).gif

Figure 1

Multi-homed Server

Multi-homed servers may be either direct- or VPN-connected, but in either case they will act as a router between the Branch and Central Office networks. One point that bears careful consideration; when a multi-homed Branch Office server connects to the Central Office through a VPN tunnel, this creates some complicated traffic flow definition problems that must be considered carefully when defining the ISA polices. Luckily, ISA Server 2006 Enterprise Edition provides the Branch Office Connection Wizard to help you manage that process.

Cc891503.937fc440-af3a-4a62-b1b2-bb1a2b1b7cd0(en-us,TechNet.10).gif

Figure 2

Direct Route (Leased Line)

Because of the way ISA handles traffic across the External network, we can’t use the edge templates in this scenario. Instead, what we must do is configure ISA using the 3-Leg Perimeter network template and assign the Internal network to the Branch Office and the Perimeter Network to the Central Office. Doing so has the effect of “turning ISA 90 degrees” in the network context so that the External network is left unused. Because the default network rules created by the network template wizard define a NAT relationship between the Internal and Perimeter networks, we must change the network rules so that they define a route relationship between the Internal and Perimeter networks.

Site-to-Site VPN

The best way to build this scenario is to use the Branch Office wizard found at %ProgramFiles%\Microsoft ISA Server\AppCfgWzd.exe using the template created from the Central Office Site-to-Site VPN terminating ISA. You should note that before you run the wizard at the Branch office ISA, you must perform a complete backup (export) of the existing ISA configuration. The Branch Office wizard makes changes to system policies that cannot be reverted in the management UI. Should the wizard fail after making these changes, the only way to revert those changes is by performing a complete policy restore (replace). If you haven’t made a complete backup, and the wizard fails to complete its policy changes, you will have to remove and reinstall ISA Server on the machine.

Configuration Storage Servers

While it may be tempting to deploy CSS to each branch in an effort to minimize storage traffic between the Branch Office and the Central Office, you should avoid this unless absolutely necessary (separate Enterprise in each BO, for example). Once the Enterprise policies are in place and you don’t incur frequent changes to the Enterprise or array policies, the amount of traffic between ISA and the CSS is negligible. By default, ISA polls CSS for changes every 15 seconds. Once your policy changes have settled in, you can configure the Branch Office array such that it only polls CSS for changes much less often. Note that any time changes are made each affected ISA server is notified by the management console to refresh the settings from storage.

Should you decide to deploy CSS in the Branch Office, you *must* ensure that you adjust the system policies that control communication between all related ISA Enterprise servers are correctly configured to allow replication and CSS management access. Those system policies are defined in table 1.

Cc891503.149e0d83-0f40-4733-b69d-b98a794daf3b(en-us,TechNet.10).gif

Table 1

The simplest way to manage these policies is to ensure that all CSS servers in the Enterprise are included in the following Enterprise elements:

  • Enterprise Remote Management Computers – this set must contain all hosts which are used to manage the Enterprise.

  • Enterprise Configuration Storage Servers – this domain name set must be populated with the fully-qualified name of each CSS deployed in the ISA Enterprise

  • Replicate Configuration Storage Servers – this address set must include the IP addresses of each CSS deployed in the ISA Enterprise

You will have to manage these lists yourself; ISA installation and the management MMC may not automatically update these sets as servers and arrays are added and deleted.

Hardening the Server

There are plenty of server administrators who still subscribe to the “kill unneeded services” methodology of server hardening. Let’s make it abundantly clear right now that the only supported method for hardening an ISA server on Windows 2003 is through the use of the Windows Security Configuration wizard in conjunction with the proper ISA Server template. If you have to deploy ISA 2004 on Windows 2000 (not a great combination, comparatively), then you must follow reference (n). Manually changing service configurations other than as described in these references is not supported at all. Properly-configured ISA Server policies provide the appropriate protection from network-based attacks, and so long as you don’t use the ISA Server as a workstation, you can minimize the application-based threats. References (n) and (o) cover the details of ISA hardening.

Branch Office as a Child Domain

While it might be tempting to define each branch office as a child domain of the Central Office domain for any number of reasons, this methodology is unsupported. Since the typical Branch Office deployment provides a single domain controller, creating child domains for each Branch Office would create service startup failures for the Branch Office server applications; especially ISA services. Thus, if the server were to be rebooted unexpectedly, it might be rendered unavailable until someone accessed it locally from the console. If the server is unattended when this occurs, it could be a weekend (or longer, depending on how remote this office may be) before this server could be brought back online. Instead, you should create an OU in the Central Office domain for each branch office and manage your Active Directory policies that way.

Domain Controller Traffic Profile

Domain controllers use a well-defined set of protocols to perform various tasks and functions. These include well-known items such as ICMP (ping), LDAP and DNS as well as less well-known protocols such as NetBIOS Session and NetBIOS Datagram. To help illustrate this process, ref (c) provides an excellent description of the most common domain controller activities; machine startup and user logon, effectively illustrating the use of several protocols involved in these two processes. Ref (d) provides a complete listing of all protocols used by various Windows servers and services. Between them, they form the basis of the core knowledge required to understand how to construct secure, reliable ISA policies for domain controller communications.

Unfortunately for the firewall administrator, domain communications and some MMC mechanisms rely on protocols such as RPC and DCOM that challenge the goal of creating secure firewall policies. This, coupled with the NAT relationship created by most firewalls, prompted the publication of refs (e), (f), (g), (h) and (k).

Our primary reference for this part of the discussion is ref (d). If you eliminate the application-specific protocols, such as SMTP, POP3 and others, it’s clear that the domain traffic profile consists of a pretty well-defined set of protocols. It’s when we include ISA and network service protocols and the various LOB applications that this set grows considerably.

Cc891503.690d66bc-f34b-46ca-b466-a0309f65135c(en-us,TechNet.10).gif

Table 2

Notes:

  1. Dyn = 1025-65535 on WS03 and earlier; 49152-65536 on Vista and later

  2. Nego = connection port is negotiated between client/server pair

  3. Only required if the server is configured for LDAP-SSL

  4. RFC specifies that NTP clients should use source UDP:123, but Windows time uses dynamic ports

  5. Secondary connection transport / protocols are negotiated in the control channel according to client application Winsock usage

  6. Firewall Web Management is used by OEM to provide non-MMC management of ISA Server

  7. Remote management of ISA Server using the ISA Management MMC involves the use of RPC mechanisms to monitor ISA service status

  8. ISA Server installation creates an SMB connection to the CSS to validate the credentials chosen by the user

ISA System Policies for Domain Traffic

In order to preserve the domain controller functionality for the server where ISA operates, the domain services need to have access to the network during ISA services startup. Since it’s the responsibility of the ISA Server System Policies to handle traffic when the firewall service is unavailable (as during startup), we need to define the proper traffic profile using the system policies. By default, the following default policy groups and rules related to domain controller traffic exist with their settings as indicated in table 3:

Cc891503.65ec28e3-8d2f-4efc-bdb7-76c86089407e(en-us,TechNet.10).gif

Table 3

There are quite a few more system policies, and some of them even duplicate some of these rules because of their association with specific functionality, but these are what we’ll use to allow server communication with remote domain controllers. One disadvantage with the System policy management UI is that it restricts the changes you can make to these rules. In the case of the policies defined above, you can only change the destination (“To”) portion of the rule; you cannot change the source (“From”). As such, we’ll have to define array-level policies that mimic these system policies so as to allow domain-related traffic to flow in the proper directions. Depending on the complexity of the branch office scenario where you deploy the ISA/DC server, you may have to adjust the rule elements used in the following examples. For instance, if you have another Branch Office connected to the Central Office through an upstream Branch Office, you’ll have to consider that in your policy rule “From” configuration. There are four basic traffic flow contexts that we have to accommodate for each deployment scenario (single- or multi-homed):

  • CSS traffic between the Branch Office ISA/DC/CSS and the Central Office CSS

  • Domain traffic between the ISA/DC and the Central Office DC/GC

  • Domain traffic between the Branch Office hosts and the ISA/DC

  • Domain traffic between the Branch Office hosts and the Central Office DC/GC

Best practices for the ISA Policies

Unlike the documents provided in references (a) and (b), this section only deals with the firewall policies in the context of “least privilege”. How you arrange your policies is well discussed in those articles.

Functionally Restrictive Policies

  1. Represent the smallest possible protocol set. While this seems like an obvious statement, what it really means is that you as the firewall administrator charged with controlling traffic between two separate locations must have a complete knowledge of the traffic generated by your organization’s applications and services as well as that created by the network structure. This requires that you work very closely with the network and application administrators and developers so that the network traffic picture is clear. Once you have this defined, you can start limit your policies to a clearly defined set of protocols.

  2. Restrict the policies to a clearly-defined set of hosts. This is accomplished by limiting the source and destination criteria of each rule. For instance, your firewall policies are much more secure if they allow DC-oriented traffic only from known hosts in a specific network, such as domain controllers, than it is to allow it from the entire network. While it’s true that such heavily-restrictive firewall policies increase the management overhead, the results are frequently worth the trouble.

  3. Limit the policies to users and/or groups whenever possible. This may require that you configure all browsers to use the proxy, or that you deploy the Firewall Client. You will probably note that in all of the domain traffic policy examples, there is no mention of limitation to users or groups. This is because much of the traffic generated by domain-related client services is handled in kernel mode. ISA cannot authenticate traffic that is sourced from the client in kernel mode and so those rules must be anonymous.

Resolving the conflicts

As functionality and security best practices goals are frequently at odds, only the business and security managers in the organization can decide how best to resolve the conflicts. The point of this discussion is to help the ISA administrators clearly define and control domain-related traffic between their central and branch offices. The use of “allow all” policies to “make life easier” is just as likely to make life harder when some custom-ported malware makes its way into your environment.

Site-to-Site VPN Connections

One thing to note as you gather all the IP ranges, subnets and host IPs to limit your policies to only known entities; the two ISA servers which comprise the two endpoints of a site-to-site communicate to each other and hosts on the remote side of the VPN connection using the IP addresses they assign each other as part of the VPN connection. For instance, let’s examine the following diagram:

Cc891503.a4c3e8dd-9892-43d7-8b8f-28a5719a4cb0(en-us,TechNet.10).gif

Figure 2

When you create a Site-to-Site VPN, the two endpoints will generally create two separate connections; one from each ISA server to the other. This behavior results in each ISA owning two IP addresses related to the tunnel.

The Central Office ISA includes IP addresses within the 10.10.255.0 - 10.10.255.255 range for the Internal network, while the Branch Office ISA includes the address range 10.10.254.0 - 10.10.254.255 range for its Internal network. The Site-to-Site VPN connection between them uses an address range of 10.10.0.0 - 10.10.0.7. Since there are only six functional addresses within that range (we don’t need or even use them all), we’ve assigned 10.10.0.1 and 10.10.0.2 to the Central Office ISA and 10.10.0.3 and 10.10.0.4 to the Branch Office ISA. The routing tables in each ISA server are automatically updated during the VPN connection process to include the VPN tunnel IP range and the RRAS service in each ISA server manages the routing to the opposite networks behind each ISA.

When the Branch Office ISA needs to communicate with a host in the Central Office Internal network, the traffic will be seen by the Central Office host as coming from 10.10.0.3 (or 10.10.0.4); the VPN tunnel address for the Branch Office ISA server. Likewise, when the two ISA Servers communicate with each other, they will use their VPN tunnel IP address to do so. Since the network relationship between Internal and “Remote” for each ISA Server must be “Route” (NAT breaks domain traffic, remember?), the traffic crossing the VPN tunnel from the ISA Internal network will use the original host’s source IP.

Minimum Policies for Single-homed ISA/DC Branch Office

The directions which follow represent the supported methods for allowing domain traffic within and between the Branch Office and Central Office networks. While these policies use entire network objects to maintain simplicity of the examples, they can and should be made much more secure to provide a “least access” policy model as discussed above. In many cases, testing will have to be performed on-site or (ideally) within a lab environment to determine the correct configuration. In any case, you must never apply an “allow all from anywhere to anywhere” policy.

CSS traffic between the Branch Office ISA/DC/CSS and the Central Office CSS

If you opted to deploy a CSS at the local branch as a replica of the Central Office CSS, then you’ll also need to configure the proper system policies. The simplest way to do this is to update the policy elements that determine the source and destination of the relevant traffic as described in Configuration Storage Servers.

Domain traffic between the Branch Office ISA/DC and the Central Office DC/GC

System Policies

Because all networks are “internal” to ISA, the default policies meet this requirement.

Enterprise or Array Policies

Because this traffic is handled by system policies, no Array- or Enterprise-level policies are required.

Domain traffic between the Branch Office hosts and the Branch Office ISA/DC

System Policies

System policies cannot be used for this purpose.

Enterprise or Array Policies

To enable domain traffic between the Branch Office hosts and the ISA/DC server, we need to mimic the system policies outlined above, but with a few changes to allow traffic to the ISA/DC server, rather than from it. The simplest policy would appear as:

Cc891503.bfb2ddf1-d322-4200-9e46-a04e233ae479(en-us,TechNet.10).gif

Table 4

Domain traffic between the Branch Office hosts and the Central Office DC/GC

Because ISA does not support traffic routing in a single-network template and the Branch Office hosts have access to the Central office network without routing through the ISA/DC, ISA policies can have no effect on this domain traffic.

Minimum Policies for a Multi-homed ISA/DC Branch Office

CSS traffic between the Branch Office ISA/DC/CSS and the Central Office CSS

If you opted to deploy a CSS at the local branch as a replica of the Central Office CSS, then you’ll also need to enable the proper system policies. The simplest way to do this is to change the policy elements that determine the source and destination of the relevant traffic as described in Configuration Storage Servers. Note that if you have configured ISA using the Branch Office Configuration wizard, you no longer have a local CSS instance.

Domain traffic between the Branch Office ISA/DC and the Central Office DC/GC

System Policies for Site-to-Site VPN

If the ISA Server was joined to the domain as part of the Branch Office Configuration wizard action, the system policies were updated to allow this traffic. Otherwise, you should make the changes as indicated in bold:

Cc891503.74f51be9-5a7e-449c-b6c9-44bc43268071(en-us,TechNet.10).gif

Table 5

System Policies for Direct Route

Because the Central Office resides on the Perimeter network, we must change the system policies that apply to domain communications to appear as shown below (changes in bold):

Cc891503.d95b50cc-23a2-4e90-b538-af4542df7cc7(en-us,TechNet.10).gif

Table 6

Enterprise or Array Policies

No Enterprise or Array policies are required if the System policies are changed as indicated above.

Domain traffic between the Branch Office hosts and the Branch Office ISA/DC

System Policies

System policies cannot be used for this purpose.

Enterprise or Array Policies

To enable domain traffic between the Branch Office hosts and the ISA/DC server, we need to mimic the system policies outlined above, but with a few changes to allow traffic to the ISA/DC server, rather than from it. The simplest policy would appear as:

Cc891503.5e4ba121-de5e-4a92-96d5-2322a0a2b39f(en-us,TechNet.10).gif

Table 7

Domain traffic between the Branch Office hosts and the Central Office DC/GC

System Policies

System policies cannot be used for this purpose.

Enterprise or Array Policies

The following policies are required to meet this need:

Cc891503.1985b187-364c-48da-b38c-2c2d8159a1e3(en-us,TechNet.10).gif

Table 8

References

A

Microsoft TechNet article; Best Practices Firewall Policy for ISA Server 2004

B

Microsoft TechNet article set; Best Practices Firewall Policy for ISA Server 2006

C

Microsoft TechNet article; Windows 2000 Startup and Logon Traffic Analysis

D

Microsoft Knowledgebase article 832017; Service overview and network port requirements for the Windows Server system

E

Microsoft Knowledgebase article 154596; How to configure RPC dynamic port allocation to work with firewalls

F

Microsoft Knowledgebase article 224196; Restricting Active Directory replication traffic and client RPC traffic to a specific port

G

Microsoft Knowledgebase article 179442; How to configure a firewall for domains and trusts

H

Microsoft Knowledgebase article 329807; ISA Server Does Not Support Domain Members In Perimeter Network

I

ISABlog posting; RPC Filter and "Enable strict RPC compliance"

J

ISABlog posting; Installing ISA Server 2006 Configuration Storage Server on a Domain Controller

K

Microsoft TechNet article; Troubleshooting Unsupported Configurations in ISA Server (Configuring Intradomain Communications with a NAT Relationship)

L

Microsoft TechNet article: Branch Office VPN Connectivity Wizard

M

Microsoft TechNet article ISA Server System Policy

N

Microsoft TechNet article Hardening the Windows Infrastructure on the ISA Server 2004 Computer

O

Microsoft TechNet article Security Guide for ISA Server 2006