Deployment Guidelines for ISA Server 2004 Enterprise Edition

Article
02/29/2008

This document describes how to plan a deployment of Microsoft® Internet Security and Acceleration (ISA) Server 2004 Enterprise Edition. Installation of ISA Server in an enterprise requires awareness of the components comprising ISA Server, and how they communicate across an enterprise.

This document will be updated over the coming months, and will then include descriptions of specific deployment topologies.

About This Document

This document is primarily conceptual. It provides recommendations on how to deploy ISA Server with the topologies encountered in many enterprises. The document has these main topics:

ISA Server Components. A discussion of the components that comprise ISA Server Enterprise Edition.
Deployment Planning. A discussion of how to assess the number and location of Configuration Storage servers and ISA Server arrays needed for your deployment.
SQL Database Deployment Guidelines. A discussion of Microsoft SQL Server™ database deployment.
Disaster Recovery. A discussion providing steps for disaster recovery.

Although this document does not provide procedures, there are many procedural documents available on the ISA Server 2004 Guidance page (https://www.microsoft.com), which will assist you in deploying ISA Server after you decide on a deployment approach:

Intended Audience

This document is intended for network administrators, network security professionals, independent software vendors, and others who plan and execute the deployment of ISA Server.

ISA Server Components

To deploy ISA Server most effectively, you should be aware of the ISA Server components and how they interact. This is particularly true if you are designing a deployment from its inception. If you are modifying a deployment or if you are only involved in the deployment on a particular level, such as an array administrator installing a new ISA Server array in a branch, you may want to review specific portions of this document relating to your tasks.

ISA Server 2004 Enterprise Edition is composed of the following components:

Configuration Storage server. For details, see Configuration Storage Server in this document.
ISA Server services. For details, see ISA Server Services in this document.
ISA Server Management. For details, see ISA Server Management in this document.
Additional components. Additional components (Advanced Logging, Firewall Client Share, and Message Screener) can be installed on separate computers. For a discussion of logging options, see Best Practices for Logging (www.microsoft.com). For a specific discussion about deployment considerations when using a central Microsoft SQL Server database for logging, see SQL Database Deployment Guidelines in this document.

The following figure illustrates the components.

As part of the installation process, you can install one or more of these installation components. Note that a Configuration Storage server must be available to install the ISA Server services component. This is because each computer running ISA Server services and ISA Server Management retrieves its configuration information from a Configuration Storage server.

Configuration Storage Server

A Configuration Storage server is a server on which the configuration for all the arrays in the enterprise is stored. This also includes the permissions settings for arrays, and reports. The Configuration Storage server uses Active Directory® Application Mode (ADAM) for storage. When you install the Configuration Storage server, you also automatically install ADAM on the computer. When you configure arrays in the enterprise, you are changing the information in the Configuration Storage server. At a later time, the ISA Server 2004 Enterprise Edition computers will access the Configuration Storage server to check whether there is any configuration change, and update their local storage (registry based) to reflect the recent changes in the enterprise.

There can be multiple Configuration Storage servers in the enterprise, each holding an exact replica of the enterprise configuration.

Each ISA Server computer has a local copy of its configuration that is a replica of the server’s configuration, which is located on the Configuration Storage server. Each array points to a specific Configuration Storage server from which it gets the updated configuration. You can also specify an alternate Configuration Storage server, which is used in case the first Configuration Storage server fails.

There are many considerations in planning how many Configuration Storage servers you require, where they should be located, and how they should be configured. Some of these are network speed, need for reliability, and the number of ISA Server array members that will connect to the Configuration Storage server. Deployment considerations are discussed in the topic Configuration Storage Server Deployment Guidelines in this document.

ISA Server Services

ISA Server services run the firewall, virtual private network (VPN), and caching functions of ISA Server. The computer running ISA Server services is connected to a Configuration Storage server, which stores the configuration information.

The computer running ISA Server services is the computer with the firewall, caching, and VPN functionality. By default, ISA Server Management is also installed on these computers. The configuration information displayed there is stored on the Configuration Storage server.

Computers running ISA Server services can be grouped in an array. Note that all computers grouped in an array must have the same:

Number of network adapters, connected to array-level networks with the same names.
Dial-up connections configured.
Time zone, with synchronized clocks (for logging).
Partitions (for logging).
Certificates installed on each array member.
Network services available to each array member, for example, Domain Name System (DNS), certificate revocation list (CRL) verification connectivity, and Active Directory connectivity.
Language version of ISA Server and Microsoft Windows Server™ 2003 installed, with the same locale set for the computer and for the user who is logged on.
Updates installed.
Domain and site configuration (or belong to a workgroup).

Determining the details of your array deployment depends on the number and distribution of the branches in your enterprise, your need to divide ISA Server functionalities between different arrays, your need for reliability (failover if an array member fails), and the load that has to be handled by the array members. Details of these considerations are provided in the topic Array Deployment Guidelines in this document.

ISA Server Management

ISA Server Management is the management console used to manage the enterprise and the array members. Using ISA Server Management, you connect to a specific Configuration Storage server to manage the enterprise.

When you decide where ISA Server Management will be used, you must consider the reliability and speed of the connection to the Configuration Storage server, your need for active monitoring of distant installations, and whether there are array-level administrators who will require management access. This is described in more detail in ISA Server Management Guidelines in this document.

Deployment Planning

When you are deploying ISA Server, you must consider the following factors to determine how many arrays, array members, and Configuration Storage servers you require, and how they should be distributed:

The number of clients that will connect to an array, either for access to resources on other networks including the Internet, or to access published servers.
The speed and reliability of connections between offices.
The need for redundancy and failover for critical operations.
The number of arrays you will be installing, which affects how many replicate Configuration Storage servers are needed.

Network Considerations

When you install ISA Server Enterprise Edition in an enterprise, you must consider how communication across the enterprise affects ISA Server performance. Specifically, you must consider:

Replication of storage data between geographically remote Configuration Storage servers. During the initial installation of a replicate Configuration Storage server, a relatively large amount of data is transferred. During normal operations, incremental amounts of data are transferred, but may use a significant portion of available bandwidth, particularly over a connection with limited capacity.

Note

For an initial replication over a slow link (less than 5 Mbps), you may want to choose to replicate from a Windows backup file, as described in Replicating a Large Enterprise Configuration Over Slow Links (www.microsoft.com).
Monitoring. Data is transferred from various ISA Server arrays in your enterprise to the computer from which you are monitoring the enterprise. Over a slow connection, we recommend that you manage ISA Server using a Terminal Services client, rather than ISA Server Management. This is discussed in ISA Server Management Guidelines in this document.
ISA Server array communication with the Configuration Storage server. In a scenario where the Configuration Storage server is not located in the same branch as the ISA Server array, there may be delays in updating the array from the Configuration Storage server, and vice versa. Note that the frequency with which an array checks the Configuration Storage server for updates can be configured on the Configuration Storage tab of the array properties. You can thereby balance the need to refresh the configuration data with the need to conserve bandwidth.
Reliability of the connection. If a connection is unreliable, and your branch ISA Server array loses connectivity to its remote Configuration Storage server, you will not be able to reconfigure that array to point to another Configuration Storage server, because you will not be able to connect ISA Server Management to the array. For this reason, you may want to have a local Configuration Storage server installed where there is an unreliable connection, or where continual access to array functionality is critical for a particular branch.
Network Load Balancing (NLB). If the IP address space in your organization is fragmented, it will impact ISA Server performance when NLB is used. We recommend that you try to keep your IP address space to less than 300 fragments. If you have more than 400 fragments, the NLB service may not start.
Network Topology Changes. If you plan to change the IP addresses of the ISA server computer internal network adapter, domain controller, Configuration Storage server, or DNS server in the Internal network, verify that the new addresses are part of the ISA Server Internal network before you make the address changes on the computers. This maintains critical connectivity, including connectivity between your ISA Server array and the Configuration Storage server. Without this connectivity, the array cannot update its configuration, preventing you from repairing the IP address range of the Internal network.

Communication Between Configuration Storage Servers

If you install a Configuration Storage server behind an ISA Server array (rather than on a computer running ISA Server services), or if you do not have a domain controller in the branch where the Configuration Storage server is installed, you must create access rules on the enterprise level to ensure that critical inter-branch communication is enabled.

For details about the rules, see the topic Creating Enterprise Policy for Branch Communication in the document Introduction to Branch Deployment of ISA Server 2004 Enterprise Edition (https://www.microsoft.com).

Configuration Storage Server Deployment Guidelines

If a Configuration Storage server fails, ISA Server Management will not provide access to any ISA Server functionality, because it requires a connection to a working Configuration Storage server. At the same time, the ISA Server 2004 computer will continue to provide firewall, VPN, and proxy services based on the last known configuration it received from the Configuration Storage server. However, you will not be able to monitor or change its configuration until the Configuration Storage server is restored, or until you connect the computer running ISA Server services and the ISA Server Management computer to a different Configuration Storage server in the enterprise.

For this reason, we make the following general recommendations about Configuration Storage server deployment. (Specific examples of how to apply these recommendations are provided in the deployment scenarios.) We recommend:

In your main office, install two Configuration Storage servers. Because these servers will be in a single network, they will easily replicate, and you will therefore have a reliable failover server.
Install a Configuration Storage server in each branch. If the branch has a fast connection to the main office or another branch, install the Configuration Storage server in the same ADAM site as that in the main office or other branch. If the connection is slow, install the branch replicate Configuration Storage server in a different ADAM site, as described in ISA Server Help. When you install your Configuration Storage servers across several ADAM sites, you can control the frequency with which replication takes place. By reducing the frequency, you reduce the use of bandwidth for Configuration Storage server communication. Other advantages of installing a Configuration Storage server in each branch are:
- You will conserve bandwidth. When an ISA Server array requires access to the Configuration Storage server, that communication uses some of the connection bandwidth. This can become significant in an enterprise if many ISA Server arrays refer to remote Configuration Storage servers. If the firewall can get that information from the local Configuration Storage server, that bandwidth use will not take place. The local Configuration Storage server will require some bandwidth to update its stored data, but this will take place only at the frequency you set across ADAM sites, and only for relatively small amounts of data.
- If your site-to-site VPN connection fails and it is that connection that provides ISA Server array connectivity to the Configuration Storage server, it will be difficult to troubleshoot the VPN connection, because you will not have ISA Server Management access to the array. If you have a local Configuration Storage server, you will be able to use ISA Server Management to troubleshoot the VPN connection.
In the most minimal deployment of Configuration Storage servers, assume one Configuration Storage server is needed for every 40 array members. (The number of arrays is not an issue.) This is based on the use of a 2 gigahertz (GHz) computer with 1 GB of memory.
If you have to conserve hardware, there are several actions you can take:
- Consider installing the Configuration Storage server on the domain controller in the branches, or on one of the computers running ISA Server services. While this is not the preferred configuration, it is supported and will allow you to have a better distribution of replicate Configuration Storage servers, while reducing the amount of required hardware.
- If necessary to conserve hardware, do not install Configuration Storage servers in hubs or branches that have a reliable, high-speed connection to the main office or branch where there is a Configuration Storage server. You may want to make an exception for a branch that has a critical function, such as a data center, or that requires absolute VPN connection reliability (because you will require connectivity to a Configuration Storage server to troubleshoot a VPN connection).
- If you can rely on the high-speed connection between one of the branches and the main office, you could use the Configuration Storage server in the branch as a backup and failover point, and not have two Configuration Storage servers in the main office.
- If necessary to conserve hardware, do not install Configuration Storage servers in branches that have a slow connection to another branch where there is a Configuration Storage server. In this case, you may also want to make an exception for a branch that has a critical function, such as a data center, or that requires absolute VPN connection reliability.

Security Recommendations for Configuration Storage Servers

The most secure location for a Configuration Storage server is behind an ISA Server array. We recommend that you install the Configuration Storage server on a dedicated computer, although you can install it on a computer that serves as the domain controller for a branch.

You can also securely install ISA Server on one of the computers running ISA Server services in the ISA Server array. However, recognize that any computer that serves as a firewall is a target for attacks. Therefore, a Configuration Storage server installed on a computer running ISA Server services on the edge of a network is a target for attacks.

In a scenario where only one computer running Windows Server 2003 is available, that computer could host the domain controller, the Configuration Storage server, and ISA Server services.

In addition to these deployment issues, consider these general security guidelines:

Safeguard the security of the Configuration Storage server. Ensure that the computer is physically secure.
After you create administrator roles, avoid performing any tasks on the Configuration Storage server. Changes to the Configuration Storage server should be done using enterprise administrator credentials on an ISA Server array computer, or on a separate management computer.
Users that belong to the Administrators group on the Configuration Storage server essentially have Enterprise Administrator permissions. This is because they can directly modify any data on the Configuration Storage server.
Audit changes to permissions on the Configuration Storage server. For instructions, see ISA Server Help.
If a Configuration Storage server is stolen, remove it from the configuration set of ADAM, as described in ADAM Help. Otherwise, a hostile party could use the stolen Configuration Storage server to corrupt the configuration of the remaining servers.

Configuration Storage Server Hardware

To ensure that your Configuration Storage server has enough speed and storage capacity for logs and reports, we recommend, as a baseline configuration:

CPU speed 2 GHz.
Memory 1 GB.
Partition type NTFS.
Disk size: You will require a 150 MB partition for the Configuration Storage server. You will require storage for reports as well. The amount of disk space required for report storage will depend on the number and type of reports you generate, and how many you retain on the Configuration Storage server. See Reports on the Configuration Storage Server for more information. Note that a standard report uses 14 Kb of disk space.

Reports on the Configuration Storage Server

We recommend that you minimize the number of reports to be saved to a Configuration Storage server. Each report saved to a Configuration Storage server is replicated to all of the other Configuration Storage servers in the enterprise. If you do not limit the number of reports that are saved, you will increase bandwidth usage for replication, as well as the amount of storage used enterprise-wide for reports. Instead, publish reports on another computer on the network.

The procedures for configuring the number of saved reports and for publishing reports are provided in ISA Server Help.

Array Deployment Guidelines

This topic describes considerations for determining whether an array should be installed in a domain or in a workgroup, how many arrays you require, and how many servers per array. For more information about ISA Server performance, see Best Practices for Performance in ISA Server (https://www.microsoft.com).

Domain and Workgroup Deployments

When planning your ISA Server deployment, you must decide whether you will install a particular ISA Server array in a domain or in a workgroup. This topic describes the advantages and disadvantages of each type of deployment

Advantages and disadvantages of domain deployments

A domain deployment has the following advantages:

In a domain, ISA Server supports rules based on domain users.
There is no need to create accounts for intra-array communication. This results in a more secure deployment.
As an array administrator, you can manage the ISA Server array from any computer in the domain using your logon credentials.

A domain deployment has the following disadvantages:

If Active Directory is compromised, for example by an internal attack, the firewall will also be compromised, because a user with administration rights can administer every domain member including the computers running ISA Server services.
If the firewall is compromised, Active Directory is at risk of attack.
When the ISA Server array is in a domain, every domain administrator can administer ISA Server, because the Domain Admins group is by default in the Administrators group on the ISA Server array members.

For more information about deploying an ISA Server array in a domain, see Introduction to Branch Deployment of ISA Server 2004 Enterprise Edition (https://www.microsoft.com).

Advantages and disadvantages of workgroup deployments

A workgroup deployment has the following advantages:

In the event that the firewall is compromised, the attacker will not gain access to the domain or to Active Directory.
Domain administrators do not have access to the ISA Server array.
Attacks on the domain or on Active Directory will not impact the firewall.

A workgroup deployment has the following disadvantages:

Workgroup deployment requires a digital certificate for connecting to the Configuration Storage server.
Because the workgroup cannot access domain user accounts, workgroup clients cannot be authenticated using Windows authentication. You can use Remote Authentication Dial-In User Service (RADIUS) authentication or RSA SecurID® authentication to authenticate clients. For more information about client authentication, see ISA Server 2004 Enterprise Edition Help.
Workgroup deployment requires management of mirrored accounts for monitoring of the array, including providing those credentials for each new monitoring session. If the accounts are not properly maintained, and passwords change frequently, this can be a security issue. Similarly, accounts are needed for intra-array communication.

For more information about deploying an ISA Server array in a workgroup, see ISA Server 2004 in a Workgroup (https://www.microsoft.com).

Assessing the Number of Arrays Needed

You can use a single ISA Server array for all firewall and proxy functionality. However, you may want to use more than one array in certain scenarios. For example:

You may want one array to handle the internal needs of your corporate network, such as Internet access, and another to handle external needs, such as VPN connections, server publishing, and Web publishing.
You may decide for security reasons to separate critical functionality in a particular array. For example, you may want to isolate VPN functionality in its own array.
You may want to limit administrative access to different ISA Server functionalities. For example, you may want a particular user to be administrator for publishing, and prevent other ISA Server administrators from accessing that array. In that case, you would create a separate array for publishing.

Assessing the Number of Servers Needed

In general, we recommend that each array include a minimum of two servers, for the following reasons:

Redundancy and failover
NLB functionality

In a situation where placement of more than one computer running ISA Server services in each branch becomes prohibitively expensive, you can use a single-member array. In this case, we recommend that your firewall clients be configured to point to an array in the main office or in a different branch if the local computer running ISA Server services becomes unavailable.

For specific information and examples for ISA Server array capacity planning, see the document ISA Server 2004 Best Practices (www.microsoft.com).

Security Recommendation for Arrays and Array Members

When an array member is taken from its array, it contains encrypted, confidential information and the keys used to encrypt that information. If an array member is stolen, the confidential information in the remaining array members must be changed.

ISA Server Management Guidelines

You need a reliable, fast connection from the Configuration Storage server to ISA Server Management, so that ISA Server Management will respond quickly, displaying updated configuration information. Similarly, ISA Server Management requires a reliable connection to the ISA Server array, to provide real-time monitoring information.

If you have a local Configuration Storage server, you should connect ISA Server Management to it. If you do not have a local Configuration Storage server, you can connect ISA Server Management to a remote Configuration Storage server over a fast link. If your connection to the remote Configuration Storage server is slower than 5 Mbps, we recommend that you use Terminal Server to manage ISA Server. In that scenario, you would run ISA Server Management in the branch where the Configuration Storage server is located, and use a remote desktop connection to connect to that management instance.

Enterprise Policy Design

An enterprise policy is a policy defined on the enterprise level that can be applied to arrays. The policy contains an ordered set of policy rules. An enterprise policy also contains a placeholder for where the array policy should appear within that enterprise policy's rules. For more information, see ISA Server Help.

This topic describes general policy considerations. For information about best practices for policy design, including tips on how to avoid policies that reduce the performance of ISA Server, see Best Practices Firewall Policy for ISA Server 2004 (www.microsoft.com).

Enterprise Policy Design Considerations

When you create an enterprise policy, you create a policy that can be applied to more than one array in your enterprise. For example, you may have three arrays that handle VPN connections, six that handle publishing, and twelve for Internet access. You can create three enterprise policies:

Enterprise access policy for VPN arrays
Enterprise access policy for publishing arrays
Enterprise access policy for Internet access arrays

Each policy will contain the access rules that are appropriate for one type of array. You then apply the appropriate enterprise policy to each array, saving the effort of creating those parts of the policy on each array. Further, if a change is needed in policy, you will only have to make the change in three policies, rather than on each of 21 arrays.

Note

Enterprise policies can only include access rules. The enterprise policy for a publishing array can control access through that array, but the publishing rules must be created on the array level.

Enterprise policies and array-level policies allow you to differentiate between different levels of administrative authority in your enterprise. ISA Server flexibility in enterprise policy rule placement, either before or after array-level rules, also allows the enterprise administrator to create rules that are not necessarily enforced on the array level. In that case, the enterprise administrator can create rules to relieve the burden of creating the rules from the array-level administrator, but can still give the array administrator policy flexibility. The following are several examples of how enterprise and array policies work together.

No array administration allowed

Scenario: All responsibility for configuration of firewall policy is maintained at the enterprise level.

Responsibility: Enterprise administrator.

Policy: When you create enterprise policies, create all of the rules as pre-array rules, to prevent the creation of array-level rules that could affect policy. Also, the enterprise administrator can create arrays that are not allowed to create deny access rules, allow access rules, or publishing rules.

Enterprise-level restrictions

Scenario: You have a corporate policy that prohibits the use of a particular protocol, or access to certain Web sites.

Responsibility: Enterprise administrator. Array administrator to complete policy on array level.

Policy: In each enterprise policy you create, include rules that deny access on the restricted protocol or to the restricted URL set. Because this is a rule that must be enforced throughout the company, and you do not want it overridden by an array-level rule, the rule must appear in the pre-array rules.

Reduce array-level responsibilities

Scenario: The array-level administrators have several other functions, and you do not want them to spend time designing array-level policies for access issues that can be handled on the enterprise level. For example, your company allows access on Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), and File Transfer Protocol (FTP), or allows access on certain protocols to specific sites or servers on the Internet.

Responsibility: Enterprise administrator. Array administrator to complete policy on array level.

Policy: In each enterprise policy you create, include rules that allow the required access. For access that is necessary throughout the enterprise, you do not want the rules overridden by an array-level rule, so they must appear in the pre-array rules. However, if there is some access that is not required, and there may be circumstances in which an array administrator may want to block access (for example, block FTP to conserve bandwidth), those rules should be placed in the post-array rules. The array administrator can create an array rule that will match requests before the enterprise rule is encountered, effectively overriding the enterprise-level rule.

SQL Database Deployment Guidelines

You can save log information to an SQL database. This is useful for remote logging.

The system policy rule named Allow remote logging using NetBIOS to trusted servers must be enabled to log to an SQL database.

Unlike the MSDE logs, an SQL database is a central log for all of the members of various ISA Server arrays in an enterprise. ISA Server array members are preconfigured to generate the daily summary reports at 00:30 (12:30 A.M.). In a scenario with many array members, the simultaneous request for gigabyte-sized logs from the computer running SQL Server will generate heavy network traffic and a significant load on the computer. The daily summary generation time can be changed, so you could stagger the summary generation time from server to server. However, the summary generation is best performed when ISA Server is not busy with other tasks, for example, late at night or early in the morning. You will likely have significant overlap between servers, and the resultant network traffic and SQL Server load.

We therefore recommend that if you are using a centralized SQL database, you ensure that there is gigabit bandwidth available from the ISA Server arrays to the computer running SQL Server. We also recommend that your computer running SQL Server is configured to handle simultaneous large requests.

If you cannot rely on the needed bandwidth or on the ability of your computer running SQL Server to handle the large requests, you have two options:

Use local MSDE logging, rather than centralized SQL logging.
Use centralized SQL logging, but do not generate daily summary reports. Instead, generate reports directly from the SQL database using SQL Reporting Services.

Disaster Recovery

There are steps you can take to limit the impact of a catastrophic hardware failure or a loss of connectivity.

Configuration Storage Server Recovery

You can limit the impact of a Configuration Storage server failure, by ensuring that it is not the only repository of the configuration data. It is best to have more than one Configuration Storage server in your enterprise, so that if one fails, the configuration can be recovered from a replicate. If you only have one Configuration Storage server in the enterprise, back it up using Windows Backup, as described in ISA Server Help. The backup file should be stored on some medium that is separate from the Configuration Storage server hardware.

If a Configuration Storage server fails, you have several options:

Create a new Configuration Storage server, and import the configuration from one of the replicate Configuration Storage servers in the enterprise.
Create a new Configuration Storage server, and import the configuration from a Windows backup file.

Array Recovery

We recommend the following approaches to handle array failure issues:

To limit the impact of a catastrophic array failure, back up the array configuration to an XML document, using the export function of ISA Server. If the Configuration Storage server data is backed up, a backup of the array data is redundant.
If the Configuration Storage server to which the array is connected fails, connect the array to a different replicate Configuration Storage server.
If you lose connectivity to the Configuration Storage server, connect to a different Configuration Storage server. If the loss of connectivity is due to a problem with the VPN connection, you will not be able to troubleshoot or repair the VPN connection on the array without a connection to the Configuration Storage server. In this case, create a VPN connection to the Configuration Storage server using Routing and Remote Access or a third-party device. After the connection is established, you can reconfigure the ISA Server VPN connection. For information about other approaches to reestablish branch connectivity, see the Branch Connectivity Options topic in Introduction to Branch Deployment of ISA Server 2004 Enterprise Edition (https://www.microsoft.com).
If an ISA Server array member fails, the remaining servers in the array will continue to work. In the case of a single-server array, the array data will be maintained on the Configuration Storage server, so that you can replace the array member and have it functioning as it was before the failure.

Additional Information

Additional ISA Server 2004 documents are available on the ISA Server 2004 Guidance page (https://www.microsoft.com).

Do you have comments about this document? Send feedback.