Planning DirectAccess with an Existing Server and Domain Isolation Deployment

Applies To: Windows 7, Windows Server 2008 R2

Server and Domain Isolation (SDI) allows administrators to dynamically segment their Windows environment into more secure and isolated logical networks using Internet Protocol security (IPsec) without costly changes to their network infrastructure or applications. This creates an additional layer of policy-driven protection, helps better protect against costly network attacks, and helps prevent unauthorized access to trusted networked resources, achieve regulatory compliance, and reduce operational costs. For more information, see Server and Domain Isolation (https://go.microsoft.com/fwlink/?Linkid=95395).

Both DirectAccess and SDI use a set of Windows Firewall with Advanced Security connection security rules in Group Policy objects (GPOs) to determine when and how to protect intranet traffic. You should perform a careful analysis of your existing SDI global IPsec settings and connection security rules and the global IPsec settings and rules created by the DirectAccess Setup Wizard to determine whether they are compatible. A mismatch in global IPsec or connection security rule settings between DirectAccess and SDI can cause an IPsec negotiation failure and a lack of connectivity when a DirectAccess client attempts to access an intranet resource protected with SDI.

For example, you need to ensure that the global main mode IPsec settings of your DirectAccess clients match the global main mode IPsec settings of your SDI deployment. The DirectAccess Setup Wizard will configure default global main mode IPsec settings for DirectAccess clients to match those of the default global main mode IPsec settings for Windows Vista and Windows Server 2008. If you have changed the global main mode IPsec settings for your SDI deployment from their default values, you need to configure the global main mode IPsec settings of the Group Policy object for DirectAccess clients created by the DirectAccess Setup Wizard to match them.

Additional design considerations for deploying DirectAccess in an existing SDI environment are the following:

• To allow for Teredo client discovery, you should exempt Internet Control Message Protocol (ICMP) from IPsec protection in your SDI deployment.

• If you are only using SDI for data integrity, you must use Encapsulating Security Payload (ESP)-NULL, rather than Authentication Header (AH). If you are using AH, you should reconfigure your SDI deployment to use ESP-NULL before deploying DirectAccess.