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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
DirectAccess Design Guide
Microsoft Corporation
Published: August 14, 2009
Author: Joe Davies
Editor: Scott Somohano
AbstractThis guide provides recommendations to help you plan a DirectAccess deployment using the
Windows Server® 2008 R2 operating system. It is intended for use by infrastructure specialists or
system architects who are planning a new DirectAccess deployment. This guide covers
DirectAccess deployment goals and design considerations for Internet Protocol version 6 (IPv6)
connectivity, access models, packet filtering, infrastructure requirements, and server placement,
redundancy, and capacity planning.
The information contained in this document represents the current view of Microsoft Corporation
on the issues discussed as of the date of publication. Because Microsoft must respond to
changing market conditions, it should not be interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the
date of publication.
This Design Guide is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the
rights under copyright, no part of this document may be reproduced, stored in or introduced into a
retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written permission
of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted in examples herein are fictitious. No
association with any real company, organization, product, domain name, e-mail address, logo,
person, place, or event is intended or should be inferred.
DirectAccess is one of the most anticipated features of the Windows Server 2008 R2 operating
system. DirectAccess allows remote users to securely access intranet shares, Web sites, and
applications without connecting to a virtual private network (VPN). DirectAccess establishes bi-
directional connectivity with a user’s intranet every time a user’s DirectAccess-enabled portable
computer connects to the Internet, even before the user logs on. Users never have to think about
connecting to the intranet, and information technology (IT) administrators can manage remote
computers outside the office, even when the computers are not connected to the VPN.
DirectAccess is supported by Windows 7 Enterprise, Windows 7 Ultimate, and Windows
Server 2008 R2.
The following are the key elements of a DirectAccess solution:
DirectAccess client. A domain-joined computer running Windows 7 Enterprise, Windows 7
Ultimate, or Windows Server 2008 R2 that can automatically and transparently connect to an
intranet through a DirectAccess server.
DirectAccess server. A domain-joined computer running Windows Server 2008 R2 that
accepts connections from DirectAccess clients and facilitates communication with intranet
resources.
Network location server. A server that a DirectAccess client uses to determine whether it is
located on the intranet or the Internet.
Certificate revocation list (CRL) distribution points. Servers that provide access to the
CRL that is published by the certification authority (CA) issuing certificates for DirectAccess.
For more information, see Appendix B: Reviewing Key DirectAccess Concepts.
About this guideThis guide is intended for use by an infrastructure specialist or system architect. The guide
provides recommendations to help you plan a new DirectAccess deployment based on the
requirements of your organization and the particular design that you want to create. It highlights
your main decision points as you plan your DirectAccess deployment. Before you read this guide,
you should have a good understanding of your organizational requirements and the capabilities
and requirements of DirectAccess.
This guide describes a set of deployment goals that are based on the primary DirectAccess
access methods. It helps you determine the most appropriate access method and corresponding
design for your environment. You can use these deployment goals to create a comprehensive
DirectAccess design that meets the needs of your environment.
7
Understanding the DirectAccess Design Process
To begin the DirectAccess design process, you must first identify your DirectAccess deployment
goals. This guide contains some predefined deployment goals so that you can understand the
ways in which DirectAccess can benefit your organization. After evaluating these goals, you can
select a DirectAccess design that meets your DirectAccess deployment objectives. Each design
includes examples to help you understand fundamental DirectAccess processes such as client
access or remote management.
The following topics explain how to identify and evaluate a DirectAccess deployment design for
your organization:
Identifying Your DirectAccess Deployment Goals
Mapping Your Deployment Goals to a DirectAccess Design
Evaluating DirectAccess Design Examples
After you identify your deployment goals and map them to a DirectAccess design, you can begin
documenting your design, based on the processes that are described in the following topics:
Planning a DirectAccess Deployment Strategy
Planning the Placement of a DirectAccess Server
Planning the Placement of a Network Location Server
Planning the Placement of CRL Distribution Points
Planning DirectAccess with Network Access Protection (NAP)
Planning DirectAccess with an Existing Server and Domain Isolation Deployment
DirectAccess Capacity Planning
Additional DirectAccess Resources
Appendix A: DirectAccess Requirements
Appendix B: Reviewing Key DirectAccess Concepts
Identifying Your DirectAccess Deployment Goals
Correctly identifying your DirectAccess deployment goals is essential for the success of your
DirectAccess design project. Depending on the size of your organization and the level of
involvement you are expecting from the information technology (IT) staff in any partner
organizations, form a project team that can clearly articulate real-world deployment issues in a
vision statement. Make sure that the members of this team understand the direction in which your
deployment project must move in order to reach your DirectAccess deployment goals.
8
When you write your vision statement, take steps to identify, clarify, and refine your deployment
goals. Prioritize and, if necessary, combine your deployment goals so that you can design and
deploy DirectAccess by using an iterative approach. You can take advantage of existing,
documented, and predefined DirectAccess deployment goals that are relevant to the
DirectAccess designs and develop a working solution for your scenarios.
The following table lists the three main tasks for articulating, refining, and documenting your
DirectAccess deployment goals.
Deployment goal tasks Reference links
Evaluate predefined DirectAccess deployment
goals that are provided in this section of the
guide and combine one or more goals to reach
your organizational objectives.
Transparent and Automatic Remote Access for
DirectAccess Clients
Ongoing Management of Remote DirectAccess
Clients
Efficient Routing of Intranet and Internet Traffic
Reduction of Remote Access-based Servers in
your Edge Network
End-to-end Traffic Protection
Multi-factor Credentials for Intranet Access
Map one goal or a combination of any of the
predefined DirectAccess deployment goals to a
DirectAccess design.
Mapping Your Deployment Goals to a
DirectAccess Design
Document your deployment goals and other
important details for your DirectAccess design.
Appendix C: Documenting Your DirectAccess
Design
Transparent and Automatic Remote Access for DirectAccess Clients
DirectAccess enhances the productivity of mobile workers by connecting their computers
automatically and seamlessly to their intranet any time Internet access is available. The user
does not have to remember to initiate a virtual private network (VPN) connection every time that
they need to access intranet resources. With DirectAccess, intranet file shares, Web sites, and
line-of-business applications can remain accessible wherever you have an Internet connection in
the same way as if you were directly connected to the intranet.
9
Ongoing Management of Remote DirectAccess Clients
With current virtual private network (VPN) solutions, the remote computer is connected to the
intranet only intermittently. This model of user-initiated connections makes it difficult for
information technology (IT) staff to manage remote computers with the latest updates and
security policies. Remote computer management can be mitigated by checking for and requiring
system health updates before completing the VPN connection. However, such requirements can
add substantial wait times to the VPN connection process.
With DirectAccess, IT staff can manage mobile computers by updating Group Policy settings and
distributing software updates any time the mobile computer has Internet connectivity, even if the
user is not logged on. This flexibility allows IT staff to manage remote computers as if they were
directly connected to the intranet and ensures that mobile users stay up-to-date with security and
system health policies.
Efficient Routing of Intranet and Internet Traffic
DirectAccess separates intranet from Internet traffic, which reduces unnecessary traffic on the
intranet by sending only traffic destined for the intranet through the DirectAccess server. Some
virtual private network (VPN) solutions use Network layer routing table entries to separate intranet
from Internet traffic, in a configuration known as split-tunneling. DirectAccess solves this problem
in the Application layer through more intelligent name resolution and in the Network layer by
summarizing the IPv6 address space of an entire organization with IPv6 address prefixes. Rather
than directing traffic solely based on a destination address, DirectAccess clients also direct traffic
based on the name needed by the application.
DirectAccess clients use a Name Resolution Policy Table (NRPT) that contains Domain Name
System (DNS) namespace rules and a corresponding set of intranet DNS servers that resolve
names for that DNS namespace. When an application on a DirectAccess client attempts to
resolve a name, it first compares the name with the rules in the NRPT. If there is a match, the
DirectAccess client uses a protected query to the specified intranet DNS servers to resolve the
name to intranet addresses and establish connections. If there are no matches, the DirectAccess
client uses Internet DNS servers to resolve the name to Internet addresses and establish
connections.
10
Reduction of Remote Access-based Servers in your Edge Network
With DirectAccess, you can reduce your dependence on remote access and application edge
servers, leading to an edge network with fewer servers that provide access to intranet resources
or applications. For example, the number of application edge servers can be reduced as the
number of DirectAccess clients increase because DirectAccess clients can now directly access
the corresponding application servers on the intranet.
End-to-end Traffic Protection
You can specify that the traffic between DirectAccess clients and intranet applications servers is
protected from end-to-end. In most virtual private network (VPN) solutions, the protection only
extends to the VPN server. This capability for end-to-end traffic protection provides additional
security for computers that are outside of the intranet. Additionally, by leveraging the flexibility and
control that is possible with connection security rules in Windows Firewall with Advanced Security,
you can specify that the end-to-end protection include encryption and not require that the traffic
be tunneled to the DirectAccess server.
Multi-factor Credentials for Intranet Access
In typically deployed access models, DirectAccess clients create two tunnels to the DirectAccess
server. The first tunnel, the infrastructure tunnel, provides access to intranet Domain Name
System (DNS) servers, Active Directory Domain Services (AD DS) domain controllers, and other
infrastructure and management servers. The second tunnel, the intranet tunnel, provides access
to intranet resources such as Web sites, file shares, and other application servers.
To provide an additional layer of security for traffic sent over the intranet tunnel, you can specify
that the intranet tunnel also require smart card authorization, which enforces the use of multiple
sets of credentials to access intranet resources. Multi-factor credentials for the intranet tunnel
uses the new tunnel-mode authorization feature of Windows Firewall with Advanced security in
Windows 7 and Windows Server 2008 R2, which allows you to specify that only authorized
computers or users can establish an inbound tunnel.
Mapping Your Deployment Goals to a DirectAccess Design
After you have reviewed the DirectAccess deployment goals and determined which are
appropriate for your organization, you can map those goals to a specific design.
11
The following table shows how well the DirectAccess designs meet the deployment goals
discussed in Identifying Your DirectAccess Deployment Goals.
DirectAccess deployment goal DirectAccess elements or features
Transparent and automatic remote access for
DirectAccess clients
Functionality in the DirectAccess server and
clients
Ongoing management of remote DirectAccess
clients
Bidirectional connections whenever the
computer is connected to the Internet
Efficient routing of intranet and Internet traffic Use of the Name Resolution Policy Table
(NRPT) and Internet Protocol version 6 (IPv6)
to separate Internet and intranet traffic
Reduction of remote access-based servers in
your edge network
Access to intranet resources through the
DirectAccess server
End-to-end traffic protection The selected server and end-to-end access
models
Multi-factor credentials for intranet access Smart card authorization on the intranet tunnel
Evaluating DirectAccess Design Examples
The following design examples illustrate the way in which DirectAccess deployment scenarios
work to provide transparent access to intranet resources.
Full Intranet Access Example
Full Intranet Access with Smart Cards Example
Selected Server Access Example
End-to-end Access Example
You can use these examples to determine the design or combination of designs that best suits
the needs of your organization.
Full Intranet Access Example
Full intranet access allows DirectAccess clients to connect to all of the Internet Protocol version 6
(IPv6)-reachable resources inside the intranet. The DirectAccess client uses Internet Protocol
security (IPsec) to create two encrypted tunnels to the Internet interface of the DirectAccess
server. The first tunnel, known as the infrastructure tunnel, allows the DirectAccess client to
access Domain Name System (DNS) servers, Active Directory Domain Services (AD DS) domain
controllers, and other infrastructure and management servers. The second tunnel, known as the
12
intranet tunnel, allows the DirectAccess client to access intranet resources. The infrastructure
tunnel uses computer authentication and the intranet tunnel uses both computer and user
authentication.
After the intranet tunnel is established, the DirectAccess client can exchange traffic with intranet
application servers. This traffic is encrypted by the tunnel for its journey across the Internet. By
default, the DirectAccess server is acting as an IPsec gateway, terminating the IPsec tunnels for
the DirectAccess client.
The following figure shows an example of full intranet access.
When the DirectAccess client starts up and determines that it is on the Internet, it creates the
tunnels to the DirectAccess server and begins normal communications with intranet infrastructure
servers such as AD DS domain controllers and application servers as if it were directly connected
to the intranet.
This design does not require IPsec protection for traffic on the intranet and is structurally very
similar to current remote access virtual private network (VPN) scenarios.
Full Intranet Access with Smart Cards Example
Full intranet access with smart cards is the full intranet access design and the use of smart cards
to provide an additional level of authorization for the intranet tunnel. The DirectAccess server
enforces the use of smart card credentials when the DirectAccess client computer attempts to
access an intranet resource.
The following figure shows an example of full intranet access with smart cards.
13
When a user on the DirectAccess client logs on to their computer with the smart card, they obtain
transparent access to intranet resources. If they log in to the computer using domain credentials,
such as a username and password combination, and attempt to access the intranet, Windows
displays a message in the notification area instructing them to enter their smart card credentials.
The user then inserts their smart card and provides their smart card personal identifier (PIN) to
access intranet resources.
This notification message will fade away in five seconds or may be covered by other notifications
in a shorter amount of time, but an icon displaying a pair of keys will stay in the notification area.
If the user misses the notification, the keys icon will be available in the overflow tray, which will
allow them to launch the credential prompt again by clicking on it.
If the user closes the smart card credential prompt from the notification area, there is no
way of relaunching it, nor will the keys show up in the overflow tray again. The user must
lock their computer and then unlock it with their smart card to access the intranet.
Selected Server Access Example
Selected server access allows you to confine the access of DirectAccess clients to a specific set
of intranet application servers and deny access to all other locations on the intranet. Intranet
access requires end-to-end Internet Protocol security (IPsec) protection from the DirectAccess
client to the specified servers. This provides an additional layer of IPsec peer authentication and
data integrity for end-to-end traffic so that DirectAccess clients can verify that they are
communicating with specific servers.
The following figure shows an example of selected server access.
Note
14
The DirectAccess client and selected servers by default perform IPsec peer authentication using
computer credentials and protect the traffic with Encapsulating Security Protocol (ESP)-NULL for
data integrity.
You can also use selected server access to require end-to-end IPsec protection from the
DirectAccess client to specified servers and allow access to all other locations on the intranet.
Traffic to other intranet application servers is not protected with IPsec peer authentication and
data integrity. The intranet tunnel between the DirectAccess client and server provides encryption
for both types of intranet traffic across the Internet.
Using authentication with null encapsulation for selected server accessAuthentication with null encapsulation is a new feature of Windows Firewall with Advanced
Security for Windows 7 and Windows Server 2008 R2. Some intranets contain hardware that
cannot parse or forward IPsec-protected traffic. With authentication with null encapsulation
enabled, IPsec peers perform normal IPsec peer authentication and include IPsec data integrity
on the first packet exchanged. Subsequent packets are sent as clear text with no IPsec
protection. This feature allows you to use IPsec for peer authentication in environments that do
not support IPsec-protected traffic flows. You can enable authentication with null encapsulation
for DirectAccess when using selected server access.
Authentication with null encapsulation is not the same as using ESP-NULL for per-packet
data integrity.
Note
15
End-to-end Access Example
End-to-end access removes the infrastructure and intranet tunnels to the DirectAccess server. All
intranet traffic is end-to-end between DirectAccess clients and intranet application servers and is
encrypted with Internet Protocol security (IPsec). In this configuration, the DirectAccess server is
no longer terminating IPsec tunnels. It is acting as a pass-through device, allowing the IPsec-
protected traffic to pass between the DirectAccess client and the application servers. A
component of the DirectAccess server, known as IPsec Denial of Service Protection (DoSP),
monitors the IPsec traffic to help prevent malicious users on the Internet from launching DoS
attacks against intranet resources.
The following figure shows an example of end-to-end access.
The DirectAccess client and intranet application servers should be configured to perform IPsec
peer authentication using computer credentials and to protect the traffic with Encapsulating
Security Protocol (ESP) for data confidentiality (encryption) and integrity.
Planning a DirectAccess Deployment Strategy
The following are some critical questions to consider as you develop a deployment strategy for
DirectAccess, with links to corresponding topics in this Design Guide. Answering these questions
will help you create a strategy that is cost-effective and resource-efficient.
Which intranet resources will be available to DirectAccess clients? For more information, see
Resources Available to DirectAccess Clients.
How do I either enable Internet Protocol version 6 (IPv6) on my intranet or have DirectAccess
use my existing IPv6 infrastructure? For more information, see Choose an Intranet IPv6
Connectivity Design.
16
What options do I have to make Internet Protocol version 4 (IPv4)-only resources available
for DirectAccess clients? For more information, see Choose Solutions for IPv4-only Intranet
Resources.
Which access models are there to choose from? For more information, see Choose an
Access Model.
What options do I have to configure DirectAccess? For more information, see Choose a
Configuration Method.
Which computers do I need to designate as management servers that will initiate connections
to DirectAccess clients? For more information, see Design for Remote Management.
What packet filters do I need to add to my firewalls and computers in my organization? For
more information, see Design Packet Filtering for DirectAccess.
What support is needed from third-party host firewalls? For more information, see
DirectAccess and Third-party Host Firewalls.
What authentication and authorization options do I have? For more information, see Choose
an Authentication and Authorization Scheme.
How does DirectAccess leverage or utilize Active Directory Domain Services (AD DS)? For
more information, see Choose an Authentication and Authorization Scheme.
How do I design my Domain Name System (DNS) infrastructure for DirectAccess? For more
information, see Design Your DNS Infrastructure for DirectAccess.
How do I design my public key infrastructure (PKI) for DirectAccess? For more information,
see Design Your PKI for DirectAccess.
How do I design my internal and external Web infrastructure for DirectAccess? For more
information, see Design your Web Servers for DirectAccess.
What options are there for separating or combining intranet and Internet traffic for
DirectAccess clients? For more information, see Choose an Internet Traffic Separation
Design.
How do I ensure that traffic between DirectAccess clients on the Internet is protected? For
more information, see Design Protection for Traffic between DirectAccess Clients.
How do I ensure that DirectAccess clients can detect connectivity to the intranet? For more
information, see Design Your Intranet for Corporate Connectivity Detection.
How does DirectAccess co-exist with my current remote access virtual private network (VPN)
solution? For more information, see Choose a DirectAccess and VPN Coexistence Design.
Resources Available to DirectAccess Clients
When designing your DirectAccess deployment, you must determine how DirectAccess clients
will reach all of the desired intranet resources.
17
IPv6 resources on your intranetDirectAccess relies on Internet Protocol version 6 (IPv6) for end-to-end connectivity between the
DirectAccess client and an intranet endpoint. DirectAccess clients only send IPv6 traffic across
the connection to the DirectAccess server. Therefore, DirectAccess clients can only communicate
using applications that support IPv6 and connect to intranet resources that are reachable with
IPv6. Internet Protocol version 4 (IPv4)-only applications on the DirectAccess client cannot be
used to access intranet application servers with DirectAccess.
The recommended configuration for your intranet is to have IPv6 connectivity to your intranet
resources. This requires the following:
An intranet infrastructure that supports the forwarding of IPv6 traffic.
IPv6-capable applications on computers that run an operating system that supports an IPv6
protocol stack.
An intranet infrastructure that supports forwarding IPv6 traffic can be achieved in the following
ways:
Configure your intranet infrastructure to support native IPv6 addressing and routing.
Computers running Windows Vista, Windows Server 2008, Windows 7, or Windows
Server 2008 R2 use IPv6 by default. Although few organizations today have a native IPv6
infrastructure, this is the preferred and recommended connectivity method. For the most
seamless intranet connectivity for DirectAccess clients, organizations should deploy a native
IPv6 infrastructure, typically alongside their existing IPv4 infrastructure.
Deploy Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) on your intranet.
Without a native IPv6 infrastructure, you can use ISATAP to make intranet servers and
applications reachable by tunneling IPv6 traffic over your IPv4-only intranet. Deploying
ISATAP consists of setting up one or more ISATAP routers that provide address configuration
and default routing for ISATAP hosts on your intranet. Computers running Windows 7 or
Windows Server 2008 R2 support ISATAP host functionality and can be configured to act as
ISATAP routers.
If you do not have a native IPv6 infrastructure or ISATAP on your intranet, the DirectAccess Setup
Wizard will automatically configure the DirectAccess server as the ISATAP router for your
intranet.
Applications that are end-to-end reachable by DirectAccess clients must be IPv6-capable and
running on an operating system that supports an IPv6 protocol stack with native IPv6 or ISATAP
host capability. For Windows-based application servers or peer computers, Windows 7, Windows
Server 2008 R2, Windows Vista, and Windows Server 2008 are highly recommended. Windows
XP and Windows Server 2003 have an IPv6 protocol stack, but many built-in system services and
applications for these operating systems are not IPv6-capable.
For applications running on non-Windows operating systems, verify that both the operating
system and the applications support IPv6 and are reachable over native IPv6 or ISATAP.
18
IPv4-only resources on the intranetBecause DirectAccess clients only send IPv6 traffic to the DirectAccess server, users on
DirectAccess clients cannot use IPv4-only client applications to reach IPv4-only resources on
your intranet. Examples of IPv4-only resources are the following:
Applications running on Windows 2000 or prior versions of Windows.
The built-in applications and system services running on Windows XP and Windows Server
2003 that are not IPv6-capable.
For applications that are not built-in to Windows, check with the software vendor to ensure
that the application is IPv6-capable. Applications that only use IPv4, such as Office
Communications Server (OCS), cannot by default be reached by DirectAccess clients.
However, IPv6-capable applications can reach IPv4-only resources on your intranet by using an
IPv6/IPv4 translation device or service. For the solutions for providing connectivity for
DirectAccess clients to IPv4-only resources, see Choose an Intranet IPv6 Connectivity Design.
Limiting connectivity to selected resourcesWith the selected server access model, you can limit the access of DirectAccess clients to a
specific set of servers identified by membership in Active Directory security groups. The following
figure shows an example of using selected server access to restrict intranet access to specific
application servers.
For more information, see Selected Server Access Example.
IPv6 resources on the IPv6 InternetBy default, Windows 7 and Windows Server 2008 R2-based computers attempt to resolve the
name 6to4.ipv6.microsoft.com to determine the IPv4 address of a 6to4 relay and
teredo.ipv6.microsoft.com to determine the IPv4 addresses of Teredo servers on the IPv4
19
Internet. With the 6to4 relay at 6to4.ipv6.microsoft.com and the Teredo servers at
teredo.ipv6.microsoft.com, Windows 7-based clients on the IPv4 Internet can reach the IPv6
Internet.
When Windows 7 and Windows Server 2008 R2-based computers are configured as
DirectAccess clients, the DirectAccess server becomes the 6to4 relay and the Teredo server so
that DirectAccess clients can tunnel IPv6 traffic destined for the intranet to the DirectAccess
server. If the DirectAccess server does not also forward default route traffic to the IPv6 Internet,
DirectAccess clients will not be able to reach the IPv6 Internet.
If you want DirectAccess clients to reach the IPv6 Internet, configure the DirectAccess server with
one of the following:
A direct, native connection to the IPv6 Internet
Configure the DirectAccess server to forward default route traffic using its native connection
to the IPv6 Internet. You can also use a separate router for your connection to the IPv6
Internet and configure the DirectAccess server to forward its default route traffic to the router.
A 6to4-tunneled connection to the IPv6 Internet
Configure the DirectAccess server to forward default route traffic using the Microsoft 6to4
Adapter interface to a 6to4 relay on the IPv4 Internet. You can configure a DirectAccess
server for the IPv4 address of the Microsoft 6to4 relay on the IPv4 Internet with the netsh
interface ipv6 6to4 set relay name=192.88.99.1 state=enabled command. Use
192.88.99.1, the IPv4 anycast address of 6to4 relays on the Internet, unless your Internet
service provider recommends a specific unicast IPv4 address of the 6to4 relay that they
maintain.
Choose an Intranet IPv6 Connectivity Design
The combinations of intranet Internet Protocol version 6 (IPv6) connectivity prior to deploying
DirectAccess are the following:
There is no existing IPv6 infrastructure
You have an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)-based IPv6
infrastructure
You have an existing native IPv6 infrastructure
In each of these combinations, you will need to ensure that the IPv6 routing infrastructure can
forward packets between DirectAccess clients and intranet resources.
No existing IPv6 infrastructureHaving no existing IPv6 infrastructure is currently the most common situation. When the
DirectAccess Setup Wizard detects that the DirectAccess server has no native or ISATAP-based
IPv6 connectivity, it automatically derives a 6to4-based 48-bit prefix for the intranet, configures
20
the DirectAccess server as an ISATAP router, and registers the name ISATAP with its Domain
Name System (DNS) server.
By default, DNS servers running Windows Server 2008 R2 or Windows Server 2008
block the resolution of the name ISATAP with the global query block list. To enable
ISATAP, you must remove the name ISATAP from the block list. For more information,
see Update the global query block list (http://go.microsoft.com/fwlink/?LinkId=157589).
Windows-based ISATAP hosts that can resolve the name ISATAP perform address
autoconfiguration with the DirectAccess server, resulting in the automatic configuration of the
following:
An ISATAP-based IPv6 address on an ISATAP tunneling interface.
A 64-bit route that provides connectivity to the other ISATAP hosts on the intranet.
A default IPv6 route that points to the DirectAccess server.
The default IPv6 route ensures that intranet ISATAP hosts can reach DirectAccess clients.
When your Windows-based ISATAP hosts obtain an ISATAP-based IPv6 address, they begin to
use ISATAP-encapsulated traffic to communicate if the destination is also an ISATAP host.
Because ISATAP uses a single 64-bit subnet for your entire intranet, your communication goes
from a segmented, multi-subnet Internet Protocol version 4 (IPv4) communication model to a flat,
single-subnet communication model with IPv6. This can affect the behavior of Active Directory
Domain Services (AD DS) and other applications that rely on your Active Directory Sites and
Services configuration. For example, if you used the Active Directory Sites and Services snap-in
to configure sites, IPv4-based subnets, and inter-site transports for forwarding of requests to
servers within sites, this configuration is not used by ISATAP hosts.
To configure Active Directory sites and services for forwarding within sites for ISATAP hosts, you
have to configure an IPv6 subnet object equivalent to each IPv4 subnet object, in which the IPv6
address prefix for the subnet expresses the same range of ISATAP host addresses as the IPv4
subnet.
For example, for the IPv4 subnet 192.168.99.0/24 and the 64-bit ISATAP address prefix
2002:836b:1:0:1::/64, the equivalent IPv6 address prefix for the IPv6 subnet object is
2002:836b:1:1:0:5efe:192.168.99.0/120. For an arbitrary IPv4 prefix length (set to 24 in the
example), the corresponding IPv6 prefix length is 96 + IPv4PrefixLength.
For the IPv6 addresses of DirectAccess clients, you should add the following:
An IPv6 subnet for the range 2001:0:WWXX:YYZZ::/64, in which WWXX:YYZZ is the colon-
hexadecimal version of the first consecutive public IPv4 address (w.x.y.z) assigned to the
Internet interface of the DirectAccess server. This IPv6 prefix is for Teredo-based
DirectAccess clients.
If you have a native IPv6 infrastructure, an IPv6 subnet for the range 48-
bitIntranetPrefix:5555::/64, in which 48-bitIntranetPrefix is the 48-bit native IPv6 prefix that is
being used on your intranet. This IPv6 prefix is for Internet Protocol over Secure Hypertext
Transfer Protocol (IP-HTTPS)-based DirectAccess clients.
If you are using a 6to4-based IPv6 prefix on your intranet, an IPv6 subnet for the range
2002:WWXX:YYZZ:2::/64, in which WWXX:YYZZ is the colon-hexadecimal version of the first
Scripted installation using Network Shell (Netsh) command-line toolFor customized DirectAccess deployments that need to be completely modified to meet a unique
set of needs, you can create a scripted configuration of the DirectAccess server using Network
Shell (Netsh) commands. These custom scripted installations allow for maximum flexibility and
the creation of unique solutions, including many permutations that are not covered in this Design
Disable Teredo server and relay functionality on your DirectAccess server
Type the netsh interface teredo set state state=disabled command from an administrator-
level command prompt on your DirectAccess server.
If you previously added a packet filter on your Internet firewall to allow Teredo traffic to and
from the DirectAccess server, remove it.
Without Teredo connectivity, DirectAccess clients that are located behind network address
translators (NATs) will use Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS)
for IPv6 connectivity to the DirectAccess server. However, IP-HTTPS-based connections have
lower performance and higher overhead than Teredo-based connections.
Packet filters for Teredo Connectivity
The following packet filters facilitate traffic for DirectAccess clients that use Teredo. If you do not
configure these packet filters, DirectAccess clients that are behind a network address translator
(NAT) will not by default be able to connect to intranet resources or be managed by intranet
management servers.
The alternative is to disable the Teredo client on DirectAccess clients. However, without Teredo
connectivity, DirectAccess clients that are located behind NAT will use Internet Protocol over
Secure Hypertext Transfer Protocol (IP-HTTPS) for Internet Protocol version 6 (IPv6) connectivity
to the DirectAccess server. IP-HTTPS-based connections have lower performance and higher
overhead than Teredo-based connections.
Packet filters to allow inbound ICMPv6 Echo Requests on all computersDirectAccess clients that are behind NATs on the Internet attempt to use Teredo for IPv6
connectivity to the DirectAccess server. DirectAccess clients are Teredo clients to the
DirectAccess server, which is acting as a Teredo server and relay. To ensure that a destination is
32
reachable, Teredo clients send an Internet Control Message Protocol for IPv6 (ICMPv6) Echo
Request message and wait for an ICMPv6 Echo Reply message.
For a Teredo-based DirectAccess client to communicate with an intranet resource, that resource
must accept inbound ICMPv6 Echo Request messages. Therefore, for DirectAccess clients to
reach any location on the intranet, you must allow inbound ICMPv6 Echo Request messages on
all of your intranet hosts.
Enable edge traversal on inbound management trafficIf you are using Windows Firewall with Advanced Security to block unsolicited inbound traffic, you
will already have a set of inbound rules that allow the traffic from your management servers.
Because DirectAccess clients that are located behind NATs will use Teredo for IPv6 connectivity
to the DirectAccess server, you must enable edge traversal on this set of inbound rules.
Enable inbound ICMPv6 Echo Requests for management trafficFor a computer that is being managed to be reachable over Teredo, ensure that the computer has
an inbound rule for ICMPv6 Echo Request messages with edge traversal enabled. The Network
Shell (Netsh) command-line tool command for this rule is the following:
Security snap-in, they will be overwritten with default values, which can result in
incompatible connection security rules that prevent DirectAccess connections.
Additional end-to-end peer authentication for selected server accessIf you configure selected server access, the DirectAccess Setup Wizard configures Windows
Firewall with Advanced Security connection security rules to use Computer certificate or
Computer (Kerberos V5) credentials for the first authentication and User (Kerberos V5)
credentials for the second authentication to the selected servers.
Peer authentication for end-to-end accessWhen you manually configure the Windows Firewall with Advanced Security connection security
rules for end-to-end access, you can configure your own methods for the first and second IPsec
peer authentication. However, the following are recommended:
First authentication: Computer certificate or Computer (Kerberos V5)
Second authentication: User (Kerberos V5)
If you modify the connection security rules created by the DirectAccess Setup Wizard,
you must use Network Shell (Netsh) commands. There are connection security rule
settings that cannot be modified with the Windows Firewall with Advanced Security snap-
in. If you modify these connection security rules with the Windows Firewall with Advanced
Security snap-in, they will be overwritten with default values, which can result in
incompatible connection security rules that prevent DirectAccess connections.
Smart cards for additional authorizationOn the Connectivity page of Step 2 in the DirectAccess Setup Wizard, you can require the use of
smart cards for access to the intranet. When this option is selected, the DirectAccess Setup
Wizard configures the IPsec connection security rule for the intranet tunnel on the DirectAccess
server to require tunnel mode authorization with smart cards. Tunnel mode authorization is a new
feature of Windows Firewall with Advanced Security for Windows 7 and Windows Server 2008 R2
that allows you to specify that only authorized computers or users can establish an inbound
tunnel.
To use smart cards with IPsec tunnel mode authorization for the intranet tunnel, you must deploy
a public key infrastructure (PKI) with smart cards infrastructure.
Because your DirectAccess clients are using smart cards for access to the intranet, you can also
use authentication mechanism assurance, a new feature of Windows Server 2008 R2, to control
access to resources, such as files, folders, and printers, based on whether the user logged on
with a smart card-based certificate. Authentication mechanism assurance requires a domain
functional level of Windows Server 2008 R2. For more information, see What's New in AD DS:
This option is moderately secure because it allows the use of local name resolution on a
private network when the intranet DNS servers are unreachable.
Use local name resolution if there is any type of error when attempting to resolve the name
using internal network DNS servers
This is the least secure option because the names of intranet network servers can be leaked
to the local subnet through local name resolution.
Choose the option that complies with your security requirements.
NRPT rulesIn step 3 of the DirectAccess Setup Wizard, you configure the rules in the NRPT, an internal table
used by the DNS Client service to determine where to send DNS name queries. The
DirectAccess Setup Wizard automatically creates two rules for DirectAccess clients:
A DNS suffix rule for the domain name of the DirectAccess server and the IPv6 addresses
corresponding to the intranet DNS servers configured on the DirectAccess server. For
example, if the DirectAccess server is a member of the corp.contoso.com domain, the
DirectAccess Setup Wizard creates a rule for the .corp.contoso.com DNS suffix.
An exemption rule for the FQDN of the network location server. For example, if the network
location server URL is https://nls.corp.contoso.com, the DirectAccess Setup Wizard creates
an exemption rule for the FQDN nls.corp.contoso.com.
You might need to configure additional NRPT rules in step 3 of the DirectAccess Setup Wizard in
the following cases:
You need to add more DNS suffixes for your intranet namespace.
If the FDQN of your intranet and Internet CRL distribution points are based on your intranet
namespace, you must add exemption rules for the FQDNs of your Internet and intranet CRL
distribution points.
If you have a split-brain DNS environment, you must add exemption rules for the names of
resources for which you want DirectAccess clients located on the Internet to access the
public (Internet) version, rather than the intranet version.
If you are redirecting traffic to an external Web site through your intranet Web proxy servers,
the external Web site is only available from the intranet, and the external Web site is using
the addresses of your Web proxy servers to permit the inbound requests, then you must add
an exemption rule for the FQDN of the external Web site and specify that the rule use your
intranet Web proxy server, rather than the IPv6 addresses of intranet DNS servers.
For example, the Contoso Corporation is testing an external Web site named
test.contoso.com. This name is not resolvable via Internet DNS servers, but Contoso’s Web
proxy server knows how to resolve the name and to direct requests for the Web site to the
external Web server. To prevent users who are not on the Contoso intranet from accessing
the site, the external Web site only allows requests from the Internet Protocol version 4 (IPv4)
Internet address of the Contoso Web proxy. Therefore, intranet users can access the Web
site because they are using the Contoso Web proxy but DirectAccess users cannot because
42
they are not using the Contoso Web proxy. By configuring an NRPT exemption rule for
test.contoso.com that uses the Contoso Web proxy, Web page requests for test.contoso.com
will be routed to the intranet Web proxy server over the IPv4 Internet.
You can also configure NRPT rules from Computer Configuration\Policies\Windows Settings\
Name Resolution Policy in the Group Policy object for DirectAccess clients.
The maximum number of rules in the NRPT is 1000.
If you are configuring namespace rules and your DNS servers are located outside of the
intranet, you should protect the DNS queries to these servers with either Internet Protocol
security (IPsec) or DNS Security Extensions (DNSSEC).
Unqualified, single-label names and DNS search suffixesUnqualified, single-label names are sometimes used for intranet servers so that you can specify a
single name, such as http://paycheck. The DNS Client service combines these names with your
DNS suffix search list to create a series of FQDNs to resolve with DNS. By default, your
computer’s domain name is in the DNS suffix search list and additional DNS suffixes can be
added. For example, when a user on a computer that is a member of the corp.contoso.com
domain types http://paycheck in their Web browser, Windows constructs the name
paycheck.corp.contoso.com as the FQDN.
You can use the Computer Configuration/Administrative Templates/Network/DNS
Client/ DNS Suffix Search List Group Policy setting to add DNS suffixes to the DNS
suffix search lists of domain-joined client computers.
To ensure that unqualified, single-label names resolve to the same intranet resources whether
DirectAccess clients are connected to the intranet or the Internet, your DNS suffix search list
should match the namespace rules in your NRPT. As a general rule, each DNS suffix for an
intranet namespace should correspond to a namespace rule in your NRPT.
If the name of a server on the local subnet is a duplicate of a server name on the intranet,
the DirectAccess client will always connect to the intranet resource. For example, if your
home network server is named Server1 and there is an intranet server of the same name,
you will always connect to the intranet Server1. To connect to the local subnet resource,
append “.local” to the name of the server. For example, to connect to the local subnet
server named Server1, use the name Server1.local.
External DNSThe DirectAccess Setup wizard configures DirectAccess clients with the IPv4 addresses of the
6to4 relay and the Teredo server with Group Policy settings in Computer Configuration\
NLBSFlags registry value to 1 on the DirectAccess virtual machine for faster idle timeout of
IPsec security associations (SAs). With the NLBSFlags registry value set to 1, the total time it
takes for IPsec to fail over is two minutes; one minute for the idle time to expire plus one
minute for IKE to renegotiate SAs. The Hyper-V nodes do not need this configuration change.
With Hyper-V and Failover Clustering the primary failover mechanisms are the following:
Live migration
There should be no discernable client connectivity outage when the clustered DA server is
live migrated.
Quick migration
With the NLBSFlags registry value set to 1, the maximum client connectivity outage on a
quick migration should be less than two minutes.
Resource move
With the NLBSFlags registry value set to 1, the maximum client connectivity outage on a
manual resource move should be less than two minutes.
Hyper-V and Failover Clustering also support automatic recovery from a single node failure.
When failover occurs, a client should get reconnected within two minutes; there is no action
needed from the user to get reconnected. If the NLBSFlags registry value is set to 1 and the host
is back online in less than two minutes, the maximum client connectivity outage on a mode failure
should be less than two minutes.
Planning the Placement of a Network Location Server
The network location server is a required component of any DirectAccess design. To function as a
network location server, a computer must be able to host and service requests for a Secure
Hypertext Transfer Protocol (HTTPS)-based uniform resource locator (URL).
56
Where to Place the Network Location Server
The network location server is a critical part of a DirectAccess deployment. If DirectAccess client
computers on the intranet cannot successfully locate and access the secure Web page on the
network location server, they might not be able to access intranet resources.
When DirectAccess clients obtain a physical connection to the intranet or experience a network
status change on the intranet (such as an address change when roaming between subnets), they
attempt a Secure Hypertext Transfer Protocol (HTTPS) connection to a configured uniform
resource locator (URL). If the DirectAccess client can successfully obtain an HTTPS connection
to the location in the configured URL, including a revocation check of the Web server’s certificate,
they determine that they are on the intranet.
To ensure that the FQDN of the network location server is reachable for a DirectAccess client with
DirectAccess-based rules in the NRPT, the DirectAccess Setup Wizard by default adds the FQDN
of the network location server as an exemption rule to the NRPT. When the DirectAccess client
attempts to resolve the FQDN of the network location server, the FQDN matches the exemption
rule in the NRPT and the DirectAccess client uses interface-configured DNS servers, which are
reachable to resolve the name and connect to the network location server.
Because the FQDN of network location URL is added as an exemption rule to the NRPT,
the intranet Web server at that FQDN will not be accessible to DirectAccess clients on the
Internet.
To ensure that DirectAccess clients can correctly detect when they are on the Internet,
DirectAccess clients on the Internet must not be able to successfully access the network location
URL. You can accomplish this by ensuring that the FQDN cannot be resolved using Internet DNS
servers, configuring the Web server to deny connections from Internet-based clients, or by
ensuring that the certificate validation process fails when DirectAccess clients are on the Internet.
In the DirectAccess Setup Wizard, you can specify that the DirectAccess server act as the
network location server or you can type the HTTPS-based URL for network location, specifying a
network location server that is separate from the DirectAccess server. Using a separate network
location server that is a highly available intranet Web server is strongly recommended.
Highly available intranet Web server as the network location server The recommended configuration for a network location server is a highly available and,
depending on the number of DirectAccess clients, high-capacity intranet Web server. The Web
server must be able to support HTTPS-based URLs with certificate-based authentication. Internet
Information Services 7.0, included with Windows Server 2008 R2 and Windows Server 2008, can
be used as a network location server. The content of the HTTPS-based URL is not important, only
the DirectAccess client’s ability to successfully access the page at the URL.
The certificate used by the Web server to act as a network location server has the following
requirements:
Note
57
In the Subject field, either an Internet Protocol (IP) address of the intranet interface of the
Web server or the FQDN of the network location URL.
For the Enhanced Key Usage field, the Server Authentication object identifier (OID).
For the CRL Distribution Points field, a certificate revocation list (CRL) distribution point that is
accessible by DirectAccess clients that are connected to the intranet.
The FQDN in the URL or the universal naming convention (UNC) path of the CRL distribution
point location should either match an exemption rule or no rules in the NRPT so that the
DirectAccess client can use interface-configured intranet DNS servers to resolve the name. If the
DirectAccess client cannot resolve the FQDN in the URL or UNC of the CRL distribution point,
access the CRL distribution point, and verify that the network location server’s certificate has not
been revoked, intranet detection fails.
DirectAccess server as the network location server If you have to use the DirectAccess server as the network location server, which is highly
discouraged, you must do the following:
Install the Web server (IIS) server role on the DirectAccess server computer.
Obtain an additional certificate to be used for HTTPS connections to the DirectAccess server
from DirectAccess clients on the intranet.
This additional certificate must be a different certificate than that used for Internet Protocol over
HTTPS (IP-HTTPS) connections and have the following properties:
In the Subject field, either an IP address of the intranet interface of the DirectAccess server or
the FQDN of the network location URL.
For the Enhanced Key Usage field, the Server Authentication OID.
For the CRL Distribution Points field, a CRL distribution point that is accessible by
DirectAccess clients that are connected to the intranet.
To ensure that DirectAccess clients can correctly detect when they are on the Internet, you can
configure IIS on the DirectAccess server to deny connections from Internet-based clients with the
IP and Domain Restrictions Web server (IIS) role service or ensure that the CRL distribution point
location in the certificate being used for network location cannot be accessed from the Internet.
Planning Redundancy for a Network Location Server
For Internet Information Services (IIS)-based Web servers that are acting as network location
servers, you can configure redundancy with Network Load Balancing. For more information, see
Overview of the Network Load Balancing Deployment Process (http://go.microsoft.com/fwlink/?
Configuration changes for the infrastructure tunnelTo allow DirectAccess clients the ability to obtain a health certificate from an HRA on the intranet
and to remediate their noncompliant system health, you must make the following configuration
changes:
For the Group Policy object for DirectAccess clients, add the Internet Protocol version 6
(IPv6) addresses of your intranet HRAs and remediation servers to the set of accessible
endpoints in the DirectAccess Policy-ClientToDnsDc connection security rule.
For the GPO for DirectAccess servers, add the IPv6 addresses of your intranet HRAs and
remediation servers to the set of accessible endpoints in the DirectAccess Policy-
DaServerToDnsDc connection security rule.
If you are using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) for intranet IPv6
connectivity, you must assign static Internet Protocol version 4 (IPv4) addresses to your HRAs
and remediation servers. If you are using native IPv6 connectivity, you must assign static IPv6
addresses to your HRAs and remediation servers.
If you modify the connection security rules created by the DirectAccess Setup Wizard,
you must use Network Shell (Netsh) commands. There are connection security rule
settings that cannot be modified with the Windows Firewall with Advanced Security snap-
in. If you modify these connection security rules with the Windows Firewall with Advanced
Security snap-in, they will be overwritten with default values, which can result in
incompatible connection security rules that prevent DirectAccess connections.
Configuration changes for the intranet tunnelAfter you have confirmed that health certificates are being obtained by compliant NAP clients, you
must choose the NAP enforcement mode for your DirectAccess clients:
In reporting mode, DirectAccess clients will be able to perform peer authentication for the
intranet tunnel on the DirectAccess server even when they are not compliant with system
health requirements. Users on noncompliant DirectAccess clients receive no notification that
they are not compliant.
In deferred enforcement mode, DirectAccess clients will be able to perform peer
authentication for the intranet tunnel on the DirectAccess server even when they are not
compliant with system health requirements. However, users on noncompliant DirectAccess
Note Note
61
clients receive a notification that they are not compliant and a date by which they will no
longer be able to connect if they are still noncompliant.
In full enforcement mode, DirectAccess clients will not be able to perform peer authentication
for the intranet tunnel when they are not compliant with system health requirements. Users on
noncompliant DirectAccess clients will receive a notification that they are not compliant.
For reporting mode and deferred enforcement mode, there are no changes that need to be made
to the settings of the Group Policy objects for the intranet tunnel. For full enforcement mode, you
must make the following configuration changes:
For the GPO for DirectAccess servers, require health certificates for the Computer certificate
authentication method in the DirectAccess Policy-DaServerToDnsDc connection security rule.
For the GPO for DirectAccess servers, require health certificates for the Computer certificate
authentication method in the DirectAccess Policy-DaServerToMgmt connection security rule.
For the GPO for DirectAccess servers, require health certificates for the Computer certificate
authentication method and enable authorization for IPsec tunneling in the DirectAccess
Policy-DaServerToCorp connection security rule.
If you modify the connection security rules created by the DirectAccess Setup Wizard,
you must use Network Shell (Netsh) commands. There are connection security rule
settings that cannot be modified with the Windows Firewall with Advanced Security snap-
in. If you modify these connection security rules with the Windows Firewall with Advanced
Security snap-in, they will be overwritten with default values, which can result in
incompatible connection security rules that prevent DirectAccess connections.
Planning DirectAccess with an Existing Server and Domain Isolation Deployment
Server and Domain Isolation (SDI) allows administrators to dynamically segment their Windows
environment into more secure and isolated logical networks using Internet Protocol security
(IPsec) without costly changes to their network infrastructure or applications. This creates an
additional layer of policy-driven protection, helps better protect against costly network attacks,
and helps prevent unauthorized access to trusted networked resources, achieve regulatory
compliance, and reduce operational costs. For more information, see Server and Domain