DirectAccess Design Guide

Microsoft Corporation

Published: August 14, 2009

Author: Joe Davies

Editor: Scott Somohano

AbstractThis guide provides recommendations to help you plan a DirectAccess deployment using the

Windows Server® 2008 R2 operating system. It is intended for use by infrastructure specialists or

system architects who are planning a new DirectAccess deployment. This guide covers

DirectAccess deployment goals and design considerations for Internet Protocol version 6 (IPv6)

connectivity, access models, packet filtering, infrastructure requirements, and server placement,

redundancy, and capacity planning.

The information contained in this document represents the current view of Microsoft Corporation

on the issues discussed as of the date of publication. Because Microsoft must respond to

changing market conditions, it should not be interpreted to be a commitment on the part of

Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the

date of publication.

This Design Guide is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,

EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the

rights under copyright, no part of this document may be reproduced, stored in or introduced into a

retrieval system, or transmitted in any form or by any means (electronic, mechanical,

photocopying, recording, or otherwise), or for any purpose, without the express written permission

of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual

property rights covering subject matter in this document. Except as expressly provided in any

written license agreement from Microsoft, the furnishing of this document does not give you any

license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the companies, organizations, products, domain names, e-mail

addresses, logos, people, places, and events depicted in examples herein are fictitious. No

association with any real company, organization, product, domain name, e-mail address, logo,

person, place, or event is intended or should be inferred.

© 2009 Microsoft Corporation. All rights reserved.

Microsoft, Windows Server, Windows 7, Windows Vista, and Windows XP are trademarks of the

Microsoft group of companies.

All other trademarks are property of their respective owners.

Contents

DirectAccess Design Guide............................................................................................................7

About this guide........................................................................................................................... 7

Understanding the DirectAccess Design Process...........................................................................8

Identifying Your DirectAccess Deployment Goals...........................................................................8

Transparent and Automatic Remote Access for DirectAccess Clients............................................9

Ongoing Management of Remote DirectAccess Clients...............................................................10

Efficient Routing of Intranet and Internet Traffic............................................................................10

Reduction of Remote Access-based Servers in your Edge Network.............................................11

End-to-end Traffic Protection.........................................................................................................11

Multi-factor Credentials for Intranet Access...................................................................................11

Mapping Your Deployment Goals to a DirectAccess Design.........................................................11

Evaluating DirectAccess Design Examples..................................................................................12

Full Intranet Access Example........................................................................................................12

Full Intranet Access with Smart Cards Example...........................................................................13

Selected Server Access Example.................................................................................................14

Using authentication with null encapsulation for selected server access...................................15

End-to-end Access Example.........................................................................................................16

Planning a DirectAccess Deployment Strategy.............................................................................16

Resources Available to DirectAccess Clients................................................................................17

IPv6 resources on your intranet.................................................................................................18

IPv4-only resources on the intranet...........................................................................................19

Limiting connectivity to selected resources...............................................................................19

IPv6 resources on the IPv6 Internet..........................................................................................19

Choose an Intranet IPv6 Connectivity Design...............................................................................20

No existing IPv6 infrastructure...................................................................................................20

Existing ISATAP infrastructure...................................................................................................22

Existing native IPv6 infrastructure.............................................................................................22

Choose Solutions for IPv4-only Intranet Resources.....................................................................23

Choose an Access Model.............................................................................................................24

Full Intranet Access...................................................................................................................... 25

Selected Server Access................................................................................................................25

End-to-End Access....................................................................................................................... 26

Choose a Configuration Method...................................................................................................27

DirectAccess Management Console..........................................................................................27

Scripted installation using Network Shell (Netsh) command-line tool........................................27

Manual configuration using Group Policy..................................................................................28

Design for Remote Management..................................................................................................28

Design Packet Filtering for DirectAccess......................................................................................29

Packet Filters for Your Internet Firewall........................................................................................29

Packet Filters for Your Intranet Firewall........................................................................................30

Confining ICMPv6 Traffic to the Intranet.......................................................................................31

Packet filters for Teredo Connectivity............................................................................................32

Packet filters to allow inbound ICMPv6 Echo Requests on all computers.................................33

Enable edge traversal on inbound management traffic.............................................................33

Enable inbound ICMPv6 Echo Requests for management traffic..............................................33

Packet Filters for Management Computers...................................................................................33

DirectAccess and Third-party Host Firewalls................................................................................34

Choose an Authentication and Authorization Scheme..................................................................35

Additional end-to-end peer authentication for selected server access.......................................36

Peer authentication for end-to-end access................................................................................36

Smart cards for additional authorization....................................................................................36

Allowing access for users with unusable smart cards............................................................37

Prompts for smart card credentials while on the intranet.......................................................37

Under the covers: Smart card authorization...........................................................................38

Design Active Directory for DirectAccess......................................................................................38

Active Directory and the DirectAccess server............................................................................39

DirectAccess and user profiles for remote users.......................................................................39

Design Your DNS Infrastructure for DirectAccess.........................................................................40

Split-brain DNS.......................................................................................................................... 40

DNS server requirements for ISATAP........................................................................................41

AAAA records for servers that do not perform DNS dynamic update........................................41

Local name resolution behavior for DirectAccess clients...........................................................41

NRPT rules................................................................................................................................ 42

Unqualified, single-label names and DNS search suffixes........................................................43

External DNS............................................................................................................................. 44

Design Your PKI for DirectAccess.................................................................................................44

Autoenrollment for computer certificates...................................................................................44

Manual enrollment for network location server and IP-HTTPS certificates................................45

Certificate revocation checking and CRL distribution points......................................................45

Enabling strong CRL checking for IPsec authentication............................................................46

Smart cards for additional authorization....................................................................................47

Design your Web Servers for DirectAccess..................................................................................47

Choose an Internet Traffic Separation Design..............................................................................48

Design Protection for Traffic between DirectAccess Clients.........................................................50

Design Your Intranet for Corporate Connectivity Detection...........................................................52

Choose a DirectAccess and VPN Coexistence Design.................................................................53

DirectAccess and third-party VPN clients..................................................................................54

Planning the Placement of a DirectAccess Server........................................................................55

When to Install a DirectAccess Server..........................................................................................55

Where to Place the DirectAccess Server......................................................................................55

Planning Redundancy for a DirectAccess Server.........................................................................56

Planning the Placement of a Network Location Server.................................................................57

Where to Place the Network Location Server...............................................................................58

Highly available intranet Web server as the network location server.........................................58

DirectAccess server as the network location server..................................................................59

Planning Redundancy for a Network Location Server..................................................................59

Planning the Placement of CRL Distribution Points......................................................................60

Where to Place the CRL Distribution Points..................................................................................60

Intranet location for intranet detection.......................................................................................60

Internet location for IP-HTTPS connections..............................................................................60

Planning Redundancy for CRL Distribution Points........................................................................61

Planning DirectAccess with Network Access Protection (NAP)....................................................61

Configuration changes for the infrastructure tunnel...................................................................62

Configuration changes for the intranet tunnel............................................................................63

Planning DirectAccess with an Existing Server and Domain Isolation Deployment......................64

DirectAccess Capacity Planning...................................................................................................64

Capacity Planning for DirectAccess Servers.................................................................................65

Increasing the number of concurrent authentications................................................................65

Moving the IPsec gateway function to a separate server..........................................................65

Using DirectAccess with UAG...................................................................................................67

Capacity Planning for Network Location Servers..........................................................................67

Capacity Planning for CRL Distribution Points..............................................................................68

Additional DirectAccess Resources..............................................................................................68

Appendix A: DirectAccess Requirements......................................................................................68

Appendix B: Reviewing Key DirectAccess Concepts....................................................................70

IPv6........................................................................................................................................... 70

IPv6 connectivity across the IPv4 Internet.............................................................................71

6to4..................................................................................................................................... 71

Teredo................................................................................................................................. 71

IP-HTTPS........................................................................................................................... 71

IPv6 connectivity across an IPv4-only intranet.......................................................................72

IPsec......................................................................................................................................... 72

Encryption.............................................................................................................................. 73

Data integrity.......................................................................................................................... 73

Separation of DNS traffic...........................................................................................................73

NRPT exemptions..................................................................................................................74

Network location servers...........................................................................................................75

How intranet detection works.................................................................................................75

Appendix C: Documenting Your DirectAccess Design..................................................................76

Concepts................................................................................................................................... 76

Goals......................................................................................................................................... 76

Infrastructure design plan..........................................................................................................76

Custom configuration plan.........................................................................................................77

Integration strategy.................................................................................................................... 77

Staging strategy......................................................................................................................... 77

Lessons learned........................................................................................................................ 78

DirectAccess Design Guide

DirectAccess is one of the most anticipated features of the Windows Server 2008 R2 operating

system. DirectAccess allows remote users to securely access intranet shares, Web sites, and

applications without connecting to a virtual private network (VPN). DirectAccess establishes bi-

directional connectivity with a user’s intranet every time a user’s DirectAccess-enabled portable

computer connects to the Internet, even before the user logs on. Users never have to think about

connecting to the intranet, and information technology (IT) administrators can manage remote

computers outside the office, even when the computers are not connected to the VPN.

DirectAccess is supported by Windows 7 Enterprise, Windows 7 Ultimate, and Windows

Server 2008 R2.

The following are the key elements of a DirectAccess solution:

DirectAccess client. A domain-joined computer running Windows 7 Enterprise, Windows 7

Ultimate, or Windows Server 2008 R2 that can automatically and transparently connect to an

intranet through a DirectAccess server.

DirectAccess server. A domain-joined computer running Windows Server 2008 R2 that

accepts connections from DirectAccess clients and facilitates communication with intranet

resources.

Network location server. A server that a DirectAccess client uses to determine whether it is

located on the intranet or the Internet.

Certificate revocation list (CRL) distribution points. Servers that provide access to the

CRL that is published by the certification authority (CA) issuing certificates for DirectAccess.

For more information, see Appendix B: Reviewing Key DirectAccess Concepts.

About this guideThis guide is intended for use by an infrastructure specialist or system architect. The guide

provides recommendations to help you plan a new DirectAccess deployment based on the

requirements of your organization and the particular design that you want to create. It highlights

your main decision points as you plan your DirectAccess deployment. Before you read this guide,

you should have a good understanding of your organizational requirements and the capabilities

and requirements of DirectAccess.

This guide describes a set of deployment goals that are based on the primary DirectAccess

access methods. It helps you determine the most appropriate access method and corresponding

design for your environment. You can use these deployment goals to create a comprehensive

DirectAccess design that meets the needs of your environment.

7

Understanding the DirectAccess Design Process

To begin the DirectAccess design process, you must first identify your DirectAccess deployment

goals. This guide contains some predefined deployment goals so that you can understand the

ways in which DirectAccess can benefit your organization. After evaluating these goals, you can

select a DirectAccess design that meets your DirectAccess deployment objectives. Each design

includes examples to help you understand fundamental DirectAccess processes such as client

access or remote management.

The following topics explain how to identify and evaluate a DirectAccess deployment design for

your organization:

Identifying Your DirectAccess Deployment Goals

Mapping Your Deployment Goals to a DirectAccess Design

Evaluating DirectAccess Design Examples

After you identify your deployment goals and map them to a DirectAccess design, you can begin

documenting your design, based on the processes that are described in the following topics:

Planning a DirectAccess Deployment Strategy

Planning the Placement of a DirectAccess Server

Planning the Placement of a Network Location Server

Planning the Placement of CRL Distribution Points

Planning DirectAccess with Network Access Protection (NAP)

Planning DirectAccess with an Existing Server and Domain Isolation Deployment

DirectAccess Capacity Planning

Additional DirectAccess Resources

Appendix A: DirectAccess Requirements

Appendix B: Reviewing Key DirectAccess Concepts

Identifying Your DirectAccess Deployment Goals

Correctly identifying your DirectAccess deployment goals is essential for the success of your

DirectAccess design project. Depending on the size of your organization and the level of

involvement you are expecting from the information technology (IT) staff in any partner

organizations, form a project team that can clearly articulate real-world deployment issues in a

vision statement. Make sure that the members of this team understand the direction in which your

deployment project must move in order to reach your DirectAccess deployment goals.

8

When you write your vision statement, take steps to identify, clarify, and refine your deployment

goals. Prioritize and, if necessary, combine your deployment goals so that you can design and

deploy DirectAccess by using an iterative approach. You can take advantage of existing,

documented, and predefined DirectAccess deployment goals that are relevant to the

DirectAccess designs and develop a working solution for your scenarios.

The following table lists the three main tasks for articulating, refining, and documenting your

DirectAccess deployment goals.

Deployment goal tasks Reference links

Evaluate predefined DirectAccess deployment

goals that are provided in this section of the

guide and combine one or more goals to reach

your organizational objectives.

Transparent and Automatic Remote Access for

DirectAccess Clients

Ongoing Management of Remote DirectAccess

Clients

Efficient Routing of Intranet and Internet Traffic

Reduction of Remote Access-based Servers in

your Edge Network

End-to-end Traffic Protection

Multi-factor Credentials for Intranet Access

Map one goal or a combination of any of the

predefined DirectAccess deployment goals to a

DirectAccess design.

Mapping Your Deployment Goals to a

DirectAccess Design

Document your deployment goals and other

important details for your DirectAccess design.

Appendix C: Documenting Your DirectAccess

Design

Transparent and Automatic Remote Access for DirectAccess Clients

DirectAccess enhances the productivity of mobile workers by connecting their computers

automatically and seamlessly to their intranet any time Internet access is available. The user

does not have to remember to initiate a virtual private network (VPN) connection every time that

they need to access intranet resources. With DirectAccess, intranet file shares, Web sites, and

line-of-business applications can remain accessible wherever you have an Internet connection in

the same way as if you were directly connected to the intranet.

9

Ongoing Management of Remote DirectAccess Clients

With current virtual private network (VPN) solutions, the remote computer is connected to the

intranet only intermittently. This model of user-initiated connections makes it difficult for

information technology (IT) staff to manage remote computers with the latest updates and

security policies. Remote computer management can be mitigated by checking for and requiring

system health updates before completing the VPN connection. However, such requirements can

add substantial wait times to the VPN connection process.

With DirectAccess, IT staff can manage mobile computers by updating Group Policy settings and

distributing software updates any time the mobile computer has Internet connectivity, even if the

user is not logged on. This flexibility allows IT staff to manage remote computers as if they were

directly connected to the intranet and ensures that mobile users stay up-to-date with security and

system health policies.

Efficient Routing of Intranet and Internet Traffic

DirectAccess separates intranet from Internet traffic, which reduces unnecessary traffic on the

intranet by sending only traffic destined for the intranet through the DirectAccess server. Some

virtual private network (VPN) solutions use Network layer routing table entries to separate intranet

from Internet traffic, in a configuration known as split-tunneling. DirectAccess solves this problem

in the Application layer through more intelligent name resolution and in the Network layer by

summarizing the IPv6 address space of an entire organization with IPv6 address prefixes. Rather

than directing traffic solely based on a destination address, DirectAccess clients also direct traffic

based on the name needed by the application.

DirectAccess clients use a Name Resolution Policy Table (NRPT) that contains Domain Name

System (DNS) namespace rules and a corresponding set of intranet DNS servers that resolve

names for that DNS namespace. When an application on a DirectAccess client attempts to

resolve a name, it first compares the name with the rules in the NRPT. If there is a match, the

DirectAccess client uses a protected query to the specified intranet DNS servers to resolve the

name to intranet addresses and establish connections. If there are no matches, the DirectAccess

client uses Internet DNS servers to resolve the name to Internet addresses and establish

connections.

10

Reduction of Remote Access-based Servers in your Edge Network

With DirectAccess, you can reduce your dependence on remote access and application edge

servers, leading to an edge network with fewer servers that provide access to intranet resources

or applications. For example, the number of application edge servers can be reduced as the

number of DirectAccess clients increase because DirectAccess clients can now directly access

the corresponding application servers on the intranet.

End-to-end Traffic Protection

You can specify that the traffic between DirectAccess clients and intranet applications servers is

protected from end-to-end. In most virtual private network (VPN) solutions, the protection only

extends to the VPN server. This capability for end-to-end traffic protection provides additional

security for computers that are outside of the intranet. Additionally, by leveraging the flexibility and

control that is possible with connection security rules in Windows Firewall with Advanced Security,

you can specify that the end-to-end protection include encryption and not require that the traffic

be tunneled to the DirectAccess server.

Multi-factor Credentials for Intranet Access

In typically deployed access models, DirectAccess clients create two tunnels to the DirectAccess

server. The first tunnel, the infrastructure tunnel, provides access to intranet Domain Name

System (DNS) servers, Active Directory Domain Services (AD DS) domain controllers, and other

infrastructure and management servers. The second tunnel, the intranet tunnel, provides access

to intranet resources such as Web sites, file shares, and other application servers.

To provide an additional layer of security for traffic sent over the intranet tunnel, you can specify

that the intranet tunnel also require smart card authorization, which enforces the use of multiple

sets of credentials to access intranet resources. Multi-factor credentials for the intranet tunnel

uses the new tunnel-mode authorization feature of Windows Firewall with Advanced security in

Windows 7 and Windows Server 2008 R2, which allows you to specify that only authorized

computers or users can establish an inbound tunnel.

Mapping Your Deployment Goals to a DirectAccess Design

After you have reviewed the DirectAccess deployment goals and determined which are

appropriate for your organization, you can map those goals to a specific design.

11

The following table shows how well the DirectAccess designs meet the deployment goals

discussed in Identifying Your DirectAccess Deployment Goals.

DirectAccess deployment goal DirectAccess elements or features

Transparent and automatic remote access for

DirectAccess clients

Functionality in the DirectAccess server and

clients

Ongoing management of remote DirectAccess

clients

Bidirectional connections whenever the

computer is connected to the Internet

Efficient routing of intranet and Internet traffic Use of the Name Resolution Policy Table

(NRPT) and Internet Protocol version 6 (IPv6)

to separate Internet and intranet traffic

Reduction of remote access-based servers in

your edge network

Access to intranet resources through the

DirectAccess server

End-to-end traffic protection The selected server and end-to-end access

models

Multi-factor credentials for intranet access Smart card authorization on the intranet tunnel

Evaluating DirectAccess Design Examples

The following design examples illustrate the way in which DirectAccess deployment scenarios

work to provide transparent access to intranet resources.

Full Intranet Access Example

Full Intranet Access with Smart Cards Example

Selected Server Access Example

End-to-end Access Example

You can use these examples to determine the design or combination of designs that best suits

the needs of your organization.

Full Intranet Access Example

Full intranet access allows DirectAccess clients to connect to all of the Internet Protocol version 6

(IPv6)-reachable resources inside the intranet. The DirectAccess client uses Internet Protocol

security (IPsec) to create two encrypted tunnels to the Internet interface of the DirectAccess

server. The first tunnel, known as the infrastructure tunnel, allows the DirectAccess client to

access Domain Name System (DNS) servers, Active Directory Domain Services (AD DS) domain

controllers, and other infrastructure and management servers. The second tunnel, known as the

12

intranet tunnel, allows the DirectAccess client to access intranet resources. The infrastructure

tunnel uses computer authentication and the intranet tunnel uses both computer and user

authentication.

After the intranet tunnel is established, the DirectAccess client can exchange traffic with intranet

application servers. This traffic is encrypted by the tunnel for its journey across the Internet. By

default, the DirectAccess server is acting as an IPsec gateway, terminating the IPsec tunnels for

the DirectAccess client.

The following figure shows an example of full intranet access.

When the DirectAccess client starts up and determines that it is on the Internet, it creates the

tunnels to the DirectAccess server and begins normal communications with intranet infrastructure

servers such as AD DS domain controllers and application servers as if it were directly connected

to the intranet.

This design does not require IPsec protection for traffic on the intranet and is structurally very

similar to current remote access virtual private network (VPN) scenarios.

Full Intranet Access with Smart Cards Example

Full intranet access with smart cards is the full intranet access design and the use of smart cards

to provide an additional level of authorization for the intranet tunnel. The DirectAccess server

enforces the use of smart card credentials when the DirectAccess client computer attempts to

access an intranet resource.

The following figure shows an example of full intranet access with smart cards.

13

When a user on the DirectAccess client logs on to their computer with the smart card, they obtain

transparent access to intranet resources. If they log in to the computer using domain credentials,

such as a username and password combination, and attempt to access the intranet, Windows

displays a message in the notification area instructing them to enter their smart card credentials.

The user then inserts their smart card and provides their smart card personal identifier (PIN) to

access intranet resources.

This notification message will fade away in five seconds or may be covered by other notifications

in a shorter amount of time, but an icon displaying a pair of keys will stay in the notification area.

If the user misses the notification, the keys icon will be available in the overflow tray, which will

allow them to launch the credential prompt again by clicking on it.

If the user closes the smart card credential prompt from the notification area, there is no

way of relaunching it, nor will the keys show up in the overflow tray again. The user must

lock their computer and then unlock it with their smart card to access the intranet.

Selected Server Access Example

Selected server access allows you to confine the access of DirectAccess clients to a specific set

of intranet application servers and deny access to all other locations on the intranet. Intranet

access requires end-to-end Internet Protocol security (IPsec) protection from the DirectAccess

client to the specified servers. This provides an additional layer of IPsec peer authentication and

data integrity for end-to-end traffic so that DirectAccess clients can verify that they are

communicating with specific servers.

The following figure shows an example of selected server access.

Note

14

The DirectAccess client and selected servers by default perform IPsec peer authentication using

computer credentials and protect the traffic with Encapsulating Security Protocol (ESP)-NULL for

data integrity.

You can also use selected server access to require end-to-end IPsec protection from the

DirectAccess client to specified servers and allow access to all other locations on the intranet.

Traffic to other intranet application servers is not protected with IPsec peer authentication and

data integrity. The intranet tunnel between the DirectAccess client and server provides encryption

for both types of intranet traffic across the Internet.

Using authentication with null encapsulation for selected server accessAuthentication with null encapsulation is a new feature of Windows Firewall with Advanced

Security for Windows 7 and Windows Server 2008 R2. Some intranets contain hardware that

cannot parse or forward IPsec-protected traffic. With authentication with null encapsulation

enabled, IPsec peers perform normal IPsec peer authentication and include IPsec data integrity

on the first packet exchanged. Subsequent packets are sent as clear text with no IPsec

protection. This feature allows you to use IPsec for peer authentication in environments that do

not support IPsec-protected traffic flows. You can enable authentication with null encapsulation

for DirectAccess when using selected server access.

Authentication with null encapsulation is not the same as using ESP-NULL for per-packet

data integrity.

Note

15

End-to-end Access Example

End-to-end access removes the infrastructure and intranet tunnels to the DirectAccess server. All

intranet traffic is end-to-end between DirectAccess clients and intranet application servers and is

encrypted with Internet Protocol security (IPsec). In this configuration, the DirectAccess server is

no longer terminating IPsec tunnels. It is acting as a pass-through device, allowing the IPsec-

protected traffic to pass between the DirectAccess client and the application servers. A

component of 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 an example of end-to-end access.

The DirectAccess client and intranet application servers should be configured to perform IPsec

peer authentication using computer credentials and to protect the traffic with Encapsulating

Security Protocol (ESP) for data confidentiality (encryption) and integrity.

Planning a DirectAccess Deployment Strategy

The following are some critical questions to consider as you develop a deployment strategy for

DirectAccess, with links to corresponding topics in this Design Guide. Answering these questions

will help you create a strategy that is cost-effective and resource-efficient.

Which intranet resources will be available to DirectAccess clients? For more information, see

Resources Available to DirectAccess Clients.

How do I either enable Internet Protocol version 6 (IPv6) on my intranet or have DirectAccess

use my existing IPv6 infrastructure? For more information, see Choose an Intranet IPv6

Connectivity Design.

16

What options do I have to make Internet Protocol version 4 (IPv4)-only resources available

for DirectAccess clients? For more information, see Choose Solutions for IPv4-only Intranet

Resources.

Which access models are there to choose from? For more information, see Choose an

Access Model.

What options do I have to configure DirectAccess? For more information, see Choose a

Configuration Method.

Which computers do I need to designate as management servers that will initiate connections

to DirectAccess clients? For more information, see Design for Remote Management.

What packet filters do I need to add to my firewalls and computers in my organization? For

more information, see Design Packet Filtering for DirectAccess.

What support is needed from third-party host firewalls? For more information, see

DirectAccess and Third-party Host Firewalls.

What authentication and authorization options do I have? For more information, see Choose

an Authentication and Authorization Scheme.

How does DirectAccess leverage or utilize Active Directory Domain Services (AD DS)? For

more information, see Choose an Authentication and Authorization Scheme.

How do I design my Domain Name System (DNS) infrastructure for DirectAccess? For more

information, see Design Your DNS Infrastructure for DirectAccess.

How do I design my public key infrastructure (PKI) for DirectAccess? For more information,

see Design Your PKI for DirectAccess.

How do I design my internal and external Web infrastructure for DirectAccess? For more

information, see Design your Web Servers for DirectAccess.

What options are there for separating or combining intranet and Internet traffic for

DirectAccess clients? For more information, see Choose an Internet Traffic Separation

Design.

How do I ensure that traffic between DirectAccess clients on the Internet is protected? For

more information, see Design Protection for Traffic between DirectAccess Clients.

How do I ensure that DirectAccess clients can detect connectivity to the intranet? For more

information, see Design Your Intranet for Corporate Connectivity Detection.

How does DirectAccess co-exist with my current remote access virtual private network (VPN)

solution? For more information, see Choose a DirectAccess and VPN Coexistence Design.

Resources Available to DirectAccess Clients

When designing your DirectAccess deployment, you must determine how DirectAccess clients

will reach all of the desired intranet resources.

17

IPv6 resources on your intranetDirectAccess relies on Internet Protocol version 6 (IPv6) for end-to-end connectivity between the

DirectAccess client and an intranet endpoint. DirectAccess clients only send IPv6 traffic across

the connection to the DirectAccess server. Therefore, DirectAccess clients can only communicate

using applications that support IPv6 and connect to intranet resources that are reachable with

IPv6. Internet Protocol version 4 (IPv4)-only applications on the DirectAccess client cannot be

used to access intranet application servers with DirectAccess.

The recommended configuration for your intranet is to have IPv6 connectivity to your intranet

resources. This requires the following:

An intranet infrastructure that supports the forwarding of IPv6 traffic.

IPv6-capable applications on computers that run an operating system that supports an IPv6

protocol stack.

An intranet infrastructure that supports forwarding IPv6 traffic can be achieved in the following

ways:

Configure your intranet infrastructure to support native IPv6 addressing and routing.

Computers running Windows Vista, Windows Server 2008, Windows 7, or Windows

Server 2008 R2 use IPv6 by default. Although few organizations today have a native IPv6

infrastructure, this is the preferred and recommended connectivity method. For the most

seamless intranet connectivity for DirectAccess clients, organizations should deploy a native

IPv6 infrastructure, typically alongside their existing IPv4 infrastructure.

Deploy Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) on your intranet.

Without a native IPv6 infrastructure, you can use ISATAP to make intranet servers and

applications reachable by tunneling IPv6 traffic over your IPv4-only intranet. Deploying

ISATAP consists of setting up one or more ISATAP routers that provide address configuration

and default routing for ISATAP hosts on your intranet. Computers running Windows 7 or

Windows Server 2008 R2 support ISATAP host functionality and can be configured to act as

ISATAP routers.

If you do not have a native IPv6 infrastructure or ISATAP on your intranet, the DirectAccess Setup

Wizard will automatically configure the DirectAccess server as the ISATAP router for your

intranet.

Applications that are end-to-end reachable by DirectAccess clients must be IPv6-capable and

running on an operating system that supports an IPv6 protocol stack with native IPv6 or ISATAP

host capability. For Windows-based application servers or peer computers, Windows 7, Windows

Server 2008 R2, Windows Vista, and Windows Server 2008 are highly recommended. Windows

XP and Windows Server 2003 have an IPv6 protocol stack, but many built-in system services and

applications for these operating systems are not IPv6-capable.

For applications running on non-Windows operating systems, verify that both the operating

system and the applications support IPv6 and are reachable over native IPv6 or ISATAP.

18

IPv4-only resources on the intranetBecause DirectAccess clients only send IPv6 traffic to the DirectAccess server, users on

DirectAccess clients cannot use IPv4-only client applications to reach IPv4-only resources on

your intranet. Examples of IPv4-only resources are the following:

Applications running on Windows 2000 or prior versions of Windows.

The built-in applications and system services running on Windows XP and Windows Server

2003 that are not IPv6-capable.

For applications that are not built-in to Windows, check with the software vendor to ensure

that the application is IPv6-capable. Applications that only use IPv4, such as Office

Communications Server (OCS), cannot by default be reached by DirectAccess clients.

However, IPv6-capable applications can reach IPv4-only resources on your intranet by using an

IPv6/IPv4 translation device or service. For the solutions for providing connectivity for

DirectAccess clients to IPv4-only resources, see Choose an Intranet IPv6 Connectivity Design.

Limiting connectivity to selected resourcesWith the selected server access model, you can limit the access of DirectAccess clients to a

specific set of servers identified by membership in Active Directory security groups. The following

figure shows an example of using selected server access to restrict intranet access to specific

application servers.

For more information, see Selected Server Access Example.

IPv6 resources on the IPv6 InternetBy default, Windows 7 and Windows Server 2008 R2-based computers attempt to resolve the

name 6to4.ipv6.microsoft.com to determine the IPv4 address of a 6to4 relay and

teredo.ipv6.microsoft.com to determine the IPv4 addresses of Teredo servers on the IPv4

19

Internet. With the 6to4 relay at 6to4.ipv6.microsoft.com and the Teredo servers at

teredo.ipv6.microsoft.com, Windows 7-based clients on the IPv4 Internet can reach the IPv6

Internet.

When Windows 7 and Windows Server 2008 R2-based computers are configured as

DirectAccess clients, the DirectAccess server becomes the 6to4 relay and the Teredo server so

that DirectAccess clients can tunnel IPv6 traffic destined for the intranet to the DirectAccess

server. If the DirectAccess server does not also forward default route traffic to the IPv6 Internet,

DirectAccess clients will not be able to reach the IPv6 Internet.

If you want DirectAccess clients to reach the IPv6 Internet, configure the DirectAccess server with

one of the following:

A direct, native connection to the IPv6 Internet

Configure the DirectAccess server to forward default route traffic using its native connection

to the IPv6 Internet. You can also use a separate router for your connection to the IPv6

Internet and configure the DirectAccess server to forward its default route traffic to the router.

A 6to4-tunneled connection to the IPv6 Internet

Configure the DirectAccess server to forward default route traffic using the Microsoft 6to4

Adapter interface to a 6to4 relay on the IPv4 Internet. You can configure a DirectAccess

server for the IPv4 address of the Microsoft 6to4 relay on the IPv4 Internet with the netsh

interface ipv6 6to4 set relay name=192.88.99.1 state=enabled command. Use

192.88.99.1, the IPv4 anycast address of 6to4 relays on the Internet, unless your Internet

service provider recommends a specific unicast IPv4 address of the 6to4 relay that they

maintain.

Choose an Intranet IPv6 Connectivity Design

The combinations of intranet Internet Protocol version 6 (IPv6) connectivity prior to deploying

DirectAccess are the following:

There is no existing IPv6 infrastructure

You have an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)-based IPv6

infrastructure

You have an existing native IPv6 infrastructure

In each of these combinations, you will need to ensure that the IPv6 routing infrastructure can

forward packets between DirectAccess clients and intranet resources.

No existing IPv6 infrastructureHaving no existing IPv6 infrastructure is currently the most common situation. When the

DirectAccess Setup Wizard detects that the DirectAccess server has no native or ISATAP-based

IPv6 connectivity, it automatically derives a 6to4-based 48-bit prefix for the intranet, configures

20

the DirectAccess server as an ISATAP router, and registers the name ISATAP with its Domain

Name System (DNS) server.

By default, DNS servers running Windows Server 2008 R2 or Windows Server 2008

block the resolution of the name ISATAP with the global query block list. To enable

ISATAP, you must remove the name ISATAP from the block list. For more information,

see Update the global query block list (http://go.microsoft.com/fwlink/?LinkId=157589).

Windows-based ISATAP hosts that can resolve the name ISATAP perform address

autoconfiguration with the DirectAccess server, resulting in the automatic configuration of the

following:

An ISATAP-based IPv6 address on an ISATAP tunneling interface.

A 64-bit route that provides connectivity to the other ISATAP hosts on the intranet.

A default IPv6 route that points to the DirectAccess server.

The default IPv6 route ensures that intranet ISATAP hosts can reach DirectAccess clients.

When your Windows-based ISATAP hosts obtain an ISATAP-based IPv6 address, they begin to

use ISATAP-encapsulated traffic to communicate if the destination is also an ISATAP host.

Because ISATAP uses a single 64-bit subnet for your entire intranet, your communication goes

from a segmented, multi-subnet Internet Protocol version 4 (IPv4) communication model to a flat,

single-subnet communication model with IPv6. This can affect the behavior of Active Directory

Domain Services (AD DS) and other applications that rely on your Active Directory Sites and

Services configuration. For example, if you used the Active Directory Sites and Services snap-in

to configure sites, IPv4-based subnets, and inter-site transports for forwarding of requests to

servers within sites, this configuration is not used by ISATAP hosts.

To configure Active Directory sites and services for forwarding within sites for ISATAP hosts, you

have to configure an IPv6 subnet object equivalent to each IPv4 subnet object, in which the IPv6

address prefix for the subnet expresses the same range of ISATAP host addresses as the IPv4

subnet.

For example, for the IPv4 subnet 192.168.99.0/24 and the 64-bit ISATAP address prefix

2002:836b:1:0:1::/64, the equivalent IPv6 address prefix for the IPv6 subnet object is

2002:836b:1:1:0:5efe:192.168.99.0/120. For an arbitrary IPv4 prefix length (set to 24 in the

example), the corresponding IPv6 prefix length is 96 + IPv4PrefixLength.

For the IPv6 addresses of DirectAccess clients, you should add the following:

An IPv6 subnet for the range 2001:0:WWXX:YYZZ::/64, in which WWXX:YYZZ is the colon-

hexadecimal version of the first consecutive public IPv4 address (w.x.y.z) assigned to the

Internet interface of the DirectAccess server. This IPv6 prefix is for Teredo-based

DirectAccess clients.

If you have a native IPv6 infrastructure, an IPv6 subnet for the range 48-

bitIntranetPrefix:5555::/64, in which 48-bitIntranetPrefix is the 48-bit native IPv6 prefix that is

being used on your intranet. This IPv6 prefix is for Internet Protocol over Secure Hypertext

Transfer Protocol (IP-HTTPS)-based DirectAccess clients.

If you are using a 6to4-based IPv6 prefix on your intranet, an IPv6 subnet for the range

2002:WWXX:YYZZ:2::/64, in which WWXX:YYZZ is the colon-hexadecimal version of the first

Note

21

consecutive public IPv4 address (w.x.y.z) assigned to the Internet interface of the

DirectAccess server. This IPv6 prefix is for IP-HTTPS-based DirectAccess clients.

A series of 6to4-based IPv6 prefixes that begin with 2002: and represent the regional, public

IPv4 address prefixes that are administered by Internet Assigned Numbers Authority (IANA)

and regional registries. The 6to4-based prefix for a public IPv4 address prefix w.x.y.z/n is

2002:WWXX:YYZZ::/[16+n], in which WWXX:YYZZ is the colon-hexadecimal version of

w.x.y.z. For example, the 7.0.0.0/8 range is administered by American Registry for Internet

Numbers (ARIN) for North America. The corresponding 6to4-based prefix for this public IPv6

address range is 2002:700::/24. For information about the IPv4 public address space, see

IANA IPv4 Address Space Registry

(http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml). These IPv6

prefixes are for 6to4-based DirectAccess clients.

Existing ISATAP infrastructureIf you have an existing ISATAP infrastructure, the DirectAccess Setup wizard will prompt you for

the 48-bit prefix of the organization and will not configure itself as an ISATAP router. To ensure

that DirectAccess clients are reachable from the intranet, you will need to modify your IPv6

routing infrastructure so that default route traffic is forwarded to the DirectAccess server.

Existing native IPv6 infrastructureIf you have an existing native IPv6 infrastructure, the DirectAccess Setup wizard will prompt you

for the 48-bit prefix of the organization and will not configure itself as an ISATAP router. To ensure

that DirectAccess clients are reachable from the intranet, you will need to modify your IPv6

routing so that default route traffic is forwarded to the DirectAccess server.

If your intranet IPv6 address space is using something other than a single 48-bit IPv6 address

prefix, you will need to modify the default connection security rules in the Group Policy objects

created by the DirectAccess Setup Wizard to include the additional IPv6 address prefixes for your

intranet.

If you are currently connected to the IPv6 Internet, you must configure your default route traffic so

that it is forwarded to the DirectAccess server, and then configure the appropriate connections

and routes on the DirectAccess server so that the default route traffic is forwarded to the router

that is connected to the IPv6 Internet.

If you are using IPv6 addresses that are not based on a 6to4 prefix on your intranet, a

6to4-based DirectAccess client computer that uses IP-HTTPS to connect to the

DirectAccess server will not be able to reach intranet locations. To correct this condition,

add a 6to4 route (2002::/16) to your intranet that points to the DirectAccess server or

reconfigure the DirectAccess server to use IPv6 addresses from your intranet prefix on its

Internet interface rather than 6to4 addresses and change the client and server tunnel

endpoints in your DirectAccess client and server Group Policy objects to the assigned

IPv6 address.

Note

22

Choose Solutions for IPv4-only Intranet Resources

A DirectAccess client sends only Internet Protocol version 6 (IPv6) traffic to the DirectAccess

server. When DirectAccess clients send Domain Name System (DNS) name query requests

across the infrastructure tunnel to the IPv6 address of an intranet DNS server, they request only

IPv6 records (AAAA DNS records). Internet Protocol version 4 (IPv4)-only applications on the

DirectAccess client will never send IPv4 traffic across the DirectAccess intranet tunnel. The same

DirectAccess client, when directly connected to the intranet, sends DNS name queries to intranet

DNS servers and requests all records, both IPv4 and IPv6. For an IPv4-only server application,

intranet DNS servers send back IPv4 records and the client application uses IPv4 to

communicate.

The end result is that an IPv6-capable client application on a DirectAccess client can use IPv4 to

access an IPv4-only server application while connected to the intranet, but cannot by default

reach the same server application when connected to the Internet.

The solutions for providing connectivity for IPv6-capable applications on DirectAccess clients to

IPv4-only intranet applications are the following:

Upgrade or update the IPv4-only intranet application to support IPv6. This update might

include updating the operating system of the server, updating the application running on the

server, or both. This is the recommended solution. For built-in applications and system

services on computers running Windows XP or Windows Server 2003, you must upgrade

Windows XP to Windows 7 or Windows Vista and upgrade Windows Server 2003 to Windows

Server 2008 R2 or Windows Server 2008.

Use a conventional remote access virtual private network (VPN) connection on the

DirectAccess client to reach the IPv4-only application.

Use a Network Address Translation-Protocol Translation (NAT-PT) or NAT64 device on your

intranet. NAT-PTs and NAT64s perform IPv6-to-IPv4 DNS name resolution and IPv6/IPv4

traffic translation services for traffic between DirectAccess clients and IPv4-only intranet

application servers.

The types of DirectAccess connectivity that are possible for IPv6-capable and IPv4-only client

and server applications are summarized in the following:

IPv6-capable client application on the DirectAccess client with an IPv6-capable server

application on the intranet

End-to-end connectivity for DirectAccess clients.

IPv6-capable client application on the DirectAccess client with an IPv4-only server application

on the intranet

Translated connectivity for DirectAccess clients only with a NAT-PT or NAT64.

IPv4-only client application on the DirectAccess client with either an IPv6-capable or IPv4-

only server application on the intranet

No connectivity for DirectAccess clients.

23

When you deploy a NAT-PT or NAT64, you typically configure it to provide coverage for specific

portions of your intranet DNS namespace. Once deployed, the NAT-PT or NAT64 will make the

necessary DNS resolutions and IPv6/IPv4 traffic translations, allowing IPv6-capable applications

on DirectAccess clients to access IPv4-only resources located within that portion of the DNS

namespace.

The following figure shows an example of using a separate NAT-PT or NAT64 device to provide

access to IPv4-only application servers on an intranet.

If you are using a NAT-PT or NAT64 in your DirectAccess deployment, you must identify the

portions of your intranet namespace that contain IPv4-only application servers and add them to

the Name Resolution Policy Table (NRPT) of your DirectAccess clients with the IPv6 addresses of

your NAT-PT or NAT-64.

Because Windows Server 2008 R2 does not provide NAT-PT or NAT64 functionality, the

configuration of these devices is beyond the scope of this design guide. Microsoft Forefront

Unified Access Gateway (UAG) includes NAT-PT functionality and can be used in conjunction

with a DirectAccess deployment. For more information, see UAG and DirectAccess

(http://go.microsoft.com/fwlink/?LinkId=159955). NAT-PT or NAT64 devices are also available

from Layer 2 and Layer 3 switch and router vendors.

Choose an Access Model

The three access models for DirectAccess, as previously described in Evaluating DirectAccess

Design Examples, are the following:

Full Intranet Access

Selected Server Access

End-to-End Access

The following topics describe the benefits and limitations of these access models.

24

Full Intranet Access

The full intranet access model allows DirectAccess clients to connect to Internet Protocol version

6 (IPv6)-reachable resources inside your intranet and provides Internet Protocol security (IPsec)-

based end-to-edge peer authentication and encryption that terminates at the DirectAccess server.

See Full Intranet Access Example for more information.

The following are the benefits of the full intranet access model:

Does not require intranet application servers that are running Windows Server 2008 or later.

Works with any IPv6-capable application servers.

Most closely resembles current virtual private network (VPN) architecture and is typically

easier to deploy.

Can be used with smart cards for an additional level of authorization.

Is fully configurable with the DirectAccess Setup Wizard.

Does not require IPsec-protected traffic on the intranet.

The following are the limitations of the full intranet access model:

Does not provide end-to-end authentication or data protection with intranet servers.

Because the DirectAccess server is terminating the IPsec tunnels, there is extra processing

load on DirectAccess server to perform encryption and decryption. This load can be mitigated

by moving the IPsec gateway function to a different server with IPsec offload network

adapters. For more information, see Capacity Planning for DirectAccess Servers.

Selected Server Access

The DirectAccess Setup Wizard allows you to configure one of the following for the selected

server access model:

The only servers that DirectAccess clients can communicate with are selected intranet

servers using Internet Protocol security (IPsec) peer authentication and end-to-end data

integrity.

The only servers that DirectAccess clients can communicate with are selected intranet

servers using IPsec peer authentication but no IPsec protection.

Communications between DirectAccess clients and selected intranet servers must perform

IPsec peer authentication and end-to-end data integrity. Communications with all other

intranet endpoints use clear text.

Communications between DirectAccess clients and intranet servers must perform IPsec peer

authentication but no IPsec protection. Communications with all other intranet endpoints use

clear text.

In each of these cases, the traffic sent between the DirectAccess client and the DirectAccess

server is encrypted over the Internet. See Selected Server Access Example for more information.

25

The following are the benefits of the selected server access model:

You can easily confine the access of DirectAccess clients to specific application servers.

Provides additional end-to-end authentication and data protection beyond that provided with

traditional virtual private network (VPN) connections.

Can be used with smart cards for an additional level of authorization.

Is fully configurable with the DirectAccess Setup Wizard.

By customizing the default Windows Firewall with Advanced Security connection security

rules created by the DirectAccess Setup Wizard, you can restrict certain users or computers

from accessing particular application servers or specify that certain client applications will not

be able to access intranet resources remotely. However, customization of connection security

rules requires knowledge of and experience with connection security rule design and

configuration.

The following are the limitations of the selected server access model:

Selected servers must run Windows Server 2008 or later. Selected servers cannot run

Windows Server 2003 or earlier.

Selected servers when using IPsec peer authentication without IPsec protection must be

running Windows Server 2008 R2 or later.

End-to-End Access

The end-to-end access model allows you to configure DirectAccess clients so that

communications between DirectAccess clients and all intranet servers perform IPsec peer

authentication, data confidentiality (encryption), and data integrity from the DirectAccess client to

the intranet resource. The traffic sent between DirectAccess clients and servers is encrypted over

both the Internet and the intranet. For more information, see the End-to-end Access Example.

The following are the benefits of the end-to-end access model:

Provides additional end-to-end authentication, data integrity, and data confidentiality beyond

that provided with traditional virtual private network (VPN) connections.

There is less processing overhead on the DirectAccess server, which is acting only as a

router and providing denial of service protection (DoSP) for the IPsec-encrypted DirectAccess

traffic.

By customizing the default Windows Firewall with Advanced Security connection security

rules created by the DirectAccess Setup Wizard, you can define policies that restrict certain

users or computers from accessing particular application servers or specify that certain

applications will not be able to access intranet resources remotely. However, customization of

the default connection security rules requires knowledge of and experience with connection

security rule design and configuration.

The following are the limitations of the end-to-end access model:

26

All intranet application servers accessible to DirectAccess clients must run Windows

Server 2008 or later. Application servers cannot run Windows Server 2003 or earlier.

Your intranet must allow the forwarding of IPsec-encrypted traffic.

Is not fully configurable with the DirectAccess Setup Wizard. You use the DirectAccess Setup

Wizard to create the initial set of DirectAccess client and server Group Policy objects and

settings and then you must customize the default Windows Firewall with Advanced Security

connection security rules.

Cannot use smart cards for an additional level of authorization.

Cannot access IPv4-only intranet resources, even with a Network Address Translation-

Protocol Translation (NAT-PT) or NAT64.

Choose a Configuration Method

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

The DirectAccess Management console

Scripted installation using the Network Shell (Netsh) command-line tool

Manual configuration using Group Policy

The following sections describe the benefits and limitations of each of these methods.

DirectAccess Management ConsoleThe DirectAccess Management Console provides several options for deploying DirectAccess.

The DirectAccess Setup Wizard guides you through four steps to determine how the

DirectAccess deployment should proceed, and before the changes are applied, you have the

option of saving the settings into an Extensible Markup Language (XML) file.

The XML file can be modified and provides a way to examine which options are being set. You

can also use the engine.ps1 PowerShell script to run the XML file. For more information, see

Perform DirectAccess Scripting (http://go.microsoft.com/fwlink/?LinkID=157388).

Scripted installation using Network Shell (Netsh) command-line toolFor customized DirectAccess deployments that need to be completely modified to meet a unique

set of needs, you can create a scripted configuration of the DirectAccess server using Network

Shell (Netsh) commands. These custom scripted installations allow for maximum flexibility and

the creation of unique solutions, including many permutations that are not covered in this Design

Guide.

27

Manual configuration using Group PolicyGroup Policy provides a policy-based method to create, distribute, and apply DirectAccess

settings to DirectAccess clients, DirectAccess servers, and selected servers. The DirectAccess

Setup Wizard automatically creates and configures Group Policy objects and settings. You can

customize your DirectAccess configuration by manually modifying the resulting Group Policy

objects and their settings.

Design for Remote Management

Because DirectAccess client computers are connected to the intranet whenever the DirectAccess

client is connected to the Internet, regardless of whether the user has logged on to the computer,

they can be more easily managed as intranet resources and kept current with Group Policy

changes, operating system updates, anti-malware software updates, and other changes.

Intranet management servers that client computers use to keep themselves current can consist of

the following:

Microsoft System Center Configuration Manager 2007 servers

Windows Update servers

Servers for anti-malware updates, such as antivirus servers

In some cases, intranet servers or computers must initiate connections to DirectAccess clients.

For example, helpdesk department computers can use remote desktop connections to connect to

and troubleshoot remote DirectAccess clients. To ensure that DirectAccess clients will accept

incoming traffic from these types of computers and require the protection of that traffic over the

Internet, you must identify the set of these intranet management computers and configure their

addresses in Step 3 of the DirectAccess Setup Wizard.

Once you have identified the computers, record their names, their Internet Protocol version 4

(IPv4) addresses (if you have no Internet Protocol version 6 (IPv6) infrastructure), or their IPv6

addresses (if you have an IPv6 infrastructure, either their public native or Intra-Site Automatic

Tunnel Addressing Protocol [ISATAP] addresses) and configure them in Step 3 of the

DirectAccess Setup Wizard.

Because DirectAccess clients can be behind network address translators (NATs) and use Teredo

for the IPv6 connectivity across the Internet, any inbound rules for Windows Firewall with

Advanced Security that permit unsolicited incoming traffic from management computers must be

modified to enable edge traversal and must have an inbound ICMPv6 Echo Request rule with

edge traversal enabled. For more information, see Packet Filters for Management Computers

When you are using end-to-end peer authentication with data integrity and remote

management traffic is sent within the intranet tunnel, you should use Encapsulating Security

Protocol (ESP)-Null instead of Authentication Header (AH) for data integrity.

If the computer that is managing a DirectAccess client from the intranet is running

Windows Vista or Windows Server 2008 and IPsec transport mode is required between the

Notes

28

managing computer and the DirectAccess client, both computers must have the same quick

mode lifetimes.

Design Packet Filtering for DirectAccess

Packet filtering must be modified for multiple components on your network to allow the following

types of traffic:

DirectAccess client traffic to and from DirectAccess servers on the Internet

DirectAccess server traffic to and from the intranet

Encapsulated DirectAccess client traffic to and from the intranet

Teredo discovery traffic for DirectAccess clients located behind network address translators

(NATs)

Management server traffic to DirectAccess clients

The following topics describe the required packet filtering for each of these types of traffic:

Packet Filters for Your Internet Firewall

Packet Filters for Your Intranet Firewall

Confining ICMPv6 Traffic to the Intranet

Packet filters for Teredo Connectivity

Packet Filters for Management Computers

Packet Filters for Your Internet Firewall

Most organizations use an Internet firewall between the Internet and the computers on their

perimeter network. This firewall is typically configured with packet filters that only allow specific

types of traffic to and from the perimeter network computers. When you add a DirectAccess

server to your perimeter network, you must configure additional packet filters to allow the traffic to

and from the DirectAccess server for all of the types of traffic that a DirectAccess client uses to

obtain Internet Protocol version 6 (IPv6) connectivity to the DirectAccess server.

If your DirectAccess server is on the Internet Protocol version 4 (IPv4) Internet, you must

configure packet filters on your Internet firewall to allow the following types of IPv4 traffic for the

DirectAccess server:

Protocol 41 inbound and outbound

For DirectAccess clients that use the 6to4 IPv6 transition technology to encapsulate IPv6

packets with an IPv4 header. In the IPv4 header, the Protocol field is set to 41 to indicate an

IPv6 packet payload.

User Datagram Protocol (UDP) destination port 3544 inbound and UDP source port 3544

outbound

29

For DirectAccess clients that use the Teredo IPv6 transition technology to encapsulate IPv6

packets with an IPv4 and UDP header. The DirectAccess server is listening on UDP port

3544 for traffic from Teredo-based DirectAccess clients.

Transmission Control Protocol (TCP) destination port 443 inbound and TCP source port 443

outbound

For DirectAccess clients that use Internet Protocol over Secure Hypertext Transfer Protocol

(IP-HTTPS) to encapsulate IPv6 packets within an IPv4-based HTTPS session. The

DirectAccess server is listening on TCP port 443 for traffic from IP-HTTPS-based

DirectAccess clients.

If your DirectAccess server is on the IPv6 Internet, you must configure packet filters on your

Internet firewall to allow the following types of IPv6 traffic for the DirectAccess server:

Protocol 50

DirectAccess on the IPv6 Internet uses the Internet Protocol security (IPsec) Encapsulating

Security Payload (ESP) to protect the packets to and from the DirectAccess server without

the encapsulation headers required for IPv6 transition technologies. In the IPv6 header, the

Protocol field is set to 50 to indicate an ESP-protected payload.

UDP destination port 500 inbound and UDP source port 500 outbound

DirectAccess on the IPv6 Internet uses the Internet Key Exchange (IKE) and Authenticated

Internet Protocol (AuthIP) protocols to negotiate IPsec security settings. The DirectAccess

server is listening on UDP port 500 for incoming IKE and AuthIP traffic.

All Internet Control Message Protocol for IPv6 (ICMPv6) traffic inbound and outbound

Packet Filters for Your Intranet Firewall

Some organizations use an additional intranet firewall between the perimeter network and the

intranet to filter out malicious traffic that makes it past the Internet firewall and perimeter network

servers. If you use an intranet firewall and the DirectAccess server is on the Internet Protocol

version 4 (IPv4) Internet, you must configure the following additional packet filters:

All IPv4 and Internet Protocol version 6 (IPv6) traffic to and from the DirectAccess server

The DirectAccess server must reach and be reachable by Active Directory Domain Services

(AD DS) domain controllers, management servers, and other intranet resources. You can

begin with this initial filter and then refine the filter over time to allow the subset of traffic

needed by the DirectAccess server.

For AD DS, the DirectAccess server must be able to communicate with the domain controller

that is acting as the primary domain controller (PDC) emulator for the domain in which the

DirectAccess server is a member. The DirectAccess server must also be able to reach at

least one domain controller and at least one global catalog for each domain in which

DirectAccess client computer accounts are members.

Protocol 41 inbound and outbound

30

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) encapsulates IPv6 packets with an

IPv4 header. In the IPv4 header, the Protocol field is set to 41 to indicate an IPv6 packet

payload. Use this packet filter if you are using ISATAP to send IPv6 traffic across your IPv4-

only intranet.

Confining ICMPv6 Traffic to the Intranet

By default, the DirectAccess Setup Wizard creates Group Policy objects for DirectAccess clients

and servers for settings that allow the following behaviors:

Internet Control Message Protocol (ICMP) traffic, for both Internet Protocol version 4 (IPv4)

and Internet Protocol version 6 (IPv6), is exempted from Internet Protocol security (IPsec)

protection

Teredo discovery traffic does not travel within the IPsec tunnels between DirectAccess clients

and servers

These default settings allow Teredo-based DirectAccess clients to perform Teredo discovery of

intranet resources. However, these settings also allow the following:

Any computer with a Teredo or 6to4 client can send Internet Control Message Protocol for

IPv6 (ICMPv6) traffic to intranet locations through the DirectAccess server to probe for valid

intranet destination IPv6 addresses. The amount of this traffic is limited by the Denial of

Service Protection (DoSP) component of the DirectAccess server.

A malicious user on the same subnet as a Teredo-based DirectAccess client can determine

the IPv6 addresses of intranet servers by capturing ICMPv6 Echo Request and Echo Reply

message exchanges.

To prevent these possible security issues, you can modify the default configuration for the

following:

Configure the global IPsec settings for the Group Policy object for DirectAccess clients to not

exempt ICMP traffic from IPsec protection (from the IPsec Settings tab for the properties of

the Windows Firewall with Advanced Security snap-in).

Configure the global IPsec settings for the Group Policy object for the DirectAccess server to

not exempt ICMP traffic from IPsec protection (from the IPsec Settings tab for the properties

of the Windows Firewall with Advanced Security snap-in).

For the Group Policy object for the DirectAccess server, create a new connection security rule

that exempts ICMPv6 traffic when it is tunneled from the DirectAccess server.

For the Group Policy object for DirectAccess clients, create a new connection security rule

that exempts ICMPv6 traffic when it is tunneled to the DirectAccess server.

With these modifications:

All ICMPv6 traffic sent through the DirectAccess server must be sent using a tunnel. Only

DirectAccess clients can send ICMPv6 traffic to intranet locations.

31

Malicious users on the same subnet as the DirectAccess client will only be able to determine

the IPv6 addresses of the DirectAccess client and the DirectAccess server. Intranet IPv6

addresses will be tunneled and encrypted with IPsec.

Although these modifications address the security issues of the default configuration, Teredo

discovery messages can no longer pass through the DirectAccess server and DirectAccess

clients cannot use Teredo as a connectivity method. Therefore, if you make these changes, you

must also do the following:

Disable Teredo client functionality on your DirectAccess clients

From the Group Policy object for DirectAccess clients, set Computer Configuration\

Administrative Templates\Networking\TCPIP Settings\IPv6 Transition Technologies\Teredo

State to Disabled.

Disable Teredo server and relay functionality on your DirectAccess server

Type the netsh interface teredo set state state=disabled command from an administrator-

level command prompt on your DirectAccess server.

If you previously added a packet filter on your Internet firewall to allow Teredo traffic to and

from the DirectAccess server, remove it.

Without Teredo connectivity, DirectAccess clients that are located behind network address

translators (NATs) will use Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS)

for IPv6 connectivity to the DirectAccess server. However, IP-HTTPS-based connections have

lower performance and higher overhead than Teredo-based connections.

Packet filters for Teredo Connectivity

The following packet filters facilitate traffic for DirectAccess clients that use Teredo. If you do not

configure these packet filters, DirectAccess clients that are behind a network address translator

(NAT) will not by default be able to connect to intranet resources or be managed by intranet

management servers.

The alternative is to disable the Teredo client on DirectAccess clients. However, without Teredo

connectivity, DirectAccess clients that are located behind NAT will use Internet Protocol over

Secure Hypertext Transfer Protocol (IP-HTTPS) for Internet Protocol version 6 (IPv6) connectivity

to the DirectAccess server. IP-HTTPS-based connections have lower performance and higher

overhead than Teredo-based connections.

Packet filters to allow inbound ICMPv6 Echo Requests on all computersDirectAccess clients that are behind NATs on the Internet attempt to use Teredo for IPv6

connectivity to the DirectAccess server. DirectAccess clients are Teredo clients to the

DirectAccess server, which is acting as a Teredo server and relay. To ensure that a destination is

32

reachable, Teredo clients send an Internet Control Message Protocol for IPv6 (ICMPv6) Echo

Request message and wait for an ICMPv6 Echo Reply message.

For a Teredo-based DirectAccess client to communicate with an intranet resource, that resource

must accept inbound ICMPv6 Echo Request messages. Therefore, for DirectAccess clients to

reach any location on the intranet, you must allow inbound ICMPv6 Echo Request messages on

all of your intranet hosts.

Enable edge traversal on inbound management trafficIf you are using Windows Firewall with Advanced Security to block unsolicited inbound traffic, you

will already have a set of inbound rules that allow the traffic from your management servers.

Because DirectAccess clients that are located behind NATs will use Teredo for IPv6 connectivity

to the DirectAccess server, you must enable edge traversal on this set of inbound rules.

Enable inbound ICMPv6 Echo Requests for management trafficFor a computer that is being managed to be reachable over Teredo, ensure that the computer has

an inbound rule for ICMPv6 Echo Request messages with edge traversal enabled. The Network

Shell (Netsh) command-line tool command for this rule is the following:

netsh advfirewall firewall add rule name="Inbound ICMPv6 Echo Request with Edge

traversal" protocol=icmpv6:128,0 dir=in action=allow edge=yes profile=public,private

Packet Filters for Management Computers

To allow management computers to initiate connections with your intranet computers, you might

already have in place a set of inbound firewall rules for management traffic on your intranet. To

allow DirectAccess clients to be managed in the same way when they are on the Internet, you

can do one of the following:

Configure your existing set of inbound firewall rules for management traffic so that they also

apply to the public and private profiles and have edge traversal enabled. Although easier to

configure, this option is not recommended because the inbound rules might allow greater

exposure what is intended for DirectAccess management functionality.

Create a duplicate set of inbound firewall rules for your management traffic in the Group

Policy object for DirectAccess clients so that they only apply to the public and private profiles,

have the appropriate source Internet Protocol version 6 (IPv6) addresses of management

computers or the IPv6 prefix of your intranet, and have edge traversal enabled. This is the

recommended option because it applies the rules only to DirectAccess clients, is scoped for

33

your intranet IPv6 addresses or prefix, and does not affect other domain computers on the

intranet or Internet.

For information about creating inbound rules, see Create an Inbound Program or Service Rule

(http://go.microsoft.com/fwlink/?LinkId=159864).

You can enable edge traversal for a Windows Firewall inbound rule in the following ways:

Using the Windows Firewall with Advanced Security snap-in, obtain properties of an inbound

rule. On the Advanced tab, in Edge traversal, select Allow edge traversal.

Use the edge=yes option for the netsh advfirewall firewall command when adding or

changing an inbound rule.

Here is an example of how to use a Network Shell (Netsh) command-line tool command to enable

edge traversal for the built-in Remote Desktop (TCP-In) inbound rule:

netsh advfirewall firewall set rule name=”Remote Desktop (TCP-In)” dir=in new edge=yes

To further ensure that the Remote Desktop connection is authenticated and encrypted, use the

following Netsh command:

netsh advfirewall firewall set rule name=”Remote Desktop (TCP-In)” dir=in new

security=authenc edge=yes

To use the security=authenc setting, ensure that there is a connection security rule that protects

the connection between the remote desktop computer and the DirectAccess client.

If the computer that is managing a DirectAccess client from the intranet is running

Windows Vista or Windows Server 2008 and Internet Protocol security (IPsec) transport

mode is required between the managing computer and the DirectAccess client, both

computers must have the same quick mode lifetimes.

DirectAccess and Third-party Host Firewalls

Because DirectAccess relies on Internet Protocol security (IPsec), Authenticated Internet Protocol

(AuthIP), and Windows Firewall connection security rules, Microsoft recommends that you do not

disable the Windows Firewall service when using a third-party host firewall. When Windows

Firewall is enabled, DirectAccess clients can use the built-in IPsec functionality and Windows

Firewall connection security rules to protect DirectAccess connections and traffic.

Your third-party firewall should be certified by the Microsoft Driver Logo Program for seamless

DirectAccess functionality. For a list of logo requirements and certified third-party host firewalls,

see Windows Quality Online Services (http://go.microsoft.com/fwlink/?Linkid=18084). Check with

your host firewall vendor to see if it supports one of the following options for seamless

DirectAccess functionality:

Uses Windows Firewall functionality.

Microsoft Forefront Client Security is an example.

Uses Windows Firewall categories and does not replace Windows Firewall connection

security (IPsec).

Note

34

Windows Firewall categories allow third-party host firewalls in Windows 7 to selectively

replace specific elements of Windows Firewall functionality while retaining others. Categories

make it possible for third-party host firewalls to operate side-by-side with Windows Firewall.

To determine if Windows Firewall is providing connection security when a third-party host

firewall is installed, type netsh advfirewall monitor show firewall at a command prompt. In

Global Settings, in the Categories section, Windows Firewall should be listed for the

ConSecRuleRuleCategory category.

Third-party host firewalls should also support edge traversal to allow intranet servers and

computers to initiate connections to Teredo-based DirectAccess clients for remote management.

Check the documentation for your third-party host firewall to determine if edge traversal is

supported and how to enable it. If supported, the documentation for your third-party firewall

typically refers to this setting as NAT traversal, enabling Teredo, or IPv6 transition technologies.

For more information, see Enabling Third Party Firewall DirectAccess Clients

(http://go.microsoft.com/fwlink/?LinkId=163777).

For more information about Windows Firewall categories, see INetFwProduct Interface

(http://go.microsoft.com/fwlink/?LinkId=157401).

For more information about third-party firewall requirements for Teredo, see Teredo co-existence

with third-party firewalls (http://go.microsoft.com/fwlink/?Linkid=157705).

Choose an Authentication and Authorization Scheme

By default, the DirectAccess Setup Wizard configures Windows Firewall with Advanced Security

connection security rules that specify the use of the following types of credentials when

negotiating the Internet Protocol security (IPsec) security associations for the tunnels to the

DirectAccess server:

The infrastructure tunnel uses Computer certificate credentials for the first authentication

and User (NTLMv2) for the second authentication. User (NTLMv2) credentials force the use

of Authenticated Internet Protocol (AuthIP) and provide access to a Domain Name System

(DNS) server and domain controller before the DirectAccess client can use Kerberos

credentials for the intranet tunnel.

The intranet tunnel uses Computer certificate credentials for the first authentication and

User (Kerberos V5) for the second authentication.

You can also specify additional authentication with selected server access, peer authentication

methods for end-to-end access, and the use of smart cards for additional authorization.

If you modify the connection security rules created by the DirectAccess Setup Wizard,

you must use Network Shell (Netsh) commands. There are connection security rule

settings that cannot be modified with the Windows Firewall with Advanced Security snap-

in. If you modify these connection security rules with the Windows Firewall with Advanced

Note

35

Security snap-in, they will be overwritten with default values, which can result in

incompatible connection security rules that prevent DirectAccess connections.

Additional end-to-end peer authentication for selected server accessIf you configure selected server access, the DirectAccess Setup Wizard configures Windows

Firewall with Advanced Security connection security rules to use Computer certificate or

Computer (Kerberos V5) credentials for the first authentication and User (Kerberos V5)

credentials for the second authentication to the selected servers.

Peer authentication for end-to-end accessWhen you manually configure the Windows Firewall with Advanced Security connection security

rules for end-to-end access, you can configure your own methods for the first and second IPsec

peer authentication. However, the following are recommended:

First authentication: Computer certificate or Computer (Kerberos V5)

Second authentication: User (Kerberos V5)

If you modify the connection security rules created by the DirectAccess Setup Wizard,

you must use Network Shell (Netsh) commands. There are connection security rule

settings that cannot be modified with the Windows Firewall with Advanced Security snap-

in. If you modify these connection security rules with the Windows Firewall with Advanced

Security snap-in, they will be overwritten with default values, which can result in

incompatible connection security rules that prevent DirectAccess connections.

Smart cards for additional authorizationOn the Connectivity page of Step 2 in the DirectAccess Setup Wizard, you can require the use of

smart cards for access to the intranet. When this option is selected, the DirectAccess Setup

Wizard configures the IPsec connection security rule for the intranet tunnel on the DirectAccess

server to require tunnel mode authorization with smart cards. Tunnel mode authorization is a new

feature of Windows Firewall with Advanced Security for Windows 7 and Windows Server 2008 R2

that allows you to specify that only authorized computers or users can establish an inbound

tunnel.

To use smart cards with IPsec tunnel mode authorization for the intranet tunnel, you must deploy

a public key infrastructure (PKI) with smart cards infrastructure.

Because your DirectAccess clients are using smart cards for access to the intranet, you can also

use authentication mechanism assurance, a new feature of Windows Server 2008 R2, to control

access to resources, such as files, folders, and printers, based on whether the user logged on

with a smart card-based certificate. Authentication mechanism assurance requires a domain

functional level of Windows Server 2008 R2. For more information, see What's New in AD DS:

Authentication Mechanism Assurance (http://go.microsoft.com/fwlink/?LinkId=159947).

Note

36

Allowing access for users with unusable smart cardsTo allow temporary access for users with smart cards that are unusable, do the following:

1. Create an Active Directory security group to contain the user accounts of users who

temporarily cannot use their smart cards.

2. For the DirectAccess server Group Policy object, configure global IPsec settings for IPsec

tunnel authorization and add the Active Directory security group to the list of authorized users.

To grant access to a user that cannot use their smart card, temporarily add their user account to

the Active Directory security group. Remove the user account from the group when the smart

card is usable.

Prompts for smart card credentials while on the intranetDue to the timing between intranet detection and the automatic establishment of tunnels to the

DirectAccess server, it is possible for users of DirectAccess clients using smart cards to be

prompted for smart card credentials when they are directly connected to the intranet. This is a

prompt that users can ignore without loss of connectivity. The solutions to this issue are the

following:

Move the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) routing function to a

separate server and then add packet filters to this server that block all User Datagram

Protocol (UDP) traffic for Internet Key Exchange (IKE) and AuthIP from the Internet Protocol

version 6 (IPv6) address prefix of the intranet to the IPv6 address of the DirectAccess

server’s tunnel endpoint. These filters will drop the tunnel establishment traffic sent by

DirectAccess clients while intranet detection is in progress. For an example of moving the

ISATAP routing function to another server, see Capacity Planning for DirectAccess Servers.

Add a connection security rule that sends tunnel endpoint traffic to an invalid destination while

intranet detection is occurring. For example, use the following Network Shell (netsh)

command-line tool command: netsh advfirewall consec add rule name="Corp

connectivity to prevent smart card prompt" endpoint1=IntranetIPv6Prefix

endpoint2=IntranetIPv6Prefix localtunnelendpoint=InvalidIPv6Address mode=tunnel

action=requireinrequireout auth1=computercert auth1ca="CN=NonExistentCA".

Both of these solutions prevent the tunnel negotiation with the DirectAccess server during intranet

detection when the DirectAccess client is on the intranet. By preventing tunnel negotiation, smart

card authorization will never occur and the user will not be prompted for their smart card

credentials.

Under the covers: Smart card authorizationSmart card authorization works by enabling tunnel mode authorization on the intranet tunnel

connection security rule of the DirectAccess server for a specific Kerberos-based security

identifier (SID). For smart card authorization, this is the well-known SID (S-1-5-65-1), which maps

to smart card-based logons. This SID is present in a DirectAccess client’s Kerberos token and is

37

referred to as “This Organization Certificate” when configured in the global IPsec tunnel mode

authorization settings.

When you enable smart card authorization in Step 2 of the DirectAccess Setup Wizard, the

DirectAccess Setup Wizard configures the global IPsec tunnel mode authorization setting with

this SID for the DirectAccess server Group Policy object. To view this configuration in the

Windows Firewall with Advanced Security snap-in for the DirectAccess server Group Policy

object, do the following:

1. Right click Windows Firewall with Advanced Security, and then click Properties.

2. On the IP Settings tab, in IPsec tunnel authorization, click Customize.

3. Click the Users tab. You should see the “NT AUTHORITY\This Organization Certificate” as

an authorized user.

If you manually configure this setting with the Users tab, you must specify the name

LocalComputerName\This Organization Certificate rather than NT AUTHORITY\This

Organization Certificate.

To perform the equivalent configuration of the DirectAccess Setup Wizard with the Network Shell

(Netsh) command-line tool, use the following commands:

netsh advfirewall consec add rule name=”Smart card tunnel” endpoint1=Intranet IPv6

address space endpoint2=Any localtunnelendpoint=DirectAccess server IPv6 address

remotetunnelendpoint=any auth1=Computercert auth1ca=”Certificate Auth name

certmapping:yes” auth2=userkerb applyauthz=yes

netsh advfirewall set global ipsec authzusergrp=O:LSD:(A;;CC;;;S-1-5-65-1)

Design Active Directory for DirectAccess

DirectAccess clients, DirectAccess servers, and selected servers must be members of an Active

Directory Domain Services (AD DS) domain. DirectAccess also uses Active Directory security

groups and Group Policy objects (GPOs) to identify sets of computers and the sets of settings

that are applied to them.

The DirectAccess Setup Wizard uses security groups to identify the following:

The computer accounts of DirectAccess clients (required)

The computer accounts of application servers for selected server access (optional)

You must create and populate these groups before running the DirectAccess Setup Wizard.

The DirectAccess Setup Wizard creates GPOs for the following:

DirectAccess clients that contains settings for Internet Protocol version 6 (IPv6) transition

technologies, Name Resolution Policy Table (NRPT) rules, intranet detection settings, and

Windows Firewall with Advanced Security connection security rules (required).

The DirectAccess server that contains settings for IPv6 transition technologies and Windows

Firewall with Advanced Security connection security rules (required).

Note

38

Selected servers that contains settings for Windows Firewall with Advanced Security

connection security rules (optional).

If you remove a computer from a DirectAccess client or selected server security group, the next

update of Group Policy will remove the DirectAccess settings from the computer.

Active Directory and the DirectAccess serverThe DirectAccess server must be a domain member and cannot be a domain controller.

Additionally, an Active Directory domain controller cannot be reachable from the Internet interface

of DirectAccess server (the Internet interface cannot be in the domain profile of Windows

Firewall). If either of these is true, the DirectAccess Setup Wizard cannot be run.

If you must have an Active Directory domain controller that is on the perimeter network, and

therefore reachable from the Internet interface of DirectAccess server, you can prevent the

DirectAccess server from reaching it by adding packet filters on the Internet interface of the

DirectAccess server that prevent connectivity to the Internet Protocol (IP) address of the

perimeter network domain controller.

Because the DirectAccess server is an IPv6 router, if you have a native IPv6 infrastructure, the

Internet interface can also reach the domain controllers on the intranet. In this case, add packet

filters to the Internet interface that prevent connectivity to the intranet domain controllers.

DirectAccess and user profiles for remote usersUsing roaming user profiles for DirectAccess clients for all of the contents of the user profile folder

can result in long logon and logoff times. If you want to store user profiles on network locations for

DirectAccess clients, use folder redirection for the folders of the user profile rather than roaming

user profiles for the entire user profile.

For more information, see the Managing Roaming User Data Deployment Guide

(http://go.microsoft.com/fwlink/?LinkId=73435).

Design Your DNS Infrastructure for DirectAccess

The design of your Domain Name System (DNS) infrastructure can impact how you configure

DirectAccess. The biggest design aspect of your DNS infrastructure is whether you use split-brain

DNS.

Split-brain DNSSplit-brain DNS is the use of the same DNS domain for both Internet and intranet resources. For

example, the Contoso Corporation is using split brain DNS; contoso.com is the domain name for

intranet resources and Internet resources. Internet users use http://www.contoso.com to access

39

Contoso’s public Web site and Contoso employees on the Contoso intranet use

http://www.contoso.com to access Contoso’s intranet Web site. A Contoso employee with their

laptop that is not a DirectAccess client on the intranet that accesses http://www.contoso.com sees

the intranet Contoso Web site. When they take their laptop to the local coffee shop and access

that same URL, they will see the public Contoso Web site.

When a DirectAccess client is on the Internet, the Name Resolution Policy Table (NRPT) sends

DNS name queries for intranet resources to intranet DNS servers. A typical NRPT for

DirectAccess will have a rule for the namespace of the organization, such as contoso.com for the

Contoso Corporation, with the Internet Protocol version 6 (IPv6) addresses of intranet DNS

servers. With just this rule in the NRPT, when a user on a DirectAccess client on the Internet

attempts to access the uniform resource locator (URL) for their Web site (such as

http://www.contoso.com), they will see the intranet version. Because of this rule, they will never

see the public version of this URL when they are on the Internet.

If you want users on DirectAccess clients to see the public version of this URL when they are on

the Internet, you must add the fully qualified domain name (FQDN) of the URL as an exemption

rule to the NRPT of DirectAccess clients. However, if you add this exemption rule, users on

DirectAccess clients will never see the intranet version of this URL when they are on the Internet.

For split-brain DNS deployments, you must list the FQDNs that are duplicated on the Internet and

intranet and decide which resources the DirectAccess client should reach, the intranet version or

the public (Internet) version. For each name that corresponds to a resource for which you want

DirectAccess clients to reach the public version, you must add the corresponding FQDN as an

exemption rule to the NRPT for your DirectAccess clients.

In a split-brain DNS environment, if you want both versions of the resource to be available,

configure your intranet resources with alternate names that are not duplicates of the names that

are being used on the Internet and instruct your users to use the alternate name when on the

Intranet. For example, configure and use the alternate name www.internal.contoso.com for the

intranet name www.contoso.com.

In a non-split-brain DNS environment, the Internet namespace is different from the intranet

namespace. For example, the Contoso Corporation uses contoso.com on the Internet and

corp.contoso.com on the intranet. Because all intranet resources use the corp.contoso.com DNS

suffix, the NRPT rule for corp.contoso.com routes all DNS name queries for intranet resources to

intranet DNS servers. DNS name queries for names with the contoso.com suffix do not match the

corp.contoso.com intranet namespace rule in the NRPT and are sent to Internet DNS servers.

With a non-split-brain DNS deployment, because there is no duplication of FQDNs for intranet

and Internet resources, there is no additional configuration needed for the NRPT. DirectAccess

clients can access both Internet and intranet resources for their organization.

DNS server requirements for ISATAPFor the intranet DNS servers that are being used by DirectAccess clients, you must use at least

one DNS server that runs Windows Server 2008 R2, Windows Server 2008 with the Q958194

hotfix (http://go.microsoft.com/fwlink/?LinkId=159951) installed, or Windows Server 2008 with

40

SP2 or later. The DNS Server service in these versions of Windows support processing DNS

name queries on the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) interface.

Alternately, you can use a non-Microsoft DNS server that is capable of listening on ISATAP

interfaces to perform DNS queries and secure DNS dynamic updates.

By default, the DNS Server service in Windows Server 2008 and later blocks name resolution for

the name ISATAP through the DNS Global Query Block List. If you are using ISATAP on your

intranet, you must remove the ISATAP name from the list. For more information, see Managing

the Global Query Block List (http://go.microsoft.com/fwlink/?LinkId=159953).

AAAA records for servers that do not perform DNS dynamic updateFor servers running IPv6-capable non-Windows operating systems that do not support DNS

dynamic update for IPv6 addresses, manually add AAAA records for the names and IPv6

addresses of these servers.

Local name resolution behavior for DirectAccess clientsIf a name cannot be resolved with DNS, the DNS Client service in Windows 7 and Windows

Server 2008 R2 can use local name resolution, with the Link-Local Multicast Name Resolution

(LLMNR) and NetBIOS over TCP/IP protocols, to resolve the name on the local subnet.

Local name resolution is typically needed for peer-to-peer connectivity when the computer is

located on private networks, such as single subnet home networks. When the DNS Client service

performs local name resolution for intranet server names and the computer is connected to a

shared subnet on the Internet, malicious users can capture LLMNR and NetBIOS over TCP/IP

messages to determine intranet server names.

In Step 3 of the DirectAccess Setup Wizard, you configure the local name resolution behavior

based on the types of responses received from intranet DNS servers. You have the following

options:

Use local name resolution only if the internal network DNS servers determined that the name

does not exist

This option is the most secure because the DirectAccess client will only perform local name

resolution for server names that cannot be resolved by intranet DNS servers. If the intranet

DNS servers can be reached, the names of intranet servers will be resolved. If the intranet

DNS servers cannot be reached or if there are other types of DNS errors, the intranet server

names will not be leaked to the subnet through local name resolution.

Use local name resolution if the internal network DNS servers determined that the name does

not exist or if the internal network DNS servers are not reachable and the DirectAccess client

computer is on a private network

41

This option is moderately secure because it allows the use of local name resolution on a

private network when the intranet DNS servers are unreachable.

Use local name resolution if there is any type of error when attempting to resolve the name

using internal network DNS servers

This is the least secure option because the names of intranet network servers can be leaked

to the local subnet through local name resolution.

Choose the option that complies with your security requirements.

NRPT rulesIn step 3 of the DirectAccess Setup Wizard, you configure the rules in the NRPT, an internal table

used by the DNS Client service to determine where to send DNS name queries. The

DirectAccess Setup Wizard automatically creates two rules for DirectAccess clients:

A DNS suffix rule for the domain name of the DirectAccess server and the IPv6 addresses

corresponding to the intranet DNS servers configured on the DirectAccess server. For

example, if the DirectAccess server is a member of the corp.contoso.com domain, the

DirectAccess Setup Wizard creates a rule for the .corp.contoso.com DNS suffix.

An exemption rule for the FQDN of the network location server. For example, if the network

location server URL is https://nls.corp.contoso.com, the DirectAccess Setup Wizard creates

an exemption rule for the FQDN nls.corp.contoso.com.

You might need to configure additional NRPT rules in step 3 of the DirectAccess Setup Wizard in

the following cases:

You need to add more DNS suffixes for your intranet namespace.

If the FDQN of your intranet and Internet CRL distribution points are based on your intranet

namespace, you must add exemption rules for the FQDNs of your Internet and intranet CRL

distribution points.

If you have a split-brain DNS environment, you must add exemption rules for the names of

resources for which you want DirectAccess clients located on the Internet to access the

public (Internet) version, rather than the intranet version.

If you are redirecting traffic to an external Web site through your intranet Web proxy servers,

the external Web site is only available from the intranet, and the external Web site is using

the addresses of your Web proxy servers to permit the inbound requests, then you must add

an exemption rule for the FQDN of the external Web site and specify that the rule use your

intranet Web proxy server, rather than the IPv6 addresses of intranet DNS servers.

For example, the Contoso Corporation is testing an external Web site named

test.contoso.com. This name is not resolvable via Internet DNS servers, but Contoso’s Web

proxy server knows how to resolve the name and to direct requests for the Web site to the

external Web server. To prevent users who are not on the Contoso intranet from accessing

the site, the external Web site only allows requests from the Internet Protocol version 4 (IPv4)

Internet address of the Contoso Web proxy. Therefore, intranet users can access the Web

site because they are using the Contoso Web proxy but DirectAccess users cannot because

42

they are not using the Contoso Web proxy. By configuring an NRPT exemption rule for

test.contoso.com that uses the Contoso Web proxy, Web page requests for test.contoso.com

will be routed to the intranet Web proxy server over the IPv4 Internet.

You can also configure NRPT rules from Computer Configuration\Policies\Windows Settings\

Name Resolution Policy in the Group Policy object for DirectAccess clients.

The maximum number of rules in the NRPT is 1000.

If you are configuring namespace rules and your DNS servers are located outside of the

intranet, you should protect the DNS queries to these servers with either Internet Protocol

security (IPsec) or DNS Security Extensions (DNSSEC).

Unqualified, single-label names and DNS search suffixesUnqualified, single-label names are sometimes used for intranet servers so that you can specify a

single name, such as http://paycheck. The DNS Client service combines these names with your

DNS suffix search list to create a series of FQDNs to resolve with DNS. By default, your

computer’s domain name is in the DNS suffix search list and additional DNS suffixes can be

added. For example, when a user on a computer that is a member of the corp.contoso.com

domain types http://paycheck in their Web browser, Windows constructs the name

paycheck.corp.contoso.com as the FQDN.

You can use the Computer Configuration/Administrative Templates/Network/DNS

Client/ DNS Suffix Search List Group Policy setting to add DNS suffixes to the DNS

suffix search lists of domain-joined client computers.

To ensure that unqualified, single-label names resolve to the same intranet resources whether

DirectAccess clients are connected to the intranet or the Internet, your DNS suffix search list

should match the namespace rules in your NRPT. As a general rule, each DNS suffix for an

intranet namespace should correspond to a namespace rule in your NRPT.

If the name of a server on the local subnet is a duplicate of a server name on the intranet,

the DirectAccess client will always connect to the intranet resource. For example, if your

home network server is named Server1 and there is an intranet server of the same name,

you will always connect to the intranet Server1. To connect to the local subnet resource,

append “.local” to the name of the server. For example, to connect to the local subnet

server named Server1, use the name Server1.local.

External DNSThe DirectAccess Setup wizard configures DirectAccess clients with the IPv4 addresses of the

6to4 relay and the Teredo server with Group Policy settings in Computer Configuration\

Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies.

For the URL for the Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) server

(the IP-HTTPS State setting), the DirectAccess Setup Wizard configures

https://Subject:443/IPHTTPS, in which Subject is the Subject field of the HTTPS certificate that

Notes Note Note

43

you specify in Step 2 of the DirectAccess Setup Wizard. If the Subject field of the IP-HTTPS

certificate is an FQDN, you must ensure that the FQDN is resolvable using Internet DNS servers.

If you modify the 6to4 Relay Name or Teredo Server Name Group Policy settings to use FQDNs

rather than an IPv4 address, you must ensure that the FQDNs are resolvable using Internet DNS

servers.

You must also ensure that the FQDNs for your Internet-accessible certificate revocation list (CRL)

distribution points are resolvable using Internet DNS servers. For example, if the URL

http://crl.contoso.com/crld/corp-DC1-CA.crl is in the CRL Distribution Points field of the IP-HTTPS

certificate of the DirectAccess server, you must ensure that the FQDN crld.contoso.com is

resolvable using Internet DNS servers.

Design Your PKI for DirectAccess

A DirectAccess deployment needs a public key infrastructure (PKI) to issue certificates to

DirectAccess clients, the DirectAccess server, selected servers, and the network location server.

Autoenrollment for computer certificatesThe DirectAccess Setup Wizard allows you to configure the full intranet access and selected

server access models that by default use certificates for Internet Protocol security (IPsec) peer

authentication. The easiest way to get certificates installed on both DirectAccess clients and

servers is to configure autoenrollment for computer certificates. For example, autoenrollment at

the domain level ensures that all domain members obtain a computer certificate from an

enterprise certification authority (CA).

Manual enrollment for network location server and IP-HTTPS certificatesYou also need to manually enroll the following certificates:

An additional certificate on the DirectAccess server for Internet Protocol over Secure

Hypertext Transfer Protocol (IP-HTTPS) authentication

An additional certificate for the network location server for HTTPS authentication

The IP-HTTPS certificate for the DirectAccess server must have the following properties:

In the Subject field, either an Internet Protocol version 4 (IPv4) address of the Internet

interface of the DirectAccess server or the fully qualified domain name (FQDN) of the IP-

HTTPS uniform resource locator (URL).

For the Enhanced Key Usage field, the Server Authentication object identifier (OID).

For the CRL Distribution Points field, a certificate revocation list (CRL) distribution point that is

accessible by DirectAccess clients that are connected to the Internet.

The HTTPS certificate for the network location server must have the following properties:

44

In the Subject field, either an Internet Protocol (IP) address of the intranet interface of the

network location server or the FQDN of the network location URL.

For the Enhanced Key Usage field, the Server Authentication OID.

For the CRL Distribution Points field, a CRL distribution point that is accessible by

DirectAccess clients that are connected to the intranet.

If the DirectAccess server is the network location server, you need an additional certificate for

HTTPS authentication. You cannot use the IP-HTTPS certificate for the network location server

HTTPS certificate. You should configure both certificates with friendly names that indicate their

purpose so that they are easier to select in the DirectAccess Setup Wizard.

Certificate revocation checking and CRL distribution pointsThe following types of connections require a certificate revocation check:

The IP-HTTPS connection between the DirectAccess client and the DirectAccess server.

If the certificate revocation check fails, DirectAccess clients cannot make IP-HTTPS-based

connections to a DirectAccess server. Therefore, an Internet-based CRL distribution point

location must be present in the IP-HTTPS certificate and accessible by DirectAccess clients

that are connected to the Internet.

The HTTPS-based connection between the DirectAccess client and the network location

server.

If the certificate revocation check fails, DirectAccess clients cannot successfully access an

HTTPS-based URL on the network location server. Therefore, an intranet-based CRL

distribution point location must be present in the network location server certificate and be

accessible by DirectAccess clients that are connected to the intranet, even when there are

DirectAccess rules in the NRPT.

The IPsec tunnels between the DirectAccess client and the DirectAccess server.

See “Enabling strong CRL checking for IPsec authentication” in this topic.

For both Internet and intranet-based CRLs, the CRL distribution point must be highly accessible.

CRL distribution points can be accessed through the following:

Web servers using an HTTP-based URL, such as http://crl.corp.contoso.com/crld/corp-DC1-

CA.crl

File servers and accessed through a universal naming convention (UNC) path, such as \\

crl.corp.contoso.com\crld\ corp-DC1-CA.crl

If your intranet CRL distribution points are only reachable over IPv6, you must configure a

Windows Firewall with Advanced Security connection security rule to exempt IPsec

protection from the IPv6 address space of your intranet to the IPv6 addresses of your

CRL distribution points.

Note

45

Enabling strong CRL checking for IPsec authenticationBy default, the DirectAccess server uses weak CRL checking when performing certificate-based

IPsec peer authentication with DirectAccess clients. With weak CRL checking, certificate

revocation checking fails only if the validating computer confirms that the certificate has been

revoked in the CRL. The DirectAccess client does not perform certificate revocation checking by

default. Revoking computer certificates is one way of blocking DirectAccess for specific

DirectAccess clients. A simpler and preferred method is to disable the computer account in Active

Directory. This method immediately prevents DirectAccess connections, such as when a laptop

computer is lost or stolen, and does not have the delay associated with propagating CRL updates

to CRL distribution points.

For an additional level of protection, you can configure strong CRL checking, in which certificate

revocation checking fails if the validating computer confirms that the certificate has been revoked

or for any error encountered during certificate revocation checking, including the inability to

access the CRL distribution point.

If you enable strong CRL checking and the DirectAccess server cannot reach the CRL

distribution point, certificate-based IPsec authentication for all DirectAccess connections

will fail.

If you are using Network Access Protection (NAP) with DirectAccess and you enable

strong CRL checking, certificate-based IPsec authentication for all DirectAccess

connections will fail. Health certificates do not contain CRL distribution points because

their lifetime is on the order of hours, instead of years for computer certificates.

Smart cards for additional authorizationTo use smart cards with IPsec tunnel mode authorization, you must first have a PKI deployment

and a smart card infrastructure. After your smart card deployment has been completed, you

enable smart card authorization on the Connectivity page of Step 2 of the DirectAccess Setup

Wizard.

You should design your PKI to replicate the entire smart card certificate chain to the

current user certificate store in a timely manner. If the PKI is slow in replicating the

certificate chain, users will obtain a smart card certificate and leave the intranet, but be

unable to use smart card authorization. To correct this condition, they might have to

return to the intranet and logon with their smart card credentials to force the PKI to install

the entire certificate chain in the local user’s certificate store.

Design your Web Servers for DirectAccess

You will need Web locations for the following resources:

Notes Note

46

The network location server through a Secure Hypertext Transfer Protocol (HTTPS)-based

uniform resource locator (URL) (required)

An HTTP-based certificate revocation list (CRL) distribution point for the HTTPS certificate of

the network location server that is accessible on the intranet (optional)

An HTTP-based CRL distribution point for the Internet Protocol over HTTPS (IP-HTTPS)

certificate of the DirectAccess server that is accessible on the Internet (optional)

The intranet and Internet CRL distribution points can also be based on a universal

naming convention (UNC) path of a file server.

In all of these cases, the Web server providing these resources must be highly available. If these

resources cannot be reached, the following occurs:

If the DirectAccess client on the intranet is unable to reach the HTTPS-based URL of the

network location server, a DirectAccess client cannot detect when it is on the intranet and

might not be able to access intranet resources.

If the DirectAccess client on the intranet is unable to reach the intranet CRL distribution point

to perform certificate revocation checking for the network location server, a DirectAccess

client cannot detect when it is on the intranet and might not be able to access intranet

resources.

If the DirectAccess client on the Internet is unable to reach the Internet CRL distribution point

to perform certificate revocation checking for the IP-HTTPS certificate, a DirectAccess client

cannot use IP-HTTPS. Because IP-HTTPS is the last transition technology that is used for

Internet Protocol version 6 (IPv6) connectivity to the DirectAccess server, DirectAccess

clients will not be able to establish a connection to the DirectAccess server when behind a

firewall or Web proxy or behind a network address translator (NAT) when the Teredo client

has been disabled.

If you configure strong CRL checking on the DirectAccess server and it cannot reach the CRL

distribution points in the DirectAccess client’s certificate, certificate-based authentication for

the IPsec tunnels will fail and DirectAccess clients will be unable to access intranet

resources.

For Internet Information Services (IIS)-based Web servers, see Planning Redundancy for a

Network Location Server and Planning Redundancy for CRL Distribution Points for information

about high availability for Web servers.

Choose an Internet Traffic Separation Design

With Internet Protocol version 6 (IPv6) and the Name Resolution Policy Table (NRPT),

DirectAccess clients by default separate their intranet and Internet traffic in the following way:

Domain Name System (DNS) name queries for intranet fully qualified domain names

(FQDNs) and all intranet traffic is exchanged over the tunnels created with the DirectAccess

server or directly with intranet servers. Intranet traffic from DirectAccess clients is IPv6 traffic.

Note

47

DNS name queries for FQDNs that correspond to exemption rules or do not match the

intranet namespace and all traffic to Internet servers is exchanged over the physical interface

that is connected to the Internet. Internet traffic from DirectAccess clients is typically Internet

Protocol version 4 (IPv4) traffic.

This is the default and recommended operation of DirectAccess.

In contrast, some remote access virtual private network (VPN) implementations, including the

VPN client in Windows 7, by default send all of their traffic—both intranet and Internet—over the

remote access VPN connection. Internet-bound traffic is routed by the VPN server to intranet

IPv4 Web proxy servers for access to IPv4 Internet resources. It is possible to separate the

intranet and Internet traffic for remote access VPN clients using split tunneling, in which you

configure the Internet Protocol (IP) routing table on VPN clients so that traffic to intranet locations

is sent over the VPN connection and traffic to all other locations is sent using the physical

interface connected to the Internet.

You can configure DirectAccess clients to send all of their traffic through the tunnels to the

DirectAccess server with force tunneling. When force tunneling is configured, DirectAccess

clients that detect that they are on the Internet modify their IPv4 default route so that default route

IPv4 traffic is not sent. With the exception of local subnet traffic, all traffic sent by the

DirectAccess client is IPv6 traffic that goes through tunnels to the DirectAccess server.

Enabling force tunneling has the following consequences:

DirectAccess clients use only Internet Protocol over Secure Hypertext Transfer Protocol (IP-

HTTPS) to obtain IPv6 connectivity to the DirectAccess server over the IPv4 Internet. IP-

HTTPS-based connections have lower performance and higher overhead on the

DirectAccess server than 6to4 and Teredo-based connections.

The only locations that a DirectAccess client can reach by default with IPv4 traffic are those

on its local subnet. All other traffic sent by the applications and services running on the

DirectAccess client is IPv6 traffic sent over the DirectAccess connection. Therefore, IPv4-only

applications on the DirectAccess client cannot be used to reach Internet resources, except

those on the local subnet.

Connectivity to the IPv4 Internet must be done through servers and devices on the intranet

that translate the IPv6 traffic from DirectAccess clients to IPv4 traffic for the IPv4 Internet. If

you do not have the appropriate servers or translators, your DirectAccess clients will not have

access to IPv4 Internet resources, even though they are directly connected to the IPv4

Internet.

To configure force tunneling, you must enable force tunneling on DirectAccess clients through

Group Policy and add a special entry in the NRPT.

To enable force tunneling with Group Policy, enable the Computer Configuration\Policies\

Administrative Templates\Network\Network Connections\Route all traffic through the

internal network setting in the Group Policy object for DirectAccess clients.

To make IPv4-based Internet resources available to DirectAccess clients that use force tunneling,

you can do one of the following:

48

Use a dual protocol (IPv4 and IPv6) proxy server, which can receive IPv6-based requests for

Internet resources and translate them to requests for IPv4-based Internet resources.

Place a Network Address Translation-Protocol Translation (NAT-PT) or NAT64 in front of your

IPv4-based proxy server. The NAT-PT or NAT64 will translate IPv6-based proxy requests to

IPv4-based requests before they are serviced by your IPv4-based proxy server.

To route DNS name resolution and connection traffic to these servers or devices for translation

and forwarding to the IPv4 Internet, you must add a rule to the NRPT for DirectAccess clients that

specifies any DNS suffix and the IPv6 address of the translation server or device.

If you are configuring the NRPT through the DirectAccess Setup Wizard, add a rule for the

following:

Name suffix is set to “.”

DNS server IPv4 or IPv6 addresses are set to the static IPv4 or IPv6 addresses of the dual-

protocol proxy server, NAT-PT, or NAT64

If you are configuring the NRPT through the Computer Configuration\Policies\Windows Settings\

Name Resolution Policy Group Policy setting, create a rule with the following:

The Any suffix

Enabled for DirectAccess

For DNS servers, add the static IPv6 addresses of the dual-protocol proxy server, NAT-PT, or

NAT64

With this NRPT rule, a DirectAccess client sends DNS name queries that do not match any of the

other rules in the NRPT to the IPv6 address of the dual-protocol proxy server, NAT-PT, or NAT64.

Due to the infrastructure requirements and reduced performance for accessing IPv4

Internet resources, Microsoft does not recommend the use of force tunneling for

DirectAccess.

Force tunneling relies on modifying the IPv4 default route in the IPv4 routing table to

prevent the DirectAccess client computer from sending traffic directly to IPv4 Internet

locations. A user with administrative rights can modify their IPv4 default route to point to

their Internet service provider’s router on the subnet.

Design Protection for Traffic between DirectAccess Clients

DirectAccess clients on the Internet can communicate with each other directly without having to

go through the DirectAccess server. For example, two DirectAccess clients on the Internet named

DACL1 and DACL2 have public Internet Protocol version 4 (IPv4) addresses and configure

themselves as 6to4 hosts with 6to4 addresses. DACL1 and DACL2 register their 6to4 addresses

with intranet DNS servers. When DACL1 initiates communication with DACL2 by name, the

intranet DNS server responds with the 6to4-based address of DACL2. DACL1 then uses 6to4

tunneling to communicate directly with DACL2.

Notes

49

Without data confidentiality, the traffic between DACL1 and DACL2 is sent as clear text. Some

applications provide their own data confidentiality and some—such as Remote Assistance,

Remote Desktop, and File and Printer Sharing—do not. To protect the traffic between

DirectAccess clients for all applications, do the following:

1. Create a connection security rule with the following properties:

Rule Type: Isolation

Requirements: Request authentication for inbound and outbound connections

Authentication Method: Computer Certificate for the first authentication

Profile: Private and Public

To configure this connection security rule using the Network Shell (Netsh) command-line tool,

you can use the following command:

netsh advfirewall consec add rule endpoint1=any endpoint2=any

action=requestinrequestout profile=public,private auth1=computercert

auth1ca=CA_Name

2. Create a connection security rule with the following properties:

Rule Type: Custom

Endpoints: Endpoint 1 address for your intranet IPv6 prefix, Endpoint 2 address for your

intranet IPv6 prefix

Requirements: No authentication

Protocols and Ports: Any

Profile: Domain, Private, and Public

3. Create an inbound rule for each application that needs to accept unsolicited inbound

connection requests.

For example, for Remote Desktop, the inbound rule has the following properties:

Rule Type: Port

Protocols and Ports: Transmission Control Protocol (TCP) 3389

Action: Allow the connection if it is secure, Require the connections to be encrypted

Profile: Private and Public

To configure this Windows Firewall rule for Remote Desktop using Netsh.exe, you can use

the following command:

netsh advfirewall firewall add rule name=RemoteDesktop profile=public,private

program=system action=allow security=authenc protocol=tcp localport=3389

For additional protection, you can require protection for all inbound connections to the

DirectAccess client. You can specify this when creating the rule in the following ways:

From the Windows Firewall with Advanced Security snap-in, on the Requirements page,

select Require authentication for inbound connections and request authentication for

outbound connections instead of Request authentication for inbound and outbound

connections.

50

For the Network Shell (Netsh) command, specify the action=requireinrequestout parameter

instead of action=requestinrequestout.

With this additional protection, outbound connections to other DirectAccess clients is encrypted

regardless of the application. Outbound connections to Internet destinations and non-

DirectAccess clients is sent as clear text.

Design Your Intranet for Corporate Connectivity Detection

Computers running Windows 7 or Windows Server 2008 R2 use corporate connectivity detection

to determine whether the computer can access the resources of your intranet. Corporate

connectivity detection is separate from network location detection. A DirectAccess client can

successfully detect corporate connectivity when it is directly connected to the intranet or when it is

roaming on the Internet. Corporate connectivity determination is used for the following:

Active Directory® Domain Services (AD DS) domain members detect corporate connectivity

before initiating updates of Group Policy settings.

Network Access Protection (NAP) clients use successful corporate connectivity detection to

perform another health check if the NAP client determines that it is unhealthy because it

could not reach a NAP health policy server in a previous heath check.

DirectAccess clients use corporate connectivity detection to determine when to use Internet

Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS). If the DirectAccess client

cannot access intranet resources using Teredo, it attempts to connect to the DirectAccess

server using IP-HTTPS.

Corporate connectivity detection relies on the ability to perform the following checks for different

purposes, depending on the computer’s configuration:

Resolve a specific intranet fully qualified domain name (FQDN) name to a specific Internet

Protocol version 6 (IPv6) address.

Determine whether an Internet Protocol security (IPsec) security association (SA) has been

established for an IPv6 address that is based on the IPv6 prefix of the intranet.

Access a specific intranet Web site.

The DirectAccess Setup Wizard automatically configures the following for corporate connectivity

detection:

The intranet-specific name and IPv6 address and registers the corresponding AAAA record in

an intranet Domain Name System (DNS) server.

The IPv6 prefix of the intranet.

The DirectAccess Setup Wizard does not automatically configure the settings and infrastructure

needed for DirectAccess clients to access a specific intranet Web site. This additional

configuration is required for branch scenarios in which a Web proxy server is between the

51

DirectAccess client and the intranet resources that it is trying to reach. This additional

configuration also aids in diagnosing DirectAccess connections.

To configure settings and infrastructure needed for DirectAccess clients to access a specific

intranet Web site, do the following:

1. Determine a Web site on your intranet that is not accessible from the Internet, is highly

available, and is reachable with IPv6. To ensure its ongoing reachability with IPv6, either

assign a static IPv6 address if you have a native IPv6 infrastructure or a static Internet

Protocol version 4 (IPv4) address if you are using Intra-Site Automatic Tunnel Addressing

Protocol (ISATAP). For example, the Contoso Corporation uses cweb.corp.contoso.com as its

central, highly-available intranet Web site. This Web server uses ISATAP and a static IPv4

address.

2. Enable the Computer Configuration/Policies/Administrative

Templates/Network/Network Connectivity Status Indicator/Corporate Website Probe

URL Group Policy setting in the Group Policy object for DirectAccess clients and configure it

for the highly available intranet URL. For example, enable and configure the Corporate

Website Probe URL setting with http://cweb.corp.contoso.com.

If the name of the highly-available intranet Web site changes, you will have to update the

Corporate Website Probe URL setting with the new URL.

You also need to add the IPv6 address for the infrastructure tunnel endpoint to the Computer

Configuration/Policies/Administrative Templates/Network/Network Connectivity Status

Indicator/Corporate Site Prefix List Group Policy setting in the Group Policy object (GPO) for

DirectAccess clients. The IPv6 address for the infrastructure tunnel endpoint is configured in the

Windows Firewall with Advanced Security connection security rule named DirectAccess Policy-

ClientToDnsDc in the GPO for DirectAccess clients.

If you use the Use local name resolution if the internal network DNS servers

determined that the name does not exist or if the internal network DNS servers are

not reachable and the DirectAccess client computer is on a private network option

for local host name resolution, the Corporate Website Probe URL setting must be

specified as a FQDN, rather than an unqualified, single-label name. If you use an

unqualified, single-label name, corporate connectivity detection might incorrectly detect

that corporate connectivity exists and diagnostics for DirectAccess can be affected.

Choose a DirectAccess and VPN Coexistence Design

Because the migration of remote access virtual private network (VPN) solution to DirectAccess

will take time, both of these solutions for remote access connectivity to intranet resources can be

used simultaneously for different sets of clients. For example, intranet client computers running

Windows Vista or Windows XP can continue to use your remote access VPN solution and

computers running Windows 7 can begin to use DirectAccess.

Note Note

52

If a computer running Windows 7 is both a DirectAccess client and a remote access VPN client,

ensure the following:

The remote access VPN server is not blocking access to the network location server on the

intranet, even when the network access of VPN clients is restricted. When the remote access

VPN connection is active, the DirectAccess client should successfully detect that it is located

on the intranet, regardless of its VPN-based network access status (restricted or full access).

Firewall or connection security rules of the DirectAccess client should not block access to

locations needed to remediate the system health of the computer when it has its access

restricted as a remote access VPN client.

The fully qualified domain name (FQDN) of the VPN server on the Internet either does not

match the intranet namespace or there is a corresponding exemption rule for the FQDN in the

Name Resolution Policy Table (NRPT).

The same computer acting as a DirectAccess server and a remote access VPN server with

Routing and Remote Access is not a supported configuration, except when used with Microsoft

Forefront Unified Access Gateway (UAG). For more information, see Overview of Forefront UAG

(http://go.microsoft.com/fwlink/?LinkId=160322).

DirectAccess and third-party VPN clientsWhen deploying DirectAccess with third-party VPN clients, it may be necessary to set the

following registry values to enable the seamless coexistence of the two remote access solutions:

Some third-party VPN clients do not create connections in the Network Connections folder.

This can cause DirectAccess to determine it has no intranet connectivity when the VPN

connection is established and connectivity to the intranet exists. This condition occurs when

third-party VPN clients register their interfaces by defining them as Network Device Interface

Specification (NDIS) ENDPOINT types. You can enable coexistence with these types of VPN

clients by setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\

NlaSvc\Parameters\ShowDomainEndpointInterfaces (REG_DWORD) registry value to 1

on DirectAccess clients.

Some third-party VPN clients use a split-tunneling configuration, which allows the VPN client

computer to access the Internet directly, without having to send the traffic through the VPN

connection to the intranet. Split-tunnel configurations typically leave the Default Gateway

setting on the VPN client as either not configured or as all zeros (0.0.0.0) . You can confirm

this behavior by establishing a successful VPN connection to your intranet and using the

Ipconfig.exe tool at command prompt to display the Default Gateway setting for the VPN

connection. By default, the DirectAccess client does not identify these types of configurations.

To configure DirectAccess clients to detect these types of VPN client configurations and

coexist with them, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\

services\NlaSvc\Parameters\Internet\ EnableNoGatewayLocationDetection

(REG_DWORD) registry value to 1.

For more information about third-party VPN clients that provide their own implementations of

Internet Protocol security (IPsec), see Recommendations for Virtual Private Network Client

53

Coexistence with the Internet Protocol Security Implementation in Microsoft Windows

(http://go.microsoft.com/fwlink/?LinkId=163776).

Planning the Placement of a DirectAccess Server

The DirectAccess server is a required component of any DirectAccess design. A DirectAccess

server must be running Windows Server 2008 R2.

See the following topics for more information about DirectAccess server deployment:

When to Install a DirectAccess Server

Where to Place the DirectAccess Server

Planning Redundancy for a DirectAccess Server

When to Install a DirectAccess Server

All DirectAccess designs described in this guide require that you install at least one DirectAccess

server. In some cases, there are more than one DirectAccess server to provide redundancy and

increased capacity.

For more information, see the following topics:

Planning Redundancy for a DirectAccess Server

DirectAccess Capacity Planning

Where to Place the DirectAccess Server

Because DirectAccess servers provide intranet connectivity to DirectAccess clients on the

Internet, DirectAccess servers are installed in your perimeter network, typically between your

Internet-facing firewall and your intranet. The following figure shows an example.

The DirectAccess server must be joined to an Active Directory domain, running Windows

Server 2008 R2, and have at least two physical network adapters installed.

The DirectAccess server must have at least two, consecutive public Internet Protocol version 4

(IPv4) addresses assigned to the interface that is connected to the perimeter network, or, in the

54

absence of an Internet firewall, connected directly to the Internet. Addresses in the ranges

10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are private IPv4 addresses and cannot be used.

The DirectAccess server requires two consecutive public IPv4 addresses so that it can act as a

Teredo server and Windows-based Teredo clients can use the DirectAccess server to perform

detection of the type of network address translator (NAT) that they are behind. For more

information, see Teredo Overview (http://go.microsoft.com/fwlink/?Linkid=157322).

The DirectAccess Management console sorts the public IPv4 addresses assigned to the

Internet adapter lexigraphically, rather than numerically. In a lexigraphic sort, numbers are

sorted alphabetically. Therefore, the DirectAccess Management console does not

consider the following sets of addresses as consecutive: w.x.y.9 and w.x.y.10, which is

sorted as w.x.y.10, w.x.y.9; w.x.y.99 and w.x.y.100, which is sorted as w.x.y.100, w.x.y.99;

w.x.y.1, w.x.y.2, and w.x.y.10, which is sorted as w.x.y.1, w.x.y.10, w.x.y.2. Use a different

set of consecutive addresses.

On the DirectAccess server, you install the DirectAccess Management Console feature through

Server Manager. You use the DirectAccess management console to configure DirectAccess

settings for the DirectAccess server and clients and monitor the status of the DirectAccess server.

DirectAccess servers should not host any other primary functions; they should be dedicated to

DirectAccess.

Planning Redundancy for a DirectAccess Server

To provide service redundancy for DirectAccess, use Microsoft Forefront Unified Access Gateway

(UAG) for scalability, high-availability, and enhanced management for a DirectAccess

deployment. For more information, see UAG and DirectAccess (http://go.microsoft.com/fwlink/?

LinkId=159955).

To provide hardware redundancy, 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

protect the system from a single node failure for the DirectAccess server.

In addition to the DirectAccess Setup Wizard, you need the following configuration:

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 (NIC)

teaming is not supported.

A fourth network adapter is a requirement if the Hyper-V clustering solution is using iSCSI

interfaces.

The Hyper-V servers are joined to the domain and connected to the appropriate

networks.

Note

55

Ensure that the Hyper-V nodes are enabled to support Data Execution Prevention and

Processor Virtualization.

Make the following Hyper-V configuration settings:

To improve overall performance, configure the following 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 VM resource is migrated or recovers from a node failure.

To speed up client reconnection in the event of a quick migration or node failure, set the

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\ Oakley\

NLBSFlags registry value to 1 on the DirectAccess virtual machine for faster idle timeout of

IPsec security associations (SAs). 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 SAs. The Hyper-V nodes do not need this configuration change.

With Hyper-V and Failover Clustering the primary failover mechanisms are the following:

Live migration

There should be no discernable client connectivity outage when the clustered DA server is

live migrated.

Quick migration

With the NLBSFlags registry value set to 1, the maximum client connectivity outage on a

quick migration should be less than two minutes.

Resource move

With the NLBSFlags registry value set to 1, the maximum client connectivity outage on a

manual resource move should be less than two minutes.

Hyper-V and Failover Clustering also support automatic recovery from a single node failure.

When failover occurs, a client should get reconnected within two minutes; there is no action

needed from the user to get reconnected. If the NLBSFlags registry value is set to 1 and the host

is back online in less than two minutes, the maximum client connectivity outage on a mode failure

should be less than two minutes.

Planning the Placement of a Network Location Server

The network location server is a required component of any DirectAccess design. To function as a

network location server, a computer must be able to host and service requests for a Secure

Hypertext Transfer Protocol (HTTPS)-based uniform resource locator (URL).

56

Where to Place the Network Location Server

The network location server is a critical part of a DirectAccess deployment. If DirectAccess client

computers on the intranet cannot successfully locate and access the secure Web page on the

network location server, they might not be able to access intranet resources.

When DirectAccess clients obtain a physical connection to the intranet or experience a network

status change on the intranet (such as an address change when roaming between subnets), they

attempt a Secure Hypertext Transfer Protocol (HTTPS) connection to a configured uniform

resource locator (URL). If the DirectAccess client can successfully obtain an HTTPS connection

to the location in the configured URL, including a revocation check of the Web server’s certificate,

they determine that they are on the intranet.

To ensure that the FQDN of the network location server is reachable for a DirectAccess client with

DirectAccess-based rules in the NRPT, the DirectAccess Setup Wizard by default adds the FQDN

of the network location server as an exemption rule to the NRPT. When the DirectAccess client

attempts to resolve the FQDN of the network location server, the FQDN matches the exemption

rule in the NRPT and the DirectAccess client uses interface-configured DNS servers, which are

reachable to resolve the name and connect to the network location server.

Because the FQDN of network location URL is added as an exemption rule to the NRPT,

the intranet Web server at that FQDN will not be accessible to DirectAccess clients on the

Internet.

To ensure that DirectAccess clients can correctly detect when they are on the Internet,

DirectAccess clients on the Internet must not be able to successfully access the network location

URL. You can accomplish this by ensuring that the FQDN cannot be resolved using Internet DNS

servers, configuring the Web server to deny connections from Internet-based clients, or by

ensuring that the certificate validation process fails when DirectAccess clients are on the Internet.

In the DirectAccess Setup Wizard, you can specify that the DirectAccess server act as the

network location server or you can type the HTTPS-based URL for network location, specifying a

network location server that is separate from the DirectAccess server. Using a separate network

location server that is a highly available intranet Web server is strongly recommended.

Highly available intranet Web server as the network location server The recommended configuration for a network location server is a highly available and,

depending on the number of DirectAccess clients, high-capacity intranet Web server. The Web

server must be able to support HTTPS-based URLs with certificate-based authentication. Internet

Information Services 7.0, included with Windows Server 2008 R2 and Windows Server 2008, can

be used as a network location server. The content of the HTTPS-based URL is not important, only

the DirectAccess client’s ability to successfully access the page at the URL.

The certificate used by the Web server to act as a network location server has the following

requirements:

Note

57

In the Subject field, either an Internet Protocol (IP) address of the intranet interface of the

Web server or the FQDN of the network location URL.

For the Enhanced Key Usage field, the Server Authentication object identifier (OID).

For the CRL Distribution Points field, a certificate revocation list (CRL) distribution point that is

accessible by DirectAccess clients that are connected to the intranet.

The FQDN in the URL or the universal naming convention (UNC) path of the CRL distribution

point location should either match an exemption rule or no rules in the NRPT so that the

DirectAccess client can use interface-configured intranet DNS servers to resolve the name. If the

DirectAccess client cannot resolve the FQDN in the URL or UNC of the CRL distribution point,

access the CRL distribution point, and verify that the network location server’s certificate has not

been revoked, intranet detection fails.

DirectAccess server as the network location server If you have to use the DirectAccess server as the network location server, which is highly

discouraged, you must do the following:

Install the Web server (IIS) server role on the DirectAccess server computer.

Obtain an additional certificate to be used for HTTPS connections to the DirectAccess server

from DirectAccess clients on the intranet.

This additional certificate must be a different certificate than that used for Internet Protocol over

HTTPS (IP-HTTPS) connections and have the following properties:

In the Subject field, either an IP address of the intranet interface of the DirectAccess server or

the FQDN of the network location URL.

For the Enhanced Key Usage field, the Server Authentication OID.

For the CRL Distribution Points field, a CRL distribution point that is accessible by

DirectAccess clients that are connected to the intranet.

To ensure that DirectAccess clients can correctly detect when they are on the Internet, you can

configure IIS on the DirectAccess server to deny connections from Internet-based clients with the

IP and Domain Restrictions Web server (IIS) role service or ensure that the CRL distribution point

location in the certificate being used for network location cannot be accessed from the Internet.

Planning Redundancy for a Network Location Server

For Internet Information Services (IIS)-based Web servers that are acting as network location

servers, you can configure redundancy with Network Load Balancing. For more information, see

Overview of the Network Load Balancing Deployment Process (http://go.microsoft.com/fwlink/?

LinkId=159956).

58

Planning the Placement of CRL Distribution Points

Certificate revocation list (CRL) distribution points are a critical component of the following

aspects of DirectAccess:

DirectAccess clients use certificate revocation checking to validate the DirectAccess server

certificate for Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS)

connections. Without a reachable CRL distribution point on the Internet, all IP-HTTPS-based

DirectAccess connections will fail.

DirectAccess clients use certificate revocation checking to validate the certificate for the

HTTPS connection to the network location server. Without a reachable CRL distribution point

on the intranet, intranet detection fails, which can impair intranet connectivity for DirectAccess

clients.

Where to Place the CRL Distribution Points

You need certificate revocation list (CRL) distribution points on both the intranet (for intranet

detection) and the Internet (for Internet Protocol over Secure Hypertext Transfer Protocol [IP-

HTTPS] connections).

Intranet location for intranet detection For intranet detection, you must configure your public key infrastructure (PKI) to publish the CRL

in a location that is resolvable and accessible from DirectAccess clients on the intranet. Use

either a fully qualified domain name (FQDN) that does not match the intranet namespace or add

the FQDN in the Name Resolution Policy Table (NRPT) as an exemption rule.

The CRL distribution point should be hosted on an intranet Web or file server that provides high

availability and, depending on the number of DirectAccess clients, high capacity.

Internet location for IP-HTTPS connections For IP-HTTPS connections, you must configure your PKI to publish the CRL in a location that is

resolvable and accessible from DirectAccess clients on the Internet. Either use an FQDN that

does not match the intranet namespace or add the FQDN in the NRPT as an exemption rule.

The CRL distribution point should be hosted on an Internet-facing and publically accessible Web

or file server that provides high availability and, depending on the number of DirectAccess clients,

high capacity.

59

Planning Redundancy for CRL Distribution Points

If the intranet certificate revocation list (CRL) distribution point becomes unavailable, intranet

detection will fail for DirectAccess clients on the intranet. If the Internet CRL distribution point

becomes unavailable, DirectAccess clients on the Internet will be unable to use Internet Protocol

over Secure Hypertext Transfer Protocol (IP-HTTPS)-based connections to the DirectAccess

server.

For CRL distribution point redundancy, you can do the following:

For a single CRL distribution point, you can configure redundancy for Internet Information

Services (IIS)-based Web servers or Windows Server 2008 R2 or Windows Server 2008-

based file servers with Network Load Balancing. For more information, see Overview of the

Network Load Balancing Deployment Process (http://go.microsoft.com/fwlink/?

LinkId=159956).

You can also configure multiple CRL distribution points on different Web or file servers on

your intranet or the Internet.

Planning DirectAccess with Network Access Protection (NAP)

Network Access Protection (NAP) for DirectAccess connections is the use of a health certificate

for the Internet Protocol security (IPsec) peer authentication of the intranet tunnel. A health

certificate is a certificate with the System Health object identifier (OID). A NAP client can only

obtain a health certificate from a Health Registration Authority (HRA) if it complies with system

health requirements as configured on a NAP health policy server.

Using NAP for enforcement of system health for DirectAccess connections requires the

deployment of the IPsec enforcement method, which includes the following elements:

NAP health policy servers

HRAs on the intranet

NAP certification authorities (CAs)

Remediation servers

NAP client settings

For information about how to deploy IPsec enforcement, see IPsec Enforcement Design

(http://go.microsoft.com/fwlink/?LinkId=160131).

In your deployment of IPsec enforcement, on the DirectAccess server, you need to install an

IPsec exemption certificate and set the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\

Microsoft\NetworkAccessProtection\ClientConfig\IkeNapUseHeuristic registry value

(REG_DWORD) to 1.

60

To prevent timing problems that might occur when obtaining Kerberos authentication and

accessing the Web location on the intranet HRA, you can configure Internet Information

Services (IIS) on the HRA to use NTLM authentication with the %windir%\system32\

inetsrv\appcmd.exe set config

-section:system.webServer/security/authentication/windowsAuthentication /-

providers.[value='Negotiate'] command.

Configuration changes for the infrastructure tunnelTo allow DirectAccess clients the ability to obtain a health certificate from an HRA on the intranet

and to remediate their noncompliant system health, you must make the following configuration

changes:

For the Group Policy object for DirectAccess clients, add the Internet Protocol version 6

(IPv6) addresses of your intranet HRAs and remediation servers to the set of accessible

endpoints in the DirectAccess Policy-ClientToDnsDc connection security rule.

For the GPO for DirectAccess servers, add the IPv6 addresses of your intranet HRAs and

remediation servers to the set of accessible endpoints in the DirectAccess Policy-

DaServerToDnsDc connection security rule.

If you are using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) for intranet IPv6

connectivity, you must assign static Internet Protocol version 4 (IPv4) addresses to your HRAs

and remediation servers. If you are using native IPv6 connectivity, you must assign static IPv6

addresses to your HRAs and remediation servers.

If you modify the connection security rules created by the DirectAccess Setup Wizard,

you must use Network Shell (Netsh) commands. There are connection security rule

settings that cannot be modified with the Windows Firewall with Advanced Security snap-

in. If you modify these connection security rules with the Windows Firewall with Advanced

Security snap-in, they will be overwritten with default values, which can result in

incompatible connection security rules that prevent DirectAccess connections.

Configuration changes for the intranet tunnelAfter you have confirmed that health certificates are being obtained by compliant NAP clients, you

must choose the NAP enforcement mode for your DirectAccess clients:

In reporting mode, DirectAccess clients will be able to perform peer authentication for the

intranet tunnel on the DirectAccess server even when they are not compliant with system

health requirements. Users on noncompliant DirectAccess clients receive no notification that

they are not compliant.

In deferred enforcement mode, DirectAccess clients will be able to perform peer

authentication for the intranet tunnel on the DirectAccess server even when they are not

compliant with system health requirements. However, users on noncompliant DirectAccess

Note Note

61

clients receive a notification that they are not compliant and a date by which they will no

longer be able to connect if they are still noncompliant.

In full enforcement mode, DirectAccess clients will not be able to perform peer authentication

for the intranet tunnel when they are not compliant with system health requirements. Users on

noncompliant DirectAccess clients will receive a notification that they are not compliant.

For reporting mode and deferred enforcement mode, there are no changes that need to be made

to the settings of the Group Policy objects for the intranet tunnel. For full enforcement mode, you

must make the following configuration changes:

For the GPO for DirectAccess servers, require health certificates for the Computer certificate

authentication method in the DirectAccess Policy-DaServerToDnsDc connection security rule.

For the GPO for DirectAccess servers, require health certificates for the Computer certificate

authentication method in the DirectAccess Policy-DaServerToMgmt connection security rule.

For the GPO for DirectAccess servers, require health certificates for the Computer certificate

authentication method and enable authorization for IPsec tunneling in the DirectAccess

Policy-DaServerToCorp connection security rule.

If you modify the connection security rules created by the DirectAccess Setup Wizard,

you must use Network Shell (Netsh) commands. There are connection security rule

settings that cannot be modified with the Windows Firewall with Advanced Security snap-

in. If you modify these connection security rules with the Windows Firewall with Advanced

Security snap-in, they will be overwritten with default values, which can result in

incompatible connection security rules that prevent DirectAccess connections.

Planning DirectAccess with an Existing Server and Domain Isolation Deployment

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 (http://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.

Note

62

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 Protocol

(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.

DirectAccess Capacity Planning

To design a scalable DirectAccess infrastructure, you must analyze the elements of a

DirectAccess deployment and develop an implementation plan that considers several factors,

including:

Performance. Which types of resources are most used by each server role in your

DirectAccess deployment? How will you monitor performance?

Roles. Do servers in your DirectAccess deployment perform multiple functions? How does

this affect performance?

Availability. Do you require 100 percent availability for all server roles in your deployment?

Access profile. When and where does your network experience peak activity? Is the activity

consistent or does it change over time?

See the following topics for additional information:

Capacity Planning for DirectAccess Servers

Capacity Planning for Network Location Servers

Capacity Planning for CRL Distribution Points

Capacity Planning for DirectAccess Servers

Capacity planning for DirectAccess servers can be done in the following ways:

Increase the number of concurrent authentications

Move the Internet Protocol security (IPsec) gateway function to a separate server that has

IPsec offload hardware

63

Use DirectAccess with Microsoft Forefront Unified Access Gateway (UAG)

Increasing the number of concurrent authenticationsTo increase the number of concurrent authentication calls in progress at one time between the

DirectAccess server and the domain controller, set the HKEY_LOCAL_MACHINE\SYSTEM\

CurrentControlSet\Services\Netlogon\Parameters\ MaxConcurrentApi (REG_DWORD)

registry value on the DirectAccess server to 5, and then restart the NETLOGON service.

Moving the IPsec gateway function to a separate serverThe DirectAccess server as configured by the DirectAccess Setup Wizard has the following

functions:

Teredo server and relay

6to4 relay

Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) server

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) router

Native Internet Protocol version 6 (IPv6) router

IPsec gateway

It is possible to move these functions to other computers. One configuration that supports

scalability for many DirectAccess connections is to move the IPsec gateway and ISATAP router

functions to another computer with IPsec offload hardware, which can handle the processor-

intensive cryptographic operations and support many IPsec tunnels. The following figure shows

an example.

In this example, Server 1 provides the 6to4 relay, Teredo server, and IP-HTTPS server functions

and Server 2 provides ISATAP router and IPsec gateway functions. DirectAccess clients use

64

Server 1 to tunnel traffic across the IPv4 Internet and establish the infrastructure and intranet

IPsec tunnels with Server 2. Intranet computers forward traffic to DirectAccess clients to Server 2.

The requirements of this configuration are the following:

Both Server 1 and Server 2 must have two physical interfaces, one classified as a public

interface and one classified as a domain interface. Server 1 has its public interface on the

Internet.

The subnet for the link between the Server 1 and Server 2, the intra-server subnet, must use

native IPv6 addressing. You cannot use 6to4 or ISATAP tunneling on this link. You must pick

a unique 64-bit prefix for your intranet and configure static IPv6 addresses for each interface

on this subnet.

You must configure a default IPv6 route (::/0) on Server 2 that points to Server 1’s interface

on the intra-server subnet.

Because Server 2 computer is a native IPv6 router, you must configure outbound firewall

rules on the interface on the intra-server subnet to prevent reachability to intranet domain

controllers.

The tunnel endpoints in the Group Policy objects for the DirectAccess clients and server must

specify the native IPv6 address of Server 2’s interface on the intra-server subnet.

With this configuration, Server 2 acts as the IPsec intranet and infrastructure tunnel endpoint,

providing decryption services for packets from DirectAccess clients and encryption services for

packets to DirectAccess clients.

The following figure shows an example of the traffic between DirectAccess clients and intranet

servers for the full intranet access model.

The traffic over the Internet between the DirectAccess client and Server 2 is encrypted through

the intranet tunnel. The traffic over the intranet between Server 2 and intranet servers is clear

text.

The recommended method to deploy this configuration is the following:

1. While configured with two consecutive public IPv4 addresses, complete the DirectAccess

Setup Wizard on Server 2.

65

2. Set up the intra-server subnet and the static IPv6 addressing of Server 1. Reconfigure Server

2 with the appropriate IPv4 addresses for the intra-server subnet and remove the two

consecutive public IPv4 addresses. Configure Server 1 with the two consecutive public IPv4

addresses on the Internet interface.

3. Configure Server 1 as a default advertising router for the intra-server subnet, and a 6to4

relay, Teredo server and relay, and IP-HTTPS server on the Internet.

4. Disable the 6to4 relay, Teredo server and relay, and IP-HTTPS server functionality on Server

2.

5. Configure Group Policy settings for the new IPsec tunnel endpoint on Server 2.

Using DirectAccess with UAGYou can expand the capacity of a single Forefront UAG DirectAccess server deployment by

creating a load-balanced Forefront UAG array that provides high availability and scalability. For

more information, see Configuring a network load balanced array for Forefront UAG DirectAccess

(http://go.microsoft.com/fwlink/?LinkId=160075).

Capacity Planning for Network Location Servers

The network location function for DirectAccess can be placed on an intranet Web server or the

DirectAccess server. Microsoft highly recommends placing the network location function on a

separate intranet Web server. You must plan the capacity of the network location server so that it

can handle the DirectAccess clients on your intranet performing intranet detection.

To provide capacity for an Internet Information Services (IIS) 7.0-based Web server, including the

DirectAccess server, see the documentation for the Web Server (IIS) role on Windows

Server 2008 R2 or Windows Server 2008 for recommendations on scaling IIS capacity.

Capacity Planning for CRL Distribution Points

The certificate revocation list (CRL) distribution points on the Internet for the Internet Protocol

over Secure Hypertext Transfer Protocol (IP-HTTPS) certificate and on the intranet for the

network location certificate can be located on Web or file servers. You must plan for the capacity

of CRL distribution points so that your Internet and intranet-connected DirectAccess clients can

perform certificate revocation checking for the IP-HTTPS connection and for network location

detection.

66

For an Internet Information Services (IIS)-based Web server or a Windows-based file server,

including the DirectAccess server, see the documentation for the Web Server (IIS) and File

Services roles on Windows Server 2008 R2 or Windows Server 2008 for recommendations on

scaling capacity.

Additional DirectAccess Resources

You can find DirectAccess product information including overviews, Webcasts, step-by-step

guides, virtual labs, and announcements at http://go.microsoft.com/fwlink/?LinkId=160519.

Also see DirectAccess on Microsoft TechNet (http://go.microsoft.com/fwlink/?LinkID=151854).

For information about how to configure DirectAccess in a test lab, see Step-by-Step Guide:

Demonstrate DirectAccess in a Test Lab (http://go.microsoft.com/fwlink/?Linkid=150613).

Appendix A: DirectAccess Requirements

Review this section for information about DirectAccess server, DirectAccess client, and network

infrastructure requirements.

Hardware and software requirements for Windows 7-based computers described in this section

apply to both x86 (32-bit) and x64 (64-bit) systems.

Element Requirements

DirectAccess client Operating system: Windows 7 Ultimate or

later, Windows 7 Enterprise or later,

Windows Server 2008 R2 or later

Member of an Active Directory Domain

Services (AD DS) domain

Computer certificate for Internet Protocol

security (IPsec) authentication

DirectAccess server Operating system: Windows

Server 2008 R2 or later

Member of an AD DS domain

At least two network adapters that are

connected to the Internet and your intranet

2 consecutive, public Internet Protocol

version 4 (IPv4) addresses configured on

the Internet network adapter (cannot be

behind a network address translator [NAT])

Certificates: Computer certificate for IPsec

67

Element Requirements

authentication, Secure Sockets Layer (SSL)

certificate for Internet Protocol over Secure

Hypertext Transfer Protocol (IP-HTTPS)

If acting as a network location server,

Internet Information Services (IIS) and an

additional SSL certificate installed

Note

There are no built-in limitations on the

number of simultaneous DirectAccess

connections that a DirectAccess server

can support.

Active Directory At least one Active Directory domain must be

deployed with at least one Windows

Server 2008 R2 or Windows Server 2008-based

domain controller (an Internet Protocol version 6

[IPv6]-capable domain controller and global

catalog). Windows Server 2008 R2 domain or

forest functional levels are not required.

Workgroups are not supported. For more

information about installing Active Directory, see

the AD DS Installation and Removal Step-by-

Step Guide (http://go.microsoft.com/fwlink/?

Linkid=139657).

Group Policy Required for centralized administration and

deployment of DirectAccess settings. The

DirectAccess Setup wizard creates a set of

Group Policy objects and settings for

DirectAccess clients, the DirectAccess server,

and selected servers.

Public key infrastructure (PKI) Required to issue computer certificates for

authentication, and optionally, health certificates

when using Network Access Protection (NAP).

External certificates are not required. For more

information about setting up a PKI with Active

Directory Certificate Services (AD CS), see

Active Directory Certificate Services

(http://go.microsoft.com/fwlink/?Linkid=106710).

Domain Name System (DNS) server At least one running Windows Server 2008 R2,

Windows Server 2008 with the Q958194 hotfix

68

Element Requirements

(http://go.microsoft.com/fwlink/?LinkID=159951),

Windows Server 2008 SP2 or later, or a third-

party DNS server that supports DNS message

exchanges over the Intra-Site Automatic Tunnel

Addressing Protocol (ISATAP).

Appendix B: Reviewing Key DirectAccess Concepts

The DirectAccess solution uses a combination of Internet Protocol version 6 (IPv6) end-to-end

connectivity, Internet Protocol security (IPsec) protection of intranet traffic, separation of Domain

Name System (DNS) traffic with the Name Resolution Policy Table (NRPT), and a network

location server that DirectAccess clients use to detect when they are on the intranet. The

following sections describe the role that these technologies have in providing DirectAccess clients

with transparent access to intranet resources.

IPv6IPv6 is the new version of the Network layer of the TCP/IP protocol stack that is designed to

replace Internet Protocol version 4 (IPv4), which is in wide use today on intranets and the

Internet. IPv6 provides an address space large enough to accommodate end-to-end addressing

of nodes on the IPv6 Internet, and with IPv6 transition technologies, of nodes on the IPv4

Internet. DirectAccess uses this capability to provide end-to-end addressing from DirectAccess

clients on the IPv4 or IPv6 Internet to computers on an intranet.

Because most of the current Internet is IPv4-based and many organizations have not deployed

native IPv6 addressing and routing on their intranets, DirectAccess uses IPv6 transition

technologies to provide IPv6 connectivity over these IPv4-only networks. Teredo, 6to4, Internet

Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS), and the Intra-Site Automatic

Tunnel Addressing Protocol (ISATAP) are examples of IPv6 transition technologies. These

technologies allow you to use IPv6 on the IPv4 Internet and your IPv4-only intranet. IPv6

transition technologies can simplify and reduce the costs of an IPv6 deployment.

IPv6 connectivity across the IPv4 InternetTo send IPv6 packets across the IPv4 Internet, a DirectAccess client can use 6to4, Teredo, or IP-

HTTPS. If the DirectAccess client has been assigned a public IPv4 address, it will use 6to4. If

assigned a private IPv4 address, it will use Teredo. If the DirectAccess client cannot connect to

the DirectAccess server with either 6to4 or Teredo, it will use IP-HTTPS.

69

6to4

6to4, defined in RFC 3056, is an IPv6 transition technology that provides IPv6 connectivity across

the IPv4 Internet for hosts or sites that have a public IPv4 address. For more information, see

IPv6 Transition Technologies (http://go.microsoft.com/fwlink/?Linkid=117205).

Teredo

Teredo, defined in RFC 4380, is an IPv6 transition technology that provides IPv6 connectivity

across the IPv4 Internet for hosts that are located behind an IPv4 network address translation

(NAT) device and are assigned a private IPv4 address. For more information, see Teredo

Overview (http://go.microsoft.com/fwlink/?Linkid=157322).

IP-HTTPS

IP-HTTPS is a new protocol for Windows 7 and Windows Server 2008 R2 that allows hosts

behind a Web proxy server or firewall to establish connectivity by tunneling IPv6 packets inside

an IPv4-based HTTPS session. HTTPS is used instead of HTTP so that Web proxy servers will

not attempt to examine the data stream and terminate the connection. IP-HTTPS is typically used

only if the client is unable to connect to the DirectAccess server using the other IPv6 connectivity

methods or if force tunneling has been configured.

For the details of IP-HTTPS, see the IP over HTTPS (IP-HTTPS) Tunneling Protocol Specification

(http://go.microsoft.com/fwlink/?Linkid=157309).

IPv6 connectivity across an IPv4-only intranetISATAP, defined in RFC 4214, is an IPv6 transition technology that provides IPv6 connectivity

between IPv6/IPv4 hosts across an IPv4-only intranet. ISATAP can be used for DirectAccess to

provide IPv6 connectivity to ISATAP hosts across your intranet.

For more information, see IPv6 Transition Technologies (http://go.microsoft.com/fwlink/?

Linkid=117205).

ISATAP can also be used to provide IPv6 connectivity when the client is at a remote

location. ISATAP deployments can either connect to the IPv6 Internet or use 6to4 to

transfer IPv6 traffic across the IPv4 Internet.

IPsecIPsec is a framework of open standards for ensuring private, secure communications over

Internet Protocol (IP) networks through the use of cryptographic security services. IPsec provides

aggressive protection against attacks through end-to-end security. The only computers that must

know about IPsec protection are the sender and receiver in the communication. IPsec provides

the ability to protect communication between workgroups, local area network computers, domain

clients and servers, branch offices (which might be physically remote), extranets, and roaming

clients.

Note

70

IPsec protection can be used in two different modes: transport mode and tunnel mode. Transport

mode is designed to protect an Internet Protocol (IP) packet payload. Tunnel mode is designed to

protect an entire IP packet. For more information, see IPsec Protocol Types

(http://go.microsoft.com/fwlink/?Linkid=157319).

DirectAccess uses IPsec settings in the form of connection security rules in the Windows Firewall

with Advanced Security snap-in and the Network Shell (Netsh) command-line tool advfirewall

context for peer authentication, data integrity, and data confidentiality (encryption) of

DirectAccess connections. Multiple rules can be applied to a computer simultaneously, each

providing a different function. The result of all of these rules working together is a DirectAccess

client that can have protected communications with the DirectAccess server and intranet servers,

encrypting traffic sent over the Internet and optionally protecting traffic from end-to-end.

Windows Server 2003 and earlier versions of Windows Server do not fully support the

use of IPsec with IPv6. IPv6-capable resources on servers running Windows Server 2003

will only be available to DirectAccess clients if you use the full intranet access model.

IPv4-only resources on servers running Windows Server 2003, including most built-in

applications and system services, require a Network Address Translation-Protocol

Translation (NAT-PT) or NAT-64 to be available to DirectAccess clients.

EncryptionWhen a DirectAccess client sends data to the intranet, the traffic is encrypted over the Internet.

For the full intranet and selected server access models, multiple connection security rules

configured on the DirectAccess client defines tunnel mode IPsec settings for communication

between the DirectAccess client and the intranet:

The first rule for the infrastructure tunnel requires authentication with a computer certificate

and encrypts traffic with IPsec and the Encapsulating Security Payload (ESP). This rule

provides protected communication with Active Directory domain controllers, DNS servers, and

other intranet resources before the user has logged on.

The second rule for the intranet tunnel requires authentication with a computer certificate and

user-based Kerberos credentials. This rule provides protected communication to intranet

resources after the user has logged on.

For the full intranet and selected server access models, termination of IPsec tunnels between the

DirectAccess client and the intranet is done by the IPsec Gateway component on the

DirectAccess server. This component can be located on a separate server with an IPsec offload

network adapter to increase performance.

Data integrityData integrity allows the receiving IPsec peer to cryptographically verify that the packet was not

changed in transit. When encrypting data with IPsec, data integrity is also provided. It is possible

to specify data integrity without encryption. This might be helpful in order to mitigate the threat of

spoofing or man-in-the-middle attacks and allow you to ensure that DirectAccess clients are

connecting to their intended servers.

Note

71

When sensitive data is being transmitted, IPsec with only data integrity should only be

used when some other form of encryption is also implemented. It is possible to have end-

to-end data integrity using transport mode rules while using end-to-edge encryption for

the tunnel mode rules, which is how the selected server access model works.

DirectAccess accomplishes data integrity through the use of transport and tunnel mode IPsec

settings. These settings can be applied to DirectAccess clients, DirectAccess servers, or

application servers and provide data integrity by requiring ESP-NULL (recommended) or

Authentication Header (AH) for IPsec-protected communications. Some network infrastructure

devices or traffic monitoring and inspection solutions might not be able to parse packets with an

IPsec ESP or AH header. In this case, you can use authentication with null encapsulation to

perform IPsec peer authentication, but no per-packet data integrity.

Separation of DNS trafficTo separate Internet traffic from intranet traffic for DirectAccess, Windows 7 and Windows

Server 2008 R2 include the NRPT, a new feature that allows DNS servers to be defined per DNS

namespace, rather than per interface. The NRPT stores a list of rules. Each rule defines a DNS

namespace and configuration settings that define the DNS client’s behavior for that namespace.

When a DirectAccess client is on the Internet, each name query request is compared against the

namespace rules stored in the NRPT. If a match is found, the request is processed according to

the settings in the NRPT rule. The settings determine which DNS servers to which the request will

be sent.

If a name query request does not match a namespace listed in the NRPT, it is sent to the DNS

servers configured in the TCP/IP settings for the specified network interface. For a remote client,

this will typically be the Internet DNS servers as configured through the Internet service provider

(ISP). For a DirectAccess client on the intranet, this will typically be the intranet DNS servers as

configured through the Dynamic Host Configuration Protocol (DHCP).

Single-label names, such as http://internal, will typically have configured DNS search suffixes

appended to the name before they are checked against the NRPT. If no DNS search suffixes are

configured and the single-label name does not match any other single-label name rules in the

NRPT, the request will be sent to the DNS servers specified in the client’s TCP/IP settings.

Namespaces, such as .internal.contoso.com, are added to the NRPT followed by the IPv6

addresses of the DNS servers to which requests matching that namespace should be directed. If

an IP address is entered for the DNS server, then all DNS requests will be sent directly to the

DNS server over the DirectAccess connection. There is no need to specify any additional security

for this configuration.

However, if a name is specified for the DNS server (such as dns.contoso.com) in the NRPT, then

that name must be publicly resolvable when the client queries the DNS servers specified in its

TCP/IP settings. To prevent an attacker from hijacking this external name query request and

injecting a malicious reply, enabling IPsec protection for the DNS message exchanges is strongly

recommended in this configuration.

Note

72

The NRPT allows DirectAccess clients to use intranet DNS servers for name resolution

(dedicated DNS servers are not required). DirectAccess is designed to prevent the exposure of

your intranet namespace to the Internet.

NRPT exemptionsThere are some names that need to be treated differently from all others with regards to name

resolution; these names must not be resolved using intranet DNS servers. To ensure that these

names are resolved with interface-configured DNS servers, you must add them as NRPT

exemptions.

If no DNS server addresses are specified in the NRPT rule, the rule is an exemption. If a DNS

name matches a rule in the NRPT that does not contain addresses of DNS servers or does not

match a rule in the NRPT, the DirectAccess client sends the name query to interface-configured

DNS servers.

If any of the following servers have a name suffix that matches an NRPT rule for the intranet

namespace, that server name must be an NRPT exemption:

Network location servers

Intranet certificate revocation list (CRL) distribution points

System health remediation servers

These servers must always be resolved with interface-configured DNS servers.

Network location serversA network location server is an intranet network server that hosts a Secure Hypertext Transfer

Protocol (HTTPS)-based uniform resource locator (URL). DirectAccess clients access this URL to

determine whether they are located on the intranet. The DirectAccess server can be the network

location server but a separate, high-availability Web server is highly recommended. The Web

server does not have to be dedicated as a network location server.

Because the behavior of the DirectAccess client depends on the response from the network

location server, it is critical to ensure that this Web site is available from each remote branch site.

Branch locations may need a separate dedicated network location Web site at each branch

location to ensure that the Web site remains accessible even in the event of a link failure.

How intranet detection worksWhen a DirectAccess client starts up or experiences a significant network change event (such as

change in link status or a new IP address), it assumes that it is not on the intranet and uses

DirectAccess rules in the NRPT to determine where to send DNS name queries. The

DirectAccess client then attempts to resolve the fully qualified domain name (FQDN) in the URL

for the network location server, which is stored in the Computer

Configuration/Policies/Administrative Templates/Network/Network Connectivity Status

Indicator/Domain Location Determination URL Group Policy setting. Because the NRPT has

73

active rules for DirectAccess, this FQDN should either match an exemption rule or no rules in the

NRPT so that the DirectAccess client can use interface-configured DNS servers.

After resolving the FQDN, the DirectAccess client attempts to connect to the HTTPS-based URL

of the network location server, which includes a Secure Sockets Layer (SSL)-based

authentication and verification of the server certificate offered by the network location server. For

authenticating the DirectAccess client’s access to the URL, use anonymous authentication or

NTLM. Certificate verification includes validating the certificate and verifying that it has not been

revoked by accessing the CRL location defined in the Web server’s certificate. When the

DirectAccess client successfully accesses the HTTPS-based URL of the network location server,

it determines that it is on the intranet. The DirectAccess client then removes the DirectAccess

NRPT rules from the active table and the DirectAccess client uses interface-configured DNS

servers to resolve all names.

Just like the URL for the network location server, the FQDN in the URL or the universal

naming convention (UNC) path for the CRL distribution point should either match an

exemption rule or no rules in the NRPT so that the DirectAccess client can use interface-

configured intranet DNS servers to resolve the name. If the DirectAccess client cannot

resolve the FQDN for the CRL distribution point, intranet location detection fails.

Appendix C: Documenting Your DirectAccess Design

Documenting your DirectAccess design will help you explain the infrastructure and policy

decisions and record the results of the deployment phases of the project. You can use the

following sections to create a document with your goals and proposed timeline, and you can add

to these sections at the end of each phase of your DirectAccess deployment.

ConceptsProvide a brief description of how DirectAccess works or use the following description:

DirectAccess gives users the experience of being seamlessly connected to their corporate

network (intranet) any time they have Internet access. With DirectAccess, users are able to

access intranet resources (such as e-mail servers, shared folders, or intranet Web sites)

securely without connecting to a virtual private network (VPN). DirectAccess provides

increased productivity for mobile workforce by offering the same connectivity experience both

in and outside of the office. DirectAccess is on whenever the user has an Internet connection,

giving users access to intranet resources whether they are traveling, at the local coffee shop,

or at home. DirectAccess is supported by Windows 7 Ultimate or later, Windows 7 Enterprise

or later, and Windows Server 2008 R2 or later.

Note

74

GoalsList your reasons for deploying DirectAccess and state how your design plan will achieve these

goals. Also provide the following:

Benefits. Describe the pre-deployment state of the network and the benefits you expect to

see as a result of the DirectAccess deployment.

Requirements. List what is required to achieve your goals. Examples include operating

system updates, equipment purchases, training, cross-team collaboration, and project

schedules.

Progress. Describe your current progress.

For more information, see Identifying Your DirectAccess Deployment Goals.

Infrastructure design planList the names and locations of servers and other devices that will be used in your DirectAccess

deployment. Include current and future plans. Provide the following details:

IPv6 connectivity. Describe how you deployed Internet Protocol version 6 (IPv6) connectivity

across your intranet. Include details on routers, default routing design, and IPv6 Internet

connectivity.

Servers, devices, and roles. List all servers and devices, including their roles, in your

DirectAccess design. Include computers and other devices used for DirectAccess certificate

validation and connectivity.

Packet filtering. List the packet filters configured on Internet and intranet firewalls, across

intranet hosts, and for DirectAccess clients.

Capacity management and redundancy. Describe your expectations for capacity

management and redundancy in the DirectAccess design.

Scaling plan. Describe changes that will be required to support the expansion of the

DirectAccess deployment to include additional capacity.

Custom configuration planUse this section to document how you had to customize the default configuration of DirectAccess

to implement specific requirements on your network.

Baseline configuration. List the steps in the DirectAccess Setup Wizard and the options

chosen for your initial configuration.

NRPT rules. List any additional Name Resolution Policy Table (NRPT) rules for intranet

namespaces or exemptions that you needed for your deployment.

Connection security rules. List any changes made to the default connection security rules

in the form of Network Shell (Netsh) commands, including the Group Policy object, the rule

name, and the changes made.

75

Integration strategyDescribe your design for integrating DirectAccess with the following technologies and solutions:

VPN. Describe the changes made to your VPN configuration to accommodate DirectAccess

detection of the intranet when connected and for third-party VPN clients.

NAP. Describe the changes to DirectAccess settings and connection security rules for

Network Access Protection (NAP) health evaluation and enforcement of DirectAccess

connections.

Server and domain isolation. Describe changes made to your existing server and domain

isolation deployment to accommodate DirectAccess client connectivity to intranet resources.

Staging strategyDescribe how you staged the deployment of DirectAccess in your organization. Include the

following information:

Staging milestones. List the set of infrastructure and deployment milestones and their

requirements.

Timeline. Provide details of your proposed timeline to deploy DirectAccess on your intranet.

Include your initial timeline and any deviation from that timeline.

Staging results. Provide the results for each stage of your DirectAccess deployment.

Trends. Describe any trends in connectivity issues encountered.

Lessons learnedUse this section to describe problems that were encountered and solutions that were

implemented during your DirectAccess deployment.

76