DirectAccess Design Guide

Microsoft Corporation
Published: August 14, 2009
Author: Joe Davies
Editor: Scott Somohano

Abstract
This 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............................................................................................................1
Abstract....................................................................................................................................1

Contents..........................................................................................................................................3

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.................................................................9

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

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

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.........................................................................................................15

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

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

IPv6 resources on your intranet.................................................................................................17
IPv4-only resources on the intranet...........................................................................................18
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...................................................................................................21
Existing native IPv6 infrastructure..............................................................................................22
Choose Solutions for IPv4-only Intranet Resources......................................................................22

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

Full Intranet Access.......................................................................................................................24

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..................................................................................27

Design for Remote Management..................................................................................................27

Design Packet Filtering for DirectAccess......................................................................................28

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

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

Confining ICMPv6 Traffic to the Intranet.......................................................................................30

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

Packet filters to allow inbound ICMPv6 Echo Requests on all computers.................................32
Enable edge traversal on inbound management traffic..............................................................32
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.......................................35
Peer authentication for end-to-end access................................................................................35
Smart cards for additional authorization....................................................................................36
Allowing access for users with unusable smart cards............................................................36
Prompts for smart card credentials while on the intranet........................................................37
Under the covers: Smart card authorization...........................................................................37

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

Active Directory and the DirectAccess server............................................................................38
DirectAccess and user profiles for remote users.......................................................................39

Design Your DNS Infrastructure for DirectAccess.........................................................................39

Split-brain DNS..........................................................................................................................39
DNS server requirements for ISATAP........................................................................................40
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.............................................................................................................................43

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

Autoenrollment for computer certificates...................................................................................44
Manual enrollment for network location server and IP-HTTPS certificates................................44
Certificate revocation checking and CRL distribution points......................................................45
Enabling strong CRL checking for IPsec authentication............................................................46
Smart cards for additional authorization....................................................................................46

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

Choose an Internet Traffic Separation Design..............................................................................47

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

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

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

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

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

When to Install a DirectAccess Server..........................................................................................54

Where to Place the DirectAccess Server......................................................................................54

Planning Redundancy for a DirectAccess Server.........................................................................55

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

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

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

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

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

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

Intranet location for intranet detection .......................................................................................59
Internet location for IP-HTTPS connections ..............................................................................59

Planning Redundancy for CRL Distribution Points........................................................................60

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

Configuration changes for the infrastructure tunnel...................................................................61
Configuration changes for the intranet tunnel............................................................................61

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

DirectAccess Capacity Planning...................................................................................................63

Capacity Planning for DirectAccess Servers.................................................................................63
Increasing the number of concurrent authentications................................................................64
Moving the IPsec gateway function to a separate server...........................................................64
Using DirectAccess with UAG...................................................................................................66

Capacity Planning for Network Location Servers..........................................................................66

Capacity Planning for CRL Distribution Points..............................................................................66

Additional DirectAccess Resources..............................................................................................67

Appendix A: DirectAccess Requirements......................................................................................67

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

IPv6...........................................................................................................................................69
IPv6 connectivity across the IPv4 Internet..............................................................................69
6to4.....................................................................................................................................69
Teredo.................................................................................................................................70
IP-HTTPS............................................................................................................................70
IPv6 connectivity across an IPv4-only intranet.......................................................................70
IPsec..........................................................................................................................................70
Encryption..............................................................................................................................71
Data integrity..........................................................................................................................71
Separation of DNS traffic...........................................................................................................72
NRPT exemptions..................................................................................................................73
Network location servers...........................................................................................................73
How intranet detection works.................................................................................................73

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

Concepts...................................................................................................................................74
Goals.........................................................................................................................................75
Infrastructure design plan..........................................................................................................75
Custom configuration plan.........................................................................................................75
Integration strategy....................................................................................................................76
Staging strategy.........................................................................................................................76
Lessons learned........................................................................................................................76
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 guide

This 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.
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,
8
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 Mapping Your Deployment Goals to a
predefined DirectAccess deployment goals to a DirectAccess Design
DirectAccess design.

Document your deployment goals and other Appendix C: Documenting Your DirectAccess
important details for your DirectAccess design. 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.

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
9
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.

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.

10
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.
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 Functionality in the DirectAccess server and
DirectAccess clients clients

Ongoing management of remote DirectAccess Bidirectional connections whenever the

clients 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

11
DirectAccess deployment goal DirectAccess elements or features

Reduction of remote access-based servers in Access to intranet resources through the

your edge network 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
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.

12
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.

Note

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.

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 access
Authentication 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.

Note

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

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.

15
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.
• 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.

16
• 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.

IPv6 resources on your intranet

DirectAccess 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.
17
 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.

IPv4-only resources on the intranet

Because 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.

18
Limiting connectivity to selected resources
With 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 Internet

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

19
 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 infrastructure

Having 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
the DirectAccess server as an ISATAP router, and registers the name ISATAP with its Domain
Name System (DNS) server.

Note

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.
20
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
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 infrastructure

If 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

21
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 infrastructure

If 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.

Note

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.

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.

22
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.
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.

23
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.

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:

24
• 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.
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
25
 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:
• 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.

26
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 Console

The 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 tool
For 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.

Manual configuration using Group Policy

Group 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.

27
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

Notes

• 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
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)

28
• 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
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

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

30
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.
• 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.

31
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 computers
DirectAccess 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
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

traffic
If 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.

32
Enable inbound ICMPv6 Echo Requests for
management traffic
For 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
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

33
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.

Note

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).
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).

34
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.

Note

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.

Additional end-to-end peer authentication for

selected server access
If 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 access

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

35
• First authentication: Computer certificate or Computer (Kerberos V5)
• Second authentication: User (Kerberos V5)

Note

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 authorization

On 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).

Allowing access for users with unusable smart cards

To 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.

36
Prompts for smart card credentials while on the intranet
Due 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 authorization

Smart 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
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.

37
 Note

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).
• 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 server

The 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.

38
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 users

Using 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 DNS
Split-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
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

39
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 ISATAP

For 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
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).

40
AAAA records for servers that do not perform
DNS dynamic update
For 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

clients
If 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
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.

41
NRPT rules
In 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
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.

Notes

The maximum number of rules in the NRPT is 1000.

42
 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

suffixes
Unqualified, 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.

Note

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.

Note

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 DNS
The 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
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.

43
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 certificates

The 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 certificates
You 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:
• 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.

44
• 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 points
The 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

Note

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.

45
Enabling strong CRL checking for IPsec
authentication
By 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.

Notes

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 authorization

To 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.

Note

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.

46
Design your Web Servers for DirectAccess
You will need Web locations for the following resources:
• 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)

Note

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:

47
• 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.
• 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.

48
To make IPv4-based Internet resources available to DirectAccess clients that use force tunneling,
you can do one of the following:
• 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.

Notes

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
49
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.
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

50
 outbound connections instead of Request authentication for inbound and outbound
connections.
• 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.

Note

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.

Note

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

52
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.
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 clients

When 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\Sho
wDomainEndpointInterfaces (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\Inte
rnet\ EnableNoGatewayLocationDetection (REG_DWORD) registry value to 1.
53
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
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).

Note

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.

55
 • The Hyper-V servers are joined to the domain and connected to the appropriate
networks.
• 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.

Note

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.

57
The certificate used by the Web server to act as a network location server has the following
requirements:
• 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

58
Overview of the Network Load Balancing Deployment Process (http://go.microsoft.com/fwlink/?
LinkId=159956).

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\Client
Config\IkeNapUseHeuristic registry value (REG_DWORD) to 1.

60
 Note

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

tunnel
To 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.

Note

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 tunnel

After 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.

61
• 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
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.

Note

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

62
Setup Wizard to determine whether they are compatible. A mismatch in global IPsec or
connection security rule settings between DirectAccess and SDI can cause an IPsec negotiation
failure and a lack of connectivity when a DirectAccess client attempts to access an intranet
resource protected with SDI.
For example, you need to ensure that the global main mode IPsec settings of your DirectAccess
clients match the global main mode IPsec settings of your SDI deployment. The DirectAccess
Setup Wizard will configure default global main mode IPsec settings for DirectAccess clients to
match those of the default global main mode IPsec settings for Windows Vista and Windows
Server 2008. If you have changed the global main mode IPsec settings for your SDI deployment
from their default values, you need to configure the global main mode IPsec settings of the Group
Policy object for DirectAccess clients created by the DirectAccess Setup Wizard to match them.
Additional design considerations for deploying DirectAccess in an existing SDI environment are
the following:
• To allow for Teredo client discovery, you should exempt Internet Control Message Protocol
(ICMP) from IPsec protection in your SDI deployment.
• If you are only using SDI for data integrity, you must use Encapsulating Security 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

63
• Move the Internet Protocol security (IPsec) gateway function to a separate server that has
IPsec offload hardware
• Use DirectAccess with Microsoft Forefront Unified Access Gateway (UAG)

Increasing the number of concurrent

authentications
To 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

server
The 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.

64
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
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 UAG

You 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.
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

66
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
authentication, Secure Sockets Layer (SSL)
certificate for Internet Protocol over Secure
Hypertext Transfer Protocol (IP-HTTPS)

67
Element Requirements

• 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
(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

68
Element Requirements

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.

IPv6
IPv6 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 Internet

To 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.

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).

69
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 intranet

ISATAP, 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).

Note

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.

IPsec
IPsec 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.
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).

70
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.

Note

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.

Encryption
When 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 integrity
Data 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.
When sensitive data is being transmitted, IPsec with only data integrity should only be
Note

71
 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 traffic

To 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.
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.

72
NRPT exemptions
There 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 servers

A 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 works

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

73
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.

Note

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.

Concepts
Provide 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.

Goals
List 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.

74
• 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 plan

List 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 plan

Use 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.

Integration strategy
Describe 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.

75
• 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 strategy
Describe 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 learned
Use this section to describe problems that were encountered and solutions that were
implemented during your DirectAccess deployment.

76