Using ISA Server 2006 to Extend Server and Domain Isolation Interoperability

A Server and Domain Isolation solution based on Microsoft® Windows® IPsec and Microsoft® Active Directory® enables IT administrators to dynamically segment a Windows environment into more secure and isolated logical networks without costly changes to the network infrastructure or applications. This creates an additional layer of policy-driven protection, allowing IT administrators to greatly reduce the risk of network attacks, helping to prevent unauthorized access to trusted networked resources, and reducing operational costs.

By implementing Server and Domain Isolation, IT professionals have a low-cost way to better safeguard sensitive data. This security makes it easier to achieve compliance with regulatory requirements such as the Health Insurance Portability and Accountability Act (HIPAA), Sarbanes-Oxley, the Gramm-Leach-Bliley Act (GLBA), and the Federal Information Security Management Act (FISMA).

However, when planning, developing, or evolving a Server and Domain Isolation solution, administrators frequently have to consider machines that do not support Internet Protocol security (IPsec) standards. These might include mainframes, non-Windows devices, older versions of Windows, or other hosts where implementing IPsec support is not standard practice. It is important to protect these systems from unauthorized access and network-based attacks while allowing them to communicate with IPsec-enabled network assets. Often, administrators also want to enable IPsec-protected systems to communicate with trusted non-IPsec assets. A number of options to mitigate risk in these scenarios while enabling the desired interoperability are possible.

This paper discusses how to use Microsoft Internet Security and Acceleration (ISA) Server running on Microsoft Windows Server 2003 as an IPsec gateway. With this solution, IT administrators can extend a Server and Domain Isolation deployment for greater interoperability while leveraging existing system software and expertise.

Each enterprise environment has unique circumstances; therefore, each organization should adapt the plans described in this paper to meet its specific needs.

Background

Introduction to IPsec

Designed by the Internet Engineering Task Force (IETF) as the security architecture for the Internet Protocol (IP), IP security (IPsec) defines IP packet formats and related infrastructure to provide end-to-end strong authentication, integrity, anti-replay, and (optionally) confidentiality for network traffic. Internet Key Exchange (IKE), part of IPsec, specifies an on-demand security negotiation and automatic key management service. All recent versions of the Windows operating system from Windows 2000 Server to Windows Vista™ and Windows Server 2008 offer Windows IPsec, a robust implementation of IPsec, to help simplify the deployment and management of network security.

A Standards-Based Framework of Security Protocols and Cryptographic Services

IPsec refers to a framework of security protocols and cryptographic services for Internet Protocol (IP) packets. Implementing end-point authentication using IPsec makes it much more difficult for an attacker to gain access to a protected machine. IPsec can be deployed as a local policy or a domain-based Group Policy. Local policies can be deployed with a Microsoft Management Console (MMC) snap-in, or via command line tools such as netsh.exe (Windows Server 2003 and later), ipseccmd.exe (Windows XP), and ipsecpol.exe (Windows 2000).

Server and Domain Isolation

Server Isolation creates a more secure, logically isolated network around a specific set of servers and/or applications and the data that support it. For example, this could be an organization’s financial servers and the hosts used by the finance department. By logically isolating these critical servers and data, network access can be restricted to only those that have a business requirement to connect to them. This greatly reduces unauthorized access to sensitive data.

Domain Isolation extends this model to an entire managed domain (i.e., those hosts that are joined to the Active Directory) to reduce the risk of unmanaged or rogue devices from impacting the security or integrity of managed, trusted hosts.

This solution is based on policy (i.e., Active Directory Group Policy) rather than the network topology and removes the need to change existing applications. Thus, Server and Domain Isolation processes are able to change dynamically based on changes in organization or business requirements.

For more information on Server and Domain Isolation, please visit Server and Domain Isolation.

IPsec Gateways for Interoperability

The purpose of a Server and Domain Isolation solution is to limit the risk of unauthorized access (external and internal) to trusted assets. Today’s networks, however, often include machines that do not natively support IPsec standards.

An IPsec gateway is an easy-to-deploy option for interoperability with these machines. It acts as a demarcation point and connection between the IPsec-enabled isolation domain and the non-IPsec domain. Other defense-in-depth security controls are then recommended to secure the non-IPsec network segment or subnet.

The IPsec gateway has separate network interfaces connecting it to both domains. It supports the end-point authentication provided by Server and Domain Isolation when communicating with computers on the IPsec-enabled isolation domain, and does not use IPsec protection when communicating with computers on the non-IPsec domain.

An IPsec gateway enables transparent interdomain communication by routing traffic between the domains while converting IPsec-protected traffic to plain text and vice versa. The IPsec gateway checks IP addresses and verifies integrity of the traffic it sends on behalf of computers in the non-IPsec domain. Since Server and Domain Isolation policy is not supported on the non-IPsec computers, the IPsec gateway also ensures that only traffic permitted by the security policy is allowed to flow between the domains.

The advantages of the IPsec gateway approach are as follows:

• Enables computers lacking full IPsec support to participate in and benefit from the defenses of Server and Domain Isolation.

• Centralizes IPsec configuration for the IPsec gateway.

• Reduces the need for special exception rules in IPsec policy.

ISA Server 2006 as an IPsec Gateway

ISA Server 2006 is ideally suited for the role of IPsec gateway as it includes all of the necessary gateway functionality: firewall protection, application-layer traffic inspection, network address translation (NAT) and through Windows Server, IPsec-based isolation support. ISA Server enables seamless communication with non-IPsec capable computers without compromising security. By using ISA Server running on Windows Server 2003 as an IPsec gateway for non-IPsec devices, IT administrators can improve network and data security while extending interoperability.

This application of ISA Server builds upon existing investments in Windows Vista, Windows Server 2003, Windows XP or Windows 2000 and Microsoft Active Directory to provide a flexible solution that can be deployed today without the need to install additional software on the hosts. By using Windows IPsec, these enhanced security benefits are implemented at the network layer, removing the need to make changes to applications. Additionally, the deployment may not require potentially disruptive changes to network topology or costly network hardware upgrades to enable policy-driven, logical network segmentation. Of course, this will be dependent on the choices you make for your own deployment.

There are certain aspects of ISA Server that must be understood prior to designing a domain isolation deployment:

1. ISA Server 2006 supports two network relationships; route and NAT. Since the primary purpose of using ISA is as an IPsec gateway, a NAT relationship must exist between the two networks, using the non-IPsec network as the source.

2. Per the ISA Troubleshooting Unsupported Configurations TechNet article , ISA does not support domain traffic across a NAT relationship. While most protocols traverse a NAT mechanism just fine, many protocols used between domain members do not. For this reason, domain members and their domain controllers should be placed on the same side of an ISA NAT relationship or ISA should provide a route relationship between them.

3. When the network relationship defined in the ISA Network rules is route, the IP traffic between hosts in the IPsec and non-IPsec networks are directed to each other, and so ISA server cannot operate as an IPsec gateway.

Solution Overview

The two most common scenarios for choosing to use ISA Server as an IPsec gateway in a network are described below. Because ISA Server makes clear distinctions between the terms “proxy” and “gateway”, we will use the term “proxy” only in the context of ISA behavior as a web proxy or SOCKS proxy. All other scenarios will refer to ISA operation as an “IPsec gateway” to avoid confusing the two contexts.

Scenario 1:  IPsec enabled Client Needs Access to a Non-IPsec-Enabled Server

When a business-critical server cannot be protected with IPsec but still needs to be accessed by IPsec-enabled clients, and the IT administrator wants to secure as much of the path as possible, the machines can be connected using ISA Server as an IPsec gateway. The non-IPsec server should continue to be protected with separate defense-in-depth security measures after gateway deployment.

Figure 1: ISA Server as an IPsec Gateway

To access the services provided by the non-IPsec host, all systems in the IPsec-enabled isolation domain will connect to the ISA Server public IP address, and IPsec transport mode will be authenticating and (optionally) encrypting this network traffic. ISA Server proxies the traffic to the non-IPsec device, which receives the connection in clear and unaware that IPsec is part of the communication path.

Scenario 2:  Allowing Controlled Access to IPsec-enabled Hosts from non-IPsec Hosts

When a non-IPsec client machine cannot run IPsec but security policies have determined it is authorized to access trusted network resources that are isolated via domain isolation, the IT administrator can connect the hosts using ISA Server as an IPsec gateway.

This figure shows a typical deployment of ISA Server as an IPsec gateway. The dual-homed gateway has one interface using IPsec in the isolation domain, while the other interface is connected to the non-Windows or legacy systems.

Figure 2: ISA Server as an IPsec Gateway

It is important to note that access checks provided by ISA Server as an IPsec gateway may be limited to IP addresses as the only traffic-limiting factors, which can be falsified for hosts in the non-IPsec network. If an intruder is able to obtain the key IP address, access might be granted if no other security measures are in place. Additional network authentication methods, such as 802.1x can be employed in the non-IPsec network to minimize this threat.

Deploying the Solution

Setting up ISA Server is the same for both scenarios. This section describes the preparation, installation, and setup process; it then details how to configure ISA Server for each scenario.

Before You Begin

Take the time to thoroughly prepare for the ISA Server deployment and configuration.

1. Review Server and Domain Isolation Using IPsec and Group Policy Guide

2. Identify affected assets. Map out allowed communications paths and boundary machines, and document any policy exceptions.

3. Identify NAT-intolerant protocols. A Server Branch Office Policies Best Practices: ISA Server co-location with a domain controller discusses many of the problems encountered with trying to pass domain-related traffic to and across ISA

4. Create a rollout schedule.

5. Communicate with users.

6. Hardware and software requirements:

   1. Hardware: Microsoft ISA Server 2006 System Requirements defines the minimum and recommended hardware and software requirements for ISA Server 2006. In order to ensure maximum supportability and reliability, the hardware you choose should be at least “compatible” and preferably “logo” listed in Windows Catalog. To improve performance, the network interface card (NIC) which serves the IPsec-enabled network should support IPsec offload. Ideally, this NIC should also be listed in Windows Catalog as “compatible”; preferably as “logo”.

   2. Software: ISA Server 2006. The choice of Standard vs. Enterprise Edition is not relevant to the IPsec gateway functionality, but may be influenced by the management and high availability choices for your environment.

Installing ISA Server

The remainder of the installation choices will depend on the individual environment.

1. Begin the installation of ISA Server, and when prompted, select Custom installation and click Next. In the Custom Setup dialog, you are offered the opportunity to include or exclude advanced logging. This choice will determine whether MSDE (advanced logging) is installed and operating as the default logging method. If you wish to use text logging or a remote SQL instance, you should select “this feature will not be available” from the Advanced Logging installation dropdown.

2. In the Internal Network dialog, the choice you make depends on whether ISA server is a domain member:

   1. Domain member: select the network which faces the domain where ISA is a member

   2. WG member: select the network where the non-IPsec machines reside

3. After the installation is complete, install the latest ISA Server updates. ISA Server updates are available from Microsoft downloads or Microsoft Update.

Disable IP Routing

After installing ISA Server, you must disable ISA Server kernel-mode IP routing. ISA Server kernel-mode IP routing and IPsec IP packet management conflict with each other and will cause improper IPsec behavior. To disable ISA Server kernel-mode IP routing:

1. Expand ISA Server Management console tree, expand Configuration, and select General.
   

2. In the details pane, under Additional Security Policy, click Configure IP Protection.
   

3. In the IP Preferences dialog, click the IP Routing tab, clear Enable IP routing.
   

4. Click Apply, then OK

Modify the ISA Server Network Structure

Because ISA Server treats the External network differently than it does any other network, you should avoid using it as part of internal network isolation deployment. In order to ensure that the traffic policies you create behave as intended, it’s best to let the External network “hang in space”. To do this, you need to redefine the network model for ISA.

Add the Additional Network

1. In ISA Server Management console tree, expand Configuration, select Networks.

2. Right-click Networks, select New, then Network
   

3. In the Welcome to the New Network Wizard dialog, enter the name of the network; for instance, IPsec Domain if ISA Server is a member of that domain which is IPsec-protected, click Next
   

4. In the Network Type dialog, select Perimeter Network, click Next
   

5. In the Network Addresses dialog, click Add Adapter
   

6. In the Select Network Adapters dialog, select the NIC which faces the network that is not defined as the Internal network, click Next
   

7. In the Network Addresses dialog, verify that the resulting address ranges are correct and click Next
   

   Note

   If the addresses listed are not correct, you should stop this process, close ISA Server Management and update the Windows routing table accordingly. Once this is corrected, you should restart this process from Step 1

8. In the Completing the New Network Wizard dialog, click Finish
   

Create the IPsec Network Rule

1. Right-click Networks, select New, then Network Rule
   

2. In the Welcome to the New Network Rule Wizard dialog, enter the name of the network rule, for instance IPsec Domain Rule, click Next
   

3. In the Network Traffic Sources dialog, click Add
   

4. In the Add Network Entities dialog, select the network which serves the non-IPsec hosts, click Add, then Close
   

5. In the Network Traffic Sources dialog, click Next
   

6. In the Network Traffic Destinations dialog, click Add
   

7. In the Add Network Entities dialog, select the network which serves the IPsec hosts, click Add, then Close
   

8. In the Network Traffic Destinations dialog, click Next
   

9. In the Network Relationship dialog, select NAT, then click Next
   

10. In the Completing the New Network Rule Wizard dialog, click Finish
    

Configuring Policy Rules

After completing the installation of ISA Server and configuring the networks and related rules, traffic policies must be created to enable and control access to or from the ISA server itself as an IPsec participant as well as for traffic to and from the non-IPsec machine(s).

Configuring IPsec Policy

A Windows IPsec policy will need to be configured on the host running ISA Server to enable communications with the other IPsec-enabled hosts. This IPsec can be deployed as a local policy or a domain-based Group Policy if the ISA Server is joined to an Active Directory domain.

For more information on configuring and deploying IPsec policies for Server and Domain Isolation, please refer to the “Server and Domain Isolation Using IPsec and Group Policy” guide available at TechNet

Creating an Access Rule for Internet Key Exchange (IKE) and IPsec ESP

Follow these steps to create an access rule allowing traffic on the IKE Client protocol between the IPsec-enabled network and the ISA Server computer. This rule is required in order for ISA to operate as an IPsec gateway.

1. In the Microsoft ISA Server Management console tree, right-click Firewall Policy, select New, then Access Rule…
   

2. On the Welcome page of the wizard, enter the name for the access rule, such as IPsec to/from ISA, and then click Next.
   

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

4. On the Protocols page, select Selected protocols and click Add
   

5. Expand VPN and IPsec, select IKE Client, click Add, select IPsec ESP, click ADD, click Close.
   

   Note

   1. If ISA Server is to perform as an IPsec gateway for IPsec-enabled hosts which operate across a remote NAT, you must also include IPsec NAT-T Client in the protocol set.
      
      
   2. If the IPsec implementation uses IPsec AH rather than IPsec ESP, you will need to create a custom protocol and use it in the access rule. The custom protocol should be created as:
      Name: IPsec AH
      Protocol Type: IP-level
      Protocol Number: 51
      Direction: Send-Receive
      
      After you create the custom IPsec AH protocol, it will be found in “User-Defined” protocol group. See ISA help for instructions on creating custom protocol definitions.
      
      

6. On the Protocols page, click Next.
   

7. On the Access Rule Sources page, click Add
   

8. In the Add Network Entities dialog box, expand Networks, select the IPsec network, click Add, select the Local Host network, click Add, and then click Close.
   

9. On the Access Rule Sources page, click Next.
   

10. On the Access Rule Destinations page, click Add to open the Add Network Entities dialog box
    

11. In the Add Network Entities dialog box, expand Networks, select the IPsec network, click Add, select the Local Host network, click Add, and then click Close.
    

12. On the Access Rule Destinations page, click Next.
    

13. On the User Sets page, click Next.
    

14. In the Completing the New Access Rule Wizard dialog, review the information on the wizard summary page, and click Finish.
    

Scenario 1: IPsec-enabled Client Access to an Non-IPsec-enabled Server

In order for hosts in the IPsec network to communicate with hosts in the non-IPsec network when using ISA Server as an IPsec gateway, they must first negotiate IPsec with the ISA server. In order for this to occur, all traffic from the IPsec-enabled host must be directed to an ISA Server IP address. To publish a non-HTTP server, you must create a server publishing rule that configures a single port for handling the traffic to server. This applies in Scenario 1 and Scenario 2.

• HTTP-based protocols – Create a Web publishing rule. These have the advantage of using the information provided in the “host” header by the client in its requests to the server. As with IIS, ISA can serve multiple web sites using a single web listener.

• non-HTTP-based protocols – Create a Server Publishing rule. Due the way ISA handles traffic across a NAT relationship, Server Publishing listeners can operate only in the NAT destination network; in this case, the IPsec-enabled network.

Creating a Server Publishing Rule

To create the publishing rule, follow these steps. The example screenshots create a rule for publishing an SMTP server.

1. In ISA Server Management, right-click Firewall Policy, point to New, and select Non-Web Server Protocol Publishing Rule.
   

2. On the New Server Publishing Rule Wizard Welcome page, provide a name for the rule. Click Next.
   

3. On the Select Server page, in Server IP address, type the IP address of the server you are publishing, and then click Next.
   

4. On the Select Protocol page, from the Selected protocol drop-down list, select SMTP Server, and then click Next.
   

5. On the Network Listener IP Addresses page, under Listen for requests from these networks, select the IPsec-enabled network, click Next.
   

   Note

   You can also select specific IP addresses that ISA Server will listen on for this rule. To do this, click the Address button, and then for the selected network, specify the IP addresses where ISA Server will listen. You may use this option to publish multiple non-IPsec hosts on the same protocol. If you are publishing multiple non-IPsec hosts on identical protocols, you must either use this option or configure the additional Server Publishing rules to use unique custom listening ports. Otherwise, you will create a resource conflict across multiple Server Publishing listeners.

   

6. Review the information on the wizard summary page, and then click Finish.
   

   Note

   On the publishing rule To tab, under Requests for the published server, there is an option to titled Requests appear to come from the ISA Server computer. This option can be used when ISA Server cannot function as the default gateway or as part of the default route for the published server. This approach has the disadvantage that the published server will be unaware of the original address of the client, which is a problem for server applications that use the client address for logging or for policy decisions.

Creating a Web Publishing Rule

• For Scenario 1, create a Web publishing rule to enable HTTP and/or HTTPS communication. The listener for the Web publishing rule should listen on the IPsec enabled network and publish a server on the non-IPsec-enabled network.

• For Scenario 2, create a Web publishing rule to enable HTTP and/or HTTPS communication. The listener for the Web publishing rule should listen on the non-IPsec-enabled network and publish a server on the IPsec network.

  Since the only difference between Scenario 1 and Scenario 2 is the placement of the Web Listener, only Scenario 1 is illustrated in the following example and publishes a single, non-SSL, anonymous (non-authenticating) web site which is hosted in the non-IPsec network.

To create a new Web publishing rule, follow these steps:

1. In ISA Server Management, right-click Firewall Policy, point to New, and select Web Site Publishing Rule.
   

2. On the Welcome page, in the Web publishing rule name field, type a name for the rule, such as Non-IPsec Web Site, click Next.
   

3. On the Select Rule Action page, ensure that the default Allow is selected, click Next.
   

4. In the Publishing Type page, select Publish a single Web site or load-balancer, click Next
   

5. In the Server Connection Security page, select Use non-secured connections… and click Next
   

6. In the first Internal Publishing Details page, Internal site name: is used to populate the host header for the forwarded requests and to resolve to the IP address of the published server. If name resolution provided for the ISA server cannot resolve this name to the proper IP address, you should select Use a computer name or IP address to connect to the published server and enter the IP address of the published server in the Computer name or IP address: field
   

7. In the second Internal Publishing Details page, enter the desired virtual directory to be published by this rule. If you wish to publish the entire web site, leave this field blank. Click Next.
   

   Note

   Select Forward the original host header instead of the actual one if your Web site has specific features that require the original host header

8. On the Public Name Details page, provide information regarding what requests will be received by the ISA Server computer and forwarded to the Web server. In Accepts requests for, if you select Any domain name, any request that is resolved to the IP address of the external Web listener of the ISA Server computer will be forwarded to your Web site.

   1. Select This domain name and provide a specific domain name, such as non-ipsec-host, where “non-ipsec-host” is resolved to the IP address where the Web listener will be defined.

   2. If you specify a folder in Path, such as News, that would also be required in the request: https://www.fabrikam.com/news. click Next.
      

9. On the Select Web Listener page, click New
   

10. On the Welcome page of the New Web Listener Wizard, type the name of the new listener, such as IPsec HTTP Web Listener 1, and then click Next.
    

11. In the Client Connection Security page, select Do not requires SSL secured connections with clients, click Next
    

12. On the Web Listener IP Addresses page, select the network which serves the IPsec-enabled hosts, click Next.
    

    Note

    1. You can also select specific IP addresses where this Web Listener will operate. To do this, click the Address button, and then for the IPsec-enabled network, choose the IP addresses where ISA Server will listen. Since Web publishing rules can distinguish requests based on the host header sent by the client, this additional step may not be required.
       
       
    2. By default, the ISA Server will compress… option is selected. If you do not need or wish to use compression for this traffic, you should uncheck this option. More information on ISA HTTP compression is available on TechNet at HTTP Compression Concepts in ISA Server 2006
       
       

13. In the Authentication Settings page, select the No Authentication from the drop-down, click Next
    

14. In the Single Sign On Settings page, click Next
    

    Note

    More information on ISA Authentication, Single Sign On and Authentication Delegation is available on TechNet at Authentication in ISA Server 2006

15. On the Completing the New Web Listener Wizard page, review the settings, and click Finish.
    

16. On the Select Web Listener page, click Next.
    

17. In the Authentication Delegation page, leave the default setting in place, click Next.
    

18. On the User Sets page, make sure the default, All users, is displayed, click Next.
    

19. On the Completing the New Web Publishing Rule Wizard page, scroll through the rule configuration to make sure that you have configured the rule correctly, and click Finish.
    

Scenario 2:  Allowing Controlled Access to IPsec-enabled Hosts from non-IPsec Hosts

In order to allow traffic from hosts in the non-IPsec to hosts in the IPsec-enabled network, you must create an access rule for traffic to the IPsec hosts. You may choose to create a single access rule that includes all expected protocols, or you may use individual rules per protocol. You should seek to strike a balance between rule simplicity and rule management; concepts which are often at odds with one another. Best Practices Firewall Policy for ISA Server 2006 discusses the fine points of ISA Rule creation and management.

The following steps will create an anonymous Access rule allowing non-IPsec hosts to make connections to any host in the IPsec network using Microsoft Common Internet File System Protocol (File Shares).

1. In the Microsoft ISA Server Management console tree, right-click Firewall Policy, select New, then Access Rule…
   

2. On the Welcome page of the wizard, enter the name for the access rule, such as IPsec-hosted File Shares, click Next.
   

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

4. On the Protocols page, select Selected protocols and click Add
   

5. In the Add Protocols dialog, expand All Protocols, select Microsoft CIFS (TCP), click Add, then Close.
   

6. In the Protocols page, click Next
   

7. On the Access Rule Sources page, click Add to open the Add Network Entities dialog box,
   

8. In the Add Network Entities dialog, expand Networks, select the network that hosts the non-IPsec computer, click Add, and then Close.
   

9. On the Access Rule Sources page, click Next.
   

10. On the Access Rule Destinations page, click Add
    

11. In the Add Network Entities box, expand Networks, select the IPsec-domain network, click Add, and then click Close.
    

12. On the Access Rule Destinations page, click Next.
    

13. On the User Sets page, leave the default choice selected, click Next.
    

14. Review the information on the wizard summary page, and then click Finish.
    

15. In the Firewall Policy details pane, click Apply to apply the changes made to the ISA policies.
    

    Note

    It may take a few moments for the rule to be applied.

16. When the OK button in the Saving Configuration Changes dialog is activated, click it.
    

    Note

    Changes to ISA policy are not instantaneous and do not affect existing connections.

Additional Traffic Policies

The ISA policies illustrated above configure ISA Server to accept and originate IPSec protocols in support of its role as an IPsec gateway and to allow HTTP and CIFS traffic in specific directions. In order for the hosts in each network to communicate with each other using their application protocols, you must create additional policies which allow specific protocols appropriate to your applications. It’s beyond the scope of this document to address these or to provide specific instructions for them.

TechNet contains many documents on ISA policy best practices as well as whitepapers covering how to publish applications such as Exchange, SharePoint and many others.

Security Implications of this Solution

Using an IPsec gateway for interoperability is less secure than using only IPsec-compliant devices. The solution does not cover all parts of the network path, so administrators must continue to protect the non-IPsec machine using alternate means. Additionally, ISA Server cannot validate untrusted machines to the degree that the IPsec-protected network does, so ISA-allowed machine IP addresses are a possible avenue of attack.

Risks that cannot be mitigated with this solution include the following:

• Trusted users disclosing high value data

• Compromise of trusted credentials

• Untrusted computers compromising other untrusted computers

• Loss of physical security of trusted computers

• Lack of policy compliance mechanisms for trusted computers

Best Practices

For Server and Domain Isolation best practices, please see the deployment documents available at Server and Domain Isolation.

For ISA Server Policies best practices, please see Best Practices Firewall Policy for ISA Server 2006

Related Links and Resources

Server and Domain Isolation TechNet article

Server and Domain Isolation Using IPsec and Group Policy Guide

https://www.microsoft.com/sdisolation

ISA Server

Microsoft ISA Server 2006 System Requirements

Best Practices Firewall Policy for ISA Server 2006

IPsec

IPsec FAQ:
https://www.microsoft.com/windowsserver2003/techinfo/overview/ipsecfaq.mspx

Community Resources

Peer Communities: https://www.microsoft.com/communities/default.mspx

Most Valuable Professional (MVP) program: https://www.microsoft.com/communities/mvp

User Groups: https://www.microsoft.com/communities/usergroups/default.mspx