Determining Domain Membership Versus Workgroup Isolation

Before ISA Server 2004 is installed, a particularly important decision must be made; whether or not to make that server a member of an Active Directory domain. The answer to this question is not simple, but there is a general consensus that it is best to limit the scope of what is accessible by any server that is exposed to unsecured networks such as the Internet.

Although there are few concrete, easily identifiable security threats to back this up, it is general best practice to reduce the exposure that the ISA server has, and limit it to only the functionality that it needs. Consequently, one of the big improvements in ISA Server 2004 is its ability to run as a workgroup member, as opposed to a domain member. There are certain pieces of functionality that differ between each of these scenarios, and it is subsequently important to outline the deployment scenarios and functional limitations of both scenarios.

Understanding Deployment Scenarios with ISA Domain Members and ISA Workgroup Members

Installing ISA as a domain member is more common in smaller organizations that require greater simplicity and administrative flexibility. One of the main reasons for this is that these smaller organizations often deploy ISA as the main, edge-facing firewall for their networks. When ISA is deployed in this fashion, the reasons against domain membership become lessened because the server itself is directly exposed to network resources, and even if it were to be compromised, making it a domain member versus a non-domain member would not help things greatly.

One of the more common ISA deployment scenarios, on the other hand, involves ISA being set up as a unihomed (single NIC) server in the DMZ of an existing firewall. In nearly all these cases, the ISA server is not made a domain member because domain membership would require the server to open additional ports on the edge-facing firewall. In this situation, if the ISA server were to be compromised, there would be functional advantages to keeping the server out of the domain.

A third deployment scenario in use in certain organizations is the creation of a separate Active Directory forest, of which the ISA server is a member. This forest would be configured with a one-way trust from the main organizational forest, allowing ISA to perform domain-related activities without posing a threat to the internal domain accounts.

Working Around the Functional Limitations of Workgroup Membership

As previously mentioned, it may be advantageous to deploy ISA Server in a workgroup, in situations where the ISA server is deployed in the DMZ of an existing firewall, or for other reasons mentioned earlier. A few functional limitations must be taken into account, however, when determining deployment strategy for ISA. These limitations and their workarounds are as follows:

• Local Accounts used for administration Because ISA is not installed in the domain, local server accounts must be used for administration. On multiple servers, this requires setting up multiple accounts and maintaining multiple passwords. In addition, when remotely administering multiple servers, each server requires re-authenticating through the console each time it is accessed.

• RADIUS or SecurID used for authentication Because domain authentication is not available, the ISA server must rely on RADIUS or SecurID authentication to be used to properly authenticate users. Because an Active Directory deployment can install the Internet Authentication Service (IAS) to provide RADIUS support, it is possible to leverage this to allow authentication of domain accounts through RADIUS on an ISA server that is not a domain member. More information on configuring IAS can be found in Chapter 9, "Enabling Client Remote Access with ISA Server 2004 Virtual Private Networks (VPNs)," and Chapter 14, "Securing Web (HTTP) Traffic."

• Firewall client use disabled The one functional limitation that cannot be overcome in a workgroup membership scenario is the fact that the full-blown ISA Client cannot be used. In reality, use of the full Firewall client, which provides advanced firewall connection rules and user-granular access control, is not widespread, so this may not factor into the equation. Because the SecureNAT client is supported, this minimizes the effects of this limitation. SecureNAT clients are essentially any client on the network (including those on the Internet) that can connect to the server and does not require any special client software to be installed. For more information on what the Firewall client can do, reference Chapter 11, "Understanding Client Deployment Scenarios with ISA Server 2004."

Changing Domain Membership

If the decision has been made to make the ISA Server a domain member, the following procedure can be used to add the server to a domain:

1.	While logged in as an account with local administrative privilege, click Start, Control Panel, System.
2.	Choose the Computer Name tab, as shown in Figure 2.9. Figure 2.9. Changing domain membership.
3.	Click the Change button.
4.	Under the Member Of section, choose Domain and type in the name of the Active Directory domain of which the ISA server will be a member. Click OK when complete.
5.	Enter the username and password of an account in the Active Directory domain that has the capability to add computers to the domain. Click OK when complete.
6.	Click OK three times at the Welcome message, reboot warning, and to close the dialog box.
7.	Click Yes to restart the server.