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