Designing a DirectAccess Solution

DirectAccess is a very flexible solution that can be deployed in different ways to meet your requirements. Many decisions must be made in advance to ensure that your DirectAccess design meets the needs of your environment. This section breaks down the numerous steps into smaller decision points to help you understand the big picture and make an informed decision.

Where do I start?

There are three main steps for designing a DirectAccess deployment:

1. Choose an access model.

2. Choose a scalability model.

3. Choose a deployment method.

Each of these steps will have an impact on how your DirectAccess deployment operates, what types of traffic flows through your network, and how you troubleshoot connectivity issues. Make sure you understand the complete architecture before you commit to any of the steps.

The following sections describe some top-level considerations that might influence each of your decisions.

Design influencers

IPv6 and IPsec are two key factors that will influence each step of the design process. The impact of these technologies must be fully understood in order to plan an effective DirectAccess deployment.

• IPv6 – Regardless of the design chosen, only servers and resources (such as printers, file shares, and databases) that are IPv6-enabled will be accessible to DirectAccess clients. The only way to work around the IPv6 requirement is to use a NAT-PT device.

• IPsec – IPsec provides an incredibly flexible framework that can be used for secure access scenarios that meet virtually any requirement.

In the next section you will learn about choosing an access model. Where you terminate IPsec encryption–at the edge or at the end server–and what level of authentication you wish to provide will play a large role in which access model you choose.

Choosing an access model

There are three access models to choose from:

• Full intranet access (end-to-edge)

• Selected server access (modified end- to-edge)

• End-to-end

Full Intranet access (end-to-edge)

The Full Intranet access model allows DirectAccess clients to connect to all resources inside the intranet. It does this by using IPsec-based tunnel policies that require authentication and encryption and IPsec sessions terminate at the IPsec Gateway. The IPsec Gateway is a function that is hosted on the DirectAccess server by default, but can be moved to a separate computer.

This access model works with application servers running Windows Server 2003, and IPsec-protected traffic is kept off of the intranet. Because of the similarity to current VPN architecture, this model might be easier to deploy in the short term.

Selected server access (modified end-to-edge)

This model is very similar to the Full Intranet access model previously described, with one important addition. Communication between the DirectAccess client and the IPsec Gateway is still protected by IPsec-based tunnel policies requiring encryption to the IPsec Gateway, but this model also adds an additional authentication mechanism.

By creating an additional IPsec rule requiring ESP+NULL from the client to the application server, the client’s communications will be encrypted to the IPsec Gateway, but authenticated all the way to the application server. This allows the DirectAccess client to maintain a high degree of confidence that they are communicating with their intended servers.

This access model also makes it easy to create restriction policies to prevent specific users or applications on DirectAccess clients from being able to access specific servers.

The following figure shows the Selected Server access model.

Authenticate only (Null Encapsulation) is a policy that is available only on Windows Server 2008 R2. Although it provides IPsec authentication on the first packet exchanged, it does not provide per-packet integrity or privacy because after the initial IKE negotiation, subsequent packets are sent with no IPsec protection; traffic flows in the clear after the IKE session has been negotiated. Networks that contain hardware that cannot parse or forward IPsec-protected traffic might benefit from this solution.

End-to-end

The end-to-end access model extends these IPsec policies all the way to the application server. In this case, the DirectAccess clients use an IPsec transport policy that requires encryption and authentication that terminate at the application server. In this case the DirectAccess server/IPsec Gateway simply acts as a pass-through device, allowing the IPsec connections to pass to the application servers.

A component on the DirectAccess server, known as IPsec Denial of Service Protection (DoSP), monitors the IPsec traffic to help prevent malicious users on the Internet from launching DoS attacks against intranet resources.

The following figure shows the end-to-end access model.

Single and multiple server models

DirectAccess can be set up using a single server. This type of setup allows DirectAccess to provide all of the baseline functionality required to operate. Because the purpose of DirectAccess is to provide connectivity to remote users, though, reliability and scalability are also important. This section discusses the various areas where the architecture of DirectAccess can be modified to improve scalability and reliability.

Single server

In the single server scenario, all of the components of DirectAccess are hosted on the same server computer. The following figure shows an example.

The benefit of this scenario is a relatively simple deployment, requiring only a single DirectAccess server.

The limitations of this scenario are a single point of failure and server performance bottlenecks can limit the maximum number of concurrent DirectAccess connections.

Multiple servers for high availability

DirectAccess can be configured inside a Hyper-V® Failover cluster. The recommended configuration consists of two Hyper-V hosts with failover clustering supporting a single shared DirectAccess server in a virtual machine. The two Hyper-V hosts will protect the system from a single node failure for the DirectAccess server. Follow these configuration guides to prepare your environment:

• Step-by-Step Guide for Testing Hyper-V and Failover Clustering

• Hyper-V: Step-by-Step Guide to Using Live Migration in Windows Server 2008 R2

You need the following configuration in addition to using the DirectAccess Setup Wizard:

1. The Hyper-V servers must be using identical server hardware.

   • Each Hyper-V server must have at least three physical network adapters to support Internet, intranet, and Failover Clustering connectivity. Network interface card teaming is not supported.

   • The Hyper-V servers are joined to the domain and connected to the appropriate networks and have IPv4 and IPv6 deselected on their Internet network adapter.

2. Ensure that the Hyper-V nodes are enabled to support Data Execution Prevention and Processor Virtualization.

3. Set the following Hyper-V configurations:

   • To improve overall performance, in the properties for the virtual machine in Failover Cluster Manager:

     • Do not set a preferred owner.

     • Set Failback to Prevent Failback. If Failback is enabled, unnecessary outages may occur when the DirectAccess virtual machine resource is migrated or recovers from a node failure.

   • To speed up client reconnection in the event of a quick migration or node failure, enable NLBSFlags for faster idle timeout of IPsec security associations. In the Windows Registry, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\ Oakley\NLBSFlags value to 1.

     With the NLBSFlags registry value set to 1, the total time it takes for IPsec to fail over is two minutes; one minute for the idle time to expire plus one minute for IKE to renegotiate security associations.

You can also use Unified Access Gateway (UAG) to provide scalability, high-availability, and enhanced management for a DirectAccess deployment. For more information, see Introducing UAG DirectAccess solution.

Choosing a deployment method

You can use the following methods to deploy and configure DirectAccess resources:

• The DirectAccess Management Console

• Scripted installation using Netsh.exe

• Manual client configuration using Group Policy

Each of these methods has benefits and limitations, which are described in the following sections.

DirectAccess Management Console

The DirectAccess Management Console provides several options for deploying DirectAccess. The DirectAccess Setup Wizard presents several questions to determine how the DirectAccess deployment should proceed, and before the changes are applied, you have the option of saving the settings into an XML file.

The XML file can be modified and provide a simple way to see which options are being set. You can also use the engine.ps1 PowerShell® script to execute the XML file. For more information, see Perform DirectAccess Scripting.

See Appendix E – Tips for Scripting later in this document for details on how to edit these scripts.

Scripted installation using Netsh.exe

For customized DirectAccess deployments that need to be completely modified to meet a unique set of needs, a scripted installation using Netsh.exe commands can be created from scratch. These custom scripted installations allow for maximum flexibility and the creation of unique solutions, including many permutations that are not covered in this guide.

Manual client configuration using Group Policy

Group Policy provides a policy-based method to create, distribute, and apply DirectAccess settings to clients, which allows for one-time and ongoing enforcement of DirectAccess settings. Group Policies are leveraged by DirectAccess setup and may optionally be used in a scripted setup. You can also customize your DirectAccess configuration by manually modifying the Group Policy objects and their settings.