DirectAccess for Windows Server 2008 R2 Design and Deployment Guides Microsoft Corporation Published: October 2009 Author: Joe Davies Editor: Scott Somahano Abstract This document contains both the Design Guide and the Deployment Guide for DirectAccess in Windows Server 2008 R2. These guides help you to design and deploy DirectAccess servers, DirectAccess clients, and infrastructure servers on your intranet. Use the Design Guide to answer the “What,” “Why,” and “When” questions a deployment design team might ask before deploying DirectAccess in a production environment. Use the Deployment Guide to answer the “How” questions a deployment team might ask when implementing a DirectAccess design. If you are using DirectAccess in Microsoft Forefront Unified Access Gateway (UAG), see the Forefront UAG Design Guide and the Forefront UAG Deployment Guide .
Welcome message from author
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 for Windows Server 2008 R2
Design and Deployment GuidesMicrosoft Corporation
Published: October 2009
Author: Joe Davies
Editor: Scott Somahano
Abstract
This document contains both the Design Guide and the Deployment Guide for DirectAccess in
Windows Server 2008 R2. These guides help you to design and deploy DirectAccess servers,
DirectAccess clients, and infrastructure servers on your intranet. Use the Design Guide to answer
the “What,” “Why,” and “When” questions a deployment design team might ask before deploying
DirectAccess in a production environment. Use the Deployment Guide to answer the “How”
questions a deployment team might ask when implementing a DirectAccess design.
If you are using DirectAccess in Microsoft Forefront Unified Access Gateway (UAG), see the
Forefront UAG Design Guide and the Forefront UAG Deployment Guide.
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.
The DirectAccess Design and Deployment Guides are 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, Windows Server, Windows Vista, and Active Directory are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Contents
DirectAccess Design Guide..........................................................................................................13
About this guide......................................................................................................................... 13
Understanding the DirectAccess Design Process.........................................................................14
Identifying Your DirectAccess Deployment Goals.........................................................................14
Transparent and Automatic Remote Access for DirectAccess Clients..........................................15
Ongoing Management of Remote DirectAccess Clients...............................................................16
Efficient Routing of Intranet and Internet Traffic............................................................................16
Reduction of Remote Access-based Servers in your Edge Network............................................17
End-to-end Traffic Protection........................................................................................................17
Multi-factor Credentials for Intranet Access..................................................................................17
Mapping Your Deployment Goals to a DirectAccess Design.........................................................17
Evaluating DirectAccess Design Examples..................................................................................18
Full Intranet Access Example........................................................................................................18
Full Intranet Access with Smart Cards Example...........................................................................19
Selected Server Access Example.................................................................................................20
Using authentication with null encapsulation for selected server access...................................21
End-to-end Access Example.........................................................................................................22
Planning a DirectAccess Deployment Strategy.............................................................................22
Resources Available to DirectAccess Clients................................................................................24
IPv6 resources on your intranet.................................................................................................24
IPv4-only resources on the intranet...........................................................................................25
Limiting connectivity to selected resources...............................................................................25
IPv6 resources on the IPv6 Internet..........................................................................................26
Choose an Intranet IPv6 Connectivity Design...............................................................................26
No existing IPv6 infrastructure...................................................................................................27
Existing ISATAP infrastructure...................................................................................................28
Existing native IPv6 infrastructure.............................................................................................28
Choose Solutions for IPv4-only Intranet Resources.....................................................................29
Choose an Access Model.............................................................................................................31
Full Intranet Access...................................................................................................................... 31
Selected Server Access................................................................................................................32
End-to-End Access....................................................................................................................... 33
Choose a Configuration Method...................................................................................................33
DirectAccess Management Console..........................................................................................34
Custom configuration using the Network Shell (Netsh) command-line tool and Group Policy...34
Design for Remote Management..................................................................................................34
Design Packet Filtering for DirectAccess......................................................................................35
Packet Filters for Your Internet Firewall........................................................................................36
Packet Filters for Your Intranet Firewall........................................................................................37
Confining ICMPv6 Traffic to the Intranet.......................................................................................37
Packet filters for Teredo Connectivity............................................................................................39
Packet filters to allow inbound ICMPv6 Echo Requests on all computers.................................39
Enable edge traversal on inbound management traffic.............................................................40
Enable inbound ICMPv6 Echo Requests for management traffic..............................................40
Packet Filters for Management Computers...................................................................................40
DirectAccess and Third-party Host Firewalls................................................................................41
Choose an Authentication and Authorization Scheme..................................................................42
Additional end-to-end peer authentication for selected server access.......................................43
Peer authentication for end-to-end access................................................................................43
Smart cards for additional authorization....................................................................................43
Allowing access for users with unusable smart cards............................................................44
Prompts for smart card credentials while on the intranet.......................................................44
Under the covers: Smart card authorization...........................................................................44
Design Addressing and Routing for the DirectAccess Server.......................................................45
IPv4 address and routing configuration.....................................................................................46
IPv6 address and routing configuration.....................................................................................46
Design Active Directory for DirectAccess......................................................................................47
Active Directory and the DirectAccess server............................................................................48
DirectAccess and user profiles for remote users.......................................................................48
Design Your DNS Infrastructure for DirectAccess.........................................................................49
Split-brain DNS.......................................................................................................................... 49
DNS server requirements for ISATAP........................................................................................50
AAAA records for servers that do not perform DNS dynamic update........................................50
Local name resolution behavior for DirectAccess clients...........................................................51
NRPT rules................................................................................................................................ 51
Unqualified, single-label names and DNS search suffixes........................................................53
External DNS............................................................................................................................. 53
Design Your PKI for DirectAccess.................................................................................................54
Autoenrollment for computer certificates...................................................................................54
Manual enrollment for network location server and IP-HTTPS certificates................................54
Certificate revocation checking and CRL distribution points......................................................55
Enabling strong CRL checking for IPsec authentication............................................................56
Smart cards for additional authorization....................................................................................56
Design Your Web Servers for DirectAccess..................................................................................57
Choose an Internet Traffic Separation Design..............................................................................58
Design Protection for Traffic between DirectAccess Clients.........................................................60
Design Your Intranet for Corporate Connectivity Detection...........................................................61
Choose a DirectAccess and VPN Coexistence Design.................................................................63
DirectAccess and third-party VPN clients..................................................................................64
Planning the Placement of a DirectAccess Server........................................................................64
When to Install a DirectAccess Server..........................................................................................65
Where to Place the DirectAccess Server......................................................................................65
Planning Redundancy for a DirectAccess Server.........................................................................66
Planning the Placement of a Network Location Server.................................................................67
Where to Place the Network Location Server...............................................................................67
Highly available intranet Web server as the network location server.........................................68
DirectAccess server as the network location server..................................................................69
Planning Redundancy for a Network Location Server..................................................................69
Planning the Placement of CRL Distribution Points......................................................................69
Where to Place the CRL Distribution Points..................................................................................70
Intranet location for intranet detection.......................................................................................70
Internet location for IP-HTTPS connections..............................................................................70
Planning Redundancy for CRL Distribution Points........................................................................71
Planning DirectAccess with Network Access Protection (NAP)....................................................71
Configuration changes for the infrastructure tunnel...................................................................72
Configuration changes for the intranet tunnel............................................................................72
Planning DirectAccess with an Existing Server and Domain Isolation Deployment......................73
Planning DirectAccess with Microsoft Forefront Threat Management Gateway...........................74
DirectAccess Capacity Planning...................................................................................................75
Capacity Planning for DirectAccess Servers.................................................................................75
Increasing the number of concurrent authentications................................................................75
Moving the IPsec gateway function to a separate server..........................................................76
Using DirectAccess with UAG...................................................................................................78
Capacity Planning for Network Location Servers..........................................................................78
Capacity Planning for CRL Distribution Points..............................................................................78
Additional DirectAccess Resources..............................................................................................78
Appendix A: DirectAccess Requirements......................................................................................79
Appendix B: Reviewing Key DirectAccess Concepts....................................................................81
IPv6........................................................................................................................................... 81
IPv6 connectivity across the IPv4 Internet.............................................................................81
6to4..................................................................................................................................... 81
Teredo................................................................................................................................. 81
IP-HTTPS........................................................................................................................... 82
IPv6 connectivity across an IPv4-only intranet.......................................................................82
IPsec......................................................................................................................................... 82
Encryption.............................................................................................................................. 83
Data integrity.......................................................................................................................... 83
Separation of DNS traffic...........................................................................................................84
NRPT exemptions..................................................................................................................85
Network location servers...........................................................................................................85
How intranet detection works.................................................................................................85
Appendix C: Documenting Your DirectAccess Design..................................................................86
Concepts................................................................................................................................... 86
Goals......................................................................................................................................... 86
Infrastructure design plan..........................................................................................................87
Custom configuration plan.........................................................................................................87
Integration strategy.................................................................................................................... 87
Staging strategy......................................................................................................................... 88
Lessons learned........................................................................................................................ 88
DirectAccess Deployment Guide..................................................................................................88
About this guide......................................................................................................................... 88
Planning Your DirectAccess Deployment......................................................................................89
Reviewing your DirectAccess design.........................................................................................89
Reviewing DirectAccess concepts.............................................................................................90
Implementing Your DirectAccess Design Plan..............................................................................90
How to implement your DirectAccess design using this guide...................................................91
Checklist: Staging a DirectAccess Deployment............................................................................92
Checklist: Preparing Your Infrastructure for DirectAccess.............................................................93
Checklist: Preparing Your DirectAccess Server............................................................................95
Checklist: Implementing a DirectAccess Design for Full Intranet Access......................................97
Checklist: Implementing a DirectAccess Design for Selected Server Access...............................99
Checklist: Implementing a DirectAccess Design for End-to-End Access....................................101
Checklist: Implementing a Redundant DirectAccess Design......................................................102
Checklist: Configuring Network Access Protection (NAP) with DirectAccess..............................103
Procedures Used in this Guide...................................................................................................104
Configure a CRL Distribution Point for Certificates.....................................................................105
Configure a Custom Certificate Template...................................................................................107
Configure Active Directory Certificate Services for CRL Locations.............................................108
Configure Client Authentication and Certificate Mapping for IP-HTTPS Connections.................110
Configure Computer Certificate Autoenrollment..........................................................................111
Configure Connection Security Rules for End-to-end Access......................................................111
Configure Connection Security Rules for Traffic Between DirectAccess Clients.........................114
Configure Corporate Connectivity Detection Settings.................................................................115
Configure DirectAccess Connection Security Rules for NAP......................................................116
Configure Force Tunneling..........................................................................................................118
Configure IIS for Network Location.............................................................................................119
Configure Packet Filters to Allow ICMP Traffic............................................................................120
Configure Packet Filters to Allow Management Traffic to DirectAccess Clients..........................121
Configure Packet Filters to Block Access to Domain Controllers................................................122
Configure Settings to Confine ICMPv6 Traffic to the Intranet......................................................123
Configure Strong Certificate Revocation Checking for IPsec Authentication..............................125
Configure the DirectAccess Server as the Network Location Server..........................................126
Configure the DirectAccess Setup Wizard for End-to-End Access.............................................127
Configure the DirectAccess Setup Wizard for Full Intranet Access.............................................128
Configure the DirectAccess Setup Wizard for Selected Server Access......................................130
Configure the NRPT for an IPv6/IPv4 DNS Gateway..................................................................132
Configure the NRPT with Group Policy.......................................................................................133
Connect to the IPv6 Internet.......................................................................................................133
Create DirectAccess Groups in Active Directory.........................................................................134
Install a Network Location Server Certificate on the DirectAccess Server..................................135
Install an IP-HTTPS Certificate...................................................................................................137
Install and Configure IIS for a Network Location Server Certificate............................................138
Install the DirectAccess Feature.................................................................................................139
Remove ISATAP from the DNS Global Query Block List............................................................140
Appendix A – Manual DirectAccess Server Configuration...........................................................140
Configure Internet access components...................................................................................141
Configure intranet access components...................................................................................142
Configure IPsec DoSP.............................................................................................................142
Configure connection security rules.........................................................................................143
DirectAccess server configuration (full intranet access model)............................................143
Connection security rules for client configuration (full intranet access model).....................144
Appendix B – Manual DirectAccess Client Configuration............................................................145
IPv6 transition technology settings..........................................................................................145
NRPT....................................................................................................................................... 146
Appendix C - DirectAccess User Interface Scripting...................................................................146
Script usage............................................................................................................................ 147
Log file..................................................................................................................................... 148
Limitation of the script..............................................................................................................148
Appendix D - DirectAccessConfig.xsd........................................................................................148
DirectAccess Troubleshooting Guide..........................................................................................163
In this guide............................................................................................................................. 163
Introduction to Troubleshooting DirectAccess.............................................................................163
When to use this guide............................................................................................................163
How to use this guide..............................................................................................................163
A-Z List of Problem Topics for DirectAccess...............................................................................164
Tools for Troubleshooting DirectAccess......................................................................................164
Network Diagnostics and Tracing...............................................................................................165
Windows Network Diagnostics................................................................................................165
Troubleshooting item in Control Panel.....................................................................................165
Network tracing for DirectAccess.............................................................................................166
Windows Firewall tracing.........................................................................................................166
Command Line Tools..................................................................................................................167
The Netsh.exe Command Line Tool............................................................................................167
netsh namespace show effectivepolicy and netsh namespace show policy............................168
netsh interface 6to4 show relay...............................................................................................169
netsh interface teredo show state............................................................................................169
netsh interface httpstunnel show interfaces.............................................................................171
netsh interface istatap show state and netsh interface istatap show router.............................172
netsh advfirewall monitor show mmsa.....................................................................................173
netsh advfirewall monitor show qmsa......................................................................................177
netsh advfirewall monitor show consec rule name=all.............................................................180
netsh advfirewall monitor show currentprofile..........................................................................184
netsh interface ipv6 show interfaces........................................................................................184
netsh interface ipv6 show interfaces level=verbose................................................................185
netsh interface ipv6 show route...............................................................................................192
The Ping.exe Command Line Tool..............................................................................................194
The Nslookup.exe Command Line Tool......................................................................................194
The Ipconfig.exe Command Line Tool.........................................................................................195
The Certutil.exe Command Line Tool..........................................................................................198
The Nltest.exe Command Line Tool............................................................................................199
Snap-in Tools.............................................................................................................................. 199
DirectAccess Management.........................................................................................................200
Log files of the DirectAccess Management snap-in.................................................................200
Group Policy Management Console and Editor..........................................................................200
NRPT rules.............................................................................................................................. 201
IPv6 Transition Technologies settings......................................................................................201
Intranet connectivity settings...................................................................................................202
Connection security rules........................................................................................................203
Windows Firewall with Advanced Security..................................................................................204
Event Viewer............................................................................................................................... 204
Certificates.................................................................................................................................. 205
General Methodology for Troubleshooting DirectAccess Connections.......................................205
Troubleshooting DirectAccess Problems.....................................................................................211
Problems with the DirectAccess Setup Wizard...........................................................................211
Fixing problems that Prevent You from Running the DirectAccess Setup Wizard.......................211
Fixing Problems Encountered during the Steps of the DirectAccess Setup Wizard....................213
Step 2-DirectAccess Server....................................................................................................213
Connectivity page.................................................................................................................213
Prefix Configuration page.....................................................................................................216
Certificate Components page...............................................................................................216
Step 3-Infrastructure Servers..................................................................................................217
Location page....................................................................................................................... 218
DNS and Domain Controller page........................................................................................218
Step 4-Application Servers......................................................................................................219
Fixing Problems Encountered when Applying the Settings of the DirectAccess Setup Wizard...219
Problems with DirectAccess Connections...................................................................................220
Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server over the
Internet.................................................................................................................................... 220
Cannot Reach the DirectAccess Server from the IPv6 Internet..................................................221
Cannot Reach the DirectAccess Server with 6to4......................................................................222
Cannot Reach the DirectAccess Server with Teredo..................................................................225
Cannot Reach the DirectAccess Server with IP-HTTPS.............................................................229
IP-HTTPS and authenticating proxies.....................................................................................232
DirectAccess Client Connection is Slow.....................................................................................232
Fixing Issues with Creating Protected Connections to the DirectAccess Server.........................233
DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server................................234
IPsec and certificate revocation checking................................................................................237
NAP health enforcement for the intranet tunnel.......................................................................238
Smart card authorization.........................................................................................................238
NTLM authentication failures...................................................................................................238
Detailed analysis of IPsec negotiation.....................................................................................239
DirectAccess Client Cannot Resolve Names with Intranet DNS Servers....................................239
Fixing Issues with Connecting to an Intranet Resource..............................................................240
DirectAccess Client Cannot Access Intranet Resources.............................................................240
Intranet Management Server Cannot Connect to a DirectAccess Client.....................................246
Fixing Problems with Creating Protected Connections to an Intranet Resource.........................248
Selected server access model.................................................................................................248
End-to-end access model........................................................................................................249
Fixing Issues with Intranet Detection..........................................................................................251
DirectAccess Client Determines that it is on the Intranet When on the Internet..........................251
DirectAccess Client Determines that it is on the Internet When on the Intranet..........................252
DirectAccess Design Guide
DirectAccess is one of the most anticipated features of the Windows Server 2008 R2 operating
system. DirectAccess allows remote users to securely access intranet shares, Web sites, and
applications without connecting to a virtual private network (VPN). DirectAccess establishes bi-
directional connectivity with a user’s intranet every time a user’s DirectAccess-enabled portable
computer connects to the Internet, even before the user logs on. Users never have to think about
connecting to the intranet, and information technology (IT) administrators can manage remote
computers outside the office, even when the computers are not connected to the VPN.
DirectAccess is supported by Windows 7 Enterprise, Windows 7 Ultimate, and Windows
Server 2008 R2.
The following are the key elements of a DirectAccess solution:
DirectAccess client. A domain-joined computer running Windows 7 Enterprise, Windows 7
Ultimate, or Windows Server 2008 R2 that can automatically and transparently connect to an
intranet through a DirectAccess server.
DirectAccess server. A domain-joined computer running Windows Server 2008 R2 that
accepts connections from DirectAccess clients and facilitates communication with intranet
resources.
Network location server. A server that a DirectAccess client uses to determine whether it is
located on the intranet or the Internet.
Certificate revocation list (CRL) distribution points. Servers that provide access to the
CRL that is published by the certification authority (CA) issuing certificates for DirectAccess.
For more information, see Appendix B: Reviewing Key DirectAccess Concepts.
About this guideThis guide is intended for use by an infrastructure specialist or system architect. The guide
provides recommendations to help you plan a new DirectAccess deployment based on the
requirements of your organization and the particular design that you want to create. It highlights
your main decision points as you plan your DirectAccess deployment. Before you read this guide,
you should have a good understanding of your organizational requirements and the capabilities
and requirements of DirectAccess.
This guide describes a set of deployment goals that are based on the primary DirectAccess
access methods. It helps you determine the most appropriate access method and corresponding
design for your environment. You can use these deployment goals to create a comprehensive
DirectAccess design that meets the needs of your environment.
Once you have determined your DirectAccess design, you can use the DirectAccess Deployment
Guide to plan and implement your design.
13
This guide, combined with the DirectAccess Deployment Guide, is also available as a Microsoft
Word file (http://go.microsoft.com/fwlink/?LinkId=163662) in the Microsoft Download Center.
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
14
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,
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.
15
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.
16
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.
17
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
18
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.
19
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
20
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
21
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.
22
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 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.
What addressing and routing do I need to configure on my DirectAccess server? For more
information, see Design Addressing and Routing for the DirectAccess Server.
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.
23
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 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
24
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 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 Solutions for IPv4-only Intranet
Resources.
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.
25
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
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.
For more information, see Connect to the IPv6 Internet in the DirectAccess Deployment Guide.
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
26
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
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 Remove ISATAP from the DNS Global Query Block List in the DirectAccess
Deployment Guide.
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:
Note
27
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 infrastructureIf you have an existing ISATAP infrastructure, the DirectAccess Setup wizard will prompt you for
the 48-bit prefix of the organization and will not configure itself as an ISATAP router. To ensure
that DirectAccess clients are reachable from the intranet, you will need to modify your IPv6
routing infrastructure so that default route traffic is forwarded to the DirectAccess server.
Existing native IPv6 infrastructureIf you have an existing native IPv6 infrastructure, the DirectAccess Setup wizard will prompt you
for the 48-bit prefix of the organization and will not configure itself as an ISATAP router. To ensure
that DirectAccess clients are reachable from the intranet, you will need to modify your IPv6
routing so that default route traffic is forwarded to the DirectAccess server.
If your intranet IPv6 address space is using something other than a single 48-bit IPv6 address
prefix, you will need to modify the default connection security rules in the Group Policy objects
created by the DirectAccess Setup Wizard to include the additional IPv6 address prefixes for your
intranet.
If you are currently connected to the IPv6 Internet, you must configure your default route traffic so
that it is forwarded to the DirectAccess server, and then configure the appropriate connections
28
and routes on the DirectAccess server so that the default route traffic is forwarded to the router
that is connected to the IPv6 Internet.
For more information, see Connect to the IPv6 Internet in the DirectAccess Deployment Guide.
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.
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 an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway, which perform IPv6/IPv4 traffic
translation and IPv6-to-IPv4 DNS name resolution services for traffic between DirectAccess
clients and IPv4-only intranet application servers. Two combinations of IPv6/IPv4 translators
Note
29
with IPv6/IPv4 DNS gateways are Network Address Translation-Protocol Translation (NAT-
PT) with DNS-Application Layer Gateway (ALG) and a NAT64 with DNS64. NAT-PT with
DNS-ALG is based on older Internet standards. NAT64 with DNS64 are based on new
Internet drafts that are in the Internet standards process.
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 an IPv6/IPv4 translator and
IPv6/IPv4 DNS gateway.
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 an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway, you typically configure it
to provide coverage for specific portions of your intranet DNS namespace. Once deployed, the
IPv6/IPv4 translator and IPv6/IPv4 DNS gateway 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
IPv6/IPv4 traffic translation and access to IPv4-only application servers on an intranet.
If you are using an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway 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 IPv6/IPv4 DNS gateway. For more
30
information, see Configure the NRPT for an IPv6/IPv4 DNS Gateway in the DirectAccess
Deployment Guide.
Because Windows Server 2008 R2 does not provide IPv6/IPv4 translator or IPv6/IPv4 DNS
gateway functionality, the configuration of these devices is beyond the scope of this design guide.
Microsoft Forefront Unified Access Gateway (UAG) includes NAT64 and DNS64 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). IPv6/IPv4 translator and IPv6/IPv4
DNS gateway 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:
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.
31
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
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
32
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 an IPv6/IPv4 translator and IPv6/IPv4
DNS gateway.
Choose a Configuration Method
You can use the following methods to deploy and configure DirectAccess:
The DirectAccess Management console
Custom configuration using the Network Shell (Netsh) command-line tool and Group Policy
The following sections describe the benefits and limitations of each of these methods.
DirectAccess Management ConsoleThe DirectAccess Management Console provides several options for deploying DirectAccess.
The DirectAccess Setup Wizard guides you through four steps to determine how the
33
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
Appendix C - DirectAccess User Interface Scripting in the DirectAccess Deployment Guide and
Perform DirectAccess Scripting (http://go.microsoft.com/fwlink/?LinkID=157388).
Custom configuration using the Network Shell (Netsh) command-line tool and Group PolicyFor customized DirectAccess deployments that need to be modified from the default settings of
the DirectAccess Setup Wizard to meet a unique set of needs, you can use Network Shell (Netsh)
commands and Group Policy settings for the Group Policy objects for DirectAccess clients,
DirectAccess servers, and selected servers. Custom configuration allows for maximum flexibility
and the creation of unique solutions, including many permutations that are not covered in this
Design Guide.
For information about Netsh commands for DirectAccess, see Appendix A – Manual DirectAccess
Server Configuration and Appendix B – Manual DirectAccess Client Configuration. For
information about Group Policy settings for DirectAccess, see Group Policy Management
Console and Editor.
Design for Remote Management
Because DirectAccess client computers are connected to the intranet whenever the DirectAccess
client is connected to the Internet, regardless of whether the user has logged on to the computer,
they can be more easily managed as intranet resources and kept current with Group Policy
changes, operating system updates, anti-malware software updates, and other changes.
Intranet management servers that client computers use to keep themselves current can consist of
the following:
Microsoft System Center Configuration Manager 2007 servers
Windows Update servers
Servers for anti-malware updates, such as antivirus servers
In some cases, intranet servers or computers must initiate connections to DirectAccess clients.
For example, helpdesk department computers can use remote desktop connections to connect to
and troubleshoot remote DirectAccess clients. To ensure that DirectAccess clients will accept
incoming traffic from these types of computers and require the protection of that traffic over the
Internet, you must identify the set of these intranet management computers and configure their
addresses in Step 3 of the DirectAccess Setup Wizard.
Once you have identified the computers, record their names, their Internet Protocol version 4
(IPv4) addresses (if you have no Internet Protocol version 6 (IPv6) infrastructure), or their IPv6
34
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. The DirectAccess Setup Wizard creates an additional set of
connection security rules for a management tunnel between DirectAccess clients and the
DirectAccess server. This management tunnel is encrypted with Internet Protocol security (IPsec),
uses computer credentials for authentication, and is separate from the intranet and infrastructure
tunnels in the full intranet and selected server access models.
Because DirectAccess clients can be behind network address translators (NATs) and use Teredo
for the IPv6 connectivity across the Internet, any inbound rules for Windows Firewall with
Advanced Security that permit unsolicited incoming traffic from management computers must be
modified to enable edge traversal and must have an inbound ICMPv6 Echo Request rule with
edge traversal enabled. For more information, see Packet Filters for Management Computers
When you are using end-to-end peer authentication with data integrity and remote
management traffic is sent within the intranet tunnel, you should use Encapsulating Security
Protocol (ESP)-Null instead of Authentication Header (AH) for data integrity.
If the computer that is managing a DirectAccess client from the intranet is running
Windows Vista or Windows Server 2008 and IPsec transport mode is required between the
managing computer and the DirectAccess client, both computers must have the same quick
mode lifetimes.
Design Packet Filtering for DirectAccess
Packet filtering must be modified for multiple components on your network to allow the following
types of traffic:
DirectAccess client traffic to and from DirectAccess servers on the Internet
DirectAccess server traffic to and from the intranet
Encapsulated DirectAccess client traffic to and from the intranet
Teredo discovery traffic for DirectAccess clients located behind network address translators
(NATs)
Management server traffic to DirectAccess clients
The following topics describe the required packet filtering for each of these types of traffic:
Packet Filters for Your Internet Firewall
Packet Filters for Your Intranet Firewall
Confining ICMPv6 Traffic to the Intranet
Packet filters for Teredo Connectivity
Packet Filters for Management Computers
Note Note
35
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, the DirectAccess
server must have two consecutive, public IPv4 addresses and your Internet firewall must pass the
traffic to the DirectAccess server without translating addresses or port numbers. 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
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.
UDP destination port 4500 inbound and UDP source port 4500 outbound
36
To support IPsec NAT-Traversal (NAT-T) for translated IPv6 clients on the IPv6 Internet, the
DirectAccess server is listening on UDP port 4500 for incoming IPsec NAT-T 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
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
37
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.
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.
38
For more information, see Configure Settings to Confine ICMPv6 Traffic to the Intranet in the
DirectAccess Deployment Guide.
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
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.
39
Enable inbound ICMPv6 Echo Requests for management trafficFor a computer that is being managed to be reachable over Teredo, ensure that the computer has
an inbound rule for ICMPv6 Echo Request messages with edge traversal enabled. The Network
Shell (Netsh) command-line tool command for this rule is the following:
netsh advfirewall firewall add rule name="Inbound ICMPv6 Echo Request with Edge
traversal" protocol=icmpv6:128,0 dir=in action=allow edge=yes profile=public,private
Packet Filters for Management Computers
To allow management computers to initiate connections with your intranet computers, you might
already have in place a set of inbound firewall rules for management traffic on your intranet. To
allow DirectAccess clients to be managed in the same way when they are on the Internet, you
can do one of the following:
Configure your existing set of inbound firewall rules for management traffic so that they also
apply to the public and private profiles and have edge traversal enabled. Although easier to
configure, this option is not recommended because the inbound rules might allow greater
exposure what is intended for DirectAccess management functionality.
Create a duplicate set of inbound firewall rules for your management traffic in the Group
Policy object for DirectAccess clients so that they only apply to the public and private profiles,
have the appropriate source Internet Protocol version 6 (IPv6) addresses of management
computers or the IPv6 prefix of your intranet, and have edge traversal enabled. This is the
recommended option because it applies the rules only to DirectAccess clients, is scoped for
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). For more information, see Configure Packet
Filters to Allow Management Traffic to DirectAccess Clients in the DirectAccess Deployment
Guide.
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:
40
netsh advfirewall firewall set rule name=”Remote Desktop (TCP-In)” dir=in new
security=authenc edge=yes
To use the security=authenc setting, ensure that there is a connection security rule that protects
the connection between the remote desktop computer and the DirectAccess client.
If the computer that is managing a DirectAccess client from the intranet is running
Windows Vista or Windows Server 2008 and Internet Protocol security (IPsec) transport
mode is required between the managing computer and the DirectAccess client, both
computers must have the same quick mode lifetimes.
DirectAccess and Third-party Host Firewalls
Because DirectAccess relies on Internet Protocol security (IPsec), Authenticated Internet Protocol
(AuthIP), and Windows Firewall connection security rules, Microsoft recommends that you do not
disable the Windows Firewall service when using a third-party host firewall. When Windows
Firewall is enabled, DirectAccess clients can use the built-in IPsec functionality and Windows
Firewall connection security rules to protect DirectAccess connections and traffic.
Your third-party firewall should be certified by the Microsoft Driver Logo Program for seamless
DirectAccess functionality. For a list of logo requirements and certified third-party host firewalls,
see Windows Quality Online Services (http://go.microsoft.com/fwlink/?Linkid=18084). Check with
your host firewall vendor to see if it supports one of the following options for seamless
DirectAccess functionality:
Uses Windows Firewall functionality.
Microsoft Forefront Client Security is an example.
Uses Windows Firewall categories and does not replace Windows Firewall connection
security (IPsec).
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).
Note
41
For more information about Windows Firewall categories, see INetFwProduct Interface
(http://go.microsoft.com/fwlink/?LinkId=157401).
For more information about third-party firewall requirements for Teredo, see Teredo co-existence
with third-party firewalls (http://go.microsoft.com/fwlink/?Linkid=157705).
Choose an Authentication and Authorization Scheme
By default, the DirectAccess Setup Wizard configures Windows Firewall with Advanced Security
connection security rules that specify the use of the following types of credentials when
negotiating the Internet Protocol security (IPsec) security associations for the tunnels to the
DirectAccess server:
The infrastructure tunnel uses Computer certificate credentials for the first authentication
and User (NTLMv2) for the second authentication. User (NTLMv2) credentials force the use
of Authenticated Internet Protocol (AuthIP) and provide access to a Domain Name System
(DNS) server and domain controller before the DirectAccess client can use Kerberos
credentials for the intranet tunnel.
The intranet tunnel uses Computer certificate credentials for the first authentication and
User (Kerberos V5) for the second authentication.
You can also specify additional authentication with selected server access, peer authentication
methods for end-to-end access, and the use of smart cards for additional authorization.
If you modify the connection security rules created by the DirectAccess Setup Wizard,
you must use Network Shell (Netsh) commands. There are connection security rule
settings that cannot be modified with the Windows Firewall with Advanced Security snap-
in. If you modify these connection security rules with the Windows Firewall with Advanced
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.
Note
42
Peer authentication for end-to-end accessWhen you manually configure the Windows Firewall with Advanced Security connection security
rules for end-to-end access, you can configure your own methods for the first and second IPsec
peer authentication. However, the following are recommended:
First authentication: Computer certificate or Computer (Kerberos V5)
Second authentication: User (Kerberos V5)
If you modify the connection security rules created by the DirectAccess Setup Wizard,
you must use Network Shell (Netsh) commands. There are connection security rule
settings that cannot be modified with the Windows Firewall with Advanced Security snap-
in. If you modify these connection security rules with the Windows Firewall with Advanced
Security snap-in, they will be overwritten with default values, which can result in
incompatible connection security rules that prevent DirectAccess connections.
Smart cards for additional authorizationOn the Connectivity page of Step 2 in the DirectAccess Setup Wizard, you can require the use of
smart cards for access to the intranet. When this option is selected, the DirectAccess Setup
Wizard configures the IPsec connection security rule for the intranet tunnel on the DirectAccess
server to require tunnel mode authorization with smart cards. Tunnel mode authorization is a new
feature of Windows Firewall with Advanced Security for Windows 7 and Windows Server 2008 R2
that allows you to specify that only authorized computers or users can establish an inbound
tunnel.
To use smart cards with IPsec tunnel mode authorization for the intranet tunnel, you must deploy
a public key infrastructure (PKI) with smart cards infrastructure.
Because your DirectAccess clients are using smart cards for access to the intranet, you can also
use authentication mechanism assurance, a new feature of Windows Server 2008 R2, to control
access to resources, such as files, folders, and printers, based on whether the user logged on
with a smart card-based certificate. Authentication mechanism assurance requires a domain
functional level of Windows Server 2008 R2. For more information, see What's New in AD DS:
Authentication Mechanism Assurance (http://go.microsoft.com/fwlink/?LinkId=159947).
Allowing access for users with unusable smart cardsTo allow temporary access for users with smart cards that are unusable, do the following:
1. Create an Active Directory security group to contain the user accounts of users who
temporarily cannot use their smart cards.
2. For the DirectAccess server Group Policy object, configure global IPsec settings for IPsec
tunnel authorization and add the Active Directory security group to the list of authorized users.
To grant access to a user that cannot use their smart card, temporarily add their user account to
the Active Directory security group. Remove the user account from the group when the smart
card is usable.
Note
43
Prompts for smart card credentials while on the intranetDue to the timing between intranet detection and the automatic establishment of tunnels to the
DirectAccess server, it is possible for users of DirectAccess clients using smart cards to be
prompted for smart card credentials when they are directly connected to the intranet. This is a
prompt that users can ignore without loss of connectivity. The solutions to this issue are the
following:
Move the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) routing function to a
separate server and then add packet filters to this server that block all User Datagram
Protocol (UDP) traffic for Internet Key Exchange (IKE) and AuthIP from the Internet Protocol
version 6 (IPv6) address prefix of the intranet to the IPv6 address of the DirectAccess
server’s tunnel endpoint. These filters will drop the tunnel establishment traffic sent by
DirectAccess clients while intranet detection is in progress. For an example of moving the
ISATAP routing function to another server, see Capacity Planning for DirectAccess Servers.
Add a connection security rule that sends tunnel endpoint traffic to an invalid destination while
intranet detection is occurring. For example, use the following Network Shell (netsh)
command-line tool command: netsh advfirewall consec add rule name="Corp
connectivity to prevent smart card prompt" endpoint1=IntranetIPv6Prefix
endpoint2=IntranetIPv6Prefix localtunnelendpoint=InvalidIPv6Address mode=tunnel
action=requireinrequireout auth1=computercert auth1ca="CN=NonExistentCA".
Both of these solutions prevent the tunnel negotiation with the DirectAccess server during intranet
detection when the DirectAccess client is on the intranet. By preventing tunnel negotiation, smart
card authorization will never occur and the user will not be prompted for their smart card
credentials.
Under the covers: Smart card authorizationSmart card authorization works by enabling tunnel mode authorization on the intranet tunnel
connection security rule of the DirectAccess server for a specific Kerberos-based security
identifier (SID). For smart card authorization, this is the well-known SID (S-1-5-65-1), which maps
to smart card-based logons. This SID is present in a DirectAccess client’s Kerberos token and is
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.
44
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 Addressing and Routing for the DirectAccess Server
The DirectAccess server must be configured with addressing and routing to support the following:
Reachability from the Internet Protocol version 4 (IPv4) Internet
Reachability from your intranet for IPv4 traffic
If your intranet is connected to the Internet Protocol version 6 (IPv6) Internet, reachability
from the IPv6 Internet for native IPv6 traffic
If your intranet has deployed native IPv6 connectivity, reachability from your intranet for native
IPv6 traffic
The following sections describe the address and routing configuration of the DirectAccess server
to support these reachability requirements.
IPv4 address and routing configurationFor the Internet interface on the DirectAccess server that is connected to the IPv4 Internet,
manually configure the following:
Two, static, consecutive public IPv4 addresses with the appropriate subnet masks.
A default gateway IPv4 address of your Internet firewall or local Internet service provider
(ISP) router.
A connection-specific Domain Name System (DNS) suffix that is different from your intranet
namespace. In most cases, you can use the DNS suffix of your ISP.
IPv4 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
45
The DirectAccess Management console sorts the public IPv4 addresses assigned to the
Internet adapter 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.
For intranet interfaces on the DirectAccess server that are connected to your IPv4-based intranet,
manually configure the following:
An IPv4 intranet address with the appropriate subnet mask.
A connection-specific DNS suffix of your intranet namespace.
Do not configure a default gateway on any intranet interfaces.
To configure the DirectAccess server to reach all the locations on your intranet, do the following:
1. List the IPv4 address spaces for all the locations on your intranet.
2. Use the route add -p or netsh interface ipv4 add route commands to add the IPv4 address
spaces as static routes in the IPv4 routing table of the DirectAccess server.
IPv6 address and routing configurationFor the Internet interface on the DirectAccess server connected to the IPv6 Internet, you can use
the autoconfigured address configuration provided by your ISP. Use the route print command to
ensure that a default IPv6 route pointing to the ISP router exists in the IPv6 routing table.
Additionally, you should manually configure a connection-specific DNS suffix that is different from
your intranet namespace on the Internet interface. In most cases, you can use the DNS suffix of
your ISP.
Next, determine the following:
If your ISP and your intranet routers are using default router preferences as described in RFC
4191.
If your ISP is using a higher default router preference than your local intranet routers.
If both of these are true, no other configuration for the default route is needed. The higher
preference for the ISP router ensures that the active default IPv6 route of the DirectAccess server
points to the IPv6 Internet.
If you are not using default router preference levels, configure your intranet interfaces with the
netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled command. This
command ensures that additional default routes pointing to intranet routers will not be added to
the IPv6 routing table. You can obtain the InterfaceIndex of your intranet interfaces from the
display of the netsh interface show interface command.
Additionally, you must configure a connection-specific DNS suffix of your intranet namespace on
the intranet interface.
To configure the DirectAccess server to reach all the IPv6 locations on your intranet, do the
following:
Important Important
46
1. List the IPv6 address spaces for all the locations on your intranet.
2. Use the netsh interface ipv6 add route command to add the IPv6 address spaces as static
routes in the IPv6 routing table of the DirectAccess server.
The instructions in this section only apply if your organization has deployed native IPv6
connectivity and the DirectAccess server is connected to the IPv6 Internet through an
IPv6-capable ISP.
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. For
more information, see Create DirectAccess Groups in Active Directory in the DirectAccess
Deployment Guide.
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 contain settings for Windows Firewall with Advanced Security
connection security rules (optional).
If you remove a computer from a DirectAccess client or selected server security group, the next
update of Group Policy will remove the DirectAccess settings from the computer.
Active Directory and the DirectAccess serverThe DirectAccess server must be a domain member and cannot be a domain controller.
Additionally, an Active Directory domain controller cannot be reachable from the Internet interface
of DirectAccess server; the Internet interface cannot be in the domain profile of Windows Firewall.
If any of these conditions exist, the DirectAccess Setup Wizard cannot be run. If a domain
controller is reachable from the Internet interface of DirectAccess server, when the Network
Location Awareness service assigns the Domain profile to the Internet interface, the connection
security rules that allow the DirectAccess server to act as an Internet Protocol security (IPsec)
Note
47
tunnel endpoint are not active. As a result, DirectAccess clients on the Internet cannot establish
the infrastructure and intranet tunnels with the DirectAccess server.
In some configurations, you must have an Active Directory domain controller that is on the
perimeter network, and therefore reachable from the Internet interface of DirectAccess server. For
example, for small offices that use a single router and a single subnet for an intranet in which
there is no physical perimeter network, all of your DirectAccess server interfaces can reach the
domain controller. In these configurations, you can prevent the DirectAccess server from reaching
the domain controller 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.
Additionally, 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 IPv6 packet filters to the Internet interface that prevent connectivity to the intranet
domain controllers.
For more information, see Configure Packet Filters to Block Access to Domain Controllers in the
DirectAccess Deployment Guide.
DirectAccess and user profiles for remote usersUsing roaming user profiles for DirectAccess clients for all of the contents of the user profile folder
can result in long logon and logoff times. If you want to store user profiles on network locations for
DirectAccess clients, use folder redirection for the folders of the user profile rather than roaming
user profiles for the entire user profile.
For more information, see the Managing Roaming User Data Deployment Guide
(http://go.microsoft.com/fwlink/?LinkId=73435).
Design Your DNS Infrastructure for DirectAccess
The design of your Domain Name System (DNS) infrastructure can impact how you configure
DirectAccess. The biggest design aspect of your DNS infrastructure is whether you use split-brain
DNS.
Split-brain DNSSplit-brain DNS is the use of the same DNS domain for both Internet and intranet resources. For
example, the Contoso Corporation is using split brain DNS; contoso.com is the domain name for
intranet resources and Internet resources. Internet users use http://www.contoso.com to access
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
48
the intranet Contoso Web site. When they take their laptop to the local coffee shop and access
that same URL, they will see the public Contoso Web site.
When a DirectAccess client is on the Internet, the Name Resolution Policy Table (NRPT) sends
DNS name queries for intranet resources to intranet DNS servers. A typical NRPT for
DirectAccess will have a rule for the namespace of the organization, such as contoso.com for the
Contoso Corporation, with the Internet Protocol version 6 (IPv6) addresses of intranet DNS
servers. With just this rule in the NRPT, when a user on a DirectAccess client on the Internet
attempts to access the uniform resource locator (URL) for their Web site (such as
http://www.contoso.com), they will see the intranet version. Because of this rule, they will never
see the public version of this URL when they are on the Internet.
If you want users on DirectAccess clients to see the public version of this URL when they are on
the Internet, you must add the fully qualified domain name (FQDN) of the URL as an exemption
rule to the NRPT of DirectAccess clients. However, if you add this exemption rule, users on
DirectAccess clients will never see the intranet version of this URL when they are on the Internet.
For split-brain DNS deployments, you must list the FQDNs that are duplicated on the Internet and
intranet and decide which resources the DirectAccess client should reach, the intranet version or
the public (Internet) version. For each name that corresponds to a resource for which you want
DirectAccess clients to reach the public version, you must add the corresponding FQDN as an
exemption rule to the NRPT for your DirectAccess clients.
In a split-brain DNS environment, if you want both versions of the resource to be available,
configure your intranet resources with alternate names that are not duplicates of the names that
are being used on the Internet and instruct your users to use the alternate name when on the
Intranet. For example, configure and use the alternate name www.internal.contoso.com for the
intranet name www.contoso.com.
In a non-split-brain DNS environment, the Internet namespace is different from the intranet
namespace. For example, the Contoso Corporation uses contoso.com on the Internet and
corp.contoso.com on the intranet. Because all intranet resources use the corp.contoso.com DNS
suffix, the NRPT rule for corp.contoso.com routes all DNS name queries for intranet resources to
intranet DNS servers. DNS name queries for names with the contoso.com suffix do not match the
corp.contoso.com intranet namespace rule in the NRPT and are sent to Internet DNS servers.
With a non-split-brain DNS deployment, because there is no duplication of FQDNs for intranet
and Internet resources, there is no additional configuration needed for the NRPT. DirectAccess
clients can access both Internet and intranet resources for their organization.
DNS server requirements for ISATAPFor the intranet DNS servers that are being used by DirectAccess clients, you must use at least
one DNS server that runs Windows Server 2008 R2, Windows Server 2008 with the Q958194
hotfix (http://go.microsoft.com/fwlink/?LinkId=159951) installed, or Windows Server 2008 with
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.
49
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 all DNS servers running Windows
Server 2008 and later. For more information, see Remove ISATAP from the DNS Global Query
Block List in the DirectAccess Deployment Guide..
AAAA records for servers that do not perform DNS dynamic updateFor servers running IPv6-capable non-Windows operating systems that do not support DNS
dynamic update for IPv6 addresses, manually add AAAA records for the names and IPv6
addresses of these servers.
Local name resolution behavior for DirectAccess clientsIf a name cannot be resolved with DNS, the DNS Client service in Windows 7 and Windows
Server 2008 R2 can use local name resolution, with the Link-Local Multicast Name Resolution
(LLMNR) and NetBIOS over TCP/IP protocols, to resolve the name on the local subnet.
Local name resolution is typically needed for peer-to-peer connectivity when the computer is
located on private networks, such as single subnet home networks. When the DNS Client service
performs local name resolution for intranet server names and the computer is connected to a
shared subnet on the Internet, malicious users can capture LLMNR and NetBIOS over TCP/IP
messages to determine intranet server names.
In Step 3 of the DirectAccess Setup Wizard, you configure the local name resolution behavior
based on the types of responses received from intranet DNS servers. You have the following
options:
Use local name resolution only if the internal network DNS servers determined that the name
does not exist
This option is the most secure because the DirectAccess client will only perform local name
resolution for server names that cannot be resolved by intranet DNS servers. If the intranet
DNS servers can be reached, the names of intranet servers will be resolved. If the intranet
DNS servers cannot be reached or if there are other types of DNS errors, the intranet server
names will not be leaked to the subnet through local name resolution.
Use local name resolution if the internal network DNS servers determined that the name does
not exist or if the internal network DNS servers are not reachable and the DirectAccess client
computer is on a private network
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.
50
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
they are not using the Contoso Web proxy. By configuring an NRPT exemption rule for
51
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. For more information,
see Configure the NRPT with Group Policy in the DirectAccess Deployment Guide.
The maximum number of rules in the NRPT is 1000.
If you are configuring namespace rules and your DNS servers are located outside of the
intranet, you should protect the DNS queries to these servers with either Internet Protocol
security (IPsec) or DNS Security Extensions (DNSSEC).
Unqualified, single-label names and DNS search suffixesUnqualified, single-label names are sometimes used for intranet servers so that you can specify a
single name, such as http://paycheck. The DNS Client service combines these names with your
DNS suffix search list to create a series of FQDNs to resolve with DNS. By default, your
computer’s domain name is in the DNS suffix search list and additional DNS suffixes can be
added. For example, when a user on a computer that is a member of the corp.contoso.com
domain types http://paycheck in their Web browser, Windows constructs the name
paycheck.corp.contoso.com as the FQDN.
You can use the Computer Configuration/Administrative Templates/Network/DNS
Client/DNS Suffix Search List Group Policy setting to add DNS suffixes to the DNS
suffix search lists of domain-joined client computers.
To ensure that unqualified, single-label names resolve to the same intranet resources whether
DirectAccess clients are connected to the intranet or the Internet, your DNS suffix search list
should match the namespace rules in your NRPT. As a general rule, each DNS suffix for an
intranet namespace should correspond to a namespace rule in your NRPT.
If the name of a server on the local subnet is a duplicate of a server name on the intranet,
the DirectAccess client will always connect to the intranet resource. For example, if your
home network server is named Server1 and there is an intranet server of the same name,
you will always connect to the intranet Server1. To connect to the local subnet resource,
append “.local” to the name of the server. For example, to connect to the local subnet
server named Server1, use the name Server1.local.
External DNSThe DirectAccess Setup wizard configures DirectAccess clients with the IPv4 addresses of the
6to4 relay and the Teredo server with Group Policy settings in Computer Configuration\
Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies.
For the URL for the Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) server
(the IP-HTTPS State setting), the DirectAccess Setup Wizard configures
https://Subject:443/IPHTTPS, in which Subject is the Subject field of the HTTPS certificate that
Notes Note Note
52
you specify in Step 2 of the DirectAccess Setup Wizard. If the Subject field of the IP-HTTPS
certificate is an FQDN, you must ensure that the FQDN is resolvable using Internet DNS servers.
If you modify the 6to4 Relay Name or Teredo Server Name Group Policy settings to use FQDNs
rather than an IPv4 address, you must ensure that the FQDNs are resolvable using Internet DNS
servers.
You must also ensure that the FQDNs for your Internet-accessible certificate revocation list (CRL)
distribution points are resolvable using Internet DNS servers. For example, if the URL
http://crl.contoso.com/crld/corp-DC1-CA.crl is in the CRL Distribution Points field of the IP-HTTPS
certificate of the DirectAccess server, you must ensure that the FQDN crld.contoso.com is
resolvable using Internet DNS servers.
Design Your PKI for DirectAccess
A DirectAccess deployment needs a public key infrastructure (PKI) to issue certificates to
DirectAccess clients, the DirectAccess server, selected servers, and the network location server.
Autoenrollment for computer certificatesThe DirectAccess Setup Wizard allows you to configure the full intranet access and selected
server access models that by default use certificates for Internet Protocol security (IPsec) peer
authentication. The easiest way to get certificates installed on both DirectAccess clients and
servers is to configure autoenrollment for computer certificates. For example, autoenrollment at
the domain level ensures that all domain members obtain a computer certificate from an
enterprise certification authority (CA).
For more information, see Configure Computer Certificate Autoenrollment in the DirectAccess
Deployment Guide.
Manual enrollment for network location server and IP-HTTPS certificatesYou also need to manually enroll the following certificates:
An additional certificate on the DirectAccess server for Internet Protocol over Secure
Hypertext Transfer Protocol (IP-HTTPS) authentication
An additional certificate for the network location server for HTTPS authentication
The IP-HTTPS certificate for the DirectAccess server must have the following properties:
In the Subject field, either an Internet Protocol version 4 (IPv4) address of the Internet
interface of the DirectAccess server or the fully qualified domain name (FQDN) of the IP-
HTTPS uniform resource locator (URL).
For the Enhanced Key Usage field, the Server Authentication object identifier (OID).
53
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.
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.
For more information, see the following topics in the DirectAccess Deployment Guide:
Configure a Custom Certificate Template
Install a Network Location Server Certificate on the DirectAccess Server
Install an IP-HTTPS Certificate
Certificate revocation checking and CRL distribution pointsThe following types of connections require a certificate revocation check:
The IP-HTTPS connection between the DirectAccess client and the DirectAccess server.
If the certificate revocation check fails, DirectAccess clients cannot make IP-HTTPS-based
connections to a DirectAccess server. Therefore, an Internet-based CRL distribution point
location must be present in the IP-HTTPS certificate and accessible by DirectAccess clients
that are connected to the Internet.
The HTTPS-based connection between the DirectAccess client and the network location
server.
If the certificate revocation check fails, DirectAccess clients cannot successfully access an
HTTPS-based URL on the network location server. Therefore, an intranet-based CRL
distribution point location must be present in the network location server certificate and be
accessible by DirectAccess clients that are connected to the intranet, even when there are
DirectAccess rules in the NRPT.
The IPsec tunnels between the DirectAccess client and the DirectAccess server.
See “Enabling strong CRL checking for IPsec authentication” in this topic.
For both Internet and intranet-based CRLs, the CRL distribution point must be highly accessible.
CRL distribution points can be accessed through the following:
Web servers using an HTTP-based URL, such as http://crl.corp.contoso.com/crld/corp-DC1-
CA.crl
54
File servers and accessed through a universal naming convention (UNC) path, such as \\
crl.corp.contoso.com\crld\ corp-DC1-CA.crl
For more information, see Configure a CRL Distribution Point for Certificates in the DirectAccess
Deployment Guide.
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.
Enabling strong CRL checking for IPsec authenticationBy default, the DirectAccess server and DirectAccess clients uses weak CRL checking when
performing certificate-based IPsec peer authentication. With weak CRL checking, certificate
revocation checking fails only if the validating computer confirms that the certificate has been
revoked in the CRL. 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. For more information, see Configure Strong Certificate
Revocation Checking for IPsec Authentication in the DirectAccess Deployment Guide.
If you enable strong CRL checking and the DirectAccess server cannot reach the CRL
distribution point, certificate-based IPsec authentication for all DirectAccess connections
will fail.
If you are using Network Access Protection (NAP) with DirectAccess and you enable
strong CRL checking, certificate-based IPsec authentication for all DirectAccess
connections will fail. Health certificates do not contain CRL distribution points because
their lifetime is on the order of hours, instead of years for computer certificates.
Smart cards for additional authorizationTo use smart cards with IPsec tunnel mode authorization, you must first have a PKI deployment
and a smart card infrastructure. After your smart card deployment has been completed, you
enable smart card authorization on the Connectivity page of Step 2 of the DirectAccess Setup
Wizard.
You should design your PKI to replicate the entire smart card certificate chain to the
current user certificate store in a timely manner. If the PKI is slow in replicating the
certificate chain, users will obtain a smart card certificate and leave the intranet, but be
Note Note Note Note
55
unable to use smart card authorization. To correct this condition, they might have to
return to the intranet and logon with their smart card credentials to force the PKI to install
the entire certificate chain in the local user’s certificate store.
Design Your Web Servers for DirectAccess
You will need Web locations for the following resources:
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)
For more information, see Configure IIS for Network Location in the DirectAccess Deployment
Guide.
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.
Note
56
Choose an Internet Traffic Separation Design
With Internet Protocol version 6 (IPv6) and the Name Resolution Policy Table (NRPT),
DirectAccess clients by default separate their intranet and Internet traffic in the following way:
Domain Name System (DNS) name queries for intranet fully qualified domain names
(FQDNs) and all intranet traffic is exchanged over the tunnels created with the DirectAccess
server or directly with intranet servers. Intranet traffic from DirectAccess clients is IPv6 traffic.
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.
57
To configure force tunneling, you must enable force tunneling on DirectAccess clients through
Group Policy and add a special entry in the NRPT.
To enable force tunneling with Group Policy, enable the Computer Configuration\Policies\
Administrative Templates\Network\Network Connections\Route all traffic through the
internal network setting in the Group Policy object for DirectAccess clients.
To make IPv4-based Internet resources available to DirectAccess clients that use force tunneling,
you can do one of the following:
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 an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway in front of your IPv4-based proxy
server. The IPv6/IPv4 translator and IPv6/IPv4 DNS gateway 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 IPv6/IPv4 DNS gateway.
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 or IPv6/IPv4 DNS gateway
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 or
IPv6/IPv4 DNS gateway
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 or IPv6/IPv4 DNS
gateway.
For more information, see Configure Force Tunneling in the DirectAccess Deployment Guide.
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.
Notes
58
Design Protection for Traffic between DirectAccess Clients
DirectAccess clients on the Internet can communicate with each other directly without having to
go through the DirectAccess server. For example, two DirectAccess clients on the Internet named
DACL1 and DACL2 have public Internet Protocol version 4 (IPv4) addresses and configure
themselves as 6to4 hosts with 6to4 addresses. DACL1 and DACL2 register their 6to4 addresses
with intranet DNS servers. When DACL1 initiates communication with DACL2 by name, the
intranet DNS server responds with the 6to4-based address of DACL2. DACL1 then uses 6to4
tunneling to communicate directly with DACL2.
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 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=CAName
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
59
To configure this Windows Firewall rule for Remote Desktop using Netsh.exe, you can use
the following command:
netsh advfirewall firewall add rule name=RemoteDesktop profile=public,private
program=system action=allow security=authenc protocol=tcp localport=3389
For additional protection, you can require protection for all inbound connections to the
DirectAccess client. You can specify this when creating the rule in the following ways:
From the Windows Firewall with Advanced Security snap-in, on the Requirements page,
select Require authentication for inbound connections and request authentication for
outbound connections instead of Request authentication for inbound and outbound
connections.
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.
For more information, see Configure Connection Security Rules for Traffic Between DirectAccess
Clients in the DirectAccess Deployment Guide.
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.
60
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
DirectAccess client and the intranet resources that it is trying to reach. This additional
configuration also aids in diagnosing DirectAccess connections.
To configure settings and infrastructure needed for DirectAccess clients to access a specific
intranet Web site, do the following:
1. Determine a Web site on your intranet that is not accessible from the Internet, is highly
available, and is reachable with IPv6. To ensure its ongoing reachability with IPv6, either
assign a static IPv6 address if you have a native IPv6 infrastructure or a static Internet
Protocol version 4 (IPv4) address if you are using Intra-Site Automatic Tunnel Addressing
Protocol (ISATAP). For example, the Contoso Corporation uses cweb.corp.contoso.com as its
central, highly-available intranet Web site. This Web server uses ISATAP and a static IPv4
address.
2. Enable the Computer Configuration/Policies/Administrative
Templates/Network/Network Connectivity Status Indicator/Corporate Website Probe
URL Group Policy setting in the Group Policy object for DirectAccess clients and configure it
for the highly available intranet URL. For example, enable and configure the Corporate
Website Probe URL setting with http://cweb.corp.contoso.com.
If the name of the highly-available intranet Web site changes, you will have to update the
Corporate Website Probe URL setting with the new URL.
You also need to add the IPv6 address for the infrastructure tunnel endpoint to the Computer
Configuration/Policies/Administrative Templates/Network/Network Connectivity Status
Indicator/Corporate Site Prefix List Group Policy setting in the Group Policy object (GPO) for
DirectAccess clients. The IPv6 address for the infrastructure tunnel endpoint is configured in the
Windows Firewall with Advanced Security connection security rule named DirectAccess Policy-
ClientToDnsDc in the GPO for DirectAccess clients.
For more information, see Configure Corporate Connectivity Detection Settings in the
DirectAccess Deployment Guide.
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
Note Note
61
specified as a FQDN, rather than an unqualified, single-label name. If you use an
unqualified, single-label name, corporate connectivity detection might incorrectly detect
that corporate connectivity exists and diagnostics for DirectAccess can be affected.
Choose a DirectAccess and VPN Coexistence Design
Because the migration of remote access virtual private network (VPN) solution to DirectAccess
will take time, both of these solutions for remote access connectivity to intranet resources can be
used simultaneously for different sets of clients. For example, intranet client computers running
Windows Vista or Windows XP can continue to use your remote access VPN solution and
computers running Windows 7 can begin to use DirectAccess.
If a computer running Windows 7 is both a DirectAccess client and a remote access VPN client,
ensure the following:
The remote access VPN server is not blocking access to the network location server on the
intranet, even when the network access of VPN clients is restricted. When the remote access
VPN connection is active, the DirectAccess client should successfully detect that it is located
on the intranet, regardless of its VPN-based network access status (restricted or full access).
Firewall or connection security rules of the DirectAccess client should not block access to
locations needed to remediate the system health of the computer when it has its access
restricted as a remote access VPN client.
The fully qualified domain name (FQDN) of the VPN server on the Internet either does not
match the intranet namespace or there is a corresponding exemption rule for the FQDN in the
Name Resolution Policy Table (NRPT).
The same computer acting as a DirectAccess server and a remote access VPN server with
Routing and Remote Access is not a supported configuration, except when used with Microsoft
Forefront Unified Access Gateway (UAG). For more information, see Overview of Forefront UAG
(http://go.microsoft.com/fwlink/?LinkId=160322).
DirectAccess and third-party VPN clientsWhen deploying DirectAccess with third-party VPN clients, it may be necessary to set the
following registry values to enable the seamless coexistence of the two remote access solutions:
Some third-party VPN clients do not create connections in the Network Connections folder.
This can cause DirectAccess to determine it has no intranet connectivity when the VPN
connection is established and connectivity to the intranet exists. This condition occurs when
third-party VPN clients register their interfaces by defining them as Network Device Interface
Specification (NDIS) ENDPOINT types. You can enable coexistence with these types of VPN
clients by setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\
62
NlaSvc\Parameters\ShowDomainEndpointInterfaces (REG_DWORD) registry value to 1
on DirectAccess clients.
Some third-party VPN clients use a split-tunneling configuration, which allows the VPN client
computer to access the Internet directly, without having to send the traffic through the VPN
connection to the intranet. Split-tunnel configurations typically leave the Default Gateway
setting on the VPN client as either not configured or as all zeros (0.0.0.0) . You can confirm
this behavior by establishing a successful VPN connection to your intranet and using the
Ipconfig.exe tool at command prompt to display the Default Gateway setting for the VPN
connection. By default, the DirectAccess client does not identify these types of configurations.
To configure DirectAccess clients to detect these types of VPN client configurations and
coexist with them, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
services\NlaSvc\Parameters\Internet\ EnableNoGatewayLocationDetection
(REG_DWORD) registry value to 1.
For more information about third-party VPN clients that provide their own implementations of
Internet Protocol security (IPsec), see Recommendations for Virtual Private Network Client
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
63
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
absence of an Internet firewall, connected directly to the Internet. Addresses in the ranges
10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are private IPv4 addresses and cannot be used.
The DirectAccess server requires two consecutive public IPv4 addresses so that it can act as a
Teredo server and Windows-based Teredo clients can use the DirectAccess server to perform
detection of the type of network address translator (NAT) that they are behind. For more
information, see Teredo Overview (http://go.microsoft.com/fwlink/?Linkid=157322).
The DirectAccess Management console sorts the public IPv4 addresses assigned to the
Internet adapter 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).
Note
64
To provide hardware redundancy, DirectAccess can be configured inside a Hyper-V Failover
cluster. The recommended configuration consists of two Hyper-V hosts with failover clustering
supporting a single shared DirectAccess server in a virtual machine. The two Hyper-V hosts
protect the system from a single node failure for the DirectAccess server.
In addition to the DirectAccess Setup Wizard, you need the following configuration:
The Hyper-V servers must be using identical server hardware.
Each Hyper-V server must have at least three physical network adapters to support
Internet, intranet, and Failover Clustering connectivity. Network interface card (NIC)
teaming is not supported.
A fourth network adapter is a requirement if the Hyper-V clustering solution is using iSCSI
interfaces.
The Hyper-V servers are joined to the domain and connected to the appropriate
networks.
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 be reconnected within two minutes; there is no action
65
needed from the user. 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).
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 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
Note
66
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 serverThe 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:
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.
For more information, see Install and Configure IIS for a Network Location Server Certificate in
the DirectAccess Deployment Guide.
DirectAccess server as the network location serverIf 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.
67
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.
For more information, see Configure the DirectAccess Server as the Network Location
Server and Install a Network Location Server Certificate on the DirectAccess Server in the
DirectAccess Deployment Guide.
Planning Redundancy for a Network Location Server
For Internet Information Services (IIS)-based Web servers that are acting as network location
servers, you can configure redundancy with Network Load Balancing. For more information, see
Overview of the Network Load Balancing Deployment Process (http://go.microsoft.com/fwlink/?
LinkId=159956).
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.
68
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 detectionFor 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 connectionsFor 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.
For more information, see Configure Active Directory Certificate Services for CRL Locations and
Configure a CRL Distribution Point for Certificates in the DirectAccess Deployment Guide.
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).
69
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 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.
In your deployment of IPsec enforcement, on the DirectAccess server, you need to install an
IPsec exemption certificate.
To prevent timing problems that might occur when obtaining Kerberos authentication and
accessing the Web location on the intranet HRA, you can configure Internet Information
Services (IIS) on the HRA to use NTLM authentication with the %windir%\system32\
inetsrv\appcmd.exe set config
-section:system.webServer/security/authentication/windowsAuthentication /-
providers.[value='Negotiate'] command.
Configuration changes for the infrastructure tunnelTo allow DirectAccess clients the ability to obtain a health certificate from an HRA on the intranet
and to remediate their noncompliant system health, you must make the following configuration
changes:
For the Group Policy object for DirectAccess clients, add the Internet Protocol version 6
(IPv6) addresses of your intranet HRAs and remediation servers to the set of accessible
endpoints in the DirectAccess Policy-ClientToDnsDc connection security rule.
Note
70
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
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
71
For more information, see Checklist: Configuring Network Access Protection (NAP) with
DirectAccess and Configure DirectAccess Connection Security Rules for NAP in the DirectAccess
Deployment Guide.
If you modify the connection security rules created by the DirectAccess Setup Wizard,
you must use Network Shell (Netsh) commands. There are connection security rule
settings that cannot be modified with the Windows Firewall with Advanced Security snap-
in. If you modify these connection security rules with the Windows Firewall with Advanced
Security snap-in, they will be overwritten with default values, which can result in
incompatible connection security rules that prevent DirectAccess connections.
Planning DirectAccess with an Existing Server and Domain Isolation Deployment
Server and Domain Isolation (SDI) allows administrators to dynamically segment their Windows
environment into more secure and isolated logical networks using Internet Protocol security
(IPsec) without costly changes to their network infrastructure or applications. This creates an
additional layer of policy-driven protection, helps better protect against costly network attacks,
and helps prevent unauthorized access to trusted networked resources, achieve regulatory
compliance, and reduce operational costs. For more information, see Server and Domain
Isolation (http://go.microsoft.com/fwlink/?Linkid=95395).
Both DirectAccess and SDI use a set of Windows Firewall with Advanced Security connection
security rules in Group Policy objects (GPOs) to determine when and how to protect intranet
traffic. You should perform a careful analysis of your existing SDI global IPsec settings and
connection security rules and the global IPsec settings and rules created by the DirectAccess
Setup Wizard to determine whether they are compatible. A mismatch in global IPsec or
connection security rule settings between DirectAccess and SDI can cause an IPsec negotiation
failure and a lack of connectivity when a DirectAccess client attempts to access an intranet
resource protected with SDI.
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.
Note
72
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.
Planning DirectAccess with Microsoft Forefront Threat Management Gateway
Microsoft Forefront Threat Management Gateway (TMG) can be installed on a DirectAccess
server to provide an additional layer of protection and for additional Forefront TMG features, such
as a full Internet Protocol version 4 (IPV4) firewall and secure Web publishing for computers that
are not DirectAccess clients.
Forefront TMG integrates with the Internet Protocol security (IPsec) Denial of Service Protection
(DoSP) component of DirectAccess to ensure that only IPsec-protected traffic is allowed to pass
through. For this reason, you must configure DirectAccess before installing Forefront TMG.
Forefront TMG also allows Internet Control Message Protocol (ICMP) traffic through by default,
which is required to support Teredo-based DirectAccess clients.
For more information, see Forefront Threat Management Gateway and DirectAccess
(http://go.microsoft.com/fwlink/?LinkId=169278).
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
73
Capacity Planning for DirectAccess Servers
Capacity planning for DirectAccess servers can be done in the following ways:
Increase the number of concurrent authentications
Move the Internet Protocol security (IPsec) gateway function to a separate server that has
IPsec offload hardware
Use DirectAccess with Microsoft Forefront Unified Access Gateway (UAG)
Increasing the number of concurrent authenticationsTo increase the number of concurrent authentication calls in progress at one time between the
DirectAccess server and the domain controller, set the HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\Netlogon\Parameters\ MaxConcurrentApi (REG_DWORD) registry
value on the DirectAccess server to 5, and then restart the NETLOGON service.
Moving the IPsec gateway function to a separate serverThe DirectAccess server as configured by the DirectAccess Setup Wizard has the following
functions:
Teredo server and relay
6to4 relay
Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) server
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) router
Native Internet Protocol version 6 (IPv6) router
IPsec gateway
It is possible to move these functions to other computers. One configuration that supports
scalability for many DirectAccess connections is to move the IPsec gateway and ISATAP router
functions to another computer with IPsec offload hardware, which can handle the processor-
intensive cryptographic operations and support many IPsec tunnels. The following figure shows
an example.
74
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.
75
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.
2. Set up the intra-server subnet and the static IPv6 addressing of Server 1. Reconfigure Server
2 with the appropriate IPv4 addresses for the intra-server subnet and remove the two
consecutive public IPv4 addresses. Configure Server 1 with the two consecutive public IPv4
addresses on the Internet interface.
3. Configure Server 1 as a default advertising router for the intra-server subnet, and a 6to4
relay, Teredo server and relay, and IP-HTTPS server on the Internet.
4. Disable the 6to4 relay, Teredo server and relay, and IP-HTTPS server functionality on Server
2.
5. Configure Group Policy settings for the new IPsec tunnel endpoint on Server 2.
Using DirectAccess with UAGYou can expand the capacity of a single Forefront UAG DirectAccess server deployment by
creating a load-balanced Forefront UAG array that provides high availability and scalability. For
more information, see Configuring a network load balanced array for Forefront UAG DirectAccess
(http://go.microsoft.com/fwlink/?LinkId=160075).
Capacity Planning for Network Location Servers
The network location function for DirectAccess can be placed on an intranet Web server or the
DirectAccess server. Microsoft highly recommends placing the network location function on a
76
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
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
77
Element Requirements
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)
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/?
78
Element Requirements
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
Addressing Protocol (ISATAP).
Appendix B: Reviewing Key DirectAccess Concepts
The DirectAccess solution uses a combination of Internet Protocol version 6 (IPv6) end-to-end
connectivity, Internet Protocol security (IPsec) protection of intranet traffic, separation of Domain
Name System (DNS) traffic with the Name Resolution Policy Table (NRPT), and a network
location server that DirectAccess clients use to detect when they are on the intranet. The
following sections describe the role that these technologies have in providing DirectAccess clients
with transparent access to intranet resources.
IPv6IPv6 is the new version of the Network layer of the TCP/IP protocol stack that is designed to
replace Internet Protocol version 4 (IPv4), which is in wide use today on intranets and the
79
Internet. IPv6 provides an address space large enough to accommodate end-to-end addressing
of nodes on the IPv6 Internet, and with IPv6 transition technologies, of nodes on the IPv4
Internet. DirectAccess uses this capability to provide end-to-end addressing from DirectAccess
clients on the IPv4 or IPv6 Internet to computers on an intranet.
Because most of the current Internet is IPv4-based and many organizations have not deployed
native IPv6 addressing and routing on their intranets, DirectAccess uses IPv6 transition
technologies to provide IPv6 connectivity over these IPv4-only networks. Teredo, 6to4, Internet
Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS), and the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) are examples of IPv6 transition technologies. These
technologies allow you to use IPv6 on the IPv4 Internet and your IPv4-only intranet. IPv6
transition technologies can simplify and reduce the costs of an IPv6 deployment.
IPv6 connectivity across the IPv4 InternetTo send IPv6 packets across the IPv4 Internet, a DirectAccess client can use 6to4, Teredo, or IP-
HTTPS. If the DirectAccess client has been assigned a public IPv4 address, it will use 6to4. If
assigned a private IPv4 address, it will use Teredo. If the DirectAccess client cannot connect to
the DirectAccess server with either 6to4 or Teredo, it will use IP-HTTPS.
6to4
6to4, defined in RFC 3056, is an IPv6 transition technology that provides IPv6 connectivity across
the IPv4 Internet for hosts or sites that have a public IPv4 address. For more information, see
IPv6 Transition Technologies (http://go.microsoft.com/fwlink/?Linkid=117205).
Teredo
Teredo, defined in RFC 4380, is an IPv6 transition technology that provides IPv6 connectivity
across the IPv4 Internet for hosts that are located behind an IPv4 network address translation
(NAT) device and are assigned a private IPv4 address. For more information, see Teredo
Overview (http://go.microsoft.com/fwlink/?Linkid=157322).
IP-HTTPS
IP-HTTPS is a new protocol for Windows 7 and Windows Server 2008 R2 that allows hosts
behind a Web proxy server or firewall to establish connectivity by tunneling IPv6 packets inside
an IPv4-based HTTPS session. HTTPS is used instead of HTTP so that Web proxy servers will
not attempt to examine the data stream and terminate the connection. IP-HTTPS is typically used
only if the client is unable to connect to the DirectAccess server using the other IPv6 connectivity
methods or if force tunneling has been configured.
For the details of IP-HTTPS, see the IP over HTTPS (IP-HTTPS) Tunneling Protocol Specification
(http://go.microsoft.com/fwlink/?Linkid=157309).
80
IPv6 connectivity across an IPv4-only intranetISATAP, defined in RFC 4214, is an IPv6 transition technology that provides IPv6 connectivity
between IPv6/IPv4 hosts across an IPv4-only intranet. ISATAP can be used for DirectAccess to
provide IPv6 connectivity to ISATAP hosts across your intranet.
For more information, see IPv6 Transition Technologies (http://go.microsoft.com/fwlink/?
Linkid=117205).
ISATAP can also be used to provide IPv6 connectivity when the client is at a remote
location. ISATAP deployments can either connect to the IPv6 Internet or use 6to4 to
transfer IPv6 traffic across the IPv4 Internet.
IPsecIPsec is a framework of open standards for ensuring private, secure communications over
Internet Protocol (IP) networks through the use of cryptographic security services. IPsec provides
aggressive protection against attacks through end-to-end security. The only computers that must
know about IPsec protection are the sender and receiver in the communication. IPsec provides
the ability to protect communication between workgroups, local area network computers, domain
clients and servers, branch offices (which might be physically remote), extranets, and roaming
clients.
IPsec protection can be used in two different modes: transport mode and tunnel mode. Transport
mode is designed to protect an Internet Protocol (IP) packet payload. Tunnel mode is designed to
protect an entire IP packet. For more information, see IPsec Protocol Types
(http://go.microsoft.com/fwlink/?Linkid=157319).
DirectAccess uses IPsec settings in the form of connection security rules in the Windows Firewall
with Advanced Security snap-in and the Network Shell (Netsh) command-line tool advfirewall
context for peer authentication, data integrity, and data confidentiality (encryption) of
DirectAccess connections. Multiple rules can be applied to a computer simultaneously, each
providing a different function. The result of all of these rules working together is a DirectAccess
client that can have protected communications with the DirectAccess server and intranet servers,
encrypting traffic sent over the Internet and optionally protecting traffic from end-to-end.
Windows Server 2003 and earlier versions of Windows Server do not fully support the
use of IPsec with IPv6. IPv6-capable resources on servers running Windows Server 2003
will only be available to DirectAccess clients if you use the full intranet access model.
IPv4-only resources on servers running Windows Server 2003, including most built-in
applications and system services, require an IPv6/IPv4 translator and IPv6/IPv4 DNS
gateway to be available to DirectAccess clients.
EncryptionWhen a DirectAccess client sends data to the intranet, the traffic is encrypted over the Internet.
For the full intranet and selected server access models, multiple connection security rules
Note Note
81
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 end-to-edge and selected server access models, termination of IPsec tunnels between
the DirectAccess client and the intranet is done by the IPsec Gateway component on the
DirectAccess server. This component can be located on a separate server with an IPsec offload
network adapter to increase performance.
Data integrityData integrity allows the receiving IPsec peer to cryptographically verify that the packet was not
changed in transit. When encrypting data with IPsec, data integrity is also provided. It is possible
to specify data integrity without encryption. This might be helpful in order to mitigate the threat of
spoofing or man-in-the-middle attacks and allow you to ensure that DirectAccess clients are
connecting to their intended servers.
When sensitive data is being transmitted, IPsec with only data integrity should only be
used when some other form of encryption is also implemented. It is possible to have end-
to-end data integrity using transport mode rules while using end-to-edge encryption for
the tunnel mode rules, which is how the selected server access model works.
DirectAccess accomplishes data integrity through the use of transport and tunnel mode IPsec
settings. These settings can be applied to DirectAccess clients, DirectAccess servers, or
application servers and provide data integrity by requiring ESP-NULL (recommended) or
Authentication Header (AH) for IPsec-protected communications. Some network infrastructure
devices or traffic monitoring and inspection solutions might not be able to parse packets with an
IPsec ESP or AH header. In this case, you can use authentication with null encapsulation to
perform IPsec peer authentication, but no per-packet data integrity.
Separation of DNS trafficTo separate Internet traffic from intranet traffic for DirectAccess, Windows 7 and Windows
Server 2008 R2 include the NRPT, a new feature that allows DNS servers to be defined per DNS
namespace, rather than per interface. The NRPT stores a list of rules. Each rule defines a DNS
namespace and configuration settings that define the DNS client’s behavior for that namespace.
When a DirectAccess client is on the Internet, each name query request is compared against the
namespace rules stored in the NRPT. If a match is found, the request is processed according to
the settings in the NRPT rule. The settings determine which DNS servers to which the request will
be sent.
Note
82
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.
NRPT exemptionsThere are some names that need to be treated differently from all others with regards to name
resolution; these names must not be resolved using intranet DNS servers. To ensure that these
names are resolved with interface-configured DNS servers, you must add them as NRPT
exemptions.
If no DNS server addresses are specified in the NRPT rule, the rule is an exemption. If a DNS
name matches a rule in the NRPT that does not contain addresses of DNS servers or does not
match a rule in the NRPT, the DirectAccess client sends the name query to interface-configured
DNS servers.
If any of the following servers have a name suffix that matches an NRPT rule for the intranet
namespace, that server name must be an NRPT exemption:
Network location servers
Intranet certificate revocation list (CRL) distribution points
System health remediation servers
These servers must always be resolved with interface-configured DNS servers.
83
Network location serversA network location server is an intranet network server that hosts a Secure Hypertext Transfer
Protocol (HTTPS)-based uniform resource locator (URL). DirectAccess clients access this URL to
determine whether they are located on the intranet. The DirectAccess server can be the network
location server but a separate, high-availability Web server is highly recommended. The Web
server does not have to be dedicated as a network location server.
Because the behavior of the DirectAccess client depends on the response from the network
location server, it is critical to ensure that this Web site is available from each remote branch site.
Branch locations may need a separate dedicated network location Web site at each branch
location to ensure that the Web site remains accessible even in the event of a link failure.
How intranet detection worksWhen a DirectAccess client starts up or experiences a significant network change event (such as
change in link status or a new IP address), it assumes that it is not on the intranet and uses
DirectAccess rules in the NRPT to determine where to send DNS name queries. The
DirectAccess client then attempts to resolve the fully qualified domain name (FQDN) in the URL
for the network location server, which is stored in the Computer
Configuration/Policies/Administrative Templates/Network/Network Connectivity Status
Indicator/Domain Location Determination URL Group Policy setting. Because the NRPT has
active rules for DirectAccess, this FQDN should either match an exemption rule or no rules in the
NRPT so that the DirectAccess client can use interface-configured DNS servers.
After resolving the FQDN, the DirectAccess client attempts to connect to the HTTPS-based URL
of the network location server, which includes a Secure Sockets Layer (SSL)-based
authentication and verification of the server certificate offered by the network location server. For
authenticating the DirectAccess client’s access to the URL, use anonymous authentication or
NTLM. Certificate verification includes validating the certificate and verifying that it has not been
revoked by accessing the CRL location defined in the Web server’s certificate. When the
DirectAccess client successfully accesses the HTTPS-based URL of the network location server,
it determines that it is on the intranet. The DirectAccess client then removes the DirectAccess
NRPT rules from the active table and the DirectAccess client uses interface-configured DNS
servers to resolve all names.
Just like the URL for the network location server, the FQDN in the URL or the universal
naming convention (UNC) path for the CRL distribution point should either match an
exemption rule or no rules in the NRPT so that the DirectAccess client can use interface-
configured intranet DNS servers to resolve the name. If the DirectAccess client cannot
resolve the FQDN for the CRL distribution point, intranet location detection fails.
Note
84
Appendix C: Documenting Your DirectAccess Design
Documenting your DirectAccess design will help you explain the infrastructure and policy
decisions and record the results of the deployment phases of the project. You can use the
following sections to create a document with your goals and proposed timeline, and you can add
to these sections at the end of each phase of your DirectAccess deployment.
ConceptsProvide a brief description of how DirectAccess works or use the following description:
DirectAccess gives users the experience of being seamlessly connected to their corporate
network (intranet) any time they have Internet access. With DirectAccess, users are able to
access intranet resources (such as e-mail servers, shared folders, or intranet Web sites)
securely without connecting to a virtual private network (VPN). DirectAccess provides
increased productivity for mobile workforce by offering the same connectivity experience both
in and outside of the office. DirectAccess is on whenever the user has an Internet connection,
giving users access to intranet resources whether they are traveling, at the local coffee shop,
or at home. DirectAccess is supported by Windows 7 Ultimate or later, Windows 7 Enterprise
or later, and Windows Server 2008 R2 or later.
GoalsList your reasons for deploying DirectAccess and state how your design plan will achieve these
goals. Also provide the following:
Benefits. Describe the pre-deployment state of the network and the benefits you expect to
see as a result of the DirectAccess deployment.
Requirements. List what is required to achieve your goals. Examples include operating
system updates, equipment purchases, training, cross-team collaboration, and project
schedules.
Progress. Describe your current progress.
For more information, see Identifying Your DirectAccess Deployment Goals.
Infrastructure design planList the names and locations of servers and other devices that will be used in your DirectAccess
deployment. Include current and future plans. Provide the following details:
IPv6 connectivity. Describe how you deployed Internet Protocol version 6 (IPv6) connectivity
across your intranet. Include details on routers, default routing design, and IPv6 Internet
connectivity.
85
Servers, devices, and roles. List all servers and devices, including their roles, in your
DirectAccess design. Include computers and other devices used for DirectAccess certificate
validation and connectivity.
Packet filtering. List the packet filters configured on Internet and intranet firewalls, across
intranet hosts, and for DirectAccess clients.
Capacity management and redundancy. Describe your expectations for capacity
management and redundancy in the DirectAccess design.
Scaling plan. Describe changes that will be required to support the expansion of the
DirectAccess deployment to include additional capacity.
Custom configuration planUse this section to document how you had to customize the default configuration of DirectAccess
to implement specific requirements on your network.
Baseline configuration. List the steps in the DirectAccess Setup Wizard and the options
chosen for your initial configuration.
NRPT rules. List any additional Name Resolution Policy Table (NRPT) rules for intranet
namespaces or exemptions that you needed for your deployment.
Connection security rules. List any changes made to the default connection security rules
in the form of Network Shell (Netsh) commands, including the Group Policy object, the rule
name, and the changes made.
Integration strategyDescribe your design for integrating DirectAccess with the following technologies and solutions:
VPN. Describe the changes made to your VPN configuration to accommodate DirectAccess
detection of the intranet when connected and for third-party VPN clients.
NAP. Describe the changes to DirectAccess settings and connection security rules for
Network Access Protection (NAP) health evaluation and enforcement of DirectAccess
connections.
Server and domain isolation. Describe changes made to your existing server and domain
isolation deployment to accommodate DirectAccess client connectivity to intranet resources.
Staging strategyDescribe how you staged the deployment of DirectAccess in your organization. Include the
following information:
Staging milestones. List the set of infrastructure and deployment milestones and their
requirements.
Timeline. Provide details of your proposed timeline to deploy DirectAccess on your intranet.
Include your initial timeline and any deviation from that timeline.
86
Staging results. Provide the results for each stage of your DirectAccess deployment.
Trends. Describe any trends in connectivity issues encountered.
Lessons learnedUse this section to describe problems that were encountered and solutions that were
implemented during your DirectAccess deployment.
DirectAccess Deployment Guide
DirectAccess is one of the most anticipated features of the Windows 7 and Windows
Server 2008 R2 operating systems. 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 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.
About this guideThis guide is intended for use by system administrators and system engineers. It provides
detailed instructions for deploying a DirectAccess design that has been preselected by you or an
infrastructure specialist or system architect in your organization. If your organization has not yet
selected a design, see the DirectAccess Design Guide. You can then use this guide to deploy
DirectAccess in your production environment.
This guide provides steps for deploying the following primary DirectAccess access methods:
1. Full intranet access
2. Selected server access
3. End-to-end access
This guide also provides steps for deploying the following additional DirectAccess configurations:
1. DirectAccess with Network Access Protection (NAP)
2. Using Hyper-V to provide redundancy
3. Adding capacity by moving the Internet Protocol security (IPsec) gateway function to another
server
Use the checklists in Implementing Your DirectAccess Design Plan to determine how best to use
the instructions in this guide to deploy your particular design. For information about hardware and
software requirements for deploying DirectAccess, see Appendix A: DirectAccess Requirements
in the DirectAccess Design Guide.
87
This guide, combined with the DirectAccess Design Guide, is also available as a Microsoft Word
file (http://go.microsoft.com/fwlink/?LinkId=163662) in the Microsoft Download Center.
Planning Your DirectAccess Deployment
After you collect information about your environment and decide on a DirectAccess design by
following the guidance in the DirectAccess Design Guide, you can begin to plan the deployment
of your organization's DirectAccess design. With the completed DirectAccess design and the
information in this topic, you can determine which tasks to perform to deploy DirectAccess in your
organization.
Reviewing your DirectAccess designIf the design team that constructed the original DirectAccess design for your organization is
different from the deployment team that will implement the design, make sure that the deployment
team reviews all final decisions with the design team. Review the following points regarding your
DirectAccess design:
Evaluate the design team's strategy to determine the best physical topology for the
placement of DirectAccess servers in your corporate network by reviewing the following
topics in the DirectAccess Design Guide:
Planning the Placement of a DirectAccess Server
Planning the Placement of a Network Location Server
Planning the Placement of CRL Distribution Points
It is possible that the design team might leave the subject of DirectAccess server placement
for the deployment team. The deployment team is then responsible for documenting and
implementing the physical topology of DirectAccess and dependent servers. The deployment
team can review the preceding topics and also the DirectAccess Capacity Planning and
Appendix A: DirectAccess Requirements topics in the DirectAccess Design Guide to help
determine the number of servers and the hardware requirements for the organization.
Ensure that members of the deployment team understand the reasons the selected
DirectAccess design is being deployed and how client and server computers will be affected.
Ensure that members of the deployment team also understand the stages of the
DirectAccess deployment and what decisions govern when to advance from one deployment
stage to the next. For more information, see Planning a DirectAccess Deployment Strategy.
After the design teams and deployment teams agree on these issues, they can proceed with the
deployment of the DirectAccess design. For more information, see Implementing Your
DirectAccess Design Plan.
88
Reviewing DirectAccess conceptsFor more information about how DirectAccess works and how to set up DirectAccess in a test lab,
see the following resources:
DirectAccess Design Guide
Appendix B: Reviewing Key DirectAccess Concepts
Step-by-Step Guide: Demonstrate DirectAccess in a Test Lab
(http://go.microsoft.com/fwlink/?LinkID=150613)
DirectAccess overviews, Webcasts, and other resources are available at the DirectAccess
Web site (http://go.microsoft.com/fwlink/?LinkId=160519)
Implementing Your DirectAccess Design Plan
Consider the following factors before you implement your design plan:
Staging strategy You can also use small-scale pilot or lab deployments to become familiar
with DirectAccess processes, update your infrastructure, and refine your criteria for
compliance. For more information about the phases of a DirectAccess deployment, see
Checklist: Staging a DirectAccess Deployment.
Server placement A DirectAccess server infrastructure includes DirectAccess servers,
network location servers, and CRL distribution points. For more information about planning
placement, load balancing, and redundancy for these servers, see the DirectAccess Design
Guide.
Documenting your DirectAccess deployment Documenting your DirectAccess
deployment helps you to set clear goals and record whether these goals are met. For more
information, see Appendix C: Documenting Your DirectAccess Design.
How to implement your DirectAccess design using this guideThe next step in implementing your design is to determine in what order each of the deployment
tasks must be performed. This guide uses checklists to help you walk through the various
infrastructure and server requirements, configuration of a specific access model, and then more
advanced optional configurations. The following illustration shows the order in which checklists for
a specific DirectAccess access model must be followed.
89
Use the following checklist to become familiar with the options for staging a DirectAccess
deployment in your organization:
Checklist: Staging a DirectAccess Deployment
Use the following checklist to become familiar with the deployment tasks to prepare your
infrastructure for DirectAccess:
Checklist: Preparing Your Infrastructure for DirectAccess
Use the following checklist to become familiar with preparing your DirectAccess server prior to
configuring the DirectAccess feature for your organization's DirectAccess access model:
Checklist: Preparing Your DirectAccess Server
Use the following checklists to become familiar with the deployment tasks when implementing
your organization's access model:
Checklist: Implementing a DirectAccess Design for Full Intranet Access
Checklist: Implementing a DirectAccess Design for Selected Server Access
Checklist: Implementing a DirectAccess Design for End-to-End Access
Use the following checklists to become familiar with the deployment tasks for implementing
optional DirectAccess configuration options:
90
Checklist: Implementing a Redundant DirectAccess Design
Checklist: Configuring Network Access Protection (NAP) with DirectAccess
Checklist: Moving the IPsec Gateway to Another Server (this document is in progress and not
yet available).
Checklist: Staging a DirectAccess Deployment
This checklist includes cross-reference links to important concepts about staging your
DirectAccess deployment. Perform these tasks after you have completed lab testing of
DirectAccess. For instructions 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).
Complete the tasks in this checklist in order. When a reference link takes you to a
conceptual topic, a procedure, or to another checklist, return to this topic so that you can
proceed with the remaining tasks in this checklist.
Checklist: Staging a DirectAccess deployment
Task Reference
Identify and prioritize goals;
decide on an access model;
identify pilot computers;
document deployment decisions
and processes.
Identifying Your DirectAccess
Deployment Goals
Choose an Access Model
Appendix C: Documenting
Your DirectAccess Design
Implement a DirectAccess pilot
deployment; start with a single
DirectAccess server and expand
the number of DirectAccess
clients until you have fully
deployed DirectAccess for the
scope of your pilot.
Implementing Your
DirectAccess Design Plan
Scale out; implement
redundancy as needed;
reevaluate goals and assess
benefits.
DirectAccess Capacity
Planning
Planning Redundancy for a
DirectAccess Server
Note
91
Checklist: Preparing Your Infrastructure for DirectAccess
This checklist includes cross-reference links to help you prepare your network and security
infrastructure for a DirectAccess deployment. It also contains links to procedures that will help
you complete the tasks that are required to implement this design.
Complete the tasks in this checklist in order. When a reference link takes you to a
conceptual topic, a procedure, or to another checklist, return to this topic so that you can
proceed with the remaining tasks in this checklist.
Checklist: Preparing your infrastructure for DirectAccess
Task Reference
Review important concepts for
DirectAccess.
Appendix B: Reviewing Key
DirectAccess Concepts
Review the client, server, and
network infrastructure
requirements for DirectAccess.
Appendix A: DirectAccess
Requirements
Create Active Directory security
groups for DirectAccess clients
(required) and selected servers
(optional) and add members.
Create DirectAccess Groups
in Active Directory
Configure packet filtering on
Internet and intranet firewalls.
Packet Filters for Your
Internet Firewall
Packet Filters for Your
Intranet Firewall
Configure packet filtering for
Internet Control Message
Protocol for IPv6 (ICMPv6)
traffic.
Configure Packet Filters to
Allow ICMP Traffic
Configure Settings to Confine
ICMPv6 Traffic to the Intranet
Configure packet filtering for
remote management computers.
Design for Remote
Management
Configure Packet Filters to
Allow Management Traffic to
DirectAccess Clients
Compile a list of additional Name
Resolution Policy Table (NRPT)
namespace or exemption rules.
Design Your DNS
Infrastructure for DirectAccess
Note
92
Task Reference
Add intranet A records as
needed for your network location
server and CRL distribution
points.
Design Your DNS
Infrastructure for DirectAccess
Add Internet Domain Name
System (DNS) Address (A)
records as needed for the
DirectAccess server as Internet
Protocol over Secure Hypertext
Transfer Protocol (IP-HTTPS)
server and certificate revocation
list (CRL) distribution points.
Design Your DNS
Infrastructure for DirectAccess
Configure your DNS servers
running Windows
Server 2008 R2 or Windows
Server 2008 to support
resolution of the Intra-Site
Automatic Tunnel Addressing
Protocol (ISATAP) name.
Remove ISATAP from the
DNS Global Query Block List
Configure your public key
infrastructure (PKI) for CRL
distribution points.
Configure a CRL Distribution
Point for Certificates
Configure Active Directory
Certificate Services for CRL
Locations
Configure Active Directory
Certificate Services (AD CS) for
autoenrollment of computer
certificates.
Configure Computer
Certificate Autoenrollment
Configure AD CS for a custom
certificate template for Secure
Sockets Layer (SSL) certificates.
Configure a Custom
Certificate Template
If needed by your design,
configure an Secure Hypertext
Transfer Protocol (HTTPS)
uniform resource locator (URL)
on your separate network
location server.
Configure IIS for Network
Location
If needed by your design, install Install and Configure IIS for a
93
Task Reference
a custom SSL certificate on your
separate network location server.
Network Location Server
Certificate
Checklist: Preparing Your DirectAccess Server
This checklist includes cross-reference links to important concepts about preparing the computer
that will be the DirectAccess server prior to installing the DirectAccess feature and running the
DirectAccess Setup Wizard. It also contains links to procedures that will help you complete the
tasks that are required to implement this design.
Complete the tasks in this checklist in order. When a reference link takes you to a
conceptual topic, a procedure, or to another checklist, return to this topic so that you can
proceed with the remaining tasks in this checklist.
Checklist: Preparing Your DirectAccess Server
Task Reference
Install two network
adapters (interfaces) on
your DirectAccess server.
Connect the internal
network interface to your
internal network.
See your hardware documentation.
From the Network
Connections folder,
configure your network
connections (interfaces)
with meaningful names
indicating the network to
which they are attached,
such as “Internet” and
“Internal network.”
Configure your internal
network interface with a
static Internet Protocol
version 4 (IPv4) address
configuration.
Design Addressing and Routing for the
DirectAccess Server
IPv4 General tab
(http://go.microsoft.com/fwlink/?LinkId=145843)
Note
94
Task Reference
Join the DirectAccess
server computer to the
appropriate Active
Directory Domain Services
(AD DS) domain.
Active Directory Domain Services Home
page on Microsoft Technet
(http://go.microsoft.com/fwlink/?Linkid=127814)
Connect the Internet
interface to the Internet.
On the Internet interface,
configure at least two
consecutive, static, public
IPv4 addresses that are
resolvable and reachable
on the Internet. Addresses
within the address ranges
10.0.0.0/8, 172.16.0.0/12,
or 192.168.0.0/16 are not
public IPv4 addresses.
Design Addressing and Routing for the
DirectAccess Server
IPv4 General tab
(http://go.microsoft.com/fwlink/?LinkId=145843)
Configure your Internet
and intranet interfaces
with different connection-
specific Domain Name
System (DNS) suffixes.
Configure your intranet
interface with the DNS
suffix for your
organization.
Design Addressing and Routing for the
DirectAccess Server
IPv4 and IPv6 Advanced DNS tab
(http://go.microsoft.com/fwlink/?LinkId=145844)
Configure static routes for
your intranet on the
DirectAccess server.
Design Addressing and Routing for the
DirectAccess Server
If a domain controller is
reachable from the
Internet interface,
configure packet filters to
prevent access.
Configure Packet Filters to Block Access to
Domain Controllers
Verify that the
DirectAccess server has a
computer certificate
installed with the computer
authentication Enhanced
View Certificates
(http://go.microsoft.com/fwlink/?LinkId=145845)
95
Task Reference
Key Usage (EKU).
Install a Secure Sockets
Layer (SSL) certificate for
Internet Protocol over
Secure Hypertext Transfer
Protocol (IP-HTTPS)
authentication.
Install an IP-HTTPS Certificate
If the DirectAccess server
is acting as the network
location server, install the
IIS (Web server) role.
Configure the DirectAccess Server as the
Network Location Server
If the DirectAccess server
is acting as the network
location server, install an
additional SSL certificate.
Install a Network Location Server Certificate
on the DirectAccess Server
Checklist: Implementing a DirectAccess Design for Full Intranet Access
This checklist includes cross-reference links to important concepts about deploying DirectAccess
in the full intranet access model. It also contains links to procedures and other checklists that will
help you complete the tasks that are required to implement this design.
Complete the tasks in this checklist in order. When a reference link takes you to a
conceptual topic, a procedure, or to another checklist, return to this topic so that you can
proceed with the remaining tasks in this checklist.
Checklist: Implementing a DirectAccess design for full intranet access
Task Reference
Review important concepts and
the example for the
DirectAccess full intranet access
model.
Full Intranet Access
Full Intranet Access Example
Configure the required
infrastructure for DirectAccess.
Checklist: Preparing Your
Infrastructure for DirectAccess
Prepare the DirectAccess server Checklist: Preparing Your
Note
96
Task Reference
computer for the DirectAccess
Setup Wizard.
DirectAccess Server
Install the DirectAccess feature
on the DirectAccess server.
Install the DirectAccess
Feature
Configure the DirectAccess
server for the full intranet access
method with the DirectAccess
Setup Wizard.
Configure the DirectAccess
Setup Wizard for Full Intranet
Access
Configure the Corporate
Website Probe URL and
Corporate Site Prefix List Group
Policy settings.
Design Your Intranet for
Corporate Connectivity Detection
Configure Corporate
Connectivity Detection Settings
If needed by your design plan,
deploy and configure IPv6/IPv4
translator and IPv6/IPv4 DNS
gateway devices.
Choose Solutions for IPv4-
only Intranet Resources
See the IPv6/IPv4 translator and
IPv6/IPv4 DNS gateway device
documentation.
Configure the NRPT for an
IPv6/IPv4 DNS Gateway
If needed by your design plan,
configure force tunneling.
Configure Force Tunneling
If needed by your design plan,
configure a connection or
routing to the Internet Protocol
version 6 (IPv6) Internet.
Connect to the IPv6 Internet
If needed by your design plan,
configure client authentication
and certificate mapping for
Internet Protocol over Secure
Hypertext Transfer Protocol (IP-
HTTPS) connections.
Configure Client
Authentication and Certificate
Mapping for IP-HTTPS
Connections
If needed by your design plan,
configure connection security
rules to protect traffic sent
between DirectAccess clients.
Configure Connection
Security Rules for Traffic
Between DirectAccess Clients
97
Checklist: Implementing a DirectAccess Design for Selected Server Access
This checklist includes cross-reference links to important concepts about deploying DirectAccess
in the selected server access model. It also contains links to procedures and other checklists that
will help you complete the tasks that are required to implement this design.
Complete the tasks in this checklist in order. When a reference link takes you to a
conceptual topic, a procedure, or to another checklist, return to this topic so that you can
proceed with the remaining tasks in this checklist.
Checklist: Implementing a DirectAccess design for selected server access
Task Reference
Review important concepts and
the example for the
DirectAccess selected server
access model.
Selected Server Access
Selected Server Access
Example
Configure the required
infrastructure for DirectAccess.
Checklist: Preparing Your
Infrastructure for DirectAccess
Prepare the DirectAccess server
computer for the DirectAccess
Setup Wizard.
Checklist: Preparing Your
DirectAccess Server
Install the DirectAccess feature
on the DirectAccess server.
Install the DirectAccess
Feature
Configure the DirectAccess
server for the selected server
access method with the
DirectAccess Setup Wizard.
Configure the DirectAccess
Setup Wizard for Selected
Server Access
Configure the Corporate
Website Probe URL and
Corporate Site Prefix List Group
Policy settings.
Design Your Intranet for
Corporate Connectivity Detection
Configure Corporate
Connectivity Detection Settings
If needed by your design plan,
deploy and configure IPv6/IPv4
translator and IPv6/IPv4 DNS
gateway devices.
Choose Solutions for IPv4-
only Intranet Resources
See the IPv6/IPv4 translator and
IPv6/IPv4 DNS gateway device
documentation.
Configure the NRPT for an
Note
98
Task Reference
IPv6/IPv4 DNS Gateway
If needed by your design plan,
configure force tunneling.
Configure Force Tunneling
If needed by your design plan,
configure a connection or
routing to the Internet Protocol
version 6 (IPv6) Internet.
Connect to the IPv6 Internet
If needed by your design plan,
configure client authentication
and certificate mapping for
Internet Protocol over Secure
Hypertext Transfer Protocol (IP-
HTTPS) connections.
Configure Client
Authentication and Certificate
Mapping for IP-HTTPS
Connections
If needed by your design plan,
configure connection security
rules to protect traffic sent
between DirectAccess clients.
Configure Connection
Security Rules for Traffic
Between DirectAccess Clients
Checklist: Implementing a DirectAccess Design for End-to-End Access
This checklist includes cross-reference links to important concepts about deploying DirectAccess
in the end-to-end access model. It also contains links to procedures and other checklists that will
help you complete the tasks that are required to implement this design.
Complete the tasks in this checklist in order. When a reference link takes you to a
conceptual topic, a procedure, or to another checklist, return to this topic so that you can
proceed with the remaining tasks in this checklist.
Checklist: Implementing a DirectAccess design for end-to-end access
Task Reference
Review important concepts and
the example for the
DirectAccess end-to-end access
model.
End-to-End Access
End-to-end Access Example
Configure the required Checklist: Preparing Your
Note
99
Task Reference
infrastructure for DirectAccess. Infrastructure for DirectAccess
Prepare the DirectAccess server
computer for the DirectAccess
Setup Wizard.
Checklist: Preparing Your
DirectAccess Server
Install the DirectAccess feature
on the DirectAccess server.
Install the DirectAccess
Feature
Configure the DirectAccess
server for the end-to-end access
method with the DirectAccess
Setup Wizard.
Configure the DirectAccess
Setup Wizard for End-to-End
Access
Customize the connection
security policies created by the
DirectAccess Setup Wizard for
end-to-end access.
Configure Connection
Security Rules for End-to-end
Access
Configure the Corporate
Website Probe URL Group
Policy setting.
Design Your Intranet for
Corporate Connectivity
Detection
Configure Corporate
Connectivity Detection Settings
If needed by your design plan,
configure force tunneling.
Configure Force Tunneling
If needed by your design plan,
configure a connection or routing
to the Internet Protocol version 6
(IPv6) Internet.
Connect to the IPv6 Internet
If needed by your design plan,
configure client authentication
and certificate mapping for
Internet Protocol over Secure
Hypertext Transfer Protocol (IP-
HTTPS) connections.
Configure Client
Authentication and Certificate
Mapping for IP-HTTPS
Connections
If needed by your design plan,
configure connection security
rules to protect traffic sent
between DirectAccess clients.
Configure Connection
Security Rules for Traffic
Between DirectAccess Clients
100
Checklist: Implementing a Redundant DirectAccess Design
This checklist includes cross-reference links to important concepts about deploying a redundant
design DirectAccess with Hyper-V. It also contains links to procedures and other checklists that
will help you complete the tasks that are required to implement this design.
Complete the tasks in this checklist in order. When a reference link takes you to a
conceptual topic, a procedure, or to another checklist, return to this topic so that you can
proceed with the remaining tasks in this checklist.
Checklist: Implementing a redundant DirectAccess design
Task Reference
Review important concepts for
using Hyper-V to provide
redundancy for DirectAccess.
Planning Redundancy for a
DirectAccess Server
As needed by your design plan,
configure DirectAccess for the
full intranet, selected server, or
end-to-end access model.
Checklist: Implementing a
DirectAccess Design for Full
Intranet Access
Checklist: Implementing a
DirectAccess Design for
Selected Server Access
Checklist: Implementing a
DirectAccess Design for End-to-
End Access
Configure two Hyper-V hosts
with failover clustering
supporting a single shared
DirectAccess server in a virtual
machine and modify the Hyper-V
configuration for DirectAccess.
Planning Redundancy for a
DirectAccess Server
Checklist: Configuring Network Access Protection (NAP) with DirectAccess
This checklist includes cross-reference links to important concepts about deploying Network
Access Protection (NAP) with DirectAccess. It also contains links to procedures and other
checklists that will help you complete the tasks that are required to implement this design.
Note
101
Complete the tasks in this checklist in order. When a reference link takes you to a
conceptual topic, a procedure, or to another checklist, return to this topic so that you can
proceed with the remaining tasks in this checklist.
Checklist: Configuring NAP with DirectAccess
Task Reference
Review important concepts for
using NAP with DirectAccess.
Planning DirectAccess with
Network Access Protection
(NAP)
Deploy NAP with the Internet
Protocol security (IPsec)
enforcement method.
Implementing Your NAP
Design Plan
Checklist: Implementing an
IPsec Enforcement Design
Install an IPsec enforcement
exemption certificate on the
DirectAccess server.
Create an IPsec NAP
Exemption Group
As needed by your design plan,
configure DirectAccess for the
full intranet, selected server, or
end-to-end access model.
Checklist: Implementing a
DirectAccess Design for Full
Intranet Access
Checklist: Implementing a
DirectAccess Design for
Selected Server Access
Checklist: Implementing a
DirectAccess Design for End-to-
End Access
As needed by your design plan,
modify the connection security
rules for DirectAccess clients
and servers.
Configure DirectAccess
Connection Security Rules for
NAP
Procedures Used in this Guide
The procedures in this section appear in the checklists of this guide. They should be used within
the context of the checklists in which they appear. They are presented here in alphabetical order.
Configure a CRL Distribution Point for Certificates
Configure a Custom Certificate Template
Configure Active Directory Certificate Services for CRL Locations
Note
102
Configure Client Authentication and Certificate Mapping for IP-HTTPS Connections
Configure Computer Certificate Autoenrollment
Configure Connection Security Rules for End-to-end Access
Configure Connection Security Rules for Traffic Between DirectAccess Clients
Configure Corporate Connectivity Detection Settings
Configure DirectAccess Connection Security Rules for NAP
Configure Force Tunneling
Configure IIS for Network Location
Configure Packet Filters to Allow ICMP Traffic
Configure Packet Filters to Allow Management Traffic to DirectAccess Clients
Configure Packet Filters to Block Access to Domain Controllers
Configure Settings to Confine ICMPv6 Traffic to the Intranet
Configure Strong Certificate Revocation Checking for IPsec Authentication
Configure the DirectAccess Server as the Network Location Server
Configure the DirectAccess Setup Wizard for End-to-End Access
Configure the DirectAccess Setup Wizard for Full Intranet Access
Configure the DirectAccess Setup Wizard for Selected Server Access
Configure the NRPT for an IPv6/IPv4 DNS Gateway
Configure the NRPT with Group Policy
Connect to the IPv6 Internet
Create DirectAccess Groups in Active Directory
Install a Network Location Server Certificate on the DirectAccess Server
Install an IP-HTTPS Certificate
Install and Configure IIS for a Network Location Server Certificate
Install the DirectAccess Feature
Remove ISATAP from the DNS Global Query Block List
Configure a CRL Distribution Point for Certificates
To successfully authenticate an Internet Protocol over Secure Hypertext Transfer Protocol (IP-
HTTPS)-based connection, DirectAccess clients must be able to check for certificate revocation
of the secure sockets layer (SSL) certificate submitted by the DirectAccess server. To
successfully perform intranet detection, DirectAccess clients must be able to check for certificate
revocation of the SSL certificate submitted by the network location server. This procedure
describes how to do the following:
103
Create a Web-based certificate revocation list (CRL) distribution point using Internet
Information Services (IIS)
Configure permissions on the CRL distribution shared folder
Publish the CRL in the CRL distribution shared folder
To complete these procedures, you must be delegated permissions to configure IIS, file sharing
permissions on a shared folder, and Active Directory Certificate Services (AD CS).
In this procedure, you create and configure a Web site to contain the CRL files.
1. On the IIS server, click Start, point to Administrative Tools, and then click Internet
Information Services (IIS) Manager.
2. In the console tree, open the server name, and then Sites.
3. Right-click Default Web Site, and then click Add virtual directory.
4. In Alias, type the name of the site containing the CRL distribution list (example: CRLD).
5. In Physical path, click the ellipsis (…).
6. Click the appropriate drive, and then click Make New Folder.
7. Type the name of a folder that will contain the CRL distribution list files (example:
CRLDist), press ENTER, and then click OK twice.
8. In the contents pane, double-click Directory Browsing.
9. In the Actions pane, click Enable.
10. In the console tree, click the new site name folder.
11. In the contents pane, double-click Configuration Editor.
12. In Section, open system.webServer\security\authentication\requestFiltering.
13. In the contents pane, double-click allowDoubleEscaping to change it from False to
True.
14. In the Actions pane, click Apply.
In this procedure, you configure the permissions on the CRL distribution file share so that the
certification authority (CA) can write CRL files.
1. On the computer that will contain the CRL distribution file shared folder, click Start, and
then click Computer.
2. Double-click the appropriate drive.
3. In the details pane, right-click the folder that will store the CRL files, and then click
Properties.
4. Click the Sharing tab, and then click Advanced Sharing.
5. Select Share this folder.
6. In Share name, add $ to the end of the folder name to hide the share (example:
CRLDist$), and then click Permissions.
To create a Web-based CRL distribution pointTo configure permissions on the CRL distribution file shared folder
104
7. Click Add, and then click Object Types.
8. Select Computers, and then click OK.
9. In Enter the object names to select, type the name of the CA, and then click OK.
10. In Group or user names, click the name of the CA computer. In Permissions, click Full
Control, and then click OK twice.
11. Click the Security tab, and then click Edit.
12. Click Add, and then click Object Types.
13. Select Computers, and then click OK.
14. In Enter the object names to select, type the name of the CA, and then click OK.
15. In Group or user names, click the name of the CA computer. In Permissions, click Full
Control, click OK, and then click Close.
In this procedure, you manually publish the CRL from the CA and check for CRL files in the folder
on the IIS server.
1. On the computer running AD CS, click Start, point to Administrative Tools, and then
click Certification Authority.
2. In the console tree, double-click the CA name, right-click Revoked Certificates, point to
All Tasks, and then click Publish.
3. If prompted, click New CRL, and then click OK.
4. Click Start, type \\IisServer\SharedFolder$, and then press ENTER.
5. In the SharedFolder$ window, you should see two CRL files named CAName and
CAName+.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure a Custom Certificate Template
The DirectAccess and network location servers require the use of certificates for Secure Sockets
Layer (SSL) authentication that have customized certificate properties. To request and modify
certificates from an Active Directory Certificate Services (AD CS)-based certification authority
(CA), you must create a customized certificate template that includes the Server Authentication
object identifier (OID).
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to create and enable certificate template settings on an AD
CS-based CA. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.
To publish the CRL To create and enable a custom certificate template
105
1. On the CA computer, click Start, type certtmpl.msc, and then press ENTER.
2. In the contents pane, right-click the Web Server template, and then click Duplicate
Template.
3. In the contents pane, right-click the Web Server template, and then click Duplicate
Template.
4. Click Windows Server 2008 Enterprise, and then click OK.
5. In Template display name, type the name of the customized SSL template. For
example, Custom SSL certificates.
6. Click the Security tab.
7. Click Authenticated Users, and then select Enroll in the Allow column.
8. Click Add, type Domain Computers, and then click OK.
9. Click Domain Computers, and then select Enroll in the Allow column.
10. Click the Request Handling tab.
11. Select Allow private key to be exported.
12. Click OK.
13. Close the MMC window without saving changes.
14. Click Start, point to Administrative Tools, and then click Certification Authority.
15. In the console tree, expand the CA name, right-click Certificate Templates, point to
New, and then click Certificate Template To Issue.
16. In the list of certificate templates, click the name of the SSL custom template, and then
click OK.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure Active Directory Certificate Services for CRL Locations
If you are using Active Directory Certificate Services, you must configure the certification authority
(CA) that issues the Secure Sockets Layer (SSL) certificates to the network location server and
the DirectAccess server with additional certificate revocation list (CRL) distribution settings.
These settings are required so that DirectAccess clients can perform certificate revocation
checking for SSL certificates of the network location server (when located on the intranet) and the
DirectAccess server (for Internet Protocol over Secure Hypertext Transfer Protocol [IP-HTTPS]-
based connections).
Prior to this procedure, you should have determined the following:
106
1. The uniform resource locator (URL) or universal naming convention (UNC) path for the CRL
distribution point that is accessible from the intranet for the SSL certificate needed for network
location detection.
2. The URL or UNC path for the CRL distribution point that is accessible from the Internet for the
SSL certificate needed by the DirectAccess server for IP-HTTPS connections.
3. The UNC path for the shared folder that will contain the CRL files written by the CA.
The computer account of the CA must have read and write permissions to the folder
corresponding to the shared folder that will contain the CRL files.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to change global settings on an AD CS-based CA. Review
details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.
The following procedure is for configuring a single CRL distribution point for issued certificates
and to configure a single corresponding location to store the CRL files. If you are using the same
URL or UNC path for both your intranet and Internet CRL location, you only need to perform this
procedure once. If you are using different locations for the intranet and Internet CRL distribution
points, perform this procedure twice on the appropriate CA.
1. On the CA computer, click Start, point to Administrative Tools, and then click
Certification Authority.
2. In the console tree, right-click the name of the CA, and then click Properties.
3. Click the Extensions tab, and then click Add.
4. In Location, type the URL or UNC path for the CRL distribution point. For example, type
http://crl.contoso.com/crld/.
5. In Variable, click <CAName>, and then click Insert.
6. In Variable, click <CRLNameSuffix>, and then click Insert.
7. In Variable, click <DeltaCRLAllowed>, and then click Insert.
8. In Location, type .crl at the end of the Location string, and then click OK.
9. Select Include in CRLs. Clients use this to find Delta CRL locations. and Include in
the CDP extension of issued certificates, and then click OK.
10. Click Add.
11. In Location, type the UNC path for the shared folder location that will contain the CRL
files.
12. In Variable, click <CAName>, and then click Insert.
13. In Variable, click <CRLNameSuffix>, and then click Insert.
14. In Variable, click <DeltaCRLAllowed>, and then click Insert.
15. In Location, type .crl at the end of the string, and then click OK.
16. Select Publish CRLs to this location and Publish Delta CRLs to this location, and
Note To configure CRL distribution settings
107
then click OK.
17. Click Yes to restart Active Directory Certificate Services.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure Client Authentication and Certificate Mapping for IP-HTTPS Connections
This procedure helps mitigate possible security issues for Internet Protocol over Secure Hypertext
Transfer Protocol (IP-HTTPS)-connected DirectAccess clients.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to configure HTTPS settings. Review details about using the
appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
1. On the DirectAccess server, start a command prompt as an administrator.
2. From the Command Prompt window, type the certutil –store my command.
3. From the output of the Certutil.exe tool, find the certificate that is being used for IP-
HTTPS authentication and note the Cert Hash(sha1) field.
4. From the Command Prompt window, type the netsh http add sslcert
ipport=IPHTTPSPublicIPv4Address:443 certhash=HashofDA_IPHTTPSCert
appid={00112233-4455-6677-8899-AABBCCDDEEFF} dsmapperusage=enabled
command.
IPHTTPSPublicIPv4Address is the public IPv4 address that the DirectAccess server
is listening on for incoming IP-HTTPS connections. You can obtain this address from
the URL in the display of the netsh interface httpstunnel show interfaces
command. IPHTTPSPublicIPv4Address is either the Internet Protocol version 4
(IPv4) address in the uniform resource locator (URL) or the IPv4 address to which the
fully qualified domain name (FQDN) in the URL resolves on the Internet.
IPHTTPSPublicIPv4Address can also be set to 0.0.0.0.
HashofDA_IPHTTPSCert is the certificate hash from step 3, a 20-byte hexadecimal
number, with the spaces removed.
You can also use the GuidGEN.exe tool (http://go.microsoft.com/fwlink/?Linkid=121586)
to generate the GUID for the appid parameter.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
To configure client authentication and certificate mapping for the IP-HTTPS certificateNote
108
Configure Computer Certificate Autoenrollment
The default connection security rules use a computer certificate for Internet Protocol security
(IPsec) peer authentication. This requires a certificate on DirectAccess clients, DirectAccess
servers, and selected servers with either the Client Authentication or IP Security IKE Intermediate
object identifier (OID). The easiest way to deploy certificates containing the Client Authentication
OID to both DirectAccess clients and servers is to configure certificate autoenrollment for the
built-in Computer Certificate template.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to change Group Policy settings. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. On a domain controller, click Start, type gpmc.msc, and then press ENTER.
2. In the console tree of the Group Policy Management console, open the domain that
contains DirectAccess client and server computer accounts.
3. In the console tree, right-click the Group Policy object that applies to all of your domain
accounts, and then click Edit.
4. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Windows Settings\Security Settings\Public Key Policies.
5. In the details pane, right-click Automatic Certificate Request Settings, point to New,
and then click Automatic Certificate Request.
6. In the Automatic Certificate Request Wizard, click Next.
7. On the Certificate Template page, click Computer, click Next, and then click Finish.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure Connection Security Rules for End-to-end Access
After you have used the DirectAccess Setup Wizard to create a base configuration for selected
server access, you must manually modify the connection security rules to require end-to-end
IPsec peer authentication and encryption between the DirectAccess client and intranet resources.
You can configure these rules for the following:
Encryption is required between DirectAccess clients and intranet resources only when the
DirectAccess client is on the Internet (no encryption when the DirectAccess client is on the
intranet).
To configure computer certificate auto-enrollment
109
Encryption is always required between DirectAccess clients and intranet resources
(encryption when the DirectAccess client is on the intranet or the Internet).
Because the default connection security rules contain settings that are not configurable with the
Windows Firewall with Advanced Security snap-in, you must modify the connection security rules
with commands in the netsh advfirewall consec context.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to change Group Policy settings. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
In this procedure, you configure end-to-end access connection security rules to require encryption
only when DirectAccess clients are on the Internet.
1. On a domain controller, start a command prompt as an administrator.
2. From the Command Prompt window, run the following commands:
netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-
4ed3-b176-a4420a810f12}”
netsh advfirewall consec set rule name=”DirectAccess Policy-clientToAppServer”
new qmsecmethods=”ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-
AES128+60min+100000kb” action=requireinrequireout
netsh advfirewall consec set rule name=”DirectAccess Policy-ClientToCorp” new
exemptipsecprotectedconnections=yes
netsh advfirewall consec set rule name=”DirectAccess Policy-ClientToDnsDc” new
exemptipsecprotectedconnections=yes
netsh advfirewall consec set rule name=”DirectAccess Policy-ClientToMgmt” new
exemptipsecprotectedconnections=yes
netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{ab991ef0-6fa9-
4bd9-bc42-3c397e8ad300}”
netsh advfirewall consec set rule name=”DirectAccess Policy-DaServerToMgmt”
new exemptipsecprotectedconnections=yes
netsh advfirewall consec set rule name=”DirectAccess Policy-DaServerToCorp”
new exemptipsecprotectedconnections=yes
netsh advfirewall consec set rule name=”DirectAccess Policy-DaServerToDnsDc”
new exemptipsecprotectedconnections=yes
netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{f7b77f47-7c33-
4d8c-bb9a-a913c5675d8d}”
netsh advfirewall consec set rule name=”DirectAccess Policy-
appServerToIpHttpsClientPolicy” new qmsecmethods=”ESP:SHA1-
AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb”
To configure end-to-end access connection security rules to require encryption only when DirectAccess clients are on the Internet
110
netsh advfirewall consec set rule name=”DirectAccess Policy-appServerToClient”
new qmsecmethods=”ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-
AES128+60min+100000kb”
In this procedure, you configure end-to-end access connection security rules to always require
encryption.
1. On a domain controller, start a command prompt as an administrator.
2. From the Command Prompt window, run the following commands:
netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-
4ed3-b176-a4420a810f12}”
netsh advfirewall consec set rule name=”DirectAccess Policy-clientToAppServer”
new endpoint2=any qmsecmethods=”ESP:SHA1-
AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb”
netsh advfirewall consec set rule name=”DirectAccess Policy-ClientToCorp” new
exemptipsecprotectedconnections=yes
netsh advfirewall consec set rule name=”DirectAccess Policy-ClientToDnsDc” new
exemptipsecprotectedconnections=yes
netsh advfirewall consec set rule name=”DirectAccess Policy-ClientToMgmt” new
exemptipsecprotectedconnections=yes
netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{ab991ef0-6fa9-
4bd9-bc42-3c397e8ad300}”
netsh advfirewall consec set rule name=”DirectAccess Policy-DaServerToMgmt”
new exemptipsecprotectedconnections=yes
netsh advfirewall consec set rule name=”DirectAccess Policy-DaServerToCorp”
new exemptipsecprotectedconnections=yes
netsh advfirewall consec set rule name=”DirectAccess Policy-DaServerToDnsDc”
new exemptipsecprotectedconnections=yes
netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{f7b77f47-7c33-
4d8c-bb9a-a913c5675d8d}”
netsh advfirewall consec set rule name=”DirectAccess Policy-
appServerToIpHttpsClientPolicy” new endpoint2=any qmsecmethods=”ESP:SHA1-
AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb”
netsh advfirewall consec set rule name=”DirectAccess Policy-appServerToClient”
new endpoint2=any qmsecmethods=”ESP:SHA1-
AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb”
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
To configure end-to-end access connection security rules to always require encryption
111
Configure Connection Security Rules for Traffic Between DirectAccess Clients
To protect the traffic sent between DirectAccess clients, you must configure additional connection
security rules.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to change Group Policy settings. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. On a domain controller, start a command prompt as an administrator.
2. In the Command Prompt window, type the netsh advfirewall set store
gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}”
command.
3. To exempt the traffic between DirectAccess clients and intranet resources when the
DirectAccess clients are connected to the intranet, type the netsh advfirewall consec
add rule name=RuleName endpoint1=IntranetIPv6Prefix endpoint2=IntranetIPv6Prefix
action=noauthentication profile=domain,public,private command.
4. To create an inbound firewall rule for an application that needs to accept unsolicited
inbound connection requests, type the netsh advfirewall firewall add rule
name=RuleName profile=public,private program=system action=allow
security=authenc protocol=Protocol localport=Port command.
For example, to create an inbound firewall rule for Remote Desktop traffic, use the netsh
advfirewall firewall add rule name=RemoteDesktop profile=public,private
program=system action=allow security=authenc protocol=tcp localport=3389
command.
5. To request protection of traffic between DirectAccess clients for all applications, at the
command prompt, type the netsh advfirewall consec add rule name=RuleName
endpoint1=any endpoint2=any action=requestinrequestout profile=public,private
auth1=computercert auth1ca=CANameString command.
6. To require protection of traffic between DirectAccess clients for all applications, at the
command prompt, type the netsh advfirewall consec add rule name=RuleName
endpoint1=any endpoint2=any action=requireinrequestout profile=public,private
auth1=computercert auth1ca=CANameString command.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
To configure connection security rules for traffic between DirectAccess clients
112
Configure Corporate Connectivity Detection Settings
You need to configure the Corporate Website Probe URL and Corporate Site Prefix List Group
Policy settings for the Group Policy object for DirectAccess clients so that they can correctly
determine corporate (intranet) network access.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to configure Group Policy settings. Review details about
using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. On a domain controller, click Start, click Run, type gpmc.msc, and then press ENTER.
2. In the console tree, open the domain.
3. In the console tree, right-click the DirectAccess Policy-{3491980e-ef3c-4ed3-b176-
a4420a810f12} Group Policy object, and then click Edit.
4. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Administrative Templates\Network\Network Connectivity
Status Indicator, and then double-click Corporate Website Probe URL in the details
pane.
5. Click Enabled.
6. In Corporate Website Probe URL, type the uniform resource locator (URL) of a highly
available intranet Web server that is available to any computer connected to the intranet,
either through a local area network (LAN) connection (such as wired or wireless) or
DirectAccess.
Note
This URL is different that the network location server URL, which is designed
to be accessible only from a computer connected to the intranet through a
LAN connection.
7. Click Apply, and then click OK.
8. Start a command prompt as an administrator.
9. From the Command Prompt window, run the netsh advfirewall set store
gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}”
command.
10. From the Command Prompt window, run the netsh advfirewall consec show rule
name=“DirectAccess Policy-ClientToDnsDc”command.
11. From the display of the netsh advfirewall consec show rule command, note the IPv6
address expressed as a range for Endpoint2.
12. In the details pane of the Group Policy Management Editor, double-click Corporate Site
To configure the NRPT with Group Policy
113
Prefix List in the details pane.
13. In Corporate Site Prefix List, type a comma, and then the IPv6 address for Endpoint2
with /128. For example, for the Endpoint2 IPv6 address 2002:836b:2::836b:2, type
2002:836b:2::836b:2/128.
14. Click Apply, and then click OK.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure DirectAccess Connection Security Rules for NAP
Configuring DirectAccess for Network Access Protection (NAP) consists of the following:
Configuring connection security rules for the infrastructure tunnel to include Health
Registration Authorities (HRAs) and remediation servers on your intranet.
If you are using NAP full enforcement, configuring connection security rules for the intranet
tunnel to require health certificates for authentication.
Before performing this procedure, you must determine the list of Internet Protocol version 6 (IPv6)
addresses for the HRAs and remediation servers on your intranet.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to change Group Policy settings. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
The following procedure modifies the connection security rules for the infrastructure tunnel to
allow DirectAccess clients access to the HRAs and remediation servers on the intranet.
1. On a domain controller, start a command prompt as an administrator.
2. From the Command Prompt window, run the following commands:
netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-
4ed3-b176-a4420a810f12}”
netsh advfirewall consec show rule name=“DirectAccess Policy-ClientToDnsDc”
3. From the display of the netsh advfirewall consec show rule command, note the IPv6
address for Endpoint2. This is the IPv6 address of the intranet Domain Name System
(DNS) server.
4. From the Command Prompt window, run the following commands:
netsh advfirewall consec set rule “DirectAccess Policy-ClientToDnsDc” new
endpoint2=IntranetDNSServerIPv6Address,ListOfHRAIPv6Addresses,ListOfRemediatio
nServerIPv6Addresses
To modify the connection security rules for the infrastructure tunnel
114
netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{ab991ef0-6fa9-
4bd9-bc42-3c397e8ad300}"
netsh advfirewall consec show rule name=“DirectAccess Policy-
DaServerToDnsDc”
5. From the display of the netsh advfirewall consec show rule command, note the IPv6
address for Endpoint1. This is the IPv6 address of the intranet DNS server.
6. From the Command Prompt window, run the netsh advfirewall consec set rule
“DirectAccess Policy-ClientToDnsDc” new
endpoint1=IntranetDNSServerIPv6Address,ListOfHRAIPv6Addresses,ListOfRemediatio
nServerIPv6Addresses command.
The following procedure modifies the connection security rules for the intranet tunnel to require
the use of health certificates by DirectAccess clients to access intranet resources. Perform this
procedure only when you are using NAP full enforcement for DirectAccess connections
1. On a domain controller, start a command prompt as an administrator.
2. From the Command Prompt window, run the following commands:
netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{ab991ef0-6fa9-
4bd9-bc42-3c397e8ad300}”
netsh advfirewall consec show rule name=“DirectAccess Policy-DaServerToCorp”
3. From the display of the netsh advfirewall consec show rule command, note the
certification authority (CA) name string for Auth1CAName.
4. From the Command Prompt window, run the following commands:
netsh advfirewall consec set rule “DirectAccess Policy-DaServerToDnsDC” new
auth1=computercert auth1ca=CANameString auth1healthcert=yes
netsh advfirewall consec set rule “DirectAccess Policy-DaServerToMgmt” new
auth1=computercert auth1ca=CANameString auth1healthcert=yes
netsh advfirewall consec set rule “DirectAccess Policy-DaServerToCorp” new
auth1=computercert auth1ca=CANameString auth1healthcert=yes applyauthz=yes
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure Force Tunneling
Before configuring force tunneling, you should have determined the Internet Protocol version 6
(IPv6) addresses of either your dual protocol (Internet Protocol version 4 [IPv4] and IPv6) proxy
servers or your IPv6/IPv4 translator and IPv6/IPv4 DNS gateway devices that are in front of your
IPv4-based proxy servers. For more information about these devices, see Choose Solutions for
IPv4-only Intranet Resources.
To modify the connection security rules for the intranet tunnel
115
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to change Group Policy settings. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. On a domain controller, click Start, type gpmc.msc, and then press ENTER.
2. In the console tree of the Group Policy Management snap-in, open the appropriate forest
and domain object, right-click the Group Policy object for DirectAccess clients, and then
click Edit.
3. In the console tree of the Group Policy Management Editor snap-in, open Computer
Configuration\Policies\Administrative Templates\Network\Network Connections.
4. In the details pane, double-click Route all traffic through the internal network.
5. In the Route all traffic through the internal network dialog box, click Enabled, and
then click OK.
6. In the console tree of the Group Policy Management Editor snap-in, open Computer
Configuration\Policies\Windows Settings\Name Resolution Policy.
7. In the details pane, in To which part of the namespace does this rule apply?, click
Any.
8. Click the DNS Settings for Direct Access tab, and then click Enable DNS settings for
Direct Access in this rule.
9. In DNS servers (optional), click Add. In DNS server, type the IPv6 address of your dual
protocol (IPv4 and IPv6) proxy server or your IPv6/IPv4 translator and IPv6/IPv4 DNS
gateway devices that are in front of your IPv4-based proxy server. Repeat this step if you
have multiple IPv6 addresses.
10. Click Create, and then click Apply.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure IIS for Network Location
If the Internet Information Services (IIS) server is being used for only Hypertext Transfer Protocol
(HTTP)-based connections, determine an alias name that will be used by DirectAccess clients
and create an address (A) record in your intranet Domain Name System (DNS) servers so that
the fully qualified domain name (FQDN) of the IIS server using the alias name can be resolved by
intranet-connected DirectAccess clients. If the IIS server is being used only for network location,
you do not need to use an alias name.
For example, the IIS server app1.corp.contoso.com is an intranet server providing only HTTP-
based connections for intranet clients. APP1 is also the network location server. The alias for
network location detection for the APP1 Web server is nls.corp.contoso.com. The network
To configure force tunneling
116
administrator creates an A record in the corp.contoso.com forward lookup zone that has the IPv4
address of app1.corp.contoso.com.
Once you have determined the FQDN of the network location server, construct the URL
https://FQDN (without the trailing “/”). This is the network location URL that you configure in Step
3 of the DirectAccess Setup Wizard.
If you are not using an alias name, you cannot connect to the IIS server that is acting as
a network location server from a DirectAccess client that is on the Internet.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to configure IIS global settings. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
The following procedure describes how to configure IIS to use the custom SSL certificate for
network location for the HTTPS security binding.
1. On the IIS server, click Start, type inetmgr.exe, and then press ENTER.
2. In the console tree of Internet Information Services (IIS) Manager, open the Sites
container for the IIS server, and then click Default Web site.
3. In the Actions pane, click Bindings.
4. In the Site Bindings dialog box, click Add.
5. In the Add Site Binding dialog box, in the Type list, click https. In SSL Certificate, click
the certificate with the FQDN of the network location server (example:
nls.corp.contoso.com).
6. Click OK, and then click Close.
If you are using an alias name, you cannot use an IIS server that is also being used for
Secure Hypertext Transfer Protocol (HTTPS)-based connections. The certificate
configured for HTTPS bindings is for the alias name and HTTPS connections using other
FQDNs will not validate.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure Packet Filters to Allow ICMP Traffic
To provide connectivity for Teredo-based DirectAccess clients, you need to configure Windows
Firewall with Advanced Security rules for all of your domain member computers to allow inbound
and outbound Internet Control Message Protocol for Internet Protocol version 4 (IPv4) (ICMPv4)
and Internet Control Message Protocol for Internet Protocol version 6 (IPv6) (ICMPv6) Echo
Request messages.
Note To configure the HTTPS security binding
Note
117
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to configure Group Policy settings. Review details about
using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. Click Start, click Run, type gpmc.msc, and then press ENTER.
2. In the console tree, open Forest/Domains/YourDomain, right-click the Group Policy
object (GPO) that applies to all of your intranet domain members, and then click Edit.
3. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security.
4. In the console tree, right-click Inbound Rules, and then click New Rule.
5. On the Rule Type page, click Custom, and then click Next. On the Program page, click
Next. On the Protocols and Ports page, for Protocol type, click ICMPv4, and then click
Customize. In the Customize ICMP Settings dialog box, click Specific ICMP types,
select Echo Request, and then click OK. Click Next. On the Scope page, click Next. On
the Action page, click Next. On the Profile page, click Next. On the Name page, for
Name, type Inbound ICMPv4 Echo Requests, and then click Finish.
6. In the console tree, right-click Inbound Rules, and then click New Rule.
7. On the Rule Type page, click Custom, and then click Next. On the Program page, click
Next. On the Protocols and Ports page, for Protocol type, click ICMPv6, and then click
Customize. In the Customize ICMP Settings dialog box, click Specific ICMP types,
select Echo Request, and then click OK. Click Next. On the Scope page, click Next. On
the Action page, click Next. On the Profile page, click Next. On the Name page, for
Name, type Inbound ICMPv6 Echo Requests, and then click Finish.
8. In the console tree, right-click Outbound Rules, and then click New Rule.
9. On the Rule Type page, click Custom, and then click Next. On the Program page, click
Next. On the Protocols and Ports page, for Protocol type, click ICMPv4, and then click
Customize. In the Customize ICMP Settings dialog box, click Specific ICMP types,
select Echo Request, and then click OK. Click Next. On the Scope page, click Next. On
the Action page, click Allow the connection, and then click Next. On the Profile page,
click Next. On the Name page, for Name, type Outbound ICMPv4 Echo Requests, and
then click Finish.
10. In the console tree, right-click Outbound Rules, and then click New Rule.
11. On the Rule Type page, click Custom, and then click Next. On the Program page, click
Next. On the Protocols and Ports page, for Protocol type, click ICMPv6, and then click
Customize. In the Customize ICMP Settings dialog box, click Specific ICMP types,
select Echo Request, and then click OK. Click Next. On the Scope page, click Next. On
the Action page, click Allow the connection, and then click Next. On the Profile page,
click Next. On the Name page, for Name, type Outbound ICMPv6 Echo Requests, and
then click Finish.
To create and enable firewall rules for ICMPv4 and ICMPv6 traffic
118
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure Packet Filters to Allow Management Traffic to DirectAccess Clients
To allow unsolicited incoming traffic from intranet computers to DirectAccess clients, the inbound
rules that allow management computers to initiate connections with intranet computers must have
edge traversal enabled for Teredo-based DirectAccess clients. See Packet Filters for
Management Computers for more information about whether to use your existing inbound rules or
to create new inbound rules just for DirectAccess clients.
For existing or duplicated inbound rules for management traffic to DirectAccess clients, you can
enable edge traversal in the following ways:
With the Windows Firewall with Advanced Security snap-in
With commands in the netsh advfirewall firewall set rule context
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to change Group Policy settings. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. Click Start, click Run, type gpmc.msc, and then press ENTER.
2. In the console tree, open Forest/Domains/YourDomain, right-click the appropriate Group
Policy object (GPO), and then click Edit.
For example, your inbound rules for management traffic that are specific to DirectAccess
clients would reside in the DirectAccess client GPO named DirectAccess Policy-
{3491980e-ef3c-4ed3-b176-a4420a810f12}.
3. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Inbound Rules.
4. In the contents pane, right-click a rule for management traffic, and then click Properties.
5. Click the Advanced tab, in Edge traversal, select Allow edge traversal, and then click
OK.
6. Repeat steps 4 and 5 for the additional rules for management traffic.
1. On a domain controller, start a command prompt as an administrator
2. From the Command Prompt window, type the netsh advfirewall set store
gpo=DomainName\GPOName command.
To enable edge traversal for an inbound rule with the Windows Firewall with Advanced Security snap-in
To enable edge traversal for an inbound rule with the Netsh.exe command-line tool
119
For example, the name of the DirectAccess client GPO for the corp.contoso.com domain
is DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}. Therefore, the
command is netsh advfirewall set store gpo=”corp.contoso.com\DirectAccess
Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}".
3. From the Command Prompt window, type the netsh advfirewall firewall show rule
name=all command.
4. From the display of this command, copy or write down the names of the inbound rules for
management traffic to DirectAccess clients.
5. From the Command Prompt window, run the netsh advfirewall firewall
name=RuleName edge=yes command for each rule noted in step 4.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure Packet Filters to Block Access to Domain Controllers
For the DirectAccess Setup Wizard to run, at least one physical interface of the DirectAccess
server computer must not be in the domain profile. Windows Firewall places an interface in the
domain profile if a domain controller for the domain for which the computer is a member is
reachable on that interface. The Internet interface of the DirectAccess server is attached to the
perimeter network. If your perimeter network contains a domain controller, such as a read-only
domain controller, Windows Firewall will place the Internet interface in the domain profile. To
prevent the Internet interface from reaching the domain controllers on the perimeter network, you
must configure outbound rules on the Internet interface to prevent connectivity to the IP
addresses of the perimeter network domain controllers.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to create Windows Firewall rules. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. On the DirectAccess server, click Start, click Run, type wf.msc, and then press ENTER.
2. In the console tree, right-click Outbound Rules, and then click New Rule.
3. On the Rule Type page, click Custom, and then click Next.
4. On the Program page, click Next.
5. On the Protocol and Ports page, click Next.
6. On the Scope page, in Which local IP addresses does this rule apply to?, click These
IP addresses, and then click Add. In IP Address, specify the Internet Protocol version 4
(IPv4) and Internet Protocol version 6 (IPv6) addresses of the Internet interface of the
To add packet filters to prevent access to domain controllers from the Internet interface
120
DirectAccess server, and then click OK.
7. In Which remote IP addresses does this rule apply to?, click These IP addresses,
and then click Add. In IP Address, specify the IPv4 or IPv6 addresses of the domain
controllers that are reachable from the Internet interface of the DirectAccess server, and
then click OK.
8. Click Next.
9. On the Action page, click Next.
10. On the Profile page, clear Domain, and then click Next.
11. On the Name page, specify a name for the rule, and then click Finish.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure Settings to Confine ICMPv6 Traffic to the Intranet
As described in Confining ICMPv6 Traffic to the Intranet, the default settings created by the
DirectAccess Setup Wizard 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) feature 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.
This procedure allows you to prevent these possible security issues.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to modify Group Policy settings. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. On a domain controller, start a command prompt as an administrator.
2. From the Command Prompt window, run the following commands:
netsh advfirewall set store gpo="DomainName\DirectAccess Policy-{3491980e-ef3c-
4ed3-b176-a4420a810f12}"
netsh advfirewall consec show rule name=”DirectAccess Policy-ClientToDnsDc”
netsh advfirewall consec show rule name=”DirectAccess Policy-ClientToCorp”
3. From the display of the last two commands, copy or write down the IPv6 addresses for
To confine ICMPv6 traffic to the intranet
121
the RemoteTunnelEndpoint.
4. From the Command Prompt window, run the following commands:
netsh advfirewall set global ipsec defaultexemptions neighbordiscovery,dhcp
netsh advfirewall consec add rule name=”Exempt ICMPv6 to Tunnel endpoint”
profile=private,public action=noauthentication mode=tunnel endpoint1=any
endpoint2=IPv6AddressesOfTheRemoteTunnelEndpoints protocol=icmpv6
netsh advfirewall set store gpo="DomainName\DirectAccess Policy-{ab991ef0-6fa9-
4bd9-bc42-3c397e8ad300}"
netsh advfirewall set global ipsec defaultexemptions neighbordiscovery,dhcp
netsh advfirewall consec add rule name=”Exempt ICMPv6 from Tunnel endpoint”
profile=private,public action=noauthentication mode=tunnel
endpoint1=IPv6AddressesOfTheRemoteTunnelEndpoints endpoint2=any
protocol=icmpv6
5. Click Start, type gpmc.msc, and then press ENTER.
6. In the console tree, open Forest/Domains/YourDomain, right-click the DirectAccess
Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} GPO, and then click Edit.
7. In the console tree of the Group Policy Management Editor, open Computer
Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with
Advanced Security.
8. Right-click Windows Firewall with Advanced Security, and then click Properties.
9. Click the IPsec Settings tab. In IPsec exemptions, in Exempt ICMP from IPsec, click
No, and then click OK.
10. Close the Group Policy Management Editor.
11. In the console tree of the Group Policy Management console, open
Forest/Domains/YourDomain, right-click the DirectAccess Policy-{ab991ef0-6fa9-
4bd9-bc42-3c397e8ad300} GPO, and then click Edit.
12. In the console tree of the Group Policy Management Editor, open Computer
Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with
Advanced Security.
13. Right-click Windows Firewall with Advanced Security, and then click Properties.
14. Click the IPsec Settings tab. In IPsec exemptions, in Exempt ICMP from IPsec, click
No, and then click OK.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
122
Configure Strong Certificate Revocation Checking for IPsec Authentication
By default, the DirectAccess server uses weak certificate revocation list (CRL) checking when
performing certificate-based Internet Protocol security (IPsec) peer authentication with
DirectAccess clients. For weak CRL checking, certificate revocation checking fails only if the
validating computer confirms that the certificate has been revoked in the CRL.
This procedure describes how to enable 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.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to change Group Policy settings. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. On a domain controller, start a command prompt as an administrator.
2. In the Command Prompt window, run the following commands:
netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{ab991ef0-6fa9-
4bd9-bc42-3c397e8ad300}”
netsh advfirewall set global ipsec strongcrlcheck 2
3. To update the DirectAccess server with this Group Policy change immediately, type the
gpupdate /target:computer command.
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.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure the DirectAccess Server as the Network Location Server
If your DirectAccess server is acting as the network location server, you must install the Web
Server (IIS) server role with the IP and Domain Restrictions role service.
To configure strong certificate revocation checking for IPsec authenticationNotes
123
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to install a server role. Review details about using the
appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
1. On the DirectAccess server, click Start, click Run, type servermanager.msc, and then
press ENTER.
2. In the console tree, click Roles. In the details pane, click Add Roles, and then click Next.
3. On the Select Server Roles page, click Web Server (IIS), and then click Next twice.
4. On the Select Role Services page, in Role services, under Security, click IP and
Domain Restrictions, and then click Next.
5. Click Install.
6. Verify that all installations were successful, and then click Close.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure the DirectAccess Setup Wizard for End-to-End Access
Unlike full intranet and selected server access, the DirectAccess Setup Wizard does not configure
the DirectAccess server for end-to-end access. However, you can use the DirectAccess Setup
Wizard to create a foundation configuration and then customize the connection security rules for
end-to-end connectivity. The four steps in the wizard configure DirectAccess clients, the
DirectAccess server, infrastructure servers, and application servers.
To complete this procedure, you must be a member of the local Administrators group, or
otherwise be delegated permissions to create and apply the configuration of the DirectAccess
Setup Wizard. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.
1. Click Start, click Run, type damgmt.msc, and then press ENTER.
2. In the console tree, click Setup.
3. In the details pane, click Configure for step 1.
4. On the DirectAccess Client Setup page, click Add.
5. In the Select Group dialog box, specify the names of your security groups that contain
DirectAccess client computers, click OK, and then click Finish.
6. Click Configure for step 2.
7. On the Connectivity page, for Interface connected to the Internet, select the network
connection that is attached to the Internet. For Interface connected to the internal
To install the IIS server role To run the DirectAccess Setup wizard for end-to-end access
124
network, select the network connection that is attached to your intranet. Click Next.
8. If you have an existing Internet Protocol version 6 (IPv6) infrastructure, a Prefix
Configuration page displays. In The IPv6 prefix that is used in your internal network,
type the 48-bit address prefix used by your organization. In The IPv6 prefix that is used
to assign IPv6 addresses to remote client computers, type the 64-bit address prefix
that you have designated for Internet Protocol over Secure Hypertext Transfer Protocol
(IP-HTTPS)-based IPv6 DirectAccess clients.
9. On the Certificate Components page, for Select the root certificate to which remote
client certificates must chain, click Browse. In the list of certificates, click the root
certificate for your public key infrastructure (PKI) that issues computer certificates to your
DirectAccess clients and servers, and then click OK.
10. For Select the certificate that will be used to secure remote client connectivity over
HTTPS, click Browse. In the list of certificates, click the certificate installed on the
DirectAccess server computer for IP-HTTPS connections, and then click OK. Click
Finish.
11. Click Configure for step 3.
12. On the Location page:
If you are using a separate network location server, click Network Location server
is run on a highly available server, type the Secure Hypertext Transfer Protocol
(HTTPS)-based uniform resource locator (URL) for network location without a trailing
/ (such as https://nls.corp.contoso.com), click Validate, and then click Next.
If you are using the DirectAccess server as the network location server, click
Network Location server is run on the DirectAccess server, click Browse, click
the certificate for network location, click OK, and then click Next.
13. On the DNS and Domain Controller page, add the appropriate rules for the Name
Resolution Policy Table (NRPT) as needed by your design. To add an NRPT rule, right-
click the empty row, and then click New. Select the appropriate local name resolution
option, and then click Next.
14. On the Management page, add the Internet Protocol (IP) addresses of computers that
will be initiating connections to DirectAccess clients as needed by your design. To add a
management computer, right-click the empty row, and then click New. Click Finish.
15. Click Configure for step 4.
16. On the DirectAccess Application Server Setup page:
a. Click Require end-to-end authentication and traffic protection for the specified
servers.
b. Click Add. In the Select Group dialog box, specify the Domain Computers group for
each of the domains of your organization.
c. Select Allow access to only those servers in the selected security groups.
17. Click Finish.
125
18. Click Save, and then click Finish.
19. In the DirectAccess Review dialog box, click Apply. In the DirectAccess Policy
Configuration message box, click OK.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure the DirectAccess Setup Wizard for Full Intranet Access
The DirectAccess Setup Wizard steps you through the configuration of a DirectAccess server for
full intranet access. The four steps in the wizard configure DirectAccess clients, the DirectAccess
server, infrastructure servers, and application servers.
To complete this procedure, you must be a member of the local Administrators group, or
otherwise be delegated permissions to create and apply the configuration of the DirectAccess
Setup Wizard. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.
1. Click Start, click Run, type damgmt.msc, and then press ENTER.
2. In the console tree, click Setup.
3. In the details pane, click Configure for step 1.
4. On the DirectAccess Client Setup page, click Add.
5. In the Select Group dialog box, specify the names of your security groups that contain
DirectAccess client computers, click OK, and then click Finish.
6. Click Configure for step 2.
7. On the Connectivity page, for Interface connected to the Internet, select the network
connection that is attached to the Internet. For Interface connected to the internal
network, select the network connection that is attached to your intranet. If you are using
smart card authorization, select Require smart card login for remote users, and
enforce this policy on the DirectAccess server. Click Next.
8. If you have an existing Internet Protocol version 6 (IPv6) infrastructure, a Prefix
Configuration page displays. In The IPv6 prefix that is used in your internal network,
type the 48-bit address prefix used by your organization. In The IPv6 prefix that is used
to assign IPv6 addresses to remote client computers, type the 64-bit address prefix
that you have designated for Internet Protocol over Secure Hypertext Transfer Protocol
(IP-HTTPS)-based IPv6 DirectAccess clients.
9. On the Certificate Components page, for Select the root certificate to which remote
client certificates must chain, click Browse. In the list of certificates, click the root
certificate for your public key infrastructure (PKI) that issues computer certificates to your
To run the DirectAccess Setup wizard for full intranet access
126
DirectAccess clients and servers, and then click OK.
10. For Select the certificate that will be used to secure remote client connectivity over
HTTPS, click Browse. In the list of certificates, click the certificate installed on the
DirectAccess server computer for IP-HTTPS connections, and then click OK. Click
Finish.
11. Click Configure for step 3.
12. On the Location page:
If you are using a separate network location server, click Network Location server
is run on a highly available server, type the Secure Hypertext Transfer Protocol
(HTTPS)-based uniform resource locator (URL) for network location without a trailing
/ (such as https://nls.corp.contoso.com), click Validate, and then click Next.
If you are using the DirectAccess server as the network location server, click
Network Location server is run on the DirectAccess server, click Browse, click
the certificate for network location, click OK, and then click Next.
13. On the DNS and Domain Controller page, add the appropriate rules for the Name
Resolution Policy Table (NRPT) as needed by your design. To add an NRPT rule, right-
click the empty row, and then click New. Select the appropriate local name resolution
option, and then click Next.
14. On the Management page, add the Internet Protocol (IP) addresses of computers that
will be initiating connections to DirectAccess clients as needed by your design. To add a
management computer, right-click the empty row, and then click New. Click Finish.
15. Click Configure for step 4.
16. On the DirectAccess Application Server Setup page, click Finish.
17. Click Save, and then click Finish.
18. In the DirectAccess Review dialog box, click Apply. In the DirectAccess Policy
Configuration message box, click OK.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure the DirectAccess Setup Wizard for Selected Server Access
The DirectAccess Setup Wizard steps you through the configuration of a DirectAccess server for
selected server access. The four steps in the wizard configure DirectAccess clients, the
DirectAccess server, infrastructure servers, and application servers.
To complete this procedure, you must be a member of the local Administrators group, or
otherwise be delegated permissions to create and apply the configuration of the DirectAccess
127
Setup Wizard. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.
1. Click Start, click Run, type damgmt.msc, and then press ENTER.
2. In the console tree, click Setup.
3. In the details pane, click Configure for step 1.
4. On the DirectAccess Client Setup page, click Add.
5. In the Select Group dialog box, specify the names of your security groups that contain
DirectAccess client computers, click OK, and then click Finish.
6. Click Configure for step 2.
7. On the Connectivity page, for Interface connected to the Internet, select the network
connection that is attached to the Internet. For Interface connected to the internal
network, select the network connection that is attached to your intranet. If you are using
smart card authorization, select Require smart card login for remote users, and
enforce this policy on the DirectAccess server. Click Next.
8. If you have an existing Internet Protocol version 6 (IPv6) infrastructure, a Prefix
Configuration page displays. In The IPv6 prefix that is used in your internal network,
type the 48-bit address prefix used by your organization. In The IPv6 prefix that is used
to assign IPv6 addresses to remote client computers, type the 64-bit address prefix
that you have designated for Internet Protocol over Secure Hypertext Transfer Protocol
(IP-HTTPS)-based IPv6 DirectAccess clients.
9. On the Certificate Components page, for Select the root certificate to which remote
client certificates must chain, click Browse. In the list of certificates, click the root
certificate for your public key infrastructure (PKI) that issues computer certificates to your
DirectAccess clients and servers, and then click OK.
10. For Select the certificate that will be used to secure remote client connectivity over
HTTPS, click Browse. In the list of certificates, click the certificate installed on the
DirectAccess server computer for IP-HTTPS connections, and then click OK. Click
Finish.
11. Click Configure for step 3.
12. On the Location page:
If you are using a separate network location server, click Network Location server
is run on a highly available server, type the Secure Hypertext Transfer Protocol
(HTTPS)-based uniform resource locator (URL) for network location without a trailing
/ (such as https://nls.corp.contoso.com), click Validate, and then click Next.
If you are using the DirectAccess server as the network location server, click
Network Location server is run on the DirectAccess server, click Browse, click
the certificate for network location, click OK, and then click Next.
13. On the DNS and Domain Controller page, add the appropriate rules for the Name
Resolution Policy Table (NRPT) as needed by your design. To add an NRPT rule, right-
To run the DirectAccess Setup wizard for selected server access
128
click the empty row, and then click New. Select the appropriate local name resolution
option, and then click Next.
14. On the Management page, add the Internet Protocol (IP) addresses of computers that
will be initiating connections to DirectAccess clients as needed by your design. To add a
management computer, right-click the empty row, and then click New. Click Finish.
15. Click Configure for step 4.
16. On the DirectAccess Application Server Setup page:
a. Click Require end-to-end authentication and traffic protection for the specified
servers.
b. Click Add. In the Select Group dialog box, specify the names of the security groups
that contain the selected servers.
c. If you want to confine the access of DirectAccess clients to only the selected servers,
select Allow access to only those servers in the selected security groups.
d. If you want to use authentication with null encapsulation, select Configure the IPsec
connection security rules on these servers to perform authentication without
traffic protection.
17. Click Finish.
18. Click Save, and then click Finish.
19. In the DirectAccess Review dialog box, click Apply. In the DirectAccess Policy
Configuration message box, click OK.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure the NRPT for an IPv6/IPv4 DNS Gateway
An IPv6/IPv4 DNS gateway translates between Internet Protocol version 6 (IPv6) and Internet
Protocol version 4 (IPv4) for DNS name queries. You need an IPv6/IPv4 DNS gateway and an
IPv6/IPv4 translator for DirectAccess clients to reach an IPv4-only resource on your intranet. For
more information about these devices, see Choose Solutions for IPv4-only Intranet Resources. If
you are using these devices 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
IPv6/IPv4 DNS gateways.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to change Group Policy settings. Review details about using
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
129
1. Identify the intranet namespaces that contain only IPv4-only resources.
2. Click Start, click Run, type gpmc.msc, and then press ENTER.
3. In the console tree, open the domain.
4. In the console tree, right-click the DirectAccess Policy-{3491980e-ef3c-4ed3-b176-
a4420a810f12} Group Policy object, and then click Edit.
5. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Windows Settings, and then click Name Resolution Policy.
6. In the details pane, click the DNS Settings for Direct Access tab, select Enable DNS
setting for DirectAccess in this rule, specify the intranet namespace as a suffix rule,
click Add, type the IPv6 address of your IPv6/IPv4 DNS gateway, and then click Create.
7. Repeat step 6 for additional namespaces as needed.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Configure the NRPT with Group Policy
You can configure the rules directly to the Name Resolution Policy Table (NRPT) with Group
Policy, rather than using the DirectAccess Setup Wizard.
To complete these procedures, you must be a member of the Administrators group, or otherwise
be delegated permissions to configure Group Policy settings. Review details about using the
appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
1. Click Start, click Run, type gpmc.msc, and then press ENTER.
2. In the console tree, open the domain.
3. In the console tree, right-click the DirectAccess Policy-{3491980e-ef3c-4ed3-b176-
a4420a810f12} Group Policy object, and then click Edit.
4. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Windows Settings, and then click Name Resolution Policy.
To create a new NRPT rule for DirectAccess, in the details pane, click DNS Settings
for Direct Access, select Enable DNS settings for DirectAccess in this rule.
Specify the namespace to which the rule applies, the certification authority and
Internet Protocol version 6 (IPv6) addresses of Domain Name System (DNS) servers
(if needed), and then click Create.
To modify an existing rule, click the rule in the NRPT, and then click Edit Rule. When
you are done making changes, click Update.
To delete an existing rule, click the rule in the NRPT, and then click Delete Rule.
To configure the NRPT for an IPv6/IPv4 DNS gateway To configure the NRPT with Group Policy
130
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Connect to the IPv6 Internet
To provide connectivity to the Internet Protocol version 6 (IPv6) Internet for DirectAccess clients,
you must configure the DirectAccess server with direct or tunneled connection to the IPv6
internet. For tunneled connections, you can use 6to4 or an IPv6-in-Internet Protocol version 4
(IPv4) tunnel to a service provider that is providing tunneled access to the IPv6 Internet.
Before performing this procedure:
If you have a direct connection to the IPv6 Internet, you must determine the interface name or
index of the DirectAccess server Internet interface and the next-hop IPv6 address for default
route traffic.
If you are using 6to4, you must determine the IPv4 address of your 6to4 relay. If your Internet
service provider (ISP) does not provide one, use 192.88.99.1.
If you are using an IPv6-in-IPv4 tunnel to a service provider, you must determine a name for
the tunnel interface on the DirectAccess server, a public IPv4 address on the DirectAccess
server to use as the local tunnel endpoint, the public IPv4 address of the service provider’s
tunnel server, and an IPv6 next-hop address.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to configure IPv6 settings. Review details about using the
appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
1. On the DirectAccess server, start a command prompt as an administrator.
2. From the Command Prompt window, type the netsh interface ipv6 add route ::/0
InterfaceNameOrIndex NextHopIPv6Address command.
1. On the DirectAccess server, start a command prompt as an administrator.
2. From the Command Prompt window, type the netsh interface ipv6 6to4 set relay
name=6to4RelayAddress state=enabled command.
1. On the DirectAccess server, start a command prompt as an administrator.
2. From the Command Prompt window, type the following commands:
netsh interface ipv6 add v6v4tunnel TunnelInterfaceName
localaddress=DirectAccessServerPublicIPv4Address
remoteaddress=ServiceProviderPublicIPv4Address
netsh interface ipv6 add route ::/0 TunnelInterfaceName NextHopIPv6Address
To configure a default IPv6 route for a direct connection to the IPv6 InternetTo configure a 6to4-tunneled connection to the IPv6 InternetTo configure an IPv6-in-IPv4-tunnel to the IPv6 Internet
131
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Create DirectAccess Groups in Active Directory
In the DirectAccess Setup Wizard, you must select one or more security groups that contain the
computer accounts for DirectAccess client and can optionally select or more security groups that
contain the computer accounts of selected servers for selected server access.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to create Active Directory Domain Services (AD DS) security
groups. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.
1. Click Start, type dsa.msc, and then press ENTER.
2. In the Active Directory Users and Computers console tree, right-click Users, point to
New, and then click Group.
3. In the New Object - Group dialog box, under Group name, type the group name
(example, DA_Clients).
4. Under Group scope, choose Global, under Group type, choose Security, and then
click OK.
1. Click Start, type dsa.msc, and then press ENTER.
2. In the Active Directory Users and Computers console tree, right-click Users, point to
New, and then click Group.
3. In the New Object - Group dialog box, under Group name, type the group name
(example, DA_SelServers).
4. Under Group scope, choose Global, under Group type, choose Security, and then
click OK.
5. In the contents pane, double-click the group that you just added, and then click the
Members tab.
6. Click Add and specify the computer account name of a selected server, and then click
OK. Repeat this step for the other selected server computer accounts.
7. Click OK.
You must add at least one member computer to the selected security group to specify it in
Step 4 of the DirectAccess Setup Wizard.
To create a security group for DirectAccess client computersTo create a security group for selected serversNote
132
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Install a Network Location Server Certificate on the DirectAccess Server
A DirectAccess server acting as a network location server must obtain an additional customized
Secure Sockets Layer (SSL) certificate.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to obtain a customized certificate. Review details about
using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. On the DirectAccess server, click Start, type mmc, and then press ENTER. Click Yes at
the User Account Control prompt.
2. Click File, and then click Add/Remove Snap-ins.
3. Click Certificates, click Add, click Computer account, click Next, select Local
computer, click Finish, and then click OK.
4. In the console tree of the Certificates snap-in, open Certificates (Local Computer)\
Personal\Certificates.
5. Right-click Certificates, point to All Tasks, and then click Request New Certificate.
6. Click Next twice.
7. On the Request Certificates page, click the name of your custom SSL certificate
template, and then click More information is required to enroll for this certificate.
8. On the Subject tab of the Certificate Properties dialog box, in Subject name, for Type,
select Common Name.
9. In Value, type the fully qualified domain name (FQDN) for the intranet name of the
DirectAccess server (for example, da1.corp.contoso.com), and then click Add.
10. In Alternative name, for Type, select DNS.
11. In Value, type the FQDN for the intranet name of the DirectAccess server, and then click
Add.
12. Click OK, click Enroll, and then click Finish.
13. In the details pane of the Certificates snap-in, verify that a new certificate with the FQDN
was enrolled with Intended Purposes of Server Authentication.
14. Right-click the certificate, and then click Properties.
15. In Friendly Name, type Network Location Certificate, and then click OK.
To install a certificate for network location
133
Steps 14 and 15 are optional, but make it easier for you to select the certificate for
network location in Step 3 of the DirectAccess Setup Wizard.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Install an IP-HTTPS Certificate
The DirectAccess server uses a customized Secure Sockets Layer (SSL) certificate to
authenticate Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS)-based
DirectAccess connections.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to request and customize an SSL certificate. Review details
about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. On the DirectAccess server, click Start, type mmc, and then press ENTER. Click Yes at
the User Account Control prompt.
2. Click File, and then click Add/Remove Snap-ins.
3. Click Certificates, click Add, click Computer account, click Next, select Local
computer, click Finish, and then click OK.
4. In the console tree of the Certificates snap-in, open Certificates (Local Computer)\
Personal\Certificates.
5. Right-click Certificates, point to All Tasks, and then click Request New Certificate.
6. Click Next twice.
7. On the Request Certificates page, click the name of your custom SSL certificate
template, and then click More information is required to enroll for this certificate.
8. On the Subject tab of the Certificate Properties dialog box, in Subject name, for Type,
select Common Name.
9. In Value, type the fully qualified domain name (FQDN) of the Internet name of the
DirectAccess server (for example, da1.contoso.com), and then click Add.
10. In Alternative name, for Type, select DNS.
11. In Value, type the FQDN of the Internet name of the DirectAccess server, and then click
Add.
12. Click OK, click Enroll, and then click Finish.
13. In the details pane of the Certificates snap-in, verify that a new certificate with the FQDN
was enrolled with Intended Purposes of Server Authentication.
14. Right-click the certificate, and then click Properties.
15. In Friendly Name, type IP-HTTPS Certificate, and then click OK.
Note To obtain an additional certificate for IP-HTTPS
134
Steps 14 and 15 are optional, but make it easier for you to select the certificate for
Secure Hypertext Transfer Protocol (HTTPS) connections in Step 2 of the DirectAccess
Setup Wizard.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Install and Configure IIS for a Network Location Server Certificate
The network location server uses a Secure Sockets Layer (SSL) certificate to authenticate
Secure Hypertext Transfer Protocol (HTTPS)-based requests from DirectAccess clients. The SSL
certificate has a customized subject and alternative name.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to request an SSL certificate and to configure certificate
settings for Internet Information Services (IIS). Review details about using the appropriate
accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
In this procedure, you request and customize an SSL certificate.
1. On the network location server, click Start, type mmc, and then press ENTER.
2. Click File, and then click Add/Remove Snap-in.
3. Click Certificates, click Add, select Computer account, click Next, select Local
computer, click Finish, and then click OK.
4. In the console tree of the Certificates snap-in, open Certificates (Local Computer)\
Personal\Certificates.
5. Right-click Certificates, point to All Tasks, and then click Request New Certificate.
6. Click Next twice.
7. On the Request Certificates page, click the name of your custom SSL certificate
template, and then click More information is required to enroll for this certificate.
8. On the Subject tab of the Certificate Properties dialog box, in Subject name, for Type,
select Common Name.
9. In Value, type the fully qualified domain name (FQDN) of the network location server (for
example, nls.corp.contoso.com), and then click Add.
10. In Alternative name, for Type, select DNS.
11. In Value, type the FQDN of the network location server (for example,
nls.corp.contoso.com), and then click Add.
12. Click OK, click Enroll, and then click Finish.
13. In the details pane of the Certificates snap-in, verify that a new certificate with the FQDN
was enrolled with Intended Purposes of Server Authentication.
Note To obtain an additional SSL certificate for network location
135
In this procedure, you configure the HTTPS security binding on the network location server to use
the new SSL certificate.
1. On the network location server, click Start, type inetmgr.exe, and then press ENTER.
2. In the console tree of Internet Information Services (IIS) Manager, open the site that
contains the network location Web page.
3. In the Actions pane, click Bindings.
4. In the Site Bindings dialog box, click Add.
5. In the Add Site Binding dialog box, in Type, click https. In SSL Certificate, click the
certificate with the FQDN.
6. Click OK, and then click Close.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Install the DirectAccess Feature
You configure DirectAccess client and server settings and monitor DirectAccess connectivity with
the DirectAccess management console, which you must install as a feature with Server Manager.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to install features from Server Manager. Review details
about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?
LinkId=83477.
1. On the DirectAccess server, click Start, click Run, type servermanager.msc, and then
press ENTER.
2. In the main window, under Features Summary, click Add features.
3. On the Select Features page, select DirectAccess Management Console.
4. In the Add Features Wizard window, click Add Required Features.
5. On the Select Features page, click Next.
6. On the Confirm Installation Selections page, click Install.
7. On the Installation Results page, click Close.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
To configure the HTTPS security binding To install the DirectAccess feature from Server Manager
136
Remove ISATAP from the DNS Global Query Block List
By default, DNS servers running Windows Server 2008 R2 or Windows Server 2008 use the
global query block list to block the resolution of the name ISATAP. To allow name resolution for
the ISATAP name, you must remove ISATAP from the global query block list of the DNS Server
service for each DNS server on your intranet running Windows Server 2008 R2 or Windows
Server 2008.
To complete these procedures, you must be a member of the local Administrators group on the
DNS server, or otherwise be delegated permissions to modify registry values on the DNS server.
Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.
1. Click Start, type regedit.exe, and then press ENTER.
2. In the console tree, open Computer\HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\DNS\Parameters.
3. In the contents pane, double-click the GlobalQueryBlockList value.
4. In the Edit Multi-String dialog box, remove the name ISATAP from the list, and then click
OK.
5. Start a command prompt as an administrator.
6. In the Command Prompt window, run the following commands:
net start dns
net stop dns
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Appendix A – Manual DirectAccess Server Configuration
You can also configure a DirectAccess server manually with a series of commands at a
Command Prompt window or within a script. The following sections describe the commands to
configure a DirectAccess server for the equivalent default configuration of the DirectAccess Setup
Wizard.
Configure Internet access components
To remove ISATAP from the DNS global query block list on a DNS server
137
Component Purpose Command
Teredo server Configure Teredo with
the name or IPv4
address of the Teredo
server.
netsh interface ipv6 set teredo server
FirstIPv4AddressOfDirectAccessServer
IPv6 interfaces Configure the IPv6
interfaces for the
correct forwarding
and advertising
behavior.
1. Run the following command for the 6to4
and Teredo interfaces:
netsh interface ipv6 set interface
InterfaceIndex forwarding=enabled
2. If a LAN interface is present with a native
IPv6 address, run the following command:
netsh interface ipv6 set interface
InterfaceIndex forwarding=enabled
3. For the IP-HTTPS interface, run the
following command:
netsh interface ipv6 set interface
IPHTTPSInterface forwarding=enabled
advertise=enabled
6to4 Enable 6to4. netsh interface 6to4 set state enabled
SSL certificates for IP-
HTTPS connections
Configure the
certificate binding.
1. Install the SSL certificate using manual
enrollment.
2. Use the netsh http add sslcert command
to configure the certificate binding.
IP-HTTPS Interface Configure the IP-
HTTPS interface.
netsh interface httpstunnel add interface
server
https://PublicIPv4AddressOrFQDN:443/iphttps
enabled certificates
IP-HTTPS Routing Configure IPv6
routing for the IP-
HTTPS interface.
netsh interface ipv6 add route IP-
HTTPSPrefix::/64 IPHTTPSInterface
publish=yes
IP-HTTPSPrefix is one of the following:
6to4-basedPrefix:2 if you are using a 6to4-
based prefix based on the first public IPv4
address assigned to Internet interface of
the DirectAccess server.
NativePrefix:5555 if you are using a 48-bit
native IPv6 prefix. 5555 is the Subnet ID
value chosen by the DirectAccess Setup
138
Component Purpose Command
Wizard.
Configure intranet access components
Component Purpose Command
ISATAP Enable ISATAP. netsh interface isatap set state enabled
ISATAP Configure the ISATAP
router address.
netsh interface isatap set router
DirectAccessServerIntranetIPv4Address
ISATAP Configure ISATAP
routing.
netsh interface ipv6 add
route IntranetPrefix:1::/64
ISATAPInterfaceIndex publish=yes
IntranetPrefix is one of the following:
The 48-bit 6to4-based prefix based on
the first public IPv4 address assigned
to Internet interface of the
DirectAccess server.
Your 48-bit native IPv6 prefix.
ISATAP Configure intranet
interface forwarding and
advertising on the
ISATAP interface.
netsh interface ipv6 set interface
ISATAPInterfaceIndex
forwarding=enabled advertise=enabled
Network Interface If you have native IPv6,
configure intranet
interface forwarding and
advertising on the LAN
interface.
netsh interface ipv6 set interface
LANInterfaceIndex forwarding=enabled
advertise=enabled
DNS Publish the ISATAP
name in DNS on the
DNS server.
dnscmd /recordadd DNSSuffix isatap A
DirectAccessServerIntranetIPv4Address
Configure IPsec DoSP
Purpose Command
Enable IPsec Denial of Service Protection netsh ipsecdosp add interface
139
Purpose Command
(DoSP) on the Internet interface. InternetInterfaceName public
Enable IPsec DoSP on the intranet interface. netsh ipsecdosp add interface
intranetInterfaceName internal
Configure connection security rulesThere are separate connection security rules for the full intranet access model for the
DirectAccess server and DirectAccess clients.
DirectAccess server configuration (full intranet access model)
Purpose Command
Connection
security rule for
traffic to the
intranet DNS
server and domain
controller (the
infrastructure
tunnel).
netsh advfirewall consec add rule name="DirectAccess Policy
ClientToDNSDC" mode=tunnel profile=public,private Endpoint1=DNS-
DCIPv6Address Endpoint2=Any
LocalTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface
RemoteTunnelEndpoint=Any Action=RequireInRequireOut
Auth1=ComputerCert Auth1CA=CANameString Auth2=UserNTLM
qmsecmethods=ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-
AES128+60min+100000kb
Connection
security rule for
traffic to
management
servers.
netsh advfirewall consec add rule name="DirectAccess Policy
ClientToMgMt" mode=tunnel profile=public,private
Endpoint1=ManagementServerIPv6 Addresses Endpoint2=Any
LocalTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface
RemoteTunnelEndpoint=Any Action=RequireInRequireOut
Auth1=ComputerCert Auth1CA=CANameString Auth2=UserNTLM
qmsecmethods=ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-
AES128+60min+100000kb
Connection
security rule for
traffic to the
intranet (the
intranet tunnel).
netsh advfirewall consec add rule name="DirectAccess Policy
ClientToCorp" mode=tunnel profile=public,private
Endpoint1=IntranetIPv6Prefix Endpoint2=Any
LocalTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface
RemoteTunnelEndpoint=Any Action=RequireInRequireOut
Auth1=ComputerCert Auth1CA=
Auth1CA=CANameString Auth2=UserKerb qmsecmethods=ESP:SHA1-
AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb
140
Connection security rules for client configuration (full intranet access model)
Purpose Command
Connection
security rule for
traffic to the
intranet DNS
server and
domain controller
(the
infrastructure
tunnel).
netsh advfirewall consec add rule name="DirectAccess Policy
ClientToDNSDC" mode=tunnel profile=public,private Endpoint1=Any
Endpoint2=DNS-DCIPv6Address LocalTunnelEndpoint=Any
RemoteTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface
Action=RequireInRequireOut Auth1=ComputerCert
Auth1CA=CANameString Auth2=UserNTLM qmsecmethods=ESP:SHA1-
AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb
Connection
security rule for
traffic to
management
servers.
netsh advfirewall consec add rule name="DirectAccess Policy
ClientToCorp" mode=tunnel profile=public,private Endpoint1=Any
Endpoint2=IntranetIPv6Prefix LocalTunnelEndpoint=Any
RemoteTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface
Action=RequireInRequireOut Auth1=ComputerCert Auth1CA=
Auth1CA=CANameString Auth2=UserKerb qmsecmethods=ESP:SHA1-
AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb
Connection
security rule for
traffic to the
intranet (the
intranet tunnel).
netsh advfirewall consec add rule name="DirectAccess Policy
ClientToMgmt" mode=tunnel profile=public,private Endpoint1=Any
Endpoint2=ManagementServerIPv6 Addresses LocalTunnelEndpoint=Any
RemoteTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface
Action=RequireInRequireOut Auth1=ComputerCert
Auth1CA=CANameString Auth2=UserNTLM qmsecmethods=ESP:SHA1-
AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb
Connection
security rule to
exempt IPsec
protection to the
network location
server.
netsh advfirewall consec add rule name=”DirectAccess Policy
clientToNlaExempt” mode=tunnel profile=public,private
endpoint1=IntranetIPv6Prefix
endpoint2=NetworkLocationServerIPv6Address action=noauthentication
protocol=tcp port2=443
141
Appendix B – Manual DirectAccess Client Configuration
Manual configuration of DirectAccess clients consist of IPv6 transition technology settings and the
Name Resolution Policy Table (NRPT).
IPv6 transition technology settings
Purpose Command Group Policy Setting
Configure
the Teredo
client as
an
enterprise
client and
configure
the
Internet
Protocol
version 4
(IPv4)
address of
the Teredo
server (the
DirectAcce
ss server).
netsh interface teredo set state
type=enterpriseclient servername=
FirstPublicIPv4AddressOfDirectAcces
sServer
Computer Configuration\Policies\
Administrative Templates\Network\TCPIP
Settings\IPv6 Transition Technologies\
Teredo State=Enterprise Client and
Computer Configuration\Policies\
Administrative Templates\Network\TCPIP
Settings\Ipv6 transition Technologies\Teredo
Server
Name=FirstPublicIPv4AddressOfDirectAcce
ssServer
Configure
the public
IPv4
address of
the 6to4
relay (the
DirectAcce
ss server).
netsh interface 6to4 set relay
name=
FirstPublicIPv4AddressOfDirectAcces
sServer
Computer Configuration\Policies\
Administrative Templates\Network\TCPIP
Settings\Ipv6 transition Technologies\6to4
Relay
Name=FirstPublicIPv4AddressOfDirectAcce
ssServer
Enable the
IP-HTTPS
client and
configure
the IP-
HTTPS
netsh interface httpstunnel add
interface client https://SubjectOfIP-
HPPTSCertificate/IPHTTPS
Computer Configuration\Policies\
Administrative Templates\Network\TCPIP
Settings\Ipv6 transition Technologies\IP-
HTTPS State set to Enabled and the IP-
HTTPS URL of https://SubjectOfIP-
142
Purpose Command Group Policy Setting
Uniform
Resource
Locator
(URL).
HPPTSCertificate:443/IPHTTPS
NRPTFor DirectAccess, the NRPT must be configured with the namespaces of your intranet with a
leading dot (for example, .internal.contoso.com or .corp.contoso.com). For a DirectAccess client,
any name request that matches one of these namespaces will be sent to the specified intranet
Domain Name System (DNS) servers. Include all intranet DNS namespaces that you want
DirectAccess client computers to access.
There are no command line methods for configuring NRPT rules. You must use Group Policy
settings. To configure the NRPT through Group Policy, use the Group Policy add-in at Computer
Configuration\Policies\Windows Settings\Name Resolution Policy in the Group Policy object
for DirectAccess clients. You can create a new NRPT rule and edit or delete existing rules. For
more information, see Configure the NRPT with Group Policy.
Appendix C - DirectAccess User Interface Scripting
DirectAccess user interface (UI) scripting allows you to use PowerShell scripts to run a
combination of Netsh.exe and PowerShell commands and configure a DirectAccess server.
The DirectAccess Setup Wizard generates an Extensible Markup Language (XML) data file that
can be passed as an input to the engine.ps1 PowerShell script. The location for the data file is
%WINDIR%\DirectAccess\DirectAccessConfig.xml. This XML data file is generated whenever you
save or apply settings with the DirectAccess Management Console. For more information and the
engine.ps1 script file, see Perform DirectAccess Scripting (http://go.microsoft.com/fwlink/?
LinkId=157388).
By accessing the tag names inside the XML file, you can configure the DirectAccess server and
all of the required Group Policies.
Here is an example of a data file:
<root>
<ServerData>
<CorpPrefix>2002:836b:1::/48</CorpPrefix>
.
143
.
</ServerData>
.
.
</root>
CorpPrefix can be accessed by a script using the format $xmldata.root.ServerData.CorpPrefix.
Three helper functions provide the ability to do the following:
Expand variables
Construct commands
Run commands and log output
These functions are extensible and more commands can be added as needed. The functions are:
Executing PowerShell commands
pscmdexec(string command, string description)
Executing Netsh.exe commands
netshcmdexec(string command, string description)
Executing Internet Protocol security (IPsec) or Windows Firewall-related Netsh.exe
commands
netshipseccmdexec(string setstorecommand, string ipseccommand, string description)
Script usageThe script takes in as arguments the data file path and the log file path along with the mandatory
mode parameter.
Engine.ps1 –mode <serveronly|gpsettingonly|all> [–data <dataFilePath>] [-log
<logFilePath>]
The first option <serveronly|gpsettingonly|all> is the following:
Serveronly Configures only the DirectAccess server. Required settings and policies are not
created for Group Policy.
GPSettingOnly Creates and configures Group Policy. It does not configure the DirectAccess
server.
All Configures both the DirectAccess server and the Group Policies. This mode is equivalent
to clicking Apply in the DirectAccess Management Console.
The data and log options are optional. If they are not present, the script uses %WINDIR%\
DirectAccess\DirectAccessConfig.xml and generates the log file in the current directory with the
name DirectAccessLog.txt.
144
Log fileThe script generates a log file named DirectAccessLog.txt when run, which contains the details
of what actions the script performed, with timestamps. The log file contents have the following
format:
Time Stamp Step: description
Executing: the command being run
Output: output of the command
Limitation of the scriptThe script relies on the Dnscmd.exe tool to perform registration of the Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP) name on the Domain Name System (DNS) server. Either install
Dnscmd.exe on the computer on which the script is being run with the Remote Server and Tools
feature or add a new Address (A) record in DNS server for the name ISATAP with the intranet
Internet Protocol version 4 (IPv4) address of the DirectAccess server. You can get this address
from the XML file at <root>-<ServerData>-<TransitionTechnologies>-<ISATAP>-
<CorpV4Address>.
Appendix D - DirectAccessConfig.xsd
The DirectAccessConfig.xml file contains DirectAccess configuration data of the DirectAccess
Setup Wizard. The following is the Extended Markup Language (XML) schema definition (XSD)
file for DirectAccessConfig.xml. To create a DirectAccessConfig.xsd file, copy the contents to
Notepad, and then save the file as DirectAccessConfig.xsd.
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns="http://www.microsoft.com/networking/DirectAccess/v1"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.microsoft.com/networking/DirectAccess/v1"
attributeFormDefault="unqualified" elementFormDefault="qualified">
<xs:element name="root">
<xs:complexType>
<xs:all>
<xs:element name="ServerData">
<xs:complexType>
<xs:all>
<xs:element name="CorpPrefix" type="ipv6Prefix" />
<xs:element name="InternetInterface" type="interface" />
145
<xs:element name="InternalNetworkInterface" type="interface" />
<xs:element name="TransitionTechnologies">
<xs:complexType>
<xs:all>
<xs:element name="ISATAP" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
This MUST be specified if there is no pre-existing IPv6 or
ISATAP
deployment on the internal network.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:all>
<xs:element name="IsatapRouterName" type="domainName" />
<xs:element name="IsatapInterfaceName" type="domainName" />
<xs:element name="CorpV4Address" type="ipv4Address" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="Teredo">
<xs:complexType>
<xs:all>
<xs:element name="FirstInternetGlobalAddress" type="ipv4Address"
/>
</xs:all>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="IPHttps">
<xs:complexType>
<xs:all>
146
<xs:element name="IpHttpsPrefix" type="ipv6Prefix" />
<xs:element name="IpHttpsCertHash" type="xs:hexBinary" />
<xs:element name="IpHttpsServerURL" type="xs:anyURI" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="DOSPConfig">
<xs:complexType>
<xs:all>
<xs:element name="IPsecUnauthenticatedPerIPRate" default="10240"
type="xs:unsignedInt" />
<xs:element name="IPsecAuthenticatedRate" default="0"
type="xs:unsignedInt" />
<xs:element name="ICMPv6Rate" default="10240" type="xs:unsignedInt" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="IsV6Deployed" type="xs:boolean" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="IIS" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
This MUST be specified in case network location server is run on the
DirectAccess
server and certificate used for securing location identification is same as
that used by remote client to secure connectivity over IPHTTPS.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:all>
<xs:element name="IpHttpsAddresses">
<xs:complexType>
147
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Address" type="ipAddress" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="InOutAddresses">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Address" type="ipAddress" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="GPO">
<xs:complexType>
<xs:all>
<xs:element name="Common">
<xs:complexType>
<xs:all>
<xs:element name="AppServers" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
List of application server addresses that will enforce
authorization.
This must be specified in case the authorization option is other
than NoAuthorization.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Address"
type="ipv6Address" />
148
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="DnsServers">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Address"
type="ipv6Address" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="MgmtServers" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Address"
type="ipv6PrefixOrAddress" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CorpV6" type="ipv6Prefix" />
<xs:element name="NonCorpV6" type="xs:string" />
<xs:element name="TunnelEndpointDnsDcMgmt" type="ipv6Address" />
<xs:element name="TunnelEndpointCorp" type="ipv6Address" />
<xs:element name="RootCert" type="xs:string" />
<xs:element name="RootCertNetshFormatted" type="xs:string" />
<xs:element name="CertType">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Root"/>
<xs:enumeration value="Intermediate"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="SmartCard">
149
<xs:complexType>
<xs:all>
<xs:element name="Option">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="NoSmartCard"/>
<xs:enumeration value="RemoteSmartCard"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="SDDLString" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
This MUST be specified in case SmartCard option selected
is RequireSmartCard.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="DistinguishedDomainName"
type="distinguishedDomainName" />
<xs:element name="DomainName" type="domainName" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="ClientPolicies">
<xs:complexType>
<xs:all>
<xs:element name="SecurityGroups">
<xs:complexType>
<xs:sequence>
150
<xs:element name="SecurityGroup" type="sg" maxOccurs="unbounded"
/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="NRPT">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="entry">
<xs:complexType>
<xs:all>
<xs:element name="Name" type="xs:string" />
<xs:element name="DirectAccessDNSServers"
type="xs:string">
<xs:annotation>
<xs:documentation>
List of DNS server IPv6 addresses (, delimited) for
the DNS suffix
specified in Name element above. Can be empty if
specifying NRPT exepmption.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:all>
<xs:attribute name="PolicyName" type="xs:string"
use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:unique name="NRPTRuleName">
<xs:selector xpath="*" />
<xs:field xpath="@PolicyName" />
</xs:unique>
</xs:element>
151
<xs:element name="DnsFallBackOptions">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="DnsFallbackNameDoesNotExist"/>
<xs:enumeration value="DnsAlwaysFallbackForAnyError"/>
<xs:enumeration value="DnsAlwaysFallbackPrivateOnly"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="NCSI">
<xs:complexType>
<xs:all>
<xs:element name="NcsiUrl" type="xs:anyURI" />
<xs:element name="NcsiRrName" type="domainName" />
<xs:element name="NcsiRrIp" type="ipv6Address"
fixed="0:0:0:0:0:0:0:1" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="NID">
<xs:complexType>
<xs:all>
<xs:element name="NidCertHash" type="xs:hexBinary"
minOccurs="0"/>
<xs:element name="NidUrl" type="xs:anyURI" />
<xs:element name="NidAddress" type="ipv6Address" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="ClientToDnsPolicy" type="xs:string"
default="DirectAccess Policy-ClientToDnsDc" />
<xs:element name="ClientToCorpPolicy" type="xs:string"
default="DirectAccess Policy-ClientToCorp" />
<xs:element name="ClientToMgmtPolicy" type="xs:string"
default="DirectAccess Policy-ClientToMgmt" minOccurs="0" />
152
<xs:element name="ClientToApplicationServerPolicy" type="xs:string"
default="DirectAccess Policy-clientToAppServer" minOccurs="0" />
<xs:element name="ClientToApplicationServerExemptPolicy"
type="xs:string" default="DirectAccess Policy-clientToAppServerExempt" minOccurs="0" />
<xs:element name="ClientToNlaExemptPolicy" type="xs:string"
default="DirectAccess Policy-clientToNlaExempt" />
<xs:element name="IpHttpsOutRuleName" type="xs:string" default="Core
Networking - IPHTTPS (TCP-Out)" />
</xs:all>
<xs:attribute name="GPOName" type="xs:string" default="DirectAccess
Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}" />
</xs:complexType>
</xs:element>
<xs:element name="ServerPolicies">
<xs:complexType>
<xs:all>
<xs:element name="SecurityGroups">
<xs:complexType>
<xs:sequence>
<xs:element name="SecurityGroup" type="sg" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ServerToDnsPolicy" type="xs:string"
default="DirectAccess Policy-DaServerToDnsDc" />
<xs:element name="ServerToCorpPolicy" type="xs:string"
default="DirectAccess Policy-DaServerToCorp" />
<xs:element name="ServerToMgmtPolicy" type="xs:string"
default="DirectAccess Policy-DaServerToMgmt" minOccurs="0" />
<xs:element name="IpHttpsInRuleName" type="xs:string" default="Core
Networking - IPHTTPS (TCP-In)" />
</xs:all>
<xs:attribute name="GPOName" type="xs:string" default="DirectAccess
Policy-{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300}" />
</xs:complexType>
153
</xs:element>
<xs:element name="AppServerPolicies">
<xs:complexType>
<xs:all>
<xs:element name="SecurityGroups" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
List of security groups containing servers that will enforce
authorization.
MUST be specified in case AuthorizationOption is other than
NoAuthorization.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="SecurityGroup" type="sg" maxOccurs="unbounded"
/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="AuthenticationOption">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="NoAuthentication"/>
<xs:enumeration value="SelectedServerEndToEnd"/>
<xs:enumeration value="EndToEndAuthentication"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="EndToEndIPsecCompatibilityMode" type="xs:boolean"
minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
Whether IPsec connection security rules on application servers
should allow null encryption.
154
MUST be specified in case AuthorizationOption is other than
NoAuthorization.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ApplicationServerToClientPolicy" type="xs:string"
default="DirectAccess Policy-appServerToClient" minOccurs="0" />
<xs:element name="ApplicationServerToIpHttpsClientPolicy"
type="xs:string" default="DirectAccess Policy-appServerToIpHttpsClientPolicy"
minOccurs="0" />
</xs:all>
<xs:attribute name="GPOName" type="xs:string" default="DirectAccess
Policy-{f7b77f47-7c33-4d8c-bb9a-a913c5675d8d}" />
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
<xs:unique name="GPONames">
<xs:selector xpath="*" />
<xs:field xpath="@GPOName" />
</xs:unique>
</xs:element>
</xs:all>
<xs:attribute name="State" type="xs:string" fixed="Complete" use="required" />
<xs:attribute name="Version" type="xs:decimal" default="1.0" />
</xs:complexType>
</xs:element>
<xs:complexType name="sg">
<xs:annotation>
<xs:documentation xml:lang="en">
Type representing a security group.
</xs:documentation>
</xs:annotation>
155
<xs:all>
<xs:element name="Name" type="xs:string" />
<xs:element name="Type">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="computer"/>
<xs:enumeration value="group"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:all>
</xs:complexType>
<xs:complexType name="interface">
<xs:annotation>
<xs:documentation xml:lang="en">
Type representing an network interface. Holds interface properties.
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="Name" type ="xs:string" />
<xs:element name="Id" type="guid" />
</xs:all>
</xs:complexType>
<xs:simpleType name="ipv4Address">
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of an IPv4 address
</xs:documentation>
</xs:annotation>
156
<xs:restriction base="xs:string">
<xs:pattern value="((0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-
9]?))\.){3}(0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ipv6Address">
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of an IPv6 address
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4}))|((([0-9a-fA-F]
{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})))|((([0-9a-fA-F]{1,4}:)*([0-
9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*)|((([0-9a-fA-F]{1,4}:)*([0-
9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0-9]{1,3}\.[0-9]{1,3}\.[0-
9]{1,3}\.[0-9]{1,3})))" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ipv6Prefix">
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of an IPv6 prefix
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})/\d+)|((([0-9a-fA-F]
{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\d+)|((([0-9a-fA-F]
{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*/\d+)|((([0-9a-
fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0-9]
{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\d+)" />
157
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ipv6PrefixOrAddress">
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of an IPv6 prefix or address
</xs:documentation>
</xs:annotation>
<xs:union memberTypes="ipv6Prefix ipv6Address" />
</xs:simpleType>
<xs:simpleType name="ipAddress" >
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of an IP address. This can be IPv4 or IPv6.
</xs:documentation>
</xs:annotation>
<xs:union memberTypes="ipv4Address ipv6Address" />
</xs:simpleType>
<xs:simpleType name="guid">
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of a GUID, generally the id of an element.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="\{[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-
fA-F0-9]{12}\}"/>
</xs:restriction>
158
</xs:simpleType>
<xs:simpleType name="domainName">
<xs:annotation>
<xs:documentation>
The domainName type represents a DNS domain name.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="([a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*[a-zA-Z][a-zA-Z0-9\-]*[a-
zA-Z0-9]" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="distinguishedDomainName">
<xs:annotation>
<xs:documentation>
This type represents a domain name in distinguished name format.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="(DC=[a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9],)*DC=[a-zA-Z][a-zA-Z0-
9\-]*[a-zA-Z0-9]" />
</xs:restriction>
</xs:simpleType>
</xs:schema>
159
DirectAccess Troubleshooting Guide
This guide provides troubleshooting information for DirectAccess in the Windows 7 and Windows
Server 2008 R2 operating systems. It is designed to help you identify and resolve problems that
might be related to DirectAccess.
In this guideThis guide is intended for use by a network or system administrator. This guide provides
information to help you identify and resolve problems quickly. Use this guide to assist you while
performing root-cause analysis of incidents and problems with components of a DirectAccess
infrastructure. Before you read this guide, you should have a good understanding of the way
DirectAccess works and how it is deployed in your organization. The following topics are included
in this guide:
Introduction to Troubleshooting DirectAccess
A-Z List of Problem Topics for DirectAccess
Tools for Troubleshooting DirectAccess
General Methodology for Troubleshooting DirectAccess Connections
Troubleshooting DirectAccess Problems
Introduction to Troubleshooting DirectAccess
This guide explains how to troubleshoot DirectAccess. If you are not familiar with this guide,
review the following sections of this introduction.
When to use this guideUse this guide when:
You have problems updating or operating DirectAccess infrastructure components.
You have problems with a new DirectAccess deployment.
You want to learn about troubleshooting techniques to use with DirectAccess.
How to use this guideThis guide contains the following topics:
A-Z List of Problem Topics for DirectAccess
This topic lists problem topics alphabetically. You can use it to find a problem topic quickly.
Tools for Troubleshooting DirectAccess
160
This topic describes how to use command line tools, services, and logs on your computer to
gather information for troubleshooting DirectAccess.
General Methodology for Troubleshooting DirectAccess Connections
This topic provides a step-by-step process for troubleshooting DirectAccess connections.
Troubleshooting DirectAccess Problems
This topic links to step-by-step procedures that help you identify and fix specific DirectAccess
problems. You can use this topic to find a solution for a problem.
A-Z List of Problem Topics for DirectAccess
The following is a list of topics you can use to troubleshoot DirectAccess problems. This list will
be updated as new problems and solutions are found. For an overview of DirectAccess
troubleshooting techniques and to view categories used to classify these topics, see
Troubleshooting DirectAccess Problems.
Cannot Reach the DirectAccess Server from the IPv6 Internet
Cannot Reach the DirectAccess Server with 6to4
Cannot Reach the DirectAccess Server with IP-HTTPS
Cannot Reach the DirectAccess Server with Teredo
DirectAccess Client Cannot Access Intranet Resources
DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server
DirectAccess Client Cannot Resolve Names with Intranet DNS Servers
DirectAccess Client Determines that it is on the Internet When on the Intranet
DirectAccess Client Determines that it is on the Intranet When on the Internet
DirectAccess Client Connection is Slow
Fixing Problems Encountered during the Steps of the DirectAccess Setup Wizard
Fixing Problems Encountered when Applying the Settings of the DirectAccess Setup Wizard
Fixing problems that Prevent You from Running the DirectAccess Setup Wizard
Fixing Problems with Creating Protected Connections to an Intranet Resource
Intranet Management Server Cannot Connect to a DirectAccess Client
Tools for Troubleshooting DirectAccess
Windows 7 and Windows Server 2008 R2 provide many tools for gathering information for
DirectAccess problem determination and resolution.
The topics in this section describe the following tool sets:
Network Diagnostics and Tracing
161
Command Line Tools
Snap-in Tools
Network Diagnostics and Tracing
Windows 7 and Windows Server 2008 R2 include extensive network diagnostics and tracing
facilities that are designed for gathering troubleshooting information on the DirectAccess client
when attempting to connect to the DirectAccess server.
This topic describes the following:
Windows Network Diagnostics
Troubleshooting item in Control Panel
Network tracing for DirectAccess
Windows Firewall tracing
Windows Network DiagnosticsTo access Windows Network Diagnostics, right-click the network connection icon in the
notification area, and then click Troubleshoot problems. Windows Network Diagnostics has
extensive support for DirectAccess connections and in many cases provides the user with
information about the root cause of the problem.
Use Windows Network Diagnostics as your first troubleshooting tool on the DirectAccess client.
Troubleshooting item in Control PanelTo focus troubleshooting on DirectAccess and collect additional information, you can use the
Connection to a Workplace Using DirectAccess troubleshooter in the Troubleshooting item of
Control Panel.
1. Click Start, and then click Control Panel.
2. In System and Security, click Find and fix problems.
3. Click Network and Internet, and then click Connection to a Workplace Using
DirectAccess.
For this troubleshooting tool to work correctly, you must configure 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. For more information, see Design Your Intranet for
Corporate Connectivity Detection.
To start the DirectAccess troubleshooterNote
162
Network tracing for DirectAccessWindows 7 and Windows Server 2008 R2 includes a new Netsh.exe context for network tracing;
netsh trace. Commands in the netsh trace context allow you to selectively enable tracing for
providers and scenarios. A provider represents an individual component in the network protocol
stack, such as Windows Sockets (WinSock), Transmission Control Protocol/Internet Protocol
(TCP/IP), Wireless Local Area Network (LAN) Services, or Network Device Interface Specification
(NDIS). A tracing scenario is a collection of providers for a specific function, such as file sharing
or wireless LAN access. You can also apply filters to exclude irrelevant details and reduce the
size of the resulting Event Tracing Log (ETL) file.
To perform detailed troubleshooting for networking issues, a helpdesk staff person or Microsoft’s
Customer Service and Support organization typically needs both internal component tracing
information and a capture of the network traffic that occurred when duplicating the problem. Prior
to Windows 7, this information had to be obtained two different ways; use Netsh.exe commands
to enable and disable tracing and a packet sniffer program such as Network Monitor to capture
the network traffic. Even with this information, it was difficult to tie these two sources of
information together to determine when network traffic was sent relative to the events in the
tracing logs.
When you perform network tracing in Windows 7 with commands in the netsh trace context, ETL
files can contain both network traffic and component tracing information in sequence. The ETL
files can be displayed with Microsoft Network Monitor 3.3 (http://go.microsoft.com/fwlink/?
LinkId=157376), which provides much more efficient way to analyze and troubleshoot network
problems.
1. Open an administrator-level command prompt.
2. In the command prompt window, type the netsh trace start scenario=directaccess
capture=yes report=yes command.
3. Reproduce the problem that you are having with DirectAccess.
4. In the command prompt window, type the netsh trace stop command.
Netsh.exe writes tracing information to the NetTrace.etl file in the %TEMP%\NetTraces folder. To
see the contents of this file, open it with Network Monitor 3.3.
Netsh.exe also writes additional environment and troubleshooting information to the NetTrace.cab
file in the %TEMP%\NetTraces folder.
Windows Firewall tracingWindows Firewall tracing provides detailed component interaction information for the Windows
Filtering Platform (WFP). WFP is a set of application programming interface (API) and system
services that provide a platform for creating network filtering applications. The WFP API allows
developers to write code that interacts with the packet processing that takes place at several
layers in the networking stack of the operating system. Network data can be filtered and also
To capture a network trace for a DirectAccess client
163
modified before it reaches its destination. Windows Firewall with Advanced Security uses WFP for
firewall filtering and connection security. You can use Windows Firewall tracing to capture and
analyze Internet Protocol security (IPsec) security negotiation.
1. Open an administrator-level command prompt.
2. In the command prompt window, type the netsh wfp capture start cab=off command.
3. Reproduce the problem that you are having with DirectAccess.
4. In the command prompt window, type the netsh wfp capture end command.
Netsh.exe writes tracing information to the Wfpdiag.xml file, which you can review for information
about connection security issues.
Command Line Tools
Windows 7 and Windows Server 2008 R2 provide a variety of command line tools to obtain
troubleshooting information. This topic describes the following tools:
The Netsh.exe Command Line Tool
The Ping.exe Command Line Tool
The Nslookup.exe Command Line Tool
The Ipconfig.exe Command Line Tool
The Certutil.exe Command Line Tool
The Nltest.exe Command Line Tool
The Netsh.exe Command Line Tool
The following Network Shell (Netsh) commands can be used to gather information when
troubleshooting DirectAccess:
netsh namespace show effectivepolicy and netsh namespace show policy
netsh interface 6to4 show relay
netsh interface teredo show state
netsh interface httpstunnel show interfaces
netsh interface istatap show state and netsh interface istatap show router
netsh interface httpstunnel show interfaces
netsh advfirewall monitor show mmsa
netsh advfirewall monitor show qmsa
netsh advfirewall monitor show consec rule name=all
netsh advfirewall monitor show currentprofile
To capture a network trace for WFP
164
netsh interface ipv6 show interfaces
netsh interface ipv6 show interfaces level=verbose
netsh interface ipv6 show route
netsh namespace show effectivepolicy and netsh namespace show policyThis command shows the rules in the Name Resolution Policy Table (NRPT) on a DirectAccess
client. The netsh namespace show policy shows the NRPT rules as configured with Group
Policy and the netsh namespace show effectivepolicy command shows the active rules.
The following is an example of output from the netsh namespace show effectivepolicy
command.
DNS Effective Name Resolution Policy Table Settings
Settings for nls.corp.contoso.com
----------------------------------------------------------------------
Certification authority : DC=com, DC=contoso, DC=corp, CN=corp-D
C1-CA
DNSSEC (Validation) : disabled
IPsec settings : disabled
DirectAccess (DNS Servers) :
DirectAccess (Proxy Settings) : Bypass proxy
Settings for .corp.contoso.com
----------------------------------------------------------------------
Certification authority : DC=com, DC=contoso, DC=corp, CN=corp-D
C1-CA
DNSSEC (Validation) : disabled
IPsec settings : disabled
DirectAccess (DNS Servers) : 2002:836b:2:1:0:5efe:10.0.0.1
DirectAccess (Proxy Settings) : Bypass proxy
165
In this example, the DirectAccess client is located on the Internet and has a namespace entry for
its intranet namespace (the rule for .corp.contoso.com) and an exemption rule for the FQDN of its
network location server (the rule for .nls.corp.contoso.com).
You use the netsh namespace show effectivepolicy command to determine the results of
network location detection and the Internet Protocol version 6 (IPv6) addresses of intranet
Domain Name System (DNS) servers for additional troubleshooting.
If there are active rules in the NRPT, the DirectAccess client has determined that it is not on the
intranet. If there are no active rules in the NRPT, the DirectAccess client has determined that
it is on the intranet or it has not been correctly configured with NRPT rules.
If there are no rules in the NRPT as configured through Group Policy (from the display of the
netsh namespace show policy command), the DirectAccess client has not been properly
configured. Verify that the computer account of the DirectAccess client is a member of the
appropriate security group.
The DirectAccess server is not a DirectAccess client and is not configured with NRPT
rules. The netsh namespace show effectivepolicy command on a DirectAccess server
should always display no rules.
netsh interface 6to4 show relayThis command shows the Internet Protocol version 4 (IPv4) address or fully qualified domain
name (FQDN) of the 6to4 relay on a DirectAccess client. On a DirectAccess client, this is set by
default through Group Policy to the first consecutive IPv4 address that is assigned to the Internet
interface of the DirectAccess server. The following is an example of output from the netsh
interface 6to4 show relay command.
Relay Name : 131.107.0.2 (Group Policy)
Use Relay : default
Resolution Interval : default
In this example, the DirectAccess client has been configured with the 6to4 relay IPv4 address of
131.107.0.2 through Group Policy.
You use the netsh interface 6to4 show relay command to determine where the DirectAccess
client is sending its default route IPv6 traffic when it has been configured with a public IPv4
address and using 6to4 to tunnel IPv6 traffic across the Internet.
netsh interface teredo show stateThis command shows the state and configuration of the Teredo component on a DirectAccess
server or client. On a DirectAccess client, the Teredo client configuration is set by default through
Group Policy and the Server Name is set to the first consecutive IPv4 address assigned to the
Internet interface of the DirectAccess server.
The following is an example of output from the netsh interface teredo show state command on
a DirectAccess client.
Note
166
Teredo Parameters
---------------------------------------------
Type : client
Server Name : 131.107.0.2 (Group Policy)
Client Refresh Interval : 30 seconds
Client Port : unspecified
State : offline
Error : client is in a managed network
In this example, the DirectAccess client has been configured with the Teredo server IPv4 address
of 131.107.0.2 through Group Policy and is in an offline state.
The following is an example of output from the netsh interface teredo show state command on
a DirectAccess server.
Teredo Parameters
---------------------------------------------
Type : server
Virtual Server Ip : 0.0.0.0
Client Refresh Interval : 30 seconds
State : online
Server Packets Received : 0
Success : 0 (Bubble 0, Echo 0, RS1 0 RS2 0)
Failure : 0 (Hdr 0, Src 0, Dest 0, Auth 0)
Relay Packets Received : 0
Success : 0 (Bubble 0, Data 0)
Failure : 0 (Hdr 0, Src 0, Dest 0)
Relay Packets Sent : 2
Success : 0 (Bubble 0, Data 0)
Failure : 2 (Hdr 0, Src 2, Dest 0)
Packets Received in the last 30 seconds:
Bubble 0, Echo 0, RS1 0, RS2 0
6to4 source address 0, native IPv6 source address 0
167
6to4 destination address 0, native IPv6 destination address 0
Estimated Bandwidth consumed in the last 30 seconds (in BPS):
Bubble 0, Echo 0, Primary 0, Secondary 0
6to4 source address 0, native IPv6 source address 0
6to4 destination address 0, native IPv6 destination address 0
In this example, the DirectAccess server is acting as a Teredo server and a Teredo relay and is in
an online state.
You use the netsh interface teredo show state command on a DirectAccess client to determine
the Teredo server of a DirectAccess client and its current state. You use the netsh interface
teredo show state command on a DirectAccess server to determine whether it is acting as a
Teredo server and its current state.
netsh interface httpstunnel show interfacesThis command shows the state and configuration of the Internet Protocol over Secure Hypertext
Transfer Protocol (IP-HTTPS) component on a DirectAccess server or client. On a DirectAccess
client, the IP-HTTPS client configuration is set by default through Group Policy. The uniform
resource locator (URL) of the IP-HTTPS server is based on the Subject field in the certificate
chosen for IP-HTTPS connections in Step 2 of the DirectAccess Setup Wizard.
The following is an example of output from the netsh interface httpstunnel show interfaces
command on a DirectAccess client.
Interface IPHTTPSInterface (Group Policy) Parameters
------------------------------------------------------------
Role : client
URL : https://da1.contoso.com:443/IPHTTPS
Last Error Code : 0x0
Interface Status : IPHTTPS interface deactivated
In this example, the DirectAccess client has been configured as an IP-HTTPS client with the URL
https://da1.contoso.com:443/IPHTTPS.
The following is an example of output from the netsh interface httpstunnel show interfaces
command on a DirectAccess server.
Interface IPHTTPSInterface Parameters
------------------------------------------------------------
Role : server
URL : https://da1.contoso.com:443/IPHTTPS
168
Client authentication mode : certificates
Last Error Code : 0x0
Interface Status : IPHTTPS interface active
In this example, the DirectAccess server has been configured as an IP-HTTPS server with the
URL https://da1.contoso.com:443/IPHTTPS and uses certificates for authentication.
You use the netsh interface httpstunnel show interfaces command on a DirectAccess client to
determine the URL of the IP-HTTPS server and the current state of the IP-HTTPS client
component. You use the netsh interface httpstunnel show interfaces command on a
DirectAccess server to determine URL of the IP-HTTPS server and to verify that it is acting as an
IP-HTTPS server and the authentication method. The URL for the netsh interface httpstunnel
show interfaces command on both the DirectAccess client and server should be the same.
netsh interface istatap show state and netsh interface istatap show routerThese commands show the state and configuration of the Intra-Site Automatic Tunnel Addressing
Protocol (ISATAP) component on the ISATAP router (the DirectAccess server) or an ISATAP host.
Unlike 6to4, Teredo, and IP-HTTPS transition technologies, the DirectAccess Setup Wizard does
not configure a name or IPv4 address for an ISATAP router in Group Policy. Instead, it attempts to
register the name ISATAP and an assigned intranet IPv4 address with its DNS server. ISATAP
hosts on the intranet use the name ISATAP to resolve the IPv4 address of the ISATAP router (the
DirectAccess server).
The following is an example of output from the netsh interface istatap show state command on
a DirectAccess server.
ISATAP State : enabled
In this example, the DirectAccess server has the ISATAP component enabled.
The following is an example of output from the netsh interface istatap show router command
on the DirectAccess server.
Router Name : isatap.corp.contoso.com
Use Relay : default
Resolution Interval : default
In this example, the DirectAccess server has constructed the ISATAP router name from the name
ISATAP and the DNS suffix assigned to the computer (corp.contoso.com).
You use the netsh interface istatap show state and netsh interface istatap show router
commands on the DirectAccess server to ensure that it is configured to act as an ISATAP router.
You use the netsh interface istatap show state and netsh interface istatap show router
commands on an intranet node to ensure that it has a default configuration.
To determine if an ISATAP host has successfully configured an ISATAP-based address, use the
ipconfig command and look for an interface named Tunnel adapter isatap.ComputerDNSSuffix.
169
Ensure that it has been assigned an ISATAP-based IPv6 address that begins with 2 or 3 and a
default gateway.
netsh advfirewall monitor show mmsaThis command shows the currently active main mode security associations (SAs) on a
DirectAccess client, a DirectAccess server, or an intranet resource.
The following is an example of output from the netsh advfirewall monitor show mmsa
command on a DirectAccess client.
Main Mode SA at 09/11/2009 10:43:59
----------------------------------------------------------------------
Local IP Address: 2002:836b:65::836b:65
Remote IP Address: 2002:836b:2::836b:2
Auth1: ComputerCert
Auth2: UserNTLM
MM Offer: None-AES128-SHA256
Cookie Pair: a075a1437682ad8e:0afed90d0f2a8cac
Health Cert: No
Main Mode SA at 09/11/2009 10:43:59
----------------------------------------------------------------------
Local IP Address: 2002:836b:65::836b:65
Remote IP Address: 2002:836b:2::836b:2
Auth1: ComputerCert
Auth2: UserNTLM
MM Offer: None-AES128-SHA256
Cookie Pair: 9e355ec21d66e39b:d748c6e2ddd09424
Health Cert: No
Main Mode SA at 09/11/2009 10:43:59
----------------------------------------------------------------------
Local IP Address: 2002:836b:65::836b:65
Remote IP Address: 2002:836b:2:1:0:5efe:10.0.0.3
Auth2 Local ID: CORP\User1
Auth2 Remote ID: host/APP1.corp.contoso.com
170
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Cookie Pair: 912ff504e979e831:4eb6fb986fa84eb9
Health Cert: No
Main Mode SA at 09/11/2009 10:43:59
----------------------------------------------------------------------
Local IP Address: 2002:836b:65::836b:65
Remote IP Address: 2002:836b:3::836b:3
Auth2 Local ID: host/CLIENT2.corp.contoso.com
Auth2 Remote ID: CORP\DA1$
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Cookie Pair: 96d2b451be5756e9:0d2515c811c26034
Health Cert: No
Main Mode SA at 09/11/2009 10:43:59
----------------------------------------------------------------------
Local IP Address: 2002:836b:65::836b:65
Remote IP Address: 2002:836b:3::836b:3
Auth2 Local ID: NT AUTHORITY\SYSTEM
Auth2 Remote ID: host/da1.corp.contoso.com
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Cookie Pair: 2ba50b46a6820026:24b64b78e8f7ac0d
Health Cert: No
Main Mode SA at 09/11/2009 10:43:59
----------------------------------------------------------------------
Local IP Address: 2002:836b:65::836b:65
Remote IP Address: 2002:836b:3::836b:3
171
Auth2 Local ID: CORP\User1
Auth2 Remote ID: host/da1.corp.contoso.com
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Cookie Pair: 4775f7dd32e268b2:b0ad96d598518fa7
Health Cert: No
Ok.
The following is an example of output from the netsh advfirewall monitor show mmsa
command on the DirectAccess server of the DirectAccess client.
Main Mode SA at 09/11/2009 10:44:03
----------------------------------------------------------------------
Local IP Address: 2002:836b:2::836b:2
Remote IP Address: 2002:836b:65::836b:65
Auth1: ComputerCert
Auth2: UserNTLM
MM Offer: None-AES128-SHA256
Cookie Pair: a075a1437682ad8e:0afed90d0f2a8cac
Health Cert: No
Main Mode SA at 09/11/2009 10:44:03
----------------------------------------------------------------------
Local IP Address: 2002:836b:2::836b:2
Remote IP Address: 2002:836b:65::836b:65
Auth1: ComputerCert
Auth2: UserNTLM
MM Offer: None-AES128-SHA256
Cookie Pair: 9e355ec21d66e39b:d748c6e2ddd09424
Health Cert: No
Main Mode SA at 09/11/2009 10:44:03
----------------------------------------------------------------------
Local IP Address: 2002:836b:3::836b:3
Remote IP Address: 2002:836b:65::836b:65
172
Auth2 Local ID: NT AUTHORITY\SYSTEM
Auth2 Remote ID: host/CLIENT2.corp.contoso.com
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Cookie Pair: 96d2b451be5756e9:0d2515c811c26034
Health Cert: No
Main Mode SA at 09/11/2009 10:44:03
----------------------------------------------------------------------
Local IP Address: 2002:836b:3::836b:3
Remote IP Address: 2002:836b:65::836b:65
Auth2 Local ID: host/da1.corp.contoso.com
Auth2 Remote ID: CORP\CLIENT2$
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Cookie Pair: 2ba50b46a6820026:24b64b78e8f7ac0d
Health Cert: No
Main Mode SA at 09/11/2009 10:44:03
----------------------------------------------------------------------
Local IP Address: 2002:836b:3::836b:3
Remote IP Address: 2002:836b:65::836b:65
Auth2 Local ID: host/da1.corp.contoso.com
Auth2 Remote ID: CORP\User1
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Cookie Pair: 4775f7dd32e268b2:b0ad96d598518fa7
Health Cert: No
Ok.
You can correlate the main mode SAs on the DirectAccess client and server through the Cookie
Pair.
173
You use the netsh advfirewall monitor show mmsa command to verify that the DirectAccess
client and server can successfully negotiate main mode Internet Protocol security (IPsec) SAs. If
there are no main mode IPsec SAs on the DirectAccess client after attempting to access an
intranet resource, investigate the inability to perform IPsec peer authentication with installed
certificates.
netsh advfirewall monitor show qmsaThis command shows the currently active quick mode SAs on a DirectAccess client, a
DirectAccess server, or an intranet resource.
The following is an example of output from the netsh advfirewall monitor show qmsa
command on a DirectAccess client.
Quick Mode SA at 09/11/2009 10:56:38
----------------------------------------------------------------------
Local IP Address: 2002:836b:65::836b:65
Remote IP Address: 2002:836b:2::836b:2
Local Port: Any
Remote Port: Any
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
PFS: None
Quick Mode SA at 09/11/2009 10:56:38
----------------------------------------------------------------------
Local IP Address: 2002:836b:65::836b:65
Remote IP Address: 2002:836b:3::836b:3
Local Port: Any
Remote Port: Any
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
PFS: None
Quick Mode SA at 09/11/2009 10:56:38
----------------------------------------------------------------------
174
Local IP Address: 2002:836b:65::836b:65
Remote IP Address: 2002:836b:2:1:0:5efe:10.0.0.3
Local Port: Any
Remote Port: Any
Protocol: Any
Direction: Both
QM Offer: ESP:SHA256-None+60min+100000kb
PFS: None
Quick Mode SA at 09/11/2009 10:56:38
----------------------------------------------------------------------
Local IP Address: 2002:836b:65::836b:65
Remote IP Address: 2002:836b:3::836b:3
Local Port: Any
Remote Port: Any
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
PFS: None
Ok.
The following is an example of output from the netsh advfirewall monitor show qmsa
command on the DirectAccess server of the DirectAccess client.
Quick Mode SA at 09/11/2009 10:56:47
----------------------------------------------------------------------
Local IP Address: 2002:836b:2::836b:2
Remote IP Address: 2002:836b:65::836b:65
Local Port: Any
Remote Port: Any
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
PFS: None
Quick Mode SA at 09/11/2009 10:56:47
175
----------------------------------------------------------------------
Local IP Address: 2002:836b:3::836b:3
Remote IP Address: 2002:836b:65::836b:65
Local Port: Any
Remote Port: Any
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
PFS: None
Quick Mode SA at 09/11/2009 10:56:47
----------------------------------------------------------------------
Local IP Address: 2002:836b:3::836b:3
Remote IP Address: 2002:836b:65::836b:65
Local Port: Any
Remote Port: Any
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
PFS: None
Ok.
You can correlate the quick mode SAs on the DirectAccess client and server through the local
and remote Internet Protocol (IP) address pairs and Quick Mode (QM) offers.
You use the netsh advfirewall monitor show qmsa command to verify that the DirectAccess
client and server can successfully negotiate quick mode IPsec SAs. If there are no quick mode
IPsec SAs on the DirectAccess client after attempting to access an intranet resource, investigate
the correlation of quick mode settings between the DirectAccess client, the DirectAccess server,
and the intranet node.
netsh advfirewall monitor show consec rule name=allThis command shows the active connection security rules on a DirectAccess client, DirectAccess
server, or intranet node.
The following is an example of the output from the netsh advfirewall monitor show consec rule
name=all command on a DirectAccess client.
176
Connection Security Rules:
Rule Name: DirectAccess Policy-clientToNlaExempt
----------------------------------------------------------------------
Enabled: Yes
Profiles: Private,Public
Type: Dynamic
Mode: Tunnel
LocalTunnelEndpoint: Any
RemoteTunnelEndpoint: Any
Endpoint1: 2002:836b:2:1::/64
Endpoint2: 2002:836b:2:1:0:5efe:10.0.0.3-2002:836b:2:
1:0:5efe:10.0.0.3
Port1: Any
Port2: 443
Protocol: TCP
Action: NoAuthentication
ExemptIPsecProtectedConnections: No
ApplyAuthorization: No
Rule Name: DirectAccess Policy-clientToAppServer
----------------------------------------------------------------------
Enabled: Yes
Profiles: Private,Public
Type: Dynamic
Mode: Transport
Endpoint1: Any
Endpoint2: 2002:836b:2:1:0:5efe:10.0.0.3-2002:836b:2:
1:0:5efe:10.0.0.3
Protocol: Any
Action: RequestInRequestOut
Auth1: ComputerCert,ComputerKerb
Auth1CAName: DC=com, DC=contoso, DC=corp, CN=corp-DC1-C
A
177
Auth1CertMapping: No
Auth1ExcludeCAName: No
Auth1CertType: Root
Auth1HealthCert: No
Auth2: UserKerb
MainModeSecMethods: DHGroup2-AES128-SHA256,DHGroup2-AES128-SHA
1,DHGroup2-3DES-SHA1
QuickModeSecMethods: ESP:SHA256-None+60min+100000kb,AH:SHA256+6
0min+100000kb,AuthNoEncap:SHA256+60min+100000kb
Rule Name: DirectAccess Policy-ClientToMgmt
----------------------------------------------------------------------
Enabled: Yes
Profiles: Private,Public
Type: Dynamic
Mode: Tunnel
LocalTunnelEndpoint: Any
RemoteTunnelEndpoint: 2002:836b:2::836b:2
Endpoint1: Any
Endpoint2: 2002:836b:2:1:200:5efe:157.60.79.2-2002:83
6b:2:1:200:5efe:157.60.79.2
Protocol: Any
Action: RequireInRequireOut
Auth1: ComputerCert
Auth1CAName: DC=com, DC=contoso, DC=corp, CN=corp-DC1-C
A
Auth1CertMapping: No
Auth1ExcludeCAName: No
Auth1CertType: Root
Auth1HealthCert: No
Auth2: UserNTLM
MainModeSecMethods: DHGroup2-AES128-SHA256,DHGroup2-AES128-SHA
1,DHGroup2-3DES-SHA1
QuickModeSecMethods: ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-AE
178
S128+60min+100000kb
ExemptIPsecProtectedConnections: No
ApplyAuthorization: No
Rule Name: DirectAccess Policy-ClientToCorp
----------------------------------------------------------------------
Enabled: Yes
Profiles: Private,Public
Type: Dynamic
Mode: Tunnel
LocalTunnelEndpoint: Any
RemoteTunnelEndpoint: 2002:836b:3::836b:3
Endpoint1: Any
Endpoint2: 2002:836b:2:1::/64
Protocol: Any
Action: RequireInRequireOut
Auth1: ComputerCert
Auth1CAName: DC=com, DC=contoso, DC=corp, CN=corp-DC1-C
A
Auth1CertMapping: No
Auth1ExcludeCAName: No
Auth1CertType: Root
Auth1HealthCert: No
Auth2: UserKerb
MainModeSecMethods: DHGroup2-AES128-SHA256,DHGroup2-AES128-SHA
1,DHGroup2-3DES-SHA1
QuickModeSecMethods: ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-AE
S128+60min+100000kb
ExemptIPsecProtectedConnections: No
ApplyAuthorization: No
Rule Name: DirectAccess Policy-ClientToDnsDc
----------------------------------------------------------------------
Enabled: Yes
179
Profiles: Private,Public
Type: Dynamic
Mode: Tunnel
LocalTunnelEndpoint: Any
RemoteTunnelEndpoint: 2002:836b:2::836b:2
Endpoint1: Any
Endpoint2: 2002:836b:2:1:0:5efe:10.0.0.1-2002:836b:2:
1:0:5efe:10.0.0.1
Protocol: Any
Action: RequireInRequireOut
Auth1: ComputerCert
Auth1CAName: DC=com, DC=contoso, DC=corp, CN=corp-DC1-C
A
Auth1CertMapping: No
Auth1ExcludeCAName: No
Auth1CertType: Root
Auth1HealthCert: No
Auth2: UserNTLM
MainModeSecMethods: DHGroup2-AES128-SHA256,DHGroup2-AES128-SHA
1,DHGroup2-3DES-SHA1
QuickModeSecMethods: ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-AE
S128+60min+100000kb
ExemptIPsecProtectedConnections: No
ApplyAuthorization: No
Ok.
You use the netsh advfirewall monitor show consec rule name=all command to verify that a
DirectAccess client, DirectAccess server, or selected server has been configured with the correct
connection security rules.
netsh advfirewall monitor show currentprofileThis command shows the networks to which the computer is attached and the firewall profiles
(public, private, or domain) assigned to each network.
The following is an example of the output from the netsh advfirewall monitor show
currentprofile command on a DirectAccess server.
180
Domain Profile:
----------------------------------------------------------------------
corp.contoso.com
Public Profile:
----------------------------------------------------------------------
Unidentified network
Ok.
In this example, the DirectAccess server is attached to two networks (corp.contoso.com and
Unidentified network). The corp.contoso.com network is assigned the domain profile and the
Unidentified network is assigned the public profile.
You use the netsh advfirewall monitor show currentprofile command to determine the profiles
that are assigned to DirectAccess clients when troubleshooting intranet detection and the profiles
assigned to a DirectAccess server when troubleshooting DirectAccess Setup Wizard problems.
netsh interface ipv6 show interfacesThis command shows the set of IPv6 interfaces on a computer and their state. The following is an
example of the output from the netsh interface ipv6 show interfaces command on a
DirectAccess server.
Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
13 25 1280 connected isatap.corp.contoso.com
14 25 1280 connected isatap.isp.example.com
11 20 1500 connected Corpnet
15 25 1280 connected 6TO4 Adapter
16 50 1280 connected Teredo Tunneling Pseudo-Interface
17 50 1280 connected IPHTTPSInterface
12 20 1500 connected Internet
You use the netsh interface ipv6 show interfaces command to quickly determine the set of
IPv6 interfaces and whether ISATAP, 6to4, Teredo, and IP-HTTPS tunneling interfaces are
present and their state (connected or disconnected).
181
netsh interface ipv6 show interfaces level=verboseThis command shows the set of IPv6 interfaces on a computer and detailed information about
their configuration.
The following is an example of the output from the netsh interface ipv6 show interfaces
level=verbose command on a DirectAccess server.
Interface Loopback Pseudo-Interface 1 Parameters
----------------------------------------------
IfLuid : loopback_1
IfIndex : 1
State : connected
Metric : 50
Link MTU : 4294967295 bytes
Reachable Time : 31000 ms
Base Reachable Time : 30000 ms
Retransmission Interval : 1000 ms
DAD Transmits : 0
Site Prefix Length : 64
Site Id : 1
Forwarding : disabled
Advertising : disabled
Neighbor Discovery : disabled
Neighbor Unreachability Detection : disabled
Router Discovery : enabled
Managed Address Configuration : disabled
Other Stateful Configuration : disabled
Weak Host Sends : enabled
Weak Host Receives : disabled
Use Automatic Metric : enabled
Ignore Default Routes : disabled
Advertised Router Lifetime : 1800 seconds
Advertise Default Route : disabled
Current Hop Limit : 0
Force ARPND Wake up patterns : disabled
182
Directed MAC Wake up patterns : disabled
Interface isatap.corp.contoso.com Parameters
----------------------------------------------
IfLuid : tunnel_4
IfIndex : 13
State : connected
Metric : 25
Link MTU : 1280 bytes
Reachable Time : 16500 ms
Base Reachable Time : 30000 ms
Retransmission Interval : 1000 ms
DAD Transmits : 0
Site Prefix Length : 64
Site Id : 1
Forwarding : enabled
Advertising : enabled
Neighbor Discovery : enabled
Neighbor Unreachability Detection : disabled
Router Discovery : enabled
Managed Address Configuration : disabled
Other Stateful Configuration : disabled
Weak Host Sends : enabled
Weak Host Receives : disabled
Use Automatic Metric : enabled
Ignore Default Routes : disabled
Advertised Router Lifetime : 1800 seconds
Advertise Default Route : enabled
Current Hop Limit : 0
Force ARPND Wake up patterns : disabled
Directed MAC Wake up patterns : disabled
Interface isatap.isp.example.com Parameters
----------------------------------------------
183
IfLuid : tunnel_5
IfIndex : 14
State : connected
Metric : 25
Link MTU : 1280 bytes
Reachable Time : 36000 ms
Base Reachable Time : 30000 ms
Retransmission Interval : 1000 ms
DAD Transmits : 0
Site Prefix Length : 64
Site Id : 1
Forwarding : disabled
Advertising : disabled
Neighbor Discovery : enabled
Neighbor Unreachability Detection : disabled
Router Discovery : enabled
Managed Address Configuration : disabled
Other Stateful Configuration : disabled
Weak Host Sends : enabled
Weak Host Receives : disabled
Use Automatic Metric : enabled
Ignore Default Routes : disabled
Advertised Router Lifetime : 1800 seconds
Advertise Default Route : disabled
Current Hop Limit : 0
Force ARPND Wake up patterns : disabled
Directed MAC Wake up patterns : disabled
Interface Corpnet Parameters
----------------------------------------------
IfLuid : ethernet_6
IfIndex : 11
State : connected
Metric : 20
184
Link MTU : 1500 bytes
Reachable Time : 19500 ms
Base Reachable Time : 30000 ms
Retransmission Interval : 1000 ms
DAD Transmits : 1
Site Prefix Length : 64
Site Id : 1
Forwarding : enabled
Advertising : disabled
Neighbor Discovery : enabled
Neighbor Unreachability Detection : enabled
Router Discovery : enabled
Managed Address Configuration : enabled
Other Stateful Configuration : enabled
Weak Host Sends : enabled
Weak Host Receives : disabled
Use Automatic Metric : enabled
Ignore Default Routes : disabled
Advertised Router Lifetime : 1800 seconds
Advertise Default Route : disabled
Current Hop Limit : 0
Force ARPND Wake up patterns : disabled
Directed MAC Wake up patterns : disabled
Interface 6TO4 Adapter Parameters
----------------------------------------------
IfLuid : tunnel_6
IfIndex : 15
State : connected
Metric : 25
Link MTU : 1280 bytes
Reachable Time : 37000 ms
Base Reachable Time : 30000 ms
Retransmission Interval : 1000 ms
185
DAD Transmits : 0
Site Prefix Length : 64
Site Id : 1
Forwarding : enabled
Advertising : disabled
Neighbor Discovery : disabled
Neighbor Unreachability Detection : disabled
Router Discovery : enabled
Managed Address Configuration : disabled
Other Stateful Configuration : disabled
Weak Host Sends : enabled
Weak Host Receives : disabled
Use Automatic Metric : enabled
Ignore Default Routes : disabled
Advertised Router Lifetime : 1800 seconds
Advertise Default Route : disabled
Current Hop Limit : 0
Force ARPND Wake up patterns : disabled
Directed MAC Wake up patterns : disabled
Interface Teredo Tunneling Pseudo-Interface Parameters
----------------------------------------------
IfLuid : tunnel_7
IfIndex : 16
State : connected
Metric : 50
Link MTU : 1280 bytes
Reachable Time : 13500 ms
Base Reachable Time : 15000 ms
Retransmission Interval : 2000 ms
DAD Transmits : 0
Site Prefix Length : 64
Site Id : 1
Forwarding : enabled
186
Advertising : disabled
Neighbor Discovery : enabled
Neighbor Unreachability Detection : enabled
Router Discovery : enabled
Managed Address Configuration : disabled
Other Stateful Configuration : disabled
Weak Host Sends : enabled
Weak Host Receives : disabled
Use Automatic Metric : enabled
Ignore Default Routes : disabled
Advertised Router Lifetime : 1800 seconds
Advertise Default Route : disabled
Current Hop Limit : 0
Force ARPND Wake up patterns : disabled
Directed MAC Wake up patterns : disabled
Interface IPHTTPSInterface Parameters
----------------------------------------------
IfLuid : tunnel_8
IfIndex : 17
State : connected
Metric : 50
Link MTU : 1280 bytes
Reachable Time : 35000 ms
Base Reachable Time : 30000 ms
Retransmission Interval : 1000 ms
DAD Transmits : 1
Site Prefix Length : 64
Site Id : 1
Forwarding : enabled
Advertising : enabled
Neighbor Discovery : enabled
Neighbor Unreachability Detection : enabled
Router Discovery : enabled
187
Managed Address Configuration : disabled
Other Stateful Configuration : disabled
Weak Host Sends : enabled
Weak Host Receives : disabled
Use Automatic Metric : enabled
Ignore Default Routes : disabled
Advertised Router Lifetime : 1800 seconds
Advertise Default Route : disabled
Current Hop Limit : 0
Force ARPND Wake up patterns : disabled
Directed MAC Wake up patterns : disabled
Interface Internet Parameters
----------------------------------------------
IfLuid : ethernet_9
IfIndex : 12
State : connected
Metric : 20
Link MTU : 1500 bytes
Reachable Time : 37000 ms
Base Reachable Time : 30000 ms
Retransmission Interval : 1000 ms
DAD Transmits : 1
Site Prefix Length : 64
Site Id : 1
Forwarding : enabled
Advertising : disabled
Neighbor Discovery : enabled
Neighbor Unreachability Detection : enabled
Router Discovery : enabled
Managed Address Configuration : enabled
Other Stateful Configuration : enabled
Weak Host Sends : enabled
Weak Host Receives : disabled
188
Use Automatic Metric : enabled
Ignore Default Routes : disabled
Advertised Router Lifetime : 1800 seconds
Advertise Default Route : disabled
Current Hop Limit : 0
Force ARPND Wake up patterns : disabled
Directed MAC Wake up patterns : disabled
You use the netsh interface ipv6 show interfaces level=verbose command on a DirectAccess
server to verify that forwarding has been enabled on the 6to4, Teredo, IP-HTTPS, ISATAP, and
local area network (LAN) interfaces and that advertising has been enabled on the IP-HTTPS and
ISATAP interfaces.
netsh interface ipv6 show routeThis command shows the entries in the IPv6 route table. The following is an example of the
output from the netsh interface ipv6 show route command on a DirectAccess server.
Publish Type Met Prefix Idx Gateway/Interface Name
------- -------- --- ------------------------ --- ------------------------
No Manual 256 ::1/128 1 Loopback Pseudo-Interface
1
No Manual 8 2001::/32 16 Teredo Tunneling Pseudo-I
nterface
Yes Manual 1000 2002::/16 15 6TO4 Adapter
No Manual 256 2002:836b:2::836b:2/128 15 6TO4 Adapter
Yes Manual 256 2002:836b:2:1::/64 13 isatap.corp.contoso.com
No Manual 256 2002:836b:2:1::/128 13 isatap.corp.contoso.com
No Manual 256 2002:836b:2:1:0:5efe:10.0.0.2/128 13 isatap.corp.cont
oso.com
Yes Manual 256 2002:836b:2:2::/64 17 IPHTTPSInterface
No Manual 256 2002:836b:2:2::/128 17 IPHTTPSInterface
No Manual 256 2002:836b:2:2:6d5c:17f7:69e8:dd2b/128 17 IPHTTPSInter
face
No Manual 256 2002:836b:3::836b:3/128 15 6TO4 Adapter
No Manual 256 fe80::/64 11 Corpnet
No Manual 256 fe80::/64 12 Internet
No Manual 256 fe80::/64 16 Teredo Tunneling Pseudo-I
189
nterface
No Manual 256 fe80::/64 17 IPHTTPSInterface
No Manual 256 fe80::5efe:10.0.0.2/128 13 isatap.corp.contoso.com
No Manual 256 fe80::200:5efe:131.107.0.2/128 14 isatap.isp.example.
com
No Manual 256 fe80::200:5efe:131.107.0.3/128 14 isatap.isp.example.
com
No Manual 256 fe80::45d1:e335:2f5e:865c/128 11 Corpnet
No Manual 256 fe80::6d5c:17f7:69e8:dd2b/128 17 IPHTTPSInterface
No Manual 256 fe80::8000:f227:7c94:fffd/128 16 Teredo Tunneling Pse
udo-Interface
No Manual 256 fe80::c862:7866:fd45:2ccf/128 12 Internet
No Manual 256 ff00::/8 1 Loopback Pseudo-Interface
1
No Manual 256 ff00::/8 17 IPHTTPSInterface
No Manual 256 ff00::/8 16 Teredo Tunneling Pseudo-I
nterface
No Manual 256 ff00::/8 11 Corpnet
No Manual 256 ff00::/8 12 Internet
You use the netsh interface ipv6 show route command to troubleshoot reachability problems
for communication between DirectAccess clients and the DirectAccess server and between
DirectAccess clients and intranet resources. You can also use the netsh interface ipv6 show
route command to determine the IPv6 prefix that the DirectAccess server is advertising to IP-
HTTPS clients, which is the 64-bit route that begins with 2 or 3 and has the Gateway/Interface
Name of IPHTTPSInterface.
The Ping.exe Command Line Tool
You use the Ping.exe command line tool in DirectAccess to verify Internet Protocol version 6
(IPv6) connectivity issues, such as the reachability from the Internet to DirectAccess server and
the DirectAccess server to an intranet resource. You can also use Ping.exe to test for intranet
DNS server name resolution.
For example, if you cannot reach any intranet resources, you can do the following from the
DirectAccess client:
1. Use the netsh namespace show effectivepolicy command to obtain the IPv6 address of
your intranet Domain Name System (DNS) server.
190
2. Use the Ping.exe tool to ping the IPv6 address of your intranet DNS server.
3. If step 2 is not successful, troubleshoot IPv6 routing and reachability issues between the
DirectAccess client and intranet DNS server.
4. If step 2 is successful, use the Ping.exe tool with the -6 option to ping the name of the intranet
server.
5. If step 4 is not successful, troubleshoot Internet Protocol security (IPsec) security issues
between the DirectAccess client and DirectAccess server.
This simplified troubleshooting example is based on the end-to-edge and selected server
deployment models and their default IPsec global settings, which exempt Internet Control
Message Protocol (ICMP) traffic from IPsec protection. Therefore, it is possible for step 2 to
succeed (the DirectAccess client sends only ICMP for IPv6 [ICMPv6] traffic, which is exempt from
IPsec protection) and step 4 to fail (the DirectAccess client sends DNS traffic, which is not
exempt from IPsec protection).
The Nslookup.exe Command Line Tool
You use the Nslookup.exe command line tool in DirectAccess to test whether intranet Domain
Name System (DNS) servers can respond to DNS queries of DirectAccess clients. However, you
must remember to specify the Internet Protocol version 6 (IPv6) address of the intranet DNS
server in the command line. The correct syntax is for using Nslookup.exe for DirectAccess
troubleshooting is nslookup IntranetFQDN IntranetDNSServerIPv6Address (example: nslookup
dc1.corp.contoso.com 2002:836b:2:1::5efe:10.0.0.1).
To emulate the behavior of the DirectAccess client, you can use the –q=aaaa command-line
parameter to request only IPv6 addresses in the response. The syntax is nslookup –q=aaaa
IntranetFQDN IntranetDNSServerIPv6Address (example: nslookup –q=aaaa
dc1.corp.contoso.com 2002:836b:2:1::5efe:10.0.0.1).
You can obtain the IPv6 address of your intranet DNS servers from the display of the netsh
namespace show effectivepolicy command.
Nslookup.exe does not use the Name Resolution Policy Table (NRPT). If you do not
specify the IPv6 address of the intranet DNS server, Nslookup.exe will send its queries to
interface-configured DNS servers.
The Ipconfig.exe Command Line Tool
You use the Ipconfig.exe command line tool to display the current Transmission Control
Protocol/Internet Protocol (TCP/IP) configuration. For DirectAccess, you use Ipconfig.exe to
determine the Internet Protocol version 6 (IPv6) configuration of a DirectAccess client, server, or
intranet node.
The following is an example of the output from the ipconfig command on a DirectAccess client.
Important
191
Windows IP Configuration
Ethernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::b52f:36dc:be07:9d6d%15
IPv4 Address. . . . . . . . . . . : 131.107.0.101
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Wireless LAN adapter Wireless Network Connection:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Ethernet adapter Local Area Connection:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Tunnel adapter isatap.{3119B40F-CEC7-404A-B368-0BE67966EBF5}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Tunnel adapter isatap.{04076670-7AF6-4B18-BF7E-8CB8393C4B4D}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Tunnel adapter 6TO4 Adapter:
Connection-specific DNS Suffix . :
192
IPv6 Address. . . . . . . . . . . : 2002:836b:65::836b:65
Default Gateway . . . . . . . . . : 2002:836b:2::836b:2
Tunnel adapter iphttpsinterface:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
In this example, the DirectAccess client is using 6to4 to reach the DirectAccess server (the
interface named Tunnel adapter 6TO4 Adapter has a 6to4-based IPv6 address and default
gateway).
The following is an example of the output from the ipconfig command on a DirectAccess server.
Windows IP Configuration
Ethernet adapter Internet:
Connection-specific DNS Suffix . : isp.example.com
Link-local IPv6 Address . . . . . : fe80::c862:7866:fd45:2ccf%12
IPv4 Address. . . . . . . . . . . : 131.107.0.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IPv4 Address. . . . . . . . . . . : 131.107.0.3
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter Corpnet:
Connection-specific DNS Suffix . : corp.contoso.com
Link-local IPv6 Address . . . . . : fe80::45d1:e335:2f5e:865c%11
IPv4 Address. . . . . . . . . . . : 10.0.0.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Tunnel adapter isatap.corp.contoso.com:
193
Connection-specific DNS Suffix . : corp.contoso.com
IPv6 Address. . . . . . . . . . . : 2002:836b:2:1:0:5efe:10.0.0.2
Link-local IPv6 Address . . . . . : fe80::5efe:10.0.0.2%13
Default Gateway . . . . . . . . . :
Tunnel adapter isatap.isp.example.com:
Connection-specific DNS Suffix . : isp.example.com
Link-local IPv6 Address . . . . . : fe80::200:5efe:131.107.0.2%14
Link-local IPv6 Address . . . . . : fe80::200:5efe:131.107.0.3%14
Default Gateway . . . . . . . . . :
Tunnel adapter 6TO4 Adapter:
Connection-specific DNS Suffix . : isp.example.com
IPv6 Address. . . . . . . . . . . : 2002:836b:2::836b:2
IPv6 Address. . . . . . . . . . . : 2002:836b:3::836b:3
Default Gateway . . . . . . . . . :
Tunnel adapter Teredo Tunneling Pseudo-Interface:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::8000:f227:7c94:fffd%16
Default Gateway . . . . . . . . . :
Tunnel adapter IPHTTPSInterface:
Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . . : 2002:836b:2:2:6d5c:17f7:69e8:dd2b
Link-local IPv6 Address . . . . . : fe80::6d5c:17f7:69e8:dd2b%17
Default Gateway . . . . . . . . . :
In this example, the DirectAccess server has an ISATAP address (on the interface named Tunnel
adapter isatap.corp.contoso.com) and is using 6to4, Teredo, and IP-HTTPS.
194
You can also use the Ipconfig.exe command line tool to display the contents of the Domain Name
System (DNS) Resolver cache with the ipconfig /displaydns command. From the contents of
the DNS Resolver cache, you can determine the results of resolving intranet resource names.
The display of the ipconfig /displaydns command can also contain the results of DNS
queries for personal communications and care should be taken to preserve the privacy of
the computer user.
The Certutil.exe Command Line Tool
You use the Certutil.exe command line tool to display information about the digital certificates that
are installed on a DirectAccess client, DirectAccess server, or intranet resource.
The following is an example of the output from the certutil –store my command on a
DirectAccess client.
================ Certificate 0 ================
Serial Number: 61b96b4300000000000b
Issuer: CN=corp-DC1-CA, DC=corp, DC=contoso, DC=com
NotBefore: 8/28/2009 11:57 AM
NotAfter: 8/28/2010 11:57 AM
Subject: CN=CLIENT2.corp.contoso.com
Certificate Template Name (Certificate Type): Machine
Non-root Certificate
Template: Machine, Computer
Cert Hash(sha1): d2 48 b0 ac d0 75 d2 17 d3 a2 52 73 03 fb 6d 93 05 d6 c5 9c
Key Container = 7658bfbea27b8a8b1a912b2792198aa7_81cb8b83-9acb-41a0-a19f-615d9
d8a0337
Simple container name: le-Machine-e4918f29-7e62-48c3-a958-445f367d773d
Provider = Microsoft RSA SChannel Cryptographic Provider
Private key is NOT exportable
Encryption test passed
CertUtil: -store command completed successfully.
You use the Certutil.exe command line tool for DirectAccess troubleshooting to determine the
subject, enhanced key usage (EKU), and certificate revocation list (CRL) distribution points fields
of installed certificates. Use the certutil -v –store my > cert.txt command and then view the
contents of the Cert.txt file.
Note
195
The Nltest.exe Command Line Tool
You use the Nltest.exe command line tool to display information about Active Directory Domain
Services (AD DS).
The following is an example of the output from the nltest /dsgetdc: /force command on a
DirectAccess client.
DC: \\DC1.corp.contoso.com
Address: \\2002:836b:2:1:0:5efe:10.0.0.1
Dom Guid: e8bae90e-02c4-4489-8abd-e63353fed05a
Dom Name: corp.contoso.com
Forest Name: corp.contoso.com
Dc Site Name: Default-First-Site-Name
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN
DNS_FOREST FULL_SECRET WS
The command completed successfully
You use the Nltest.exe command line tool (the nltest /dsgetdc: /force command) for
DirectAccess troubleshooting to determine whether DirectAccess clients, DirectAccess servers,
and intranet resources can locate and contact domain controllers for Internet Protocol security
(IPsec) authentication.
Snap-in Tools
Windows 7 and Windows Server 2008 R2 also provide a set of snap-ins to gather troubleshooting
information or modify settings to correct problems. The following snap-ins can be used for
DirectAccess troubleshooting:
DirectAccess Management
Group Policy Management Console and Editor
Windows Firewall with Advanced Security
Event Viewer
Certificates
DirectAccess Management
With the Monitoring node of the DirectAccess Management snap-in, you can monitor the overall
status and obtain performance counters for DirectAccess server components.
To view the status of the DirectAccess server with DirectAccess monitoring
196
1. On the DirectAccess server, click Start, type damgmt.msc, and then press ENTER.
2. In the console tree of the DirectAccess Management console, click Monitoring.
3. In the details pane, click Details to obtain performance monitor counters for a
component.
The Teredo Relay, Teredo Server, ISATAP, and 6to4 components display a green (healthy) status
if there was traffic activity on any of the tunnel interfaces during the last 10 seconds. IP-HTTPS
and Network Security components display a green status if there were one or more active
sessions or tunnels in the last 10 seconds. If there was no traffic or active sessions in the last 10
seconds, the component shows with a yellow status. If a component has failed, its status is red.
Log files of the DirectAccess Management snap-inFor additional information about events and errors encountered by the Setup node of the
DirectAccess Management snap-in and the DirectAccess Setup Wizard, see the %SystemRoot%\
Tracing\DASetup.log file.
For additional information about events and errors encountered by the Monitoring node of the
DirectAccess Management snap-in, see the %SystemRoot%\Tracing\DAMontr.log file.
Group Policy Management Console and Editor
DirectAccess clients, servers, and selected servers obtain their DirectAccess settings through
Group Policy objects. The primary tools for viewing and changing the configuration of settings
within Group Policy objects are the Group Policy Management Console and Group Policy
Management Editor snap-ins.
For DirectAccess, you use the Group Policy Management Editor snap-in to view or modify the
following configuration:
Name Resolution Policy Table (NRPT) rules
Internet Protocol version 6 (IPv6) transition technologies
Intranet connectivity
Connection security rules
NRPT rulesRules in the NRPT that you configure in step 3 of the DirectAccess Setup Wizard are created in
the Computer Configuration\Policies\Windows Settings\Name Resolution Policy node of the
Group Policy object for DirectAccess clients.
Use the Group Policy Management Editor snap-in to verify the configuration of NRPT rules and
modify them as needed.
197
IPv6 Transition Technologies settingsThe DirectAccess Setup Wizard configures settings for the 6to4, Teredo, and Internet Protocol
over Secure Hypertext Transfer Protocol (IP-HTTPS) IPv6 transition technologies in the
Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6
Transition Technologies node of the Group Policy object for DirectAccess clients.
The following table lists the IPv6 transition technology settings and their values as set by the
DirectAccess Setup Wizard.
Setting name Description Value set by the DirectAccess
Setup Wizard
6to4 Relay Name Allows you to specify a 6to4
relay name for a 6to4 host. A
6to4 relay is used as a default
gateway for IPv6 network traffic
sent by the 6to4 host.
The first consecutive Internet
Protocol version 4 (IPv4)
address of the DirectAccess
server’s Internet interface.
6to4 Relay Name Resolution
Interval
Allows you to specify the
interval at which the 6to4 relay
name is resolved.
N/A (not configured)
6to4 State Allows you to configure the
state of the 6to4 client.
N/A
IP-HTTPS State Allows you to configure the
state of the IP-HTTPS client.
The IP-HTTPS uniform
resource locator (URL) and the
interface in a default state.
ISATAP Router Name Allows you to specify a router
name or IPv4 address for an
ISATAP router.
N/A
ISATAP State Allows you to configure the
state of the Intra-Site Automatic
Tunnel Addressing Protocol
(ISATAP) host.
N/A
Teredo Client Port Allows you to specify the User
Datagram Protocol (UDP) port
the Teredo client will use to
send packets.
N/A
Teredo Default Qualified Allows you to set Teredo to be
ready to communicate. By
default, Teredo enters a
dormant state when not in use.
Set to enabled state.
198
Setting name Description Value set by the DirectAccess
Setup Wizard
The qualification process brings
it out of a dormant state.
Teredo Refresh Rate Allows you to configure the rate
at which Teredo clients refresh
the Network Address Translator
(NAT) translation table.
N/A
Teredo Server Name Allows you to specify the name
of the Teredo server.
The first consecutive IPv4
address of the DirectAccess
server’s Internet interface.
Teredo State Allows you to specify the state
of the Teredo service.
N/A
Use the Group Policy Management Editor snap-in to verify the configuration of 6to4, Teredo, and
IP-HTTPS settings for DirectAccess clients and modify them as needed.
Intranet connectivity settingsSettings for the intranet and network location detection processes are configured by the
DirectAccess Setup Wizard in the Computer Configuration\Policies\Administrative
Templates\Network\Network Connection Status Indicator node of the Group Policy object for
DirectAccess clients.
Setting name Description Value set by the DirectAccess
Setup Wizard
Corporate DNS Probe Host
Address
The expected address when
querying the Corporate DNS
Probe Host Name.
::1
Corporate DNS Probe Host
Name
A fully qualified domain
name (FQDN) to query to
determine corporate
connectivity.
directaccess-
corpConnectivityHost.
ComputerDNSSuffix
Corporate Site Prefix List The list of IPv6 addresses
and prefixes that define the
address space of the
corporate network.
The IPv6 prefix of the intranet.
199
Setting name Description Value set by the DirectAccess
Setup Wizard
Corporate Website Probe
URL
A URL to request to
determine corporate
connectivity.
N/A (not configured)
Domain Location
Determination URL
The Secure Hypertext
Transfer Protocol (HTTPS)-
based URL of the network
location server.
The URL specified during the
DirectAccess Setup Wizard or
obtained from the Subject field of
the certificate on the DirectAccess
server that was selected for
network location.
Use the Group Policy Management Editor snap-in to verify the configuration of these corporate
connectivity settings—most importantly for DirectAccess, the Domain Location Determination
URL setting—and modify them as needed.
Connection security rulesThe DirectAccess Setup Wizard configures connection security rules to define traffic protection in
the Computer Configuration\Policies\Windows Settings\Security Settings\Windows
Firewall with Advanced Security\Windows Firewall with Advanced Security node of the
Group Policy objects for DirectAccess clients, the DirectAccess server, and selected servers.
Use the Group Policy Management Editor snap-in only to view the connection security
rules. Because the DirectAccess Setup Wizard creates the connection security rules with
advanced settings for which there is no user interface equivalent, you must not modify
the connection security rules with the Group Policy Management Editor snap-in. Instead,
use netsh advfirewall consec set rule commands.
Windows Firewall with Advanced Security
Use the Windows Firewall with Advanced Security snap-in from the Administrative Tools folder to
view the active firewall rules, connection security rules, and Internet Protocol security (IPsec)
security associations (SAs).
1. Click Start, type wf.msc, and then press ENTER.
2. In the console tree of the Windows Firewall with Advanced Security snap-in, double-click
Monitoring.
To view the active firewall rules, in the console tree, click Firewall.
To view the active connection security rules, in the console tree, click Connection
Note To use the Windows Firewall with Advanced Security snap-in
200
Security Rules.
To view the active main mode or quick mode SAs, in the console tree, double-click
Security Associations, and then click Main Mode or Quick Mode.
On a DirectAccess client, if there are active connection security rules whose names begin with
DirectAccess Policy, the DirectAccess client has determined that it is not connected to your
intranet. If there are active connection security rules but no main mode or quick mode SAs after
attempting to access an intranet resource, the DirectAccess client is unable to negotiate IPsec
protection with the DirectAccess server.
Event Viewer
Use the Event Viewer snap-in on a DirectAccess client to examine Windows events for
operational Internet Protocol security (IPsec) and Windows Firewall events, intranet detection
events, and IPsec negotiation events.
1. Click Start, type eventvwr.msc, and then press ENTER.
2. In the console tree of Event Viewer, navigate to the appropriate location.
3. In the contents pane, double-click a Windows event to view its details.
For troubleshooting DirectAccess problems, view the events in the following locations:
Applications and Service Logs\Microsoft\Windows\Windows Firewall with Advanced Security
Use this event log to view Windows Firewall and connection security (IPsec) operational
events, such as changes to network profiles or firewall settings.
Applications and Services Logs\Microsoft\Windows\NCSI\Operational
Use this event log to view intranet detection, also known as Inside/Outside detection, and its
results.
Windows Logs\Security
IPsec events in the Windows Logs\Security event log are configured through audit settings,
which are not enabled by default. To enable audit settings and view IPsec audit events for
IPsec security negotiations, use Auditpol.exe, a command line tool that modifies audit polices
of the local computer to enable or disable the various categories and subcategories of events
and then view the events in the Event Viewer snap-in. To enable audit policies for IPsec
security negotiation, run the auditpol /set /subcategory:”IPsec Main Mode”,“IPsec
Extended Mode” /success:enable /failure:enable command at an elevated command
prompt.
Then, view events 4653, 4654 and 4984 in the Windows Logs\Security event log.
To start the Event Viewer snap-in
201
Certificates
Use the Certificates snap-in to view the properties of certificates in the computer store of a
DirectAccess client, DirectAccess server, intranet server, or the network location server.
1. Click Start, type mmc, and then press ENTER.
2. Click File, and then click Add/Remove Snap-in.
3. Click Certificates, click Add, select Computer account, click Next, select Local
computer, click Finish, and then click OK.
4. In the console tree of the Certificates snap-in, open Certificates (Local Computer)\
Personal\Certificates.
5. To view the properties of a certificate, double-click the certificate in the details pane.
You use the Certificates snap-in for DirectAccess troubleshooting to verify the subject, enhanced
key usage (EKU), and certificate revocation list (CRL) distribution points on the Details tab for the
properties of installed certificates.
General Methodology for Troubleshooting DirectAccess Connections
DirectAccess connections initiated by DirectAccess clients occur in the following stages:
1. Internet Protocol version 6 (IPv6) connectivity to the DirectAccess server.
2. Negotiation of protection of DirectAccess traffic with the DirectAccess server (for the full
intranet and selected server access models).
3. IPv6 connectivity to the intranet resource.
4. Negotiation of protection of DirectAccess traffic with the intranet server (for the selected
server and end-to-end access models).
You can use the following process as a general methodology for incrementally stepping through
the DirectAccess connection requirements for a DirectAccess client on the Internet to
successfully access an intranet resource:
1. The DirectAccess client computer must be running Windows 7 Ultimate Edition, Windows 7
Enterprise Edition, or Windows Server 2008 R2.
2. The DirectAccess client computer must be a member of an Active Directory Domain Services
(AD DS) domain and its computer account must be a member of one of the security groups
configured in step 1 of the DirectAccess Setup Wizard.
3. The DirectAccess client computer must have received computer configuration Group Policy
settings for DirectAccess.
To view certificates in the computer store with the Certificates snap-in
202
To verify, use the Resultant Set of Policy snap-in to ensure that DirectAccess Policy-
{3491980e-ef3c-4ed3-b176-a4420a810f12} is listed for the computer configuration Group
Policy objects associated with the DirectAccess client computer.
4. The DirectAccess server computer must have received computer configuration Group Policy
settings for DirectAccess.
To verify, use the Resultant Set of Policy snap-in to ensure that DirectAccess Policy-
{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300} is listed for the computer configuration Group
Policy objects associated with the DirectAccess server computer.
5. The DirectAccess client must have a global IPv6 address.
Use the ipconfig command to display the Transmission Control Protocol/Internet Protocol
(TCP/IP) configuration. Is there an IPv6 address assigned to an interface that begins with 2 or
3?
If so, go to step 6.
If not, use the netsh interface 6to4 show relay, netsh interface teredo show state, and
netsh interface httpstunnel show interfaces commands on the DirectAccess client and
server to verify the configuration of 6to4, Teredo, and Internet Protocol over Secure Hypertext
Transfer Protocol (IP-HTTPS).
If the DirectAccess client is connected to the Internet Protocol version 4 (IPv4)
Internet, check the IPv4 address assigned by the Internet service provider (ISP)
or local router. For a public IPv4 address, your Tunnel adapter 6TO4 Adapter
should be configured with an address that starts with 2002. The Tunnel adapter
6TO4 Adapter should also be assigned a default gateway. For a private IPv4
address, your Teredo interface should be configured with an address that starts
with 2001.
For IP-HTTPS, look at the Tunnel adapter iphttpsinterface. Unless you had a
native IPv6 infrastructure in place prior to running the DirectAccess Setup
Wizard, the Tunnel adapter iphttpsinterface should be configured with an
address that starts with 2002. The Tunnel adapter iphttpsinterface should also
be assigned a default gateway.
For more information and additional troubleshooting steps, see Fixing Connectivity Issues
Between the DirectAccess Client and the DirectAccess Server over the Internet.
6. The DirectAccess client must be able to reach the IPv6 addresses of the DirectAccess server.
Use the ipconfig command on the DirectAccess server to display the TCP/IP configuration.
Note the global IPv6 addresses of the DirectAccess server (those starting with 2 or 3). From
the DirectAccess client, ping any of the global IPv6 addresses of the DirectAccess server,
starting with the IPv6 addresses that begin with 2002.
If successful, go to step 7.
If not successful, troubleshoot the IPv6 reachability between the DirectAccess client and
server. For more information and additional troubleshooting steps, see Fixing Connectivity
Issues Between the DirectAccess Client and the DirectAccess Server over the Internet.
Tips
203
7. The intranet servers have a global IPv6 address.
Use the ipconfig command on the intranet server to display the TCP/IP configuration. Is
there an IPv6 address assigned to an interface that begins with 2 or 3?
If so, go to step 8.
If not, troubleshoot the IPv6 infrastructure on your intranet. For Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP), ensure that your Domain Name System (DNS) servers
running Windows Server 2008 or later have the name ISATAP removed from their global
query block lists. Additionally, verify that the DirectAccess server has registered an ISATAP A
record in the intranet DNS. For additional information and troubleshooting steps, see
DirectAccess Client Cannot Access Intranet Resources.
If you are using an IPv6/IPv4 translator such as NAT64 or Network Address
Translation-Protocol Translation (NAT-PT) to reach the intranet server, it will not
have a global IPv6 address. In this case, ensure that the NAT64 or NAT-PT has a
global IPv6 address.
8. The DirectAccess client on the Internet must correctly determine that it is not on the intranet.
Use the netsh namespace show effectivepolicy command to display the Name Resolution
Policy Table (NRPT). There should be NRPT rules for the intranet namespace and an
exemption rule for the fully qualified domain name (FQDN) of the network location server.
If you have the appropriate rules in your NRPT, go to step 9.
If not, determine the network location uniform resource locator (URL) from the reg query
HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\
CorporateConnectivity /v DomainLocationDeterminationUrl command.
Ensure that the FQDN from this URL either does not match the DNS suffix for your intranet
namespace in the NRPT or matches an exemption rule.
For additional information and troubleshooting steps, see DirectAccess Client Determines
that it is on the Intranet When on the Internet.
9. The DirectAccess client must not be assigned the domain firewall profile.
Use the netsh advfirewall monitor show currentprofile command to display the attached
networks and their determined firewall profiles. None of your networks should be assigned
the domain profile.
If none of your networks have been assigned the domain profile, go to step 10.
If any of your networks has been assigned the domain profile, determine if you have an active
remote access virtual private network (VPN) connection or a domain controller that is
available on the Internet.
10. The DirectAccess client must have IPv6 reachability to its intranet DNS servers.
From the display of the netsh namespace show effectivepolicy command, obtain the IPv6
addresses of your intranet DNS servers. Ping these IPv6 addresses from the DirectAccess
client.
If successful, go to step 11.
Note
204
If not successful, troubleshoot the IPv6 reachability between the DirectAccess client and the
intranet DNS servers. Ensure that your DirectAccess server has only a single IPv4 default
gateway that is configured on the Internet interface. Also ensure that your DirectAccess
server has been configured with the set of IPv4 routes on the intranet interface that allow it to
access all of the IPv4 destinations of your intranet.
The use of the Ping.exe tool assumes the default global Internet Protocol security
(IPsec) settings that exempt Internet Control Message Protocol (ICMP) traffic
from IPsec protection.
11. The DirectAccess client must be able to use intranet DNS servers to resolve intranet FQDNs.
Use the nslookup –q=aaaa IntranetFQDN IntranetDNSServerIPv6Address command to
resolve the names of intranet servers (example: nslookup –q=aaaa dc1.corp.contoso.com
2002:836b:2:1::5efe:10.0.0.1). The Nslookup.exe tool should display the IPv6 addresses of
the specified intranet server.
If the Nslookup.exe tool performs successful name resolution, go to step 12.
If there is no response from the intranet DNS server, go to step 14. If the name was not
found, determine why the corresponding AAAA record is not in your intranet DNS.
For additional information and troubleshooting steps, see DirectAccess Client Cannot
Resolve Names with Intranet DNS Servers.
12. The DirectAccess client must have reachability to the intranet servers.
Use the Ping.exe tool to ping the IPv6 addresses of intranet servers.
If successful, go to step 13.
If not successful, troubleshoot the IPv6 reachability between the DirectAccess client and the
intranet servers.
The use of the Ping.exe tool assumes the default global IPsec settings that
exempt ICMP traffic from IPsec protection.
13. The DirectAccess client must be able to communicate with intranet servers using application
layer protocols.
Use the appropriate program to access the intranet server. If File and Printer Sharing is
enabled on the intranet server, test application layer protocol access with the net view \\
IntranetFQDN command. The application on the DirectAccess client must be IPv6-capable. If
not, you cannot use it for DirectAccess.
If not successful, go to step 14.
14. For the end-to-edge or selected server access models, the DirectAccess client must be able
to successfully negotiate main mode and quick mode IPsec security associations (SAs) with
the DirectAccess server for the infrastructure tunnel.
On the DirectAccess client, use the Windows Firewall with Advanced Security snap-in or the
netsh advfirewall monitor show mmsa and netsh advfirewall monitor show qmsa
commands to determine if there are main mode and quick mode SAs to the IPv6 address
2002:WWXX:YYZZ::WWXX:YYZZ. WWXX:YYZZ is the colon-hexadecimal representation of
the first consecutive IPv4 address assigned to the Internet interface of the DirectAccess
Note Note
205
server. For example, for 131.107.0.1, the corresponding IPv6 address is 2002:836b:1::836b:1
(131=0x83, 107=0x6b).
If successful, go to step 15.
If not successful, use the nltest /dsgetdc: /force command on the DirectAccess server to
ensure that it can access a domain controller. If there are no domain controllers listed,
troubleshoot the lack of discoverability and connectivity between the DirectAccess server and
an Active Directory domain controller.
Ensure that the DirectAccess client and DirectAccess server have the proper certificates for
IPsec peer authentication.
If the proper certificates are installed on the DirectAccess client and DirectAccess server, use
Windows Firewall tracing on the DirectAccess client and analyze the contents of the
Wfpdiag.xml file. For more information, see Network Diagnostics and Tracing.
15. For the end-to-edge or selected server access models, the DirectAccess client must be able
to successfully negotiate main mode and quick mode IPsec SAs with the DirectAccess server
for the intranet tunnel.
Verify that you have logged on to the DirectAccess client computer with a domain account.
Local computer accounts do not have the credentials to authenticate the intranet tunnel.
On the DirectAccess client, use the Windows Firewall with Advanced Security snap-in or the
netsh advfirewall monitor show mmsa and netsh advfirewall monitor show qmsa
commands to determine if there are main mode and quick mode SAs to the IPv6 address
2002:RRSS:TTUU::RRSS:TTUU. RRSS:TTUU is the colon-hexadecimal representation of
the second consecutive IPv4 address assigned to the Internet interface of the DirectAccess
server.
If the SAs exist and you are using an IPv6/IPv4 translator such as NAT64 or NAT-PT to reach
the intranet server, verify that the IPv6/IPv4 translator supports translating the application
protocol. Some protocols embed IP address information in the packet payload and cannot be
used across some IPv6/IPv4 translators.
If successful, go to step 16.
If not successful, use the nltest /dsgetdc: /force command on the DirectAccess server to
ensure that it has access to a domain controller. If there are no domain controllers listed,
troubleshoot the lack of discoverability and connectivity between the DirectAccess server and
Active Directory.
Use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it has
access to a domain controller. If there are no domain controllers listed, ensure that the IPv6-
capable domain controllers that are being used by DirectAccess clients are using site-less
locator records in DNS.
Ensure that the DirectAccess client and DirectAccess server have the proper certificates for
IPsec peer authentication.
If the proper certificates are installed on the DirectAccess client and DirectAccess server, use
Windows Firewall tracing on the DirectAccess client and analyze the contents of the
Wfpdiag.xml file. For more information, see Network Diagnostics and Tracing.
206
For additional information and troubleshooting steps, see DirectAccess Client Cannot
Establish Tunnels to the DirectAccess Server.
16. For the end-to-end access model or the selected servers in the selected server access
model, the DirectAccess client must be able to successfully negotiate main mode and quick
mode IPsec SAs with the intranet or selected server.
On the DirectAccess client, use the Windows Firewall with Advanced Security snap-in or the
netsh advfirewall monitor show mmsa and netsh advfirewall monitor show qmsa
commands to determine if there are main mode and quick mode SAs to the IPv6 address of
the intranet or selected server.
If not successful, use the nltest /dsgetdc: /force command on the intranet or selected server
to ensure that it has access to a domain controller. If there are no domain controllers listed,
troubleshoot the lack of discoverability and connectivity between the intranet or selected
server and Active Directory.
Use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it has
access to a domain controller. If there are no domain controllers listed, ensure that the IPv6-
capable domain controllers that are being used by DirectAccess clients are using site-less
locator records in DNS.
Ensure that the DirectAccess client and intranet or selected server have the proper
certificates for IPsec peer authentication.
If the proper certificates are installed on the DirectAccess client and intranet or selected
server, use Windows Firewall tracing on the DirectAccess client and analyze the contents of
the Wfpdiag.xml file. For more information, see Network Diagnostics and Tracing.
For additional information and troubleshooting steps, see Fixing Problems with Creating
Protected Connections to an Intranet Resource.
Troubleshooting DirectAccess Problems
Problems with DirectAccess typically fall into the following categories:
Problems successfully running the DirectAccess Setup Wizard
You can resolve most of these types of problems by meeting the configuration requirements
of either the DirectAccess server or the network infrastructure. See Problems with the
DirectAccess Setup Wizard.
Problems with DirectAccess connections
You can resolve most of these types of problems by stepping through the General
Methodology for Troubleshooting DirectAccess Connections. For additional information to
troubleshoot specific types of DirectAccess connection problems, see Problems with
DirectAccess Connections.
207
Problems with the DirectAccess Setup Wizard
The problems that you might encounter when using the DirectAccess Setup Wizard to configure a
DirectAccess server typically fall into the following categories:
Fixing problems that Prevent You from Running the DirectAccess Setup Wizard
Fixing Problems Encountered during the Steps of the DirectAccess Setup Wizard
Fixing Problems Encountered when Applying the Settings of the DirectAccess Setup Wizard
Fixing problems that Prevent You from Running the DirectAccess Setup Wizard
If the DirectAccess server does not meet the configuration requirements, when you run the
DirectAccess Management snap-in and click Setup in the console tree, the DirectAccess
Management snap-in displays a series of messages indicating the error conditions that exist.
The following table lists the most common error messages, a description of the error condition,
and the steps to correct it.
Error message Error condition and the steps to correct
The current security context is not associated
or accessible to Active Directory Domain
Services (AD DS).
The DirectAccess server cannot reach a
domain controller of the domain in which it is a
member. Verify the connection to your intranet
and name resolution and reachability to an
intranet domain controller.
The DirectAccess server must be joined to an
Active Directory domain. Please join this server
to a domain and then try again.
The DirectAccess server cannot be a
standalone server. Join it to the appropriate AD
DS domain.
The Active Directory domain is unreachable.
Unable to get domain information.
The DirectAccess server cannot reach a
domain controller of the domain in which it is a
member. Verify the connection to your intranet
and name resolution and reachability to an
intranet domain controller.
The DirectAccess server must have two or
more physical network interfaces. Verify that
you have two or more interfaces and then try
again.
The DirectAccess server requires two physical
network adapters corresponding to two local
area network (LAN) or wireless LAN (WLAN)
network adapters that are installed in the
DirectAccess server computer.
208
Error message Error condition and the steps to correct
At least two network interfaces must be
configured with static IP addresses. Please
contact the network administrator to obtain and
assign static IP addresses to this server.
The network connections corresponding to the
network adapters for the DirectAccess server’s
connection to the Internet and intranet must be
configured with static Internet Protocol version
4 (IPv4) addresses. They cannot use the
Dynamic Host Configuration Protocol (DHCP)
to obtain an IPv4 address configuration.
The DirectAccess server must have two
consecutive public IPv4 addresses configured
on the same physical interface. Configure IPv4
addresses and try again.
At least one of the network connections
corresponding to the network adapters installed
in the DirectAccess server must have two,
consecutive public IPv4 addresses statically
assigned. These two consecutive addresses
are needed by the DirectAccess server to act
as a Teredo server. Obtain two consecutive
addresses and assign them to a network
adapter on the DirectAccess server.
Note
The DirectAccess Management
console sorts the public IPv4
addresses 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.
For additional information about events and errors encountered by the DirectAccess Management
snap-in, see the %SystemRoot%\Tracing\DASetup.log file.
For more information about the configuration requirements of the DirectAccess server, see
Appendix A: DirectAccess Requirements and Checklist: Preparing Your DirectAccess Server.
209
Fixing Problems Encountered during the Steps of the DirectAccess Setup Wizard
The following sections describe problems that you might encounter on the pages of the
DirectAccess Setup Wizard in the DirectAccess Management snap-in and how to correct them.
For additional information about events and errors encountered by the DirectAccess Setup
Wizard, see the %SystemRoot%\Tracing\DASetup.log file.
Step 2-DirectAccess ServerStep 2 of the DirectAccess Setup Wizard has the following pages:
Connectivity
Prefix configuration
Certificate components
Connectivity pageOn the Connectivity page, you select the interface that is connected to the Internet, the interface
that is connected to the intranet (internal network), and specify whether you want to require smart
cards for an additional level of authorization for access to the intranet.
The following table lists most typical error messages you might see when selecting the Internet or
intranet (internal network) interface.
Error message Error condition and the steps to correct
The Internet interface must have two
consecutive global Internet Protocol version 4
(IPv4) addresses configured. Select an
interface with two consecutive global IPv4
addresses.
The interface that you select must have two,
consecutive public IPv4 addresses statically
assigned. These two consecutive addresses
are needed by the DirectAccess server to act
as a Teredo server.
Note
The DirectAccess Management
console sorts the public IPv4
addresses 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
210
Error message Error condition and the steps to correct
w.x.y.1, w.x.y.10, w.x.y.2. Use a
different set of consecutive addresses.
The Internet interface must not be classified as
a domain network.
The interface that you have specified for the
Internet is connected to a network that contains
a domain controller (the network has been
assigned the domain firewall profile). The
Internet interface must be connected to a
network that has been assigned the Public or
Private profiles. Select a different interface or
add outbound packet filters to the selected
interface that block connectivity to the IP
addresses of the domain controllers. For more
information, see Configure Packet Filters to
Block Access to Domain Controllers.
You can use the netsh advfirewall monitor
show currentprofile command to display the
networks to which your computer is attached
and their assigned profiles. Then, use the
Network Connections window to determine the
networks to which the interfaces are connected.
The internal network interface must be
classified as a domain network.
The interface that you have specified for the
intranet (internal network) is connected to a
network that has been assigned the Private or
Public firewall profile. The intranet interface
must be connected to a network that has been
assigned the Domain profile, which contains a
domain controller. Select a different interface.
You can use the netsh advfirewall monitor
show currentprofile command to display the
networks to which your computer is attached
and their assigned profiles. Then, use the
Network Connections window to determine the
networks to which the interfaces are connected.
The internal network interface does not have
Domain Name System (DNS) server settings
configured. Select an interface with DNS server
settings configured.
The intranet (internal network) interface must
be manually configured with the IPv4 or IPv6
addresses of at least one intranet DNS server.
Select another interface or manually configure
the appropriate interface with the IPv4 or
Internet Protocol version 6 (IPv6) addresses of
211
Error message Error condition and the steps to correct
at least one intranet DNS server.
The internal network interface does not have a
connection-specific DNS suffix. Select an
interface with a connection-specific DNS suffix.
The intranet (internal network) interface must
be manually configured with a connection-
specific DNS suffix that represents your intranet
DNS namespace (for example,
corp.contoso.com). Select another interface or
manually configure the appropriate interface
with a connection-specific DNS suffix.
IPv6 was detected on your Internet interface.
DirectAccess setup will apply settings without
considering the IPv6 settings on the Internet
interface.
Your Internet interface has a native IPv6
address assigned. The DirectAccess Setup
Wizard will configure IPv6 for the intranet
without regard to the IPv6 configuration of the
Internet interface.
However, you will need to configure packet
filters on the Internet interface to prevent the
Internet interface from being assigned the
Domain firewall profile. For more information,
see Configure Packet Filters to Block Access to
Domain Controllers.
Prefix Configuration pageOn the Prefix Configuration page, which the DirectAccess Setup Wizard displays only when it
detects global or unique local IPv6 addresses on the intranet interface, you specify the IPv6 prefix
for your organization and the 64-bit prefix assigned to Internet Protocol over Secure Hypertext
Transfer Protocol (IP-HTTPS)-based DirectAccess clients.
The following table lists the error messages you might see when specifying the organization or
IP-HTTPS prefixes.
Error message Error condition and the steps to correct
The IPv6 prefix you provided for the internal
network is not valid. Provide a valid IPv6 prefix.
You have not specified a valid global or unique
local address prefix for your organization.
The IPv6 prefix you provided to assign to the
IPv6 addresses of remote client computers is
not valid. Provide a valid IPv6 prefix.
You have not specified a valid 64-bit global or
unique local address prefix for your IP-HTTPS-
based DirectAccess clients.
The network prefix you provided to assign to
IPv6 addresses must be a subset of the internal
network IPv6 prefix. Provide a valid IPv6 prefix.
The 64-bit prefix for your IP-HTTPS-based
DirectAccess clients must be based on the IPv6
prefix for your organization. For example, if
212
Error message Error condition and the steps to correct
your intranet IPv6 prefix is 2001:db8:4ac1::/48,
your 64-bit prefix must be of the form
2001:db8:4ac1:xxxx::/64.
Certificate Components pageOn the Certificate Components page, you select a root or intermediate certificate for IPsec
authentication and the certificate used by the DirectAccess server for client-based authentication
of IP-HTTPS connections.
The following table lists the most common error messages you might see when specifying the IP-
HTTPS certificate.
Error message Error condition and the steps to correct
The selected certificate has a subject name that
is not valid. Select a certificate with a valid
subject name.
The certificate that you selected does not have
a valid value in the Subject field. A valid Subject
field is required to configure DirectAccess
clients with a Secure Hypertext Transfer
Protocol (HTTPS)-based uniform resource
locator (URL) of the IP-HTTPS server (the
DirectAccess server). To see the value of the
Subject field, use the Certificates snap-in for
the local computer store, obtain properties of
the certificate, and then click the Details tab.
The selected certificate does not have a subject
name. Select a certificate with a subject name.
or
The selected certificate does not contain a
subject name.
The certificate that you selected does not have
a value in the Subject field. The Subject field is
required to configure DirectAccess clients with
an HTTPS-based URL of the IP-HTTPS server
(the DirectAccess server).
The selected certificate does not have Server
Authentication Enhanced Key Usage enabled.
The certificate that you selected does not have
the Server Authentication object identifier (OID)
in the Enhanced Key Usage (EKU) field. The
Server Authentication OID is required by the
DirectAccess server to perform HTTPS-based
authentications as the IP-HTTPS server. Select
a certificate with a Server Authentication OID or
obtain a new certificate with a Server
Authentication OID. To see the value of the
EKU field, use the Certificates snap-in for the
213
Error message Error condition and the steps to correct
local computer store, obtain properties of the
certificate, and then click the Details tab.
Unable to resolve the subject name of the
certificate to a valid Internet Protocol (IP)
address.
The DirectAccess Setup Wizard cannot resolve
the fully qualified domain name (FQDN) in the
Subject field of the selected certificate. Select a
certificate with a resolvable FQDN in the
Subject field or obtain a new certificate with a
resolvable FQDN.
Step 3-Infrastructure ServersStep 3 of the DirectAccess Setup Wizard has the following pages:
Location
DNS and Domain Controller
Management
The following topics describe the most typical problems encountered on the Location and DNS
and Domain Controller pages.
Location pageOn the Location page, you specify the HTTPS-based URL of the network location server or you
specify that the DirectAccess server is the network location server and the certificate to use for
HTTPS authentication.
For the HTTPS-based URL of the network location server, ensure the following:
You are specifying an HTTPS-based URL, rather than a Hypertext Transfer Protocol (HTTP)-
based URL.
The URL is valid and can be reached from the DirectAccess server. To test reachability, click
Verify or type the URL in your Web browser on the DirectAccess server. You should be able
to view the Web page with no errors in the certificate authentication.
If you are using an IP address in the FQDN portion of the URL, it must be an IPv6 address
and it must be reachable by the DirectAccess server over IPv6.
If you have selected the DirectAccess server as the network location server, you might see the
message The IP and Domain Restrictions role service of the Web Server (IIS) role must be
installed for network location to work properly on the DirectAccess server. Install this role
service and try again. The IP and Domain Restrictions role service prevents DirectAccess
clients on the Internet from reaching the network location URL on the DirectAccess server.
Additionally, you cannot select the certificate that you are using for IP-HTTPS as the network
location server certificate. Select another certificate or obtain an additional certificate with the
214
Server Authentication OID. For more information about the network location certificate
requirements, see Design Your PKI for DirectAccess.
DNS and Domain Controller pageOn the DNS and Domain Controller page, you configure the rules in the Name Resolution Policy
Table (NRPT) of DirectAccess clients. The DirectAccess Setup Wizard automatically creates
default rules based on the configuration of the DirectAccess server. When you add new NRPT
namespace rules, you must specify a namespace (with a leading period) and the IPv4 or IPv6
addresses of the DNS servers. When you add new NRPT exemption rules, you must specify the
FQDN.
When configuring NRPT rules, ensure that:
You are using a valid DNS suffix or FQDN.
The FQDN for an exemption rule can be resolved to its IPv4 or IPv6 address. To test this, try
to ping the name in a Command Prompt window.
When configuring the IP addresses for DNS servers, ensure the following:
They are not duplicated for a rule.
That the DNS server is available on the network and is responding to DNS queries. To test
this, use the nslookup IntranetName DNSServerIPAddress command in a Command Prompt
window.
Step 4-Application ServersThe most common problem in this step is the error message You must have at least one
computer object, or the corresponding IP address, in the selected security groups. Select a
security group that contains at least one member.
Fixing Problems Encountered when Applying the Settings of the DirectAccess Setup Wizard
When you click Apply from the DirectAccess Review dialog box, the DirectAccess Server Setup
Wizard configures the DirectAccess server and a set of Group Policy objects and their settings.
The following table lists the most common types of error messages that you might encounter
during this step.
Error message Error condition and the steps to correct
Registration of Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP) in Domain Name
The DirectAccess server computer does not
have the privileges to use DNS dynamic update
215
Error message Error condition and the steps to correct
System (DNS) failed. to create an Address (A) record in its DNS
server for the name ISATAP. This most
commonly occurs when using a DNS server
that is not running Windows. Configure the
appropriate privileges or permissions so that
the DirectAccess server computer can create
this A record.
Membership in the local Administrators group,
or equivalent, is the minimum required to
complete this operation.
You must log on to the DirectAccess server
computer with a user account that has local
administrator privileges.
DirectAccess server configuration failed
because the IP-HTTPS interface cannot be
configured.
The IP-HTTPS interface is not active. Use the
netsh interface httpstunnel show interfaces
command to display the state of the IP-HTTPS
interface.
DirectAccess server configuration failed
because the 6to4 interface is not operational.
The 6to4 service is not active. Use the netsh
interface 6to4 show state command to display
the state of the 6to4 service. If needed, start the
6to4 service with the netsh interface 6to4 set
state enabled command.
DirectAccess server configuration failed
because the Teredo interface is not operational.
The Teredo service is not active. Use the netsh
interface teredo show state command to
display the state of the Teredo service. If
needed, start the Teredo service with the netsh
interface teredo set state default command.
If you see the DirectAccess server configuration failed. message, ensure that the Internet and
intranet interfaces have been configured with different connection-specific DNS suffixes. The
connection-specific DNS suffix of the intranet interface should be the DNS suffix of the Active
Directory domain of the DirectAccess server. A specific DNS suffix for the Internet interface is not
needed, but it must be different than the DNS suffix of the intranet interface.
If you see the DirectAccess server configuration failed. message, see the %SystemRoot%\
Tracing\DASetup.log file for additional information about events and errors encountered by the
DirectAccess Setup Wizard. For example, if the DirectAccess server cannot register the IPv6
Address (AAAA) record for corpConnectivityHost.DomainName and the IPv6 address of ::1 with a
DNS server that is not running Windows, the DirectAccess Setup Wizard displays the
DirectAccess server configuration failed. message
216
Problems with DirectAccess Connections
The problems with DirectAccess connections typically fall in the following categories:
Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server
over the Internet
Fixing Issues with Connecting to an Intranet Resource
Fixing Issues with Connecting to an Intranet Resource
Fixing Problems with Creating Protected Connections to an Intranet Resource
Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server over the Internet
The typical problems with connectivity issues between the DirectAccess client and the
DirectAccess server over the Internet are the following:
Cannot Reach the DirectAccess Server from the IPv6 Internet
Cannot Reach the DirectAccess Server with 6to4
Cannot Reach the DirectAccess Server with Teredo
Cannot Reach the DirectAccess Server with IP-HTTPS
DirectAccess Client Connection is Slow
Cannot Reach the DirectAccess Server from the IPv6 Internet
If the DirectAccess client is on the Internet Protocol version 6 (IPv6) Internet (it has been
assigned a globally routable IPv6 address by the local Internet service provider), it can reach the
DirectAccess server in the following ways:
If the DirectAccess server is also on the IPv6 Internet, the routing infrastructure of the IPv6
Internet forwards IPv6 traffic directly to the DirectAccess server (IPv6 reachability end-to-
end).
If the DirectAccess server is on the Internet Protocol version 4 (IPv4) Internet and using 6to4,
the routing infrastructure of the IPv6 Internet forwards the traffic to a 6to4 relay, which
forwards the encapsulated IPv6 traffic across the IPv4 Internet to the DirectAccess server
(IPv6 reachability from DirectAccess client to the 6to4 relay, IPv4-encapsulated IPv6
reachability from the 6to4 relay to the DirectAccess server).
217
In either case, there must be a routing path between the DirectAccess client and server that
allows the following types of IPv6 traffic:
Internet Control Message Protocol for IPv6 (ICMPv6) (IPv6 Next Header value of 58)
Internet Key Exchange (IKE)/Authenticating Internet Protocol (AuthIP) (User Datagram
Protocol [UDP] port 500)
Internet Protocol security (IPsec) Encapsulating Security Protocol (ESP) (IPv6 Next Header
value of 50)
To ensure that your DirectAccess server is on the IPv6 Internet, run the ipconfig command at a
Command Prompt. There should be an IPv6 address assigned to your network adapter that starts
with 2 or 3 but is not based on the 2002::/16 or 2001:0::/32 prefixes.
1. On the DirectAccess client, start a command prompt as an administrator.
2. From the Command Prompt window, run the netsh advfirewall set store
gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}”
command.
3. From the Command Prompt window, run the netsh advfirewall consec show rule
name=”DirectAccess Policy-ClientToDnsDc” command.
4. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint.
This is the IPv6 address of the DirectAccess server for the infrastructure tunnel.
If you cannot reach this IPv6 address, use the tracert –d IPv6Address command to trace
the route to the destination.
5. From the Command Prompt window, run the netsh advfirewall consec show rule
name=”DirectAccess Policy-ClientToCorp” command.
6. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint.
This is the IPv6 address of the DirectAccess server for the intranet tunnel.
If you cannot reach this IPv6 address, use the tracert –d IPv6Address command to trace
the route to the destination.
Cannot Reach the DirectAccess Server with 6to4
If the DirectAccess client is on the Internet Protocol version 4 (IPv4) Internet, is not on the
Internet Protocol version 6 (IPv6) Internet, and has a public IPv4 address assigned to a local area
network (LAN) or wireless LAN interface, the DirectAccess client attempts to use 6to4 to
encapsulate IPv6 traffic sent to the DirectAccess server.
To troubleshoot connectivity from a DirectAccess client on the IPv6 Internet to the DirectAccess server
218
If the DirectAccess server is on the IPv4 Internet (the DirectAccess tunnel endpoints are 6to4
addresses that have the form 2002:WWXX:YYZZ::WWXX:YYZZ, where WWXX:YYZZ is the
colon hexadecimal representation of w.x.y.z, a public IPv4 address), the DirectAccess client
encapsulates IPv6 traffic directly to the DirectAccess server. If the DirectAccess server is only on
the IPv6 Internet (the DirectAccess tunnel endpoints are not 6to4 addresses), the DirectAccess
client encapsulates IPv6 traffic and sends it to a 6to4 relay. The 6to4 relay then forwards the
native IPv6 traffic across the IPv6 Internet to the DirectAccess server.
On the IPv4 Internet, there must be a routing path between the DirectAccess client and server
that allows IPv4 protocol 41 traffic. If the traffic is also traveling on the IPv6 Internet, there must
be a routing path between the DirectAccess client and server that allows the following types of
traffic:
Internet Control Message Protocol for IPv6 (ICMPv6) (IPv6 Next Header value of 58)
Internet Key Exchange (IKE)/Authenticating Internet Protocol (AuthIP) (User Datagram
Protocol [UDP] port 500)
Internet Protocol security (IPsec) Encapsulating Security Protocol (ESP) (IPv6 Next Header
value of 50)
6to4 addresses can also take the form 2002:WWXX:YYZZ:SubnetID:InterfaceID. In this
form, 6to4 is being used to generate a 48-bit global IPv6 address prefix based on a public
IPv4 address (w.x.y.z). When 6to4 is used this way, hosts use the 6to4-derived address
prefix for native IPv6 addressing and the 6to4-based address is assigned to a LAN
interface, not the Tunnel Adapter 6TO4 Adapter. This type of 6to4-based addressing can
be used on an intranet or used for native IPv6 addressing of a single-subnet home or
small office network, in which the local Internet router is providing 6to4 router
functionality.
1. On the DirectAccess client, start a command prompt as an administrator.
2. From the Command Prompt window, run the reg query HKLM\SYSTEM\
CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command.
If the DisabledComponents registry value is present, the command displays its value. If
the DisabledComponents registry value is not present, the command displays ERROR:
The system was unable to find the specified registry key or value.
If DisabledComponents is present and it is not 0, convert it to a binary number. If the first
or second bit from the right in the binary number is 1, DisabledComponents has disabled
6to4. You must change the first and second bit from the right to 0 to enable 6to4.
3. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\
Microsoft\Windows\TCPIP\v6Transition /v 6to4_RouterName command.
This command should display the first consecutive public IPv4 address of the
DirectAccess server’s Internet interface.
4. From the Command Prompt window, run the netsh interface 6to4 show relay
command.
Note To verify 6to4 functionality and configuration on a DirectAccess client
219
This command should display the first consecutive public IPv4 address of the
DirectAccess server’s Internet interface in Relay Name.
5. From the Command Prompt window, run the netsh interface 6to4 show state
command.
This command should display default or enabled in 6to4 Service State.
The 6to4 service state should not show disabled. A value of disabled means that the
DirectAccess client will never bring up a 6to4 interface. A value of default means that the
DirectAccess client will bring up a 6to4 interface if it does not have a global IPv6 address
assigned already and it has a public IPv4 address. A value of enabled means that the
DirectAccess client will bring up a 6to4 interface whenever it has a public IPv4 address
assigned.
6. From the Command Prompt window, run the netsh advfirewall set store
gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}”
command.
7. From the Command Prompt window, run the netsh advfirewall consec show rule
name=”DirectAccess Policy-ClientToDnsDc” command.
8. From the Command Prompt window, note the IPv6 address in RemoteTunnelEndpoint.
9. From the Command Prompt window, run the route print command.
The IPv6 route table should have ::/0 route with the Gateway address set to the IPv6
address in step 8. The IPv6 route table should also have 2002::/16 route with the
Gateway address set to On-link.
1. On the DirectAccess server, start a command prompt as an administrator.
2. From the Command Prompt window, run the ipconfig command.
This command should display a interface named Tunnel adapter 6TO4 Adapter that has
the Domain Name System (DNS) suffix configured on the Internet interface and with two
IPv6 addresses of the form 2002:WWXX:YYZZ::WWXX:YYZZ, corresponding to the two
consecutive IPv4 addresses assigned to the Internet interface.
3. From the Command Prompt window, run the reg query HKLM\SYSTEM\
CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command.
If the DisabledComponents registry value is present, the command displays its value. If
the DisabledComponents registry value is not present, the command displays ERROR:
The system was unable to find the specified registry key or value.
If DisabledComponents is present and it is not 0, convert it to a binary number. If the first
or second bit from the right in the binary number is 1, DisabledComponents has disabled
6to4. You must change the first and second bit from the right to 0 to enable 6to4.
4. From the Command Prompt window, run the netsh interface 6to4 show state
command.
This command should display enabled in 6to4 Service State. The 6to4 service state
To verify 6to4 functionality and configuration on the DirectAccess server
220
should not show disabled. A value of disabled means that the DirectAccess server will
never bring up a 6to4 interface. A value of default means that the DirectAccess server
will bring up a 6to4 interface if it does not have a global IPv6 address assigned already
and it has a public IPv4 address. A value of enabled means that the DirectAccess server
will bring up a 6to4 interface whenever it has a public IPv4 address assigned.
5. From the Command Prompt window, run the route print command.
The IPv6 route table should have 2002::/16 route with the interface index of the Microsoft
6to4 Adapter and the Gateway address set to On-link.
1. On the DirectAccess client, start a command prompt as an administrator.
2. From the Command Prompt window, run the netsh interface 6to4 show relay
command.
This command should display the first consecutive public IPv4 address of the
DirectAccess server’s Internet interface in Relay Name.
3. From the Command Prompt window, ping the IPv4 address from step 2.
This step ensures that the DirectAccess client can reach the first public IPv4 address of
the DirectAccess server.
4. From the Command Prompt window, ping the next consecutive IPv4 address from step 2.
This step ensures that the DirectAccess can reach the second public IPv4 address of the
DirectAccess server.
5. From the Command Prompt window, run the netsh advfirewall set store
gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}”
command.
6. From the Command Prompt window, run the netsh advfirewall consec show rule
name=”DirectAccess Policy-ClientToDnsDc” command.
7. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint.
This is the IPv6 address of the DirectAccess server for the infrastructure tunnel.
If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the
tracert –d IPv6Address command to trace the route to the destination.
8. From the Command Prompt window, run the netsh advfirewall consec show rule
name=”DirectAccess Policy-ClientToCorp” command.
9. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint.
This is the IPv6 address of the DirectAccess server for the intranet tunnel.
If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the
tracert –d IPv6Address command to trace the route to the destination.
To troubleshoot connectivity from a 6to4-based DirectAccess client on the IPv4 Internet to the DirectAccess server
221
Cannot Reach the DirectAccess Server with Teredo
If the DirectAccess client is on the Internet Protocol version 4 (IPv4) Internet, is not on the
Internet Protocol version 6 (IPv6) Internet, and has a private IPv4 address assigned to a local
area network (LAN) interface, the DirectAccess client attempts to use Teredo to encapsulate IPv6
traffic sent to the DirectAccess server.
If the DirectAccess server is on the IPv4 Internet (the DirectAccess tunnel endpoints are 6to4
addresses that have the form 2002:WWXX:YYZZ::WWXX:YYZZ, where WWXX:YYZZ is the
colon hexadecimal representation of w.x.y.z, a public IPv4 address), the DirectAccess client
encapsulates IPv6 traffic directly to the DirectAccess server. If the DirectAccess server is only on
the IPv6 Internet (the DirectAccess tunnel endpoints are not 6to4 addresses), the DirectAccess
client encapsulates IPv6 traffic and sends it to a Teredo relay. The Teredo relay then forwards the
native IPv6 traffic across the IPv6 Internet to the DirectAccess server.
On the IPv4 Internet, there must be a routing path between the DirectAccess client and server
that allows User Datagram Protocol (UDP) destination port 3544 traffic for Teredo-encapsulated
traffic to the DirectAccess server and UDP source port 3544 traffic for Teredo-encapsulated traffic
from the DirectAccess server.
If the traffic is also traveling on the IPv6 Internet, there must be a routing path between the
DirectAccess client and server that allows the following types of traffic:
Internet Control Message Protocol for IPv6 (ICMPv6) (IPv6 Next Header value of 58)
Internet Key Exchange (IKE)/Authenticating Internet Protocol (AuthIP) (User Datagram
Protocol [UDP] port 500)
Internet Protocol security (IPsec) Encapsulating Security Protocol (ESP) (IPv6 Next Header
value of 50)
1. On the DirectAccess client, start a command prompt as an administrator.
2. From the Command Prompt window, run the ipconfig command.
You should see a Tunnel adapter Teredo Tunneling Pseudo-Interface with an IPv6
address that begins with 2001.
3. From the Command Prompt window, run the route print command.
The IPv6 route table should have a ::/0 route with the interface index of the Microsoft
Teredo Tunnel Adapter and the Gateway address set to On-link.
4. From the Command Prompt window, run the reg query HKLM\SYSTEM\
CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command.
If the DisabledComponents registry value is present, the command displays its value. If
the DisabledComponents registry value is not present, the command displays ERROR:
The system was unable to find the specified registry key or value.
If DisabledComponents is present and it is not 0, convert it to a binary number. If the first
To verify Teredo functionality and configuration on a DirectAccess client
222
or fourth bit from the right in the binary number is 1, DisabledComponents has disabled
Teredo. You must change the first and fourth bit from the right to 0 to enable Teredo.
5. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\
Microsoft\Windows\TCPIP\v6Transition /v Teredo_ServerName command.
This command should display the first consecutive public IPv4 address of the
DirectAccess server’s Internet interface.
6. From the Command Prompt window, run the netsh interface teredo show state
command.
This command should display enterpriseclient or client in Type and the first
consecutive public IPv4 address of the DirectAccess server’s Internet interface in Server
Name. See the following table for information about the Teredo client state.
Teredo state Description
qualified The Teredo tunnel interface has completed its
negotiation with the Teredo server and has
been used recently.
dormant The Teredo tunnel interface has completed its
negotiation with the Teredo server but has not
been used recently.
probe The Teredo tunnel interface has completed its
negotiation with the Teredo server.
offline An error or other condition has occurred and
the Teredo interface is not active.
If the Teredo state is offline and the error state is Teredo server is unreachable over UDP, UDP
port 3544 traffic may be blocked somewhere between the DirectAccess client and the
DirectAccess server due to the following:
A third-party host firewall that is running on the DirectAccess client.
An intermediate router or network firewall between the DirectAccess client and the
DirectAccess server. It is a common practice in organizations to block unexpected UDP traffic
with their Internet firewalls.
Another possibility is that the DirectAccess server is not available.
If the Teredo state is offline and the error state is Client is in a managed network, the
DirectAccess client has detected a local Active Directory domain. In this case, the Teredo client
will not bring up the Teredo tunnel adapter unless the Teredo client has been configured as an
enterprise client. You can view the Teredo client type from the netsh interface teredo show
state command. If set to client, a reachable domain controller will prevent Teredo from becoming
active. If it set to enterpriseclient, Teredo will be active even when a domain controller is
reachable. You can change a Teredo client from client to enterpriseclient with the Computer
223
Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition
Technologies\Teredo State setting of the Group Policy object for DirectAccess clients or for an
individual DirectAccess client with the netsh interface teredo set state enterpriseclient
command.
1. On the DirectAccess server, start a command prompt as an administrator.
2. From the Command Prompt window, run the route print command.
The IPv6 route table should have a 2001::/32 route with the interface index of the Teredo
Tunneling Pseudo-Interface and the Gateway address set to On-link.
3. From the Command Prompt window, run the reg query HKLM\SYSTEM\
CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command.
If the DisabledComponents registry value is present, the command displays its value. If
the DisabledComponents registry value is not present, the command displays ERROR:
The system was unable to find the specified registry key or value.
If DisabledComponents is present and it is not 0, convert it to a binary number. If the first
or fourth bit from the right in the binary number is 1, DisabledComponents has disabled
Teredo. You must change the first and fourth bit from the right to 0 to enable Teredo.
4. From the Command Prompt window, run the netsh interface teredo show state
command.
This command should display server in Type and online in State.
1. On the DirectAccess client, start a command prompt as an administrator.
2. From the Command Prompt window, run the netsh interface teredo show state
command.
This command should display the first consecutive public IPv4 address of the
DirectAccess server’s Internet interface in Server Name.
3. From the Command Prompt window, ping the IPv4 address from step 2. If there is a
name in Server Name instead of an address, ping the name and ensure that it resolves
to the first consecutive public IPv4 address of the DirectAccess server’s Internet
interface.
This step ensures that the DirectAccess can reach the first public IPv4 address of the
DirectAccess server.
4. From the Command Prompt window, ping the next consecutive IPv4 address from step 2.
This step ensures that the DirectAccess can reach the second public IPv4 address of the
DirectAccess server.
5. From the Command Prompt window, run the netsh advfirewall set store
gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}”
command.
To verify Teredo functionality and configuration on the DirectAccess serverTo troubleshoot connectivity from a Teredo-based DirectAccess client on the IPv4 Internet to the DirectAccess server
224
6. From the Command Prompt window, run the netsh advfirewall consec show rule
name=”DirectAccess Policy-ClientToDnsDc” command.
7. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint.
This is the IPv6 address of the DirectAccess server for the infrastructure tunnel.
If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the
tracert –d IPv6Address command to trace the route to the destination.
8. From the Command Prompt window, run the netsh advfirewall consec show rule
name=”DirectAccess Policy-ClientToCorp” command.
9. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint.
This is the IPv6 address of the DirectAccess server for the intranet tunnel.
If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the
tracert –d IPv6Address command to trace the route to the destination.
Cannot Reach the DirectAccess Server with IP-HTTPS
A DirectAccess client on the Internet that has a private Internet Protocol version 4 (IPv4) address
attempts to use Teredo to obtain Internet Protocol version 6 (IPv6) connectivity to the
DirectAccess server. However, private networks can block Teredo traffic because they only allow
very specific types of Internet traffic, such as Domain Name System (DNS), Hypertext Transfer
Protocol (HTTP), and Secure Hypertext Transfer Protocol (HTTPS). In this case, the Teredo client
on the DirectAccess client cannot communicate with its Teredo server to obtain a Teredo-based
IPv6 address.
To provide IPv6 connectivity in this case and other situations where Teredo traffic is not
forwarded, DirectAccess attempts to use Internet Protocol over Secure Hypertext Transfer
Protocol (IP-HTTPS), in which IPv6 packets are sent over an IPv4-based HTTPS session. Since
most private firewalls and Web proxies forward HTTPS traffic, IP-HTTPS provides IPv6
connectivity in these restrictive networking environments.
The DirectAccess client obtains a 64-bit IPv6 address prefix by performing a router discovery
exchange with the DirectAccess server acting as the IP-HTTPS server. The IPv6 address prefix is
either automatically created by the DirectAccess Setup Wizard or specified in the Prefix
Configuration page of step 2.
On the IPv4 Internet, there must be a routing path between the DirectAccess client and server
that allows Transmission Control Protocol (TCP) destination port 433 traffic for HTTPS-
encapsulated traffic to the DirectAccess server and TCP source port 433 traffic for HTTPS-
encapsulated traffic from the DirectAccess server.
1. On the DirectAccess client, start a command prompt as an administrator.
To verify IP-HTTPS functionality and configuration on a DirectAccess client
225
2. From the Command Prompt window, run the reg query HKLM\SYSTEM\
CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command.
If the DisabledComponents registry value is present, the command displays its value. If
the DisabledComponents registry value is not present, the command displays ERROR:
The system was unable to find the specified registry key or value.
If DisabledComponents is present and it is not 0, convert it to a binary number. If the first
bit from the right in the binary number is 1, DisabledComponents has disabled IP-HTTPS.
You must change the first bit from the right to 0 to enable IP-HTTPS.
3. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\
Microsoft\Windows\TCPIP\v6Transition\iphttps\iphttpsinterface /v /s command.
This command should display IP-HTTPS client state setting and the IP-HTTPS uniform
resource locator (URL). If IPHTTPS_ClientState is set to 3, IP-HTTPS is disabled. From
the Command Prompt window, run the netsh interface httpstunnel set interface
state=enabled command.
4. From the Command Prompt window, run the netsh interface httpstunnel show
interfaces command.
This command should display client in Role and the IP-HTTPS URL from step 3 in URL.
1. On the DirectAccess server, start a command prompt as an administrator.
2. From the Command Prompt window, run the reg query HKLM\SYSTEM\
CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command.
If the DisabledComponents registry value is present, the command displays its value. If
the DisabledComponents registry value is not present, the command displays ERROR:
The system was unable to find the specified registry key or value.
If DisabledComponents is present and it is not 0, convert it to a binary number. If the first
bit from the right in the binary number is 1, DisabledComponents has disabled IP-HTTPS.
You must change the first bit from the right to 0 to enable IP-HTTPS.
3. From the Command Prompt window, run the netsh interface httpstunnel show
interfaces command.
This command should display server in Role, the IP-HTTPS URL in URL, and IPHTTPS
interface active in Interface Status.
1. On the DirectAccess client, open an Internet browser and ensure that you can access
Internet locations.
A DirectAccess client behind a captive portal that requires you to login or provide billing
information can initially prevent an IP-HTTPS-based DirectAccess connection. After you
have access to the Internet, try to access an intranet resource.
2. Start a command prompt as an administrator.
3. From the Command Prompt window, run the ipconfig command.
To verify IP-HTTPS functionality and configuration on the DirectAccess serverTo troubleshoot connectivity from an IP-HTTPS-based DirectAccess client on the IPv4 Internet to the DirectAccess server
226
Check the configuration of the Tunnel adapter iphttpsinterface. If IP-HTTPS is being
used, there should be an IPv6 address assigned. If there is no IPv6 address assigned,
look at the other interfaces for a global IPv6 address (one beginning with 2 or 3). If there
is an interface with a public IPv4 address, IP-HTTPS will not be used.
4. From the Command Prompt window, run the netsh interface httpstunnel show
interfaces command.
This command displays the IP-HTTPS URL in URL.
5. From the Command Prompt window, ping the fully qualified domain name (FQDN) from
the URL in step 3.
This ensures that the DirectAccess client can resolve the name of the IP-HTTPS server
in the URL and reach the resolved IPv4 address of the DirectAccess server.
6. Paste the URL from step 3 into your Internet browser and attempt to access it.
Ensure that the IP-HTTPS web site is accessible and has no certificate errors. If there are
certificate errors, see the To troubleshoot certificate problems for an IP-HTTPS-
based connection to the DirectAccess server procedure in this topic.
7. From the Command Prompt window, run the netsh advfirewall set store
gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}”
command.
8. From the Command Prompt window, run the netsh advfirewall consec show rule
name=”DirectAccess Policy-ClientToDnsDc” command.
9. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint.
This is the IPv6 address of the DirectAccess server for the infrastructure tunnel.
If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the
tracert –d IPv6Address command to trace the route to the destination.
10. From the Command Prompt window, run the netsh advfirewall consec show rule
name=”DirectAccess Policy-ClientToCorp” command.
11. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint.
This is the IPv6 address of the DirectAccess server for the intranet tunnel.
If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the
tracert –d IPv6Address command to trace the route to the destination.
1. Ensure that the FQDN in the IP-HTTPS URL matches the Subject field of the IP-HTTPS
certificate on the DirectAccess server.
If not, you need to either select the correct certificate on the DirectAccess server or install
a certificate that can be used for IP-HTTPS connections. For information about IP-HTTPS
certificate requirements, see Design Your PKI for DirectAccess.
2. Using the Certificates snap-in to view the properties of the IP-HTTPS certificate on the
DirectAccess server, determine the Internet certificate revocation list (CRL) distribution
point locations for the IP-HTTPS certificate (the URL without the file name).
To troubleshoot certificate problems for an IP-HTTPS-based connection to the DirectAccess server
227
3. From a Command Prompt window on the DirectAccess client, ping the FQDN from the
CRL distribution point location in step 2.
This step ensures that the DirectAccess client can resolve the name of the CRL
distribution point server location and reach the resolved address.
4. Type the Internet CRL distribution point from step 2 into your Internet browser. You should
see a series of files with the .crl extension. Ensure that you can open the .crl files.
If you cannot reach the CRL distribution point and open the .crl files from the
DirectAccess client, you cannot use IP-HTTPS.
5. Perform certificate troubleshooting on the DirectAccess client and server to ensure that
the DirectAccess client can successfully validate the IP-HTTPS certificate of the
DirectAccess server and the DirectAccess server can successfully validate the IP-HTTPS
certificate of the DirectAccess client.
IP-HTTPS and authenticating proxiesIP-HTTPS does not support proxy servers that require authentication with each connection, which
might cause problems with IP-HTTPS connections. To determine if you are behind this type of
proxy, open your Internet browser and browse a public Web site. You might be prompted for
authentication. Open a second Internet browser window or tab and browse a different public Web
site. If you can get to the second Web site without having to specify authentication credentials, IP-
HTTPS should work across the proxy. If you need to enter credentials each time you access a
different Web site, IP-HTTPS might be blocked.
DirectAccess Client Connection is Slow
DirectAccess performance is dependent on many factors such as the speed of the DirectAccess
client’s connection to the Internet, Internet latency and congestion between the DirectAccess
client and server, and the current load on the DirectAccess server. Another reason might be the
type of Internet Protocol version 6 (IPv6) encapsulation being used over the Internet Protocol
version 4 (IPv4) Internet. 6to4 and Teredo tend to have higher performance because the
encapsulation is simpler to process. Internet Protocol over Secure Hypertext Transfer Protocol
(IP-HTTPS) tends to have lower performance because of the higher protocol overhead and the
additional Secure Hypertext Transfer Protocol (HTTPS)-based encryption and decryption. When
examining performance issues, one of the first places to look is the display of the ipconfig
command on the DirectAccess server, which indicates the type of encapsulation based on the
interface that has a global IPv6 address assigned.
A DirectAccess client on a private IPv4 network behind a network address translator (NAT) must
connect to the DirectAccess server using either Teredo or IP-HTTPS. Each of these transition
technologies requires particular types of traffic between the DirectAccess client and the
DirectAccess server:
228
Teredo requires IPv4 and User Datagram Protocol (UDP) destination port 3544 for traffic to
the two public IPv4 addresses of the Teredo server and relay (the DirectAccess server). The
Teredo relay requires Internet Control Message Protocol for IPv6 (ICMPv6) Echo Request
and Echo Reply messages to be allowed for all intranet destinations, including the
DirectAccess server.
IP-HTTPS requires IPv4 and Transmission Control Protocol (TCP) destination port 443 traffic
between the DirectAccess client and the first consecutive public IPv4 address of the
DirectAccess server.
The DirectAccess client needs to determine which of these two transition technologies to use. IP-
HTTPS and Teredo both attempt qualification of their interface state at the same time. If the
Teredo interface is qualified, the IP-HTTPS client waits in an offline state for a computed delay for
the DirectAccess client to detect corporate connectivity. The computed delay is either ten seconds
or a network delay larger than ten seconds based on the round trip time of TCP packets from the
client to the public IPv4 address of the DirectAccess server. If the DirectAccess client detects
corporate connectivity within this network delay, the IP-HTTPS client will remain in an offline
state. If the DirectAccess client does not detect corporate connectivity within this network delay,
the IP-HTTPS client will attempt to qualify again.
Using IP-HTTPS for DirectAccess connectivity has higher overhead and lower performance than
Teredo. If the DirectAccess client is using IP-HTTPS instead of Teredo, the DirectAccess client
will have a lower performance connection.
However, due to network timing issues, it is possible for the DirectAccess client to have both
Teredo and IP-HTTPS interfaces active, but use only the IP-HTTPS interface for traffic to the
intranet. This condition occurs when the DirectAccess client takes more than the computed delay
for the DirectAccess client to determine corporate connectivity over the Teredo interface. To test
for this condition, run the ipconfig command at a command prompt. If you have global addresses
on both the Teredo and IP-HTTPS tunnel interfaces, this condition has occurred.
Fixing Issues with Creating Protected Connections to the DirectAccess Server
For the full intranet or selected server access models, DirectAccess clients create the following
Internet Protocol security (IPsec) tunnels to Internet Protocol version 6 (IPv6) addresses assigned
to the DirectAccess server:
The infrastructure tunnel that provides access to domain controllers, intranet Domain Name
System (DNS) servers, and other infrastructure servers needed by the computer before the
user has logged on.
The intranet tunnel that provides access to the entire intranet, which is available after the user
has logged on.
To troubleshoot the IPsec security associations (SAs) that the DirectAccess client and server
negotiate to establish these protected tunnels, see the following topics:
229
DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server
DirectAccess Client Cannot Resolve Names with Intranet DNS Servers
If you have specified management servers in Step 3 of the DirectAccess Wizard, there is an
additional management tunnel that is typically initiated by a management server on the intranet.
For more information, see Intranet Management Server Cannot Connect to a DirectAccess Client.
DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server
A DirectAccess client that has determined that it is not on the intranet will have effective
DirectAccess-based rules in its Name Resolution Policy Table (NRPT). These rules instruct the
DirectAccess client to send Domain Name System (DNS) queries that match the intranet
namespace to an intranet DNS server. When the DirectAccess client attempts to find a domain
controller, it must resolve names for which the DNS suffix matches the intranet namespace and a
corresponding rule in the effective NRPT. But before a DNS query can be sent to the intranet
DNS server, the infrastructure tunnel must be established.
After the infrastructure tunnel is successfully established, the DirectAccess client sends the DNS
query to locate a domain controller. The DirectAccess client then connects to the domain
controller, performs a computer-based domain logon, and connects to other infrastructure servers
as needed to perform computer-based start-up functions, such as performing a health evaluation
and obtaining a health certificate with Network Access Protection (NAP).
When the user logs on to the computer and a process in the context of the user account attempts
to access an intranet resource by its Internet Protocol version 6 (IPv6) address, the DirectAccess
client establishes the intranet tunnel.
For both tunnels, success of the Internet Protocol security (IPsec) tunnel mode security
associations (SAs) depends on the connection security rules configured on DirectAccess clients
and the DirectAccess server. These rules consist of a variety of settings for the following:
The source or destination IPv6 addresses or address prefixes for which IPsec tunnel mode is
required.
The tunnel endpoints (the IPv6 addresses of the DirectAccess server).
The authentication methods required to successfully authenticate both IPsec peers (the
DirectAccess client and server).
For the infrastructure tunnel, the authentication methods are computer certificate and
UserNTLM (using the computer’s computer account credentials).
For the intranet tunnel, the authentication methods are computer certificate and UserKerb
(using the user’s user account credentials).
The encryption and data integrity methods.
The DirectAccess Setup Wizard configures a compatible set of connection security rules for the
DirectAccess server and DirectAccess clients that should result in a successful negotiation of
230
IPsec SAs for both tunnels, provided the DirectAccess client and server have certificates installed
in their computer store that can be used for IPsec and validated by both IPsec peers.
If the DirectAccess client cannot successfully negotiate the two tunnels, it cannot connect to
resources on the intranet.
1. On the DirectAccess client, start a command prompt as an administrator.
2. On the DirectAccess client, click Start, type wf.msc, and then press ENTER.
3. In the tree pane of the Windows Firewall with Advanced Security snap-in console, click
Connection Security Rules.
In the details pane, you should see connection security rules whose names begin with
DirectAccess Policy. If not, this DirectAccess client has not received its connection
security rules from computer configuration Group Policy. Verify that the DirectAccess
client is running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows
Server 2008 R2 and is a member of one of the security groups specified in step 1 of the
DirectAccess Setup Wizard.
4. In the tree pane of the Windows Firewall with Advanced Security snap-in console, open
Monitoring\Connection Security Rules.
In the details pane, you should see a list of connection security rules that begin with
DirectAccess Policy, including rules named DirectAccess Policy-ClientToDnsDc and
DirectAccess Policy-ClientCorp.
5. If you do not see these rules, from the Command Prompt window, run the netsh
advfirewall monitor show currentprofile command.
This command displays the attached networks and their determined firewall profiles.
None of your networks should be in the domain profile. If any of your networks has been
assigned the domain profile, determine if you have an active remote access virtual
private network (VPN) connection or a domain controller that is available on the Internet.
6. From the Command Prompt window, run the netsh advfirewall monitor show mmsa
command.
There should be a main mode SA with the Remote IP Address set to the IPv6 address
2002:WWXX:YYZZ::WWXX:YYZZ, in which WWXX:YYZZ is the colon hexadecimal
representation of w.x.y.z, the first public Internet Protocol version 4 (IPv4) address
assigned to the Internet interface of the DirectAccess server. For example, if the first
public IPv4 address is 131.107.0.2, the corresponding 6to4 IPv6 address is
2002:836b:2::836b:2 (836b:2 is the colon-hexadecimal representation for 131.107.0.2).
The main mode SA should also have ComputerCert for Auth1 and UserNTLM for
Auth2.
7. From the Command Prompt window, run the netsh advfirewall monitor show qmsa
command.
There should be a quick mode SA with the Remote IP Address set to the IPv6 address
To verify whether the DirectAccess client can successfully create the infrastructure tunnel
231
2002:WWXX:YYZZ::WWXX:YYZZ, corresponding to the first public IPv4 address
assigned to the Internet interface of the DirectAccess server.
If the DirectAccess client computer cannot establish the main and quick mode SAs for the
infrastructure tunnel using the default connection security rules created by the DirectAccess
Setup Wizard, the most likely problem is a certificate authentication failure. For more information,
see the “IKE certificate selection process” and “IKE certificate acceptance process” sections of
Public Key Certificate.
You can view the certificates in the local computer store on the DirectAccess client and server
with the Certificates snap-in.
To ensure that the DirectAccess server can access a domain controller to validate the credentials
of the DirectAccess client, run the nltest /dsgetdc: /force command at an elevated command
prompt. If there are no domain controllers listed, troubleshoot the lack of discoverability and
connectivity between the DirectAccess server and Active Directory.
Similarly, use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it
has access to a domain controller. If there are no domain controllers listed, ensure that the IPv6-
capable domain controllers that are being used by DirectAccess clients are using site-less locator
records in DNS.
To perform detailed IPsec negotiation analysis, use IPsec audit events in the Windows Logs\
Security event log and network tracing for DirectAccess. For more information, see Event Viewer
and Network Diagnostics and Tracing.
1. On the DirectAccess client, start a command prompt as an administrator.
2. From the Command Prompt window, run the net view \\IntranetFileServer command.
Alternately, use your Internet Web browser to access an intranet uniform resource locator
(URL) or another application to access an intranet resource.
3. From the Command Prompt window, run the netsh advfirewall monitor show mmsa
command.
There should be a main mode SA with the Remote IP Address set to the 6to4 IPv6
address corresponding to the second public IPv4 address assigned to the Internet
interface of the DirectAccess server. For example, if the first public IPv4 address is
131.107.0.3, the corresponding 6to4 IPv6 address is 2002:836b:3::836b:3 (836b:3 is the
colon-hexadecimal notation for 131.107.0.3). The main mode SA should also have
ComputerCert for Auth1 and UserKerb for Auth2.
4. From the Command Prompt window, run the netsh advfirewall monitor show qmsa
command.
There should be a quick mode SA with the Remote IP Address set to the 6to4 IPv6
address corresponding to the second public IPv4 address assigned to the Internet
interface of the DirectAccess server.
If the DirectAccess client computer cannot establish the main and quick mode SAs for the intranet
tunnel using the default connection security rules created by the DirectAccess Setup Wizard, the
To verify whether the DirectAccess client can successfully create the intranet tunnel
232
most likely problem is a certificate authentication failure. For more information, see the “IKE
certificate selection process” and “IKE certificate acceptance process” sections of Public Key
Certificate.
To ensure that the DirectAccess server can access a domain controller to validate the credentials
of the DirectAccess client, run the nltest /dsgetdc: /force command at an elevated command
prompt. If there are no domain controllers listed, troubleshoot the lack of discoverability and
connectivity between the DirectAccess server and Active Directory.
Similarly, use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it
has access to a domain controller. If there are no domain controllers listed, ensure that the IPv6-
capable domain controllers that are being used by DirectAccess clients are using site-less locator
records in DNS.
To perform detailed IPsec negotiation analysis, use IPsec audit events in the Windows Logs\
Security event log and network tracing for DirectAccess. For more information, see Event Viewer
and Network Diagnostics and Tracing.
IPsec and certificate revocation checkingBy default, the DirectAccess client does not perform certificate revocation checking on the
certificates that it receives from IPsec peers for authentication. However, the DirectAccess server
by default performs certificate revocation checking on the certificates that it receives from IPsec
peers with either a weak or strong CRL check.
With weak CRL checking, IPsec will check its local certificate revocation list (CRL) cache for
revoked certificates. If the certificate being examined is in the cache as revoked, authentication
will fail. If it is not listed as revoked in the local CRL cache, authentication will succeed. You can
view the list of CRL files in your local CRL cache with the certutil -URLcache CRL command.
Weak CRL checking is the default configuration of the DirectAccess server.
With strong CRL checking, IPsec will check the certificate for revocation its local CRL cache and
the published CRL distribution points. If the certificate being examined is in the cache as revoked,
is listed in the CRL from the CRL distribution point as revoked, or the CRL distribution point is not
accessible, authentication fails. If strong CRL checking is enabled, obtain the certificate properties
of the computer certificate for the DirectAccess client, examine the CRL Distribution Point field,
and verify that the DirectAccess server can access the CRL from one of the specified CRL
distribution point locations. If the DirectAccess server cannot retrieve the CRL from any of these
locations, all IPsec certificate authentication fails.
If strong or weak CRL checking configured on either the DirectAccess server or client, you can
obtain additional information through the Windows Logs\Security event log. To view the failures
for IPsec in the Windows Logs\Security event log in Event Viewer, you must enable auditing on
the DirectAccess client or server with the auditpol.exe /set /SubCategory:"IPsec Main
Mode","IPsec Extended Mode" /success:enable /failure:enable command.
Look for the following events in the Windows Logs\Security event log:
Event ID 4653: Main Mode: Failed: An IPsec Main Mode Negotiation Failed
233
Event ID 4654: Quick Mode: Failed: An IPsec Quick Mode Negotiation Failed
Event ID 4984: Extended Mode: Failed: An IPsec Extended Mode Negotiation Failed. The
corresponding Main Mode Security Association has been deleted.
Extended Mode failures are typically generated for problems with user authentication for
tunnel mode and for IPsec authorization failures, such as when you are using smart cards for
additional authorization. Event 4984 indicates that the credentials supplied are not authorized
to establish the tunnel to the DirectAccess Server.
NAP health enforcement for the intranet tunnelIf NAP full enforcement mode is configured in the connection security rules for the intranet tunnel
and the DirectAccess client does not receive a health certificate, the DirectAccess client will not
be able to access intranet resources.
The Windows Logs\Security event log will contain an IPsec audit failure. The specific event that
indicates a NAP health failure is the following:
MessageId=13905
SymbolicName=ERROR_IPSEC_IKE_AUTHORIZATION_FAILURE. SA establishment is not
authorized.
To perform additional NAP health evaluation troubleshooting, see Introduction to
Troubleshooting NAP and Fixing Health Certificate Problems in the Network Access
Protection Troubleshooting Guide.
Smart card authorizationIf you are using smart cards for an additional level of authorization and IPsec authentication fails,
the Windows Logs\Security event log will contain IPsec audit failures. For smart card
authorization, the authorization rules on the DirectAccess server require that a DirectAccess
client specify a security identifier (SID) that indicates the user is in possession of a certificate that
qualifies for the "This Organization Certificate" property.
The specific event that indicates a failure to present a smart card-based certificate during the
negotiation of the intranet tunnel is the following:
MessageId=13906
SymbolicName=ERROR_IPSEC_IKE_STRONG_CRED_AUTHORIZATION_FAILURE. SA
establishment is not authorized because of lack of a PKINIT-based credential of sufficient
strength.
NTLM authentication failuresIf there are NTLM authentication errors during authentication (specifically NTLM on the
DirectAccess client fails with NO_AUTHENTICATING_AUTHORITY), there might be a bottleneck
at the DirectAccess server. To increase the number of concurrent authentication calls in progress
234
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.
Detailed analysis of IPsec negotiationIn addition to the events in the Windows Logs\Security event log, you can use Windows Firewall
tracing to capture detailed IPsec negotiation and component interaction information. For more
information, see Network Diagnostics and Tracing.
DirectAccess Client Cannot Resolve Names with Intranet DNS Servers
When a DirectAccess client has determined that it is on the Internet, it uses rules in the Name
Resolution Policy Table (NRPT) to send Domain Name System (DNS) queries for intranet
resources to intranet DNS servers. DirectAccess clients receive NRPT rules through Group
Policy.
1. On the DirectAccess client, start a command prompt as an administrator.
2. From the Command Prompt window, run the netsh namespace show policy command.
This command displays the NRPT rules configured through Group Policy, which are
typically one or more namespace rules (with a leading period) for your intranet
namespace and one or more exemption rules for names that should not be resolvable
while on the Internet (fully qualified domain names [FQDNs] without a leading period for
names such as your network location server). Verify that your entire intranet namespace
is represented by namespace rules. If there are no rules, verify that the DirectAccess
client is running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows
Server 2008 R2, is a member of a security group specified in step 1 of the DirectAccess
Setup Wizard, and has updated its computer configuration Group Policy.
In the DirectAccess-based rules for your intranet namespace, there should be at least
one Internet Protocol version 6 (IPv6) address for DirectAccess (DNS Servers).
3. From the Command Prompt window, run the netsh namespace show effective
command.
This command displays the current effective rules.
If there are no DirectAccess-based rules, the DirectAccess client has determined that it is
on the intranet.
4. From the Command Prompt window, ping the IPv6 addresses of your intranet DNS
To troubleshoot why a DirectAccess client cannot resolve names with an intranet DNS server
235
servers from step 2 or 3.
This ensures that the intranet DNS server is reachable across the DirectAccess
connection.
5. From the Command Prompt window, use the nslookup –q=aaaa IntranetFQDN
IntranetDNSServerIPv6Address command to resolve the names of intranet servers
(example: nslookup –q=aaaa dc1.corp.contoso.com 2002:836b:2:1::5efe:10.0.0.1).
This command should display the IPv6 addresses of the specified intranet server.
If there are no IPv6 addresses for the name, determine why the corresponding IPv6
(AAAA) records are not in your intranet DNS.
If there is no response from the intranet DNS server, troubleshoot the infrastructure
tunnel between the DirectAccess client and server. For more information, see
DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server.
Fixing Issues with Connecting to an Intranet Resource
Issues with connecting to and from intranet resources typically fall into the following categories:
DirectAccess Client Cannot Access Intranet Resources
Intranet Management Server Cannot Connect to a DirectAccess Client
DirectAccess Client Cannot Access Intranet Resources
A DirectAccess client uses Internet Protocol version 6 (IPv6) exclusively to access intranet
resources across the DirectAccess connection with the DirectAccess server. When a
DirectAccess client queries the intranet Domain Name System (DNS) servers, it requests only
IPv6 addresses. The intranet DNS server will respond with IPv6 addresses in the following cases:
The intranet resource server is IPv6-capable and has registered its unique local or global
IPv6 addresses in DNS.
In this case, the DirectAccess client can connect to the intranet resource server using end-to-
end IPv6 addresses. A client application on the DirectAccess client can communicate with its
corresponding server application on the intranet resource server if both client and server
applications are IPv6-capable.
The intranet resource is not IPv6-capable, but the intranet DNS server is performing an
IPv6/Internet Protocol version 4 (IPv4) DNS gateway function and returning the IPv6 address
236
of an IPv6/IPv4 translator, such as a NAT64 or Network Address Translation-Protocol
Translation (NAT-PT).
In this case, the DirectAccess client can connect to the IPv4-only intranet resource using an
intermediate IPv6/IPv4 translator. This topic does not describe troubleshooting DirectAccess
connectivity when using an IPv6/IPv4 DNS gateway or IPv6/IPv4 translator.
As described in Choose an Intranet IPv6 Connectivity Design, you can use native IPv6
(recommended) or Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) to deploy IPv6
connectivity on your intranet. In either case, IPv6-capable nodes on your network are reachable
with IPv6 and, if they support DNS dynamic update, register their IPv6 addresses in DNS.
1. On the DirectAccess client, start a command prompt as an administrator.
2. From the Command Prompt window, run the netsh namespace show effective
command.
This command displays the current effective rules, which are typically one or more
namespace rules (with a leading period) for your intranet namespace and one or more
exemption rules for names that should not be resolvable while on the Internet (fully
qualified domain names [FQDNs] without a leading period for names such as your
network location server). Verify that your entire intranet namespace is represented by
DirectAccess-based namespace rules.
In the rules for your intranet namespace, there should be at least one IPv6 address for
DirectAccess (DNS Servers).
If there are no rules, run the netsh namespace show policy command. If there are
DirectAccess-based rules, the DirectAccess client has determined that it is on the
intranet. If there are no rules, verify that the DirectAccess client is running Windows 7
Ultimate Edition, Windows 7 Enterprise Edition, or Windows Server 2008 R2, is a
member of a security group specified in step 1 of the DirectAccess Setup Wizard, and
has updated its computer configuration Group Policy.
3. From the Command Prompt window, ping the IPv6 addresses of your intranet DNS
servers from step 2.
This step ensures that the intranet DNS server is reachable across the DirectAccess
connection.
4. Verify that the FQDN of the intranet resource matches a namespace rule in the NRPT
and does not match an exemption rule.
This step ensures that the DirectAccess client will send its queries to the intranet DNS
servers, rather than an Internet DNS server.
5. From the Command Prompt window, use the nslookup –q=aaaa IntranetFQDN
IntranetDNSServerIPv6Address command to resolve the names of intranet servers to
IPv6 addresses (example: nslookup –q=aaaa dc1.corp.contoso.com
2002:836b:2:1::5efe:10.0.0.1).
This command should display the IPv6 addresses of the specified intranet server.
To troubleshoot why a DirectAccess client cannot connect to an intranet resource
237
If there are no IPv6 addresses for the name, see the To determine the IPv6 addresses
that an intranet resource registers in DNS procedure in this topic.
If there is no response from the intranet DNS server, troubleshoot the infrastructure
tunnel between the DirectAccess client and server. For more information, see
DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server.
6. From the Command Prompt window, ping the IPv6 addresses of the intranet resource
server from step 5.
This ensures that the intranet resource server is reachable across the DirectAccess
connection.
7. From the DirectAccess client, attempt to connect to the intranet server using the
appropriate application or run the net view \\IntranetServerName command from the
Command Prompt window.
If there is no response from the intranet DNS server, verify that the client and server or
peer applications running on both the DirectAccess client and intranet server are IPv6-
capable.
If the peer or client application running on the DirectAccess client is not IPv6-capable,
you cannot use it over the DirectAccess connection.
If the peer or client application running on the intranet server is not IPv6-capable, you can
update the application to support IPv6 or place it behind an IPv6/IPv4 translator. Most
built-in server applications and system services on computers running Windows Server
2003 or Windows XP are not IPv6-capable.
8. If the applications running on both the DirectAccess client and intranet server are IPv6-
capable, troubleshoot the intranet tunnel between the DirectAccess client and server.
For more information, see DirectAccess Client Cannot Establish Tunnels to the
DirectAccess Server.
1. On the Windows-based intranet resource server, start a command prompt as an
administrator.
2. From the Command Prompt window, run the ipconfig command.
This command displays your current Transmission Control Protocol/Internet Protocol
(TCP/IP) configuration, including both IPv4 and IPv6 addresses.
Verify that an IPv6 global address (an address that begins with 2 or 3) or an IPv6 unique
local address (begins with fd) is assigned to an interface on the computer. If all of the
IPv6 addresses begin with fe80, the intranet resource has not been configured with an
IPv6 address that is registerable in DNS and reachable by DirectAccess clients. For more
information, see the To troubleshoot why an intranet ISATAP host does not
configure an ISATAP address procedure in this topic.
3. If there is a global or unique local IPv6 address assigned to an interface, use the
nslookup –q=aaaa IntranetServerFQDN IntranetDNSServerIPAddress command to
determine if the intranet resource has registered its IPv6 address. For example, for the
To determine the IPv6 addresses that an intranet resource registers in DNS
238
intranet resource named APP1 in the corp.contoso.com domain that has been configured
to use the DNS server at 10.0.0.1, the command is nslookup –q=aaaa
app1.corp.contoso.com 10.0.0.1.
This command should display the IPv6 addresses of the intranet resource that are
registered in DNS.
4. If there are no IPv6 addresses for the name, run the ipconfig /registerdns command
and go to step 3.
If there are still no IPv6 addresses, troubleshoot DNS dynamic update between the
intranet resource server and its DNS servers.
If you are using ISATAP for IPv6 connectivity on your intranet, ISATAP hosts should automatically
discover the IPv4 address of the ISATAP router (the DirectAccess server) and configure an
ISATAP address on an ISATAP interface.
1. On the Windows-based intranet resource, start a command prompt as an
administrator.
2. From the Command Prompt window, run the reg query HKLM\SYSTEM\
CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command.
If the DisabledComponents registry value is present, the command displays its value. If
the DisabledComponents registry value is not present, the command displays ERROR:
The system was unable to find the specified registry key or value.
If DisabledComponents is present and it is not 0, convert it to a binary number. If the first
or third bit from the right in the binary number is 1, DisabledComponents has disabled
ISATAP. You must change the first and third bit from the right to 0 to enable ISATAP.
3. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\
Microsoft\Windows\TCPIP\v6Transition /v ISATAP_RouterName command.
This command should display ERROR: The system was unable to find the specified
registry key or value. If it does not, note the value.
4. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\
Microsoft\Windows\TCPIP\v6Transition /v ISATAP_State command.
This command should display ERROR: The system was unable to find the specified
registry key or value. If it does not, ensure that the value is set to enabled. If it is set to
disabled, change the Computer Configuration\Policies\Administrative Templates\
Network\TCPIP Settings\IPv6 Transition Technologies\ISATAP State setting in the
Group Policy object for this intranet resource to either Enabled or Not Configured and
update computer configuration Group Policy.
5. From the Command Prompt window, run the netsh interface isatap show state
command.
This command should display enabled in ISATAP State.
6. From the Command Prompt window, run the netsh interface isatap show router
To troubleshoot why an intranet ISATAP host does not configure an ISATAP address
239
command.
This command should display default or the name from step 3 in Router Name.
7. From the Command Prompt window, ping the name isatap or the name from step 3.
This ensures that the intranet resource can resolve the name of the ISATAP router to an
IPv4 address and reach the IPv4 address. Verify that the IPv4 address is assigned to the
computer that is the intranet ISATAP router, which is typically the DirectAccess server.
8. If the name isatap or the name from step 3 does not resolve, check your DNS server to
verify that the corresponding Address (A) record exists in your intranet DNS.
9. DNS servers running Windows Server 2008 or later will not by default answer queries for
the name isatap unless you remove it from the global query block list. Verify that the
name isatap has been removed from the global query block list. For more information,
see Remove ISATAP from the DNS Global Query Block List.
The next step in troubleshooting ISATAP connectivity is the ISATAP router.
1. On the DirectAccess server acting as the ISATAP router, start a command prompt as
an administrator.
2. From the Command Prompt window, run the reg query HKLM\SYSTEM\
CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command.
If the DisabledComponents registry value is present, the command displays its value. If
the DisabledComponents registry value is not present, the command displays ERROR:
The system was unable to find the specified registry key or value.
If DisabledComponents is present and it is not 0, convert it to a binary number. If the first
or third bit from the right in the binary number is 1, DisabledComponents has disabled
ISATAP. You must change the first and third bit from the right to 0 to enable ISATAP.
3. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\
Microsoft\Windows\TCPIP\v6Transition /v ISATAP_RouterName command.
This command should display ERROR: The system was unable to find the specified
registry key or value. If it does not, note the value.
4. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\
Microsoft\Windows\TCPIP\v6Transition /v ISATAP_State command.
This command should display ERROR: The system was unable to find the specified
registry key or value. If it does not, ensure that the value is set to enabled.
5. From the Command Prompt window, run the netsh interface isatap show state
command.
This command should display enabled in ISATAP State.
6. From the Command Prompt window, run the netsh interface isatap show router
command.
This command should display isatap.IntranetDNSSuffix in Router Name.
To troubleshoot an ISATAP router
240
7. From the Command Prompt window, ping the name isatap.
This demonstrates that the DirectAccess server has registered the ISATAP name. Verify
that the resolved IPv4 address is assigned to an intranet interface of the DirectAccess
server.
8. From the Command Prompt window, run the netsh interface ipv6 show interfaces
command.
This command lists all of the IPv6 interfaces and their interface index numbers. Note the
interface index (Idx) of the interface named isatap.IntranetDNSSuffix.
9. From the Command Prompt window, run the netsh interface ipv6 show interface
ISATAPInterfaceIndex command.
Verify that Advertising and Forwarding are set to Enabled. If not, run the netsh
interface ipv6 set interface ISATAPInterfaceIndex advertise=enabled
forwarding=enabled command.
10. From the Command Prompt window, run the netsh interface ipv6 show route
command.
This command lists the routes in the IPv6 route table. Verify that there is a 64-bit route
with the Gateway/Interface Name set to isatap.IntranetDNSSuffix and Publish set to
Yes. This is the ISATAP subnet route that the DirectAccess server is advertising to
ISATAP hosts on the intranet. The 64-bit route typically has the form
2002:WWXX:YYZZ:1::/64, in which WWXX:YYZZ is the colon hexadecimal
representation of w.x.y.z, the first public IPv4 address of the DirectAccess server’s
Internet interface.
11. If Publish is set to No for the route in step 10, run the netsh interface ipv6 set route
64BitRoute ISATAPInterfaceIndex publish=yes.
Intranet Management Server Cannot Connect to a DirectAccess Client
Management servers specified in Step 3 of the DirectAccess Setup Wizard can initiate
connections with DirectAccess clients using a management tunnel, an Internet Protocol security
(IPsec) tunnel similar to the infrastructure tunnel automatically established by the DirectAccess
client computer to access domain controllers, Domain Name System (DNS) servers, and other
types of infrastructure servers. The management server can connect to the DirectAccess client
before the user has logged on. Alternately, the management tunnel can be established by the
DirectAccess client computer when it initiates communication with a management server.
Just like the infrastructure tunnel, success of the tunnel mode security associations (SAs) for the
management tunnel depends on the connection security rules configured on DirectAccess clients
and the DirectAccess server. These rules consist of a variety of settings for the following:
241
The source or destination Internet Protocol version 6 (IPv6) addresses of the management
servers for which IPsec tunnel mode is required.
The tunnel endpoints (the IPv6 addresses of the DirectAccess server).
The computer certificate and UserNTLM (using the computer’s computer account credentials)
authentication methods required to successfully authenticate the DirectAccess client and
server.
The encryption and data integrity methods.
The DirectAccess Setup Wizard configures a compatible set of connection security rules for the
DirectAccess server and DirectAccess clients that should result in a successful negotiation of
IPsec SAs for the management tunnel.
If DirectAccess server and DirectAccess client cannot successfully negotiate the management
tunnel, the management server on the intranet cannot communicate with the DirectAccess client
to remotely manage, install updates, or perform other management functions.
1. On the DirectAccess client, start a command prompt as an administrator.
2. On the DirectAccess client, click Start, type wf.msc, and then press ENTER.
3. In the tree pane of the Windows Firewall with Advanced Security snap-in console, click
Connection Security Rules.
In the details pane, you should see connection security rules whose names begin with
DirectAccess Policy. If not, this DirectAccess client has not received its connection
security rules from computer configuration Group Policy. Verify that the DirectAccess
client is running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows
Server 2008 R2 and is a member of one of the security groups specified in step 1 of the
DirectAccess Setup Wizard.
4. In the tree pane of the Windows Firewall with Advanced Security snap-in console, open
Monitoring\Connection Security Rules.
In the details pane, you should see a list of connection security rules that begin with
DirectAccess Policy, including a rule named DirectAccess Policy-ClientToMgmt.
5. If you do not see these rules, from the Command Prompt window, run the netsh
advfirewall monitor show currentprofile command.
This command displays the attached networks and their determined firewall profiles.
None of your networks should be in the domain profile. If any of your networks has been
assigned the domain profile, determine if you have an active remote access virtual
private network (VPN) connection or a domain controller that is available on the Internet.
6. Double-click the DirectAccess Policy-ClientToMgmt rule and then click the Computers
tab. Verify that the IPv6 address of the management server is listed in Endpoint 2. This
list of IPv6 addresses was configured in step 3 of the DirectAccess Setup Wizard.
7. From the intranet, use the management server to initiate communication with the
DirectAccess client. For example, use the management server to establish a remote
To verify whether the management server can successfully create the management tunnel
242
desktop connection to the DirectAccess client.
8. On the DirectAccess client, from the Command Prompt window, run the netsh
advfirewall monitor show mmsa command.
There should be a main mode SA with the Remote IP Address set to the IPv6 address
2002:WWXX:YYZZ::WWXX:YYZZ, corresponding to the first public IPv4 address
assigned to the Internet interface of the DirectAccess server. For example, if the first
public IPv4 address is 131.107.0.2, the corresponding 6to4 IPv6 address is
2002:836b:2::836b:2 (836b:2 is the colon-hexadecimal notation for 131.107.0.2). The
main mode SA should also have ComputerCert for Auth1 and UserNTLM for Auth2.
9. From the Command Prompt window, run the netsh advfirewall monitor show qmsa
command.
There should be a quick mode SA with the Remote IP Address set to the IPv6 address
2002:WWXX:YYZZ::WWXX:YYZZ, corresponding to the first public IPv4 address
assigned to the Internet interface of the DirectAccess server.
If the DirectAccess client computer cannot establish the main and quick mode SAs for the
management tunnel using the default connection security rules created by the DirectAccess
Setup Wizard, the most likely problem is a certificate authentication failure. For more information,
see the “IKE certificate selection process” and “IKE certificate acceptance process” sections of
Public Key Certificate.
You can view the certificates in the local computer store on the DirectAccess client and server
with the Certificates snap-in
To ensure that the DirectAccess server can access a domain controller to validate the credentials
of the DirectAccess client, run the nltest /dsgetdc: /force command at an elevated command
prompt. If there are no domain controllers listed, troubleshoot the lack of discoverability and
connectivity between the DirectAccess server and Active Directory.
Similarly, use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it
has access to a domain controller. If there are no domain controllers listed, ensure that the IPv6-
capable domain controllers that are being used by DirectAccess clients are using site-less locator
records in DNS.
To perform detailed IPsec negotiation analysis, use IPsec audit events in the Windows Logs\
Security event log and network tracing for DirectAccess. For more information, see Event Viewer
and Network Diagnostics and Tracing.
If you have configured DirectAccess for the end-to-end access model, verify that the
management server has been configured with compatible connection security rules to use
transport mode IPsec when initiating communication with DirectAccess clients.
243
Fixing Problems with Creating Protected Connections to an Intranet Resource
For the selected server or end-to-end access models, DirectAccess clients use Internet Protocol
security (IPsec) transport mode rules to protect the traffic from the DirectAccess client to intranet
resource servers. In the case of the selected server access model, the end-to-end protection is
between DirectAccess clients and a set of resource servers defined by security group
membership. In the case of the end-to-end access model, the end-to-end protection is between
DirectAccess clients and all intranet resource servers that are domain members.
Selected server access modelFor selected server access, the DirectAccess Setup Wizard configures a compatible set of
connection security rules for DirectAccess clients and the selected servers that should result in a
successful establishment of transport mode IPsec security associations (SAs). If the DirectAccess
client cannot successfully create the transport mode SAs, the DirectAccess client cannot connect
to the selected servers on the intranet.
1. On the DirectAccess client, start a command prompt as an administrator.
2. On the DirectAccess client, click Start, type wf.msc, and then press ENTER.
3. In the tree pane of the Windows Firewall with Advanced Security snap-in console, click
Connection Security Rules.
In the details pane, you should see connection security rules whose names begin with
DirectAccess Policy. If not, this DirectAccess client has not received its connection
security rules from computer configuration Group Policy. Verify that the DirectAccess
client is running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows
Server 2008 R2 and is a member of one of the security groups specified in step 1 of the
DirectAccess Setup Wizard.
4. In the tree pane of the Windows Firewall with Advanced Security snap-in console, open
Monitoring\Connection Security Rules.
In the details pane, you should see a list of connection security rules that begin with
DirectAccess Policy, including a rule named DirectAccess Policy-clientToAppServer.
5. If you do not see these rules, from the Command Prompt window, run the netsh
advfirewall monitor show currentprofile command.
This command displays the attached networks and their determined firewall profiles.
None of your networks should be in the domain profile. If any of your networks has been
assigned the domain profile, determine if you have an active remote access virtual
private network (VPN) connection or a domain controller that is available on the Internet.
6. Double-click the DirectAccess Policy- clientToAppServer rule and then click the
To verify whether the DirectAccess client can successfully create transport mode IPsec SAs to selected servers
244
Computers tab. Verify that the Internet Protocol version 6 (IPv6) addresses of the
selected servers are listed in Endpoint 2. This list of IPv6 addresses was configured
based on the selected server security groups specified in step 4 of the DirectAccess
Setup Wizard.
7. Initiate communication with the selected server. For example, use the appropriate
application or the net view \\SelectedServerName command.
8. From the Command Prompt window, run the netsh advfirewall monitor show mmsa
command.
There should be a main mode SA with the Remote IP Address set to the IPv6 address of
the selected server. The main mode SA should also have ComputerCert or
ComputerKerb for Auth1 and UserKerb for Auth2.
9. From the Command Prompt window, run the netsh advfirewall monitor show qmsa
command.
There should be a quick mode SA with the Remote IP Address set to the IPv6 address
of the selected server.
If the DirectAccess client computer cannot establish the main and quick mode SAs to the
selected server using the default connection security rules created by the DirectAccess Setup
Wizard, the most likely problem is the lack of corresponding connection security rules on the
selected server. Verify that a rule named DirectAccess Policy-appServerToClient appears in
the Connection Security Rules and Monitoring\Connection Security Rules nodes in the
console tree of the Windows Firewall with Advanced Security snap-in on the selected server.
End-to-end access modelFor end-to-end access, you manually configure the settings created by the DirectAccess Setup
Wizard for selected server access to apply to all of the computers in your domain. For more
information, see Checklist: Implementing a DirectAccess Design for End-to-End Access. The
result is a compatible set of connection security rules for DirectAccess clients and all intranet
domain member computers for successful negotiation of end-to-end, encrypted transport mode
IPsec SAs. If the DirectAccess client cannot successfully create the transport mode SAs, the
DirectAccess client cannot connect to intranet resources.
1. On the DirectAccess client, start a command prompt as an administrator.
2. Click Start, type wf.msc, and then press ENTER.
3. In the tree pane of the Windows Firewall with Advanced Security snap-in console, click
Connection Security Rules.
In the details pane, you should see connection security rules whose names begin with
DirectAccess Policy. If not, this DirectAccess client has not received its connection
security rules from computer configuration Group Policy. Verify that the DirectAccess
client is running Windows 7 Ultimate Edition or Windows 7 Enterprise Edition and is a
member of one of the security groups specified in step 1 of the DirectAccess Setup
To verify whether the DirectAccess client can successfully create transport mode IPsec SAs to intranet resources
245
Wizard.
4. In the tree pane of the Windows Firewall with Advanced Security snap-in console, open
Monitoring\Connection Security Rules.
In the details pane, you should see a list of connection security rules that begin with
DirectAccess Policy, including a rule named DirectAccess Policy-clientToAppServer.
5. If you do not see this rule, from the Command Prompt window, run the netsh advfirewall
monitor show currentprofile command.
This command displays the attached networks and their determined firewall profiles.
None of your networks should be in the domain profile. If any of your networks has been
assigned the domain profile, determine if you have an active remote access virtual
private network (VPN) connection or a domain controller that is available on the Internet.
6. Initiate communication with an intranet server. For example, use an appropriate client
application or the net view \\IntranetServer command.
7. From the Command Prompt window, run the netsh advfirewall monitor show mmsa
command.
There should be a main mode SA with the Remote IP Address set to the IPv6 address of
the intranet server. The main mode SA should also have ComputerCert or
ComputerKerb for Auth1 and UserKerb for Auth2.
8. From the Command Prompt window, run the netsh advfirewall monitor show qmsa
command.
There should be a quick mode SA with the Remote IP Address set to the IPv6 address
of the intranet server.
If the DirectAccess client computer cannot establish the main and quick mode SAs to intranet
server using the modified connection security rules, the most likely problem is the lack of
corresponding connection security rules on intranet servers. Verify that a rule named
DirectAccess Policy-appServerToClient appears in the Connection Security Rules and
Monitoring\Connection Security Rules nodes in the console tree of the Windows Firewall with
Advanced Security snap-in on your intranet servers.
Fixing Issues with Intranet Detection
DirectAccess clients determine whether they are directly attached to the intranet using a local
area network (LAN) or wireless LAN (WLAN) connection whenever there is a change in network
state. To detect the intranet, DirectAccess clients attempt to access a Secure Hypertext Transfer
Protocol (HTTPS)-based uniform resource locator (URL) hosted by the network location server.
This URL is configured in step 3 of the DirectAccess Setup Wizard and stored in the Computer
Configuration\Policies\Administrative Templates\Network\Network Connection Status
Indicator\Domain Location Determination URL setting of the Group Policy object for
DirectAccess clients.
246
After a network state change and before intranet detection is complete, the DirectAccess client
has the DirectAccess-based rules in its effective Name Resolution Policy Table (NRPT). If intranet
detection determines that the DirectAccess client is on the intranet, the DirectAccess-based rules
in the effective NRPT are removed. If intranet detection determines that the DirectAccess client is
on the Internet, the DirectAccess-based rules in the NRPT are not removed.
The most common issues that can occur with intranet detection are the following:
DirectAccess Client Determines that it is on the Intranet When on the Internet
DirectAccess Client Determines that it is on the Internet When on the Intranet
DirectAccess Client Determines that it is on the Intranet When on the Internet
If the DirectAccess client can successfully access the Secure Hypertext Transfer Protocol
(HTTPS)-based uniform resource locator (URL) hosted by the network location server when
directly attached to the Internet, intranet detection determines that a DirectAccess client is on the
intranet and removes the DirectAccess-based rules in the effective Name Resolution Policy Table
(NRPT). If the DirectAccess client computer has an existing, active virtual private network (VPN)
connection to the intranet, this is the desired behavior. With an existing layer 2 connection to the
intranet, such as that provided by a VPN connection, the network location server is accessible
and DirectAccess should not be used to provide intranet connectivity.
If the DirectAccess client computer does not have an existing, active VPN connection to the
intranet, the network location server should not be accessible. If it is, the DirectAccess client
removes the DirectAccess-based rules in the effective NRPT and the DirectAccess client sends
all Domain Name System (DNS) name queries to interface-configured DNS servers. The result is
that the DirectAccess client will not be able to resolve intranet DNS server names and connect to
intranet DNS servers through the DirectAccess server.
If the network location server is accessible from DirectAccess clients on the Internet, it could be
due to the following:
Your NRPT does not have an exemption rule for the fully qualified domain name (FQDN) of
the network location URL
If the FQDN of the network location URL matches the namespace rule for your intranet, you
must have an additional exemption rule for the FQDN in the NRPT. With this exemption rule,
the DirectAccess client uses interface-configured DNS servers for the FQDN, which Internet
DNS servers should not be able to resolve. If this exemption rule is missing and the FQDN of
the network location URL matches the namespace rule for your intranet, the DirectAccess
client will use intranet DNS servers to successfully resolve the FQDN and access the network
location server over the DirectAccess connection.
The network location URL is accessible from the Internet
247
The network location URL is designed to be accessible only from the intranet. You should not
be able to access the FQDN of the network location URL or the HTTPS-based URL from an
Internet-connected computer. To test this, connect a computer that is not a DirectAccess
client to the Internet and attempt to ping the FQDN of the network location URL and use an
Internet browser to access the network location URL. If you can resolve the name and access
the URL, remove the Internet DNS records for the FQDN or remove the network location
server from the Internet. If the DirectAccess server is acting as the network location server,
ensure that the IP and Domain Restrictions role service is installed for the Web server (IIS)
role to prevent DirectAccess clients on the Internet from reaching the network location URL
on the DirectAccess server.
DirectAccess Client Determines that it is on the Internet When on the Intranet
If the DirectAccess client cannot access the Secure Hypertext Transfer Protocol (HTTPS)-based
uniform resource locator (URL) hosted by the network location server when directly attached to
the intranet, intranet detection determines that a DirectAccess client is on the Internet and keeps
the DirectAccess-based rules in the effective Name Resolution Policy Table (NRPT). With the
DirectAccess-based rules in the effective NRPT, the DirectAccess client sends Domain Name
System (DNS) queries for names that match the intranet namespace to the Internet Protocol
version 6 (IPv6) addresses of intranet DNS servers.
If you have native IPv6 connectivity and the IPv6 addresses of the DNS servers configured in the
namespace rules are reachable, the DirectAccess client will be able to successfully resolve and
connect to intranet DNS servers. However, if the NRPT rules use a different set of DNS servers
than intranet computers through interface-configured DNS servers (for example, to place the load
of DirectAccess and intranet clients on different sets of DNS servers), DirectAccess clients on the
intranet will continue to use the DNS servers that are intended for use by DirectAccess clients on
the Internet.
If you are using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) for IPv6 connectivity
on your intranet, DirectAccess clients will not be able to access intranet resources. The reason for
the lack of connectivity for ISATAP-based intranets is based on the following configuration and
behavior defaults:
There is an intranet namespace rule in the effective NRPT.
The DNS server IPv6 addresses for the intranet namespace rule in the effective NRPT are
ISATAP-based addresses.
The DirectAccess client discovers the Internet Protocol version 4 (IPv4) address of the
ISATAP router by attempting to resolve the name ISATAP.
When IPv6 on the DirectAccess client computer performs autoconfiguration, it sends router
solicitations on its local area network (LAN) and wireless LAN (WLAN) interfaces. With no native
IPv6 support on local routers, there are no replies and the DirectAccess client attempts to resolve
248
the name isatap, which includes appending its DNS domain suffix to form a fully qualified domain
name (FQDN). Because the DNS domain suffix is the same as the suffix for the intranet
namespace rule in the effective NRPT, the FQDN for the ISATAP router name matches the
intranet namespace rule in the NRPT. Therefore, the DirectAccess client attempts to send a DNS
name query to the ISATAP-based address of the intranet DNS server, which it cannot reach
because it does not yet have an ISATAP address. The result is that the DirectAccess client
cannot reach the IPv6 addresses of its intranet DNS servers and cannot resolve intranet DNS
names.
1. On the DirectAccess client, start a command prompt as an administrator.
2. From the Command Prompt window, run the netsh namespace show policy command.
There should be set of NRPT rules. If not, this DirectAccess client has not received its
NRPT rules from computer configuration Group Policy. Verify that this computer is
running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows
Server 2008 R2 and is a member of one of the security groups specified in step 1 of the
DirectAccess Setup Wizard.
3. From the Command Prompt window, run the netsh namespace show effective
command.
If you have the same set of DirectAccess-based rules as in step 2, the DirectAccess
client has determined that it is on the Internet.
If the set of DirectAccess-based rules in step 2 are not listed, the DirectAccess client has
determined that it is on the intranet.
4. Click Start, type eventvwr.msc, and then press ENTER.
5. In the console tree, open Application and Services Logs\Microsoft\Windows\NCSI\
Operational.
6. Double-click the most recent Information events with the event ID 4010.
The text on the General tab displays the result of the latest intranet detections (also
known as Inside/Outside detections) as either INSIDE or OUTSIDE. INSIDE means the
intranet has been detected. OUTSIDE means that the intranet has not been detected.
Look at the events for the interfaces with interface numbers that begin with 0x47 (WLAN)
and 0x60 (LAN). If any of the LAN or WLAN interfaces are INSIDE, the DirectAccess
client is on the intranet. If all of the LAN and WLAN interfaces are OUTSIDE, the
DirectAccess client is not on the intranet.
You can also use the wevtutil qe Microsoft-Windows-NCSI/Operational /rd:true /f:text
>> filename.log command to export the events to a text file.
1. On the DirectAccess client, start a command prompt as an administrator.
2. From the Command Prompt window, run the reg query HKLM\software\policies\
microsoft\windows\NetworkConnectivityStatusIndicator\CorporateConnectivity /v
To determine the results of intranet detection on a DirectAccess clientNote
To troubleshoot why a DirectAccess client on the intranet cannot successfully access the network location URL
249
DomainLocationDeterminationUrl command.
This displays the network location URL. If there is no value, the DirectAccess client has
not been properly configured with computer configuration Group Policy. Verify that this
computer is running Windows 7 Ultimate Edition or Windows 7 Enterprise Edition and is a
member of one of the security groups specified in step 1 of the DirectAccess Setup
Wizard.
3. From the Command Prompt window, run the netsh namespace show policy command.
4. Compare the FQDN in the network location URL to the NRPT rules from step 3.
Either the FQDN should not match the DirectAccess-based intranet namespace rules or it
should match an exemption rule for the FQDN. In either case, the DirectAccess client will
use interface-configured DNS server to resolve the FQDN in the network location URL.
5. From the Command Prompt window, ping the FQDN in the network location URL.
This step ensures that the DirectAccess client can resolve the name and reach the
network location server.
6. Attempt to access the network location URL with your Internet browser.
You should see the Web page without any certificate errors. Note that the contents of the
Web page do not matter, only the ability to successfully access it.
If you see a certificate error, verify the following for the certificate on the network location server
that is being used for HTTPS (SSL)-based connections:
The DirectAccess client can validate and trust the network location certificate.
The Subject field is the FQDN from the network location URL.
The Enhanced Key Usage field contains the Server Authentication object identifier (OID).
The certificate revocation list (CRL) Distribution Points field contains at least one CRL
distribution point that the DirectAccess client can successfully access.
1. On the network location server, obtain the CRL distribution points—the Hypertext
Transfer Protocol (HTTP) URL without the file name or the universal naming convention
(UNC) path without the file name—from the CRL Distribution Points field of the certificate
being used for HTTPS-based connections. If the network location server is running
Windows, use the Certificates snap-in for the local computer store and view the Details
tab for the properties of the HTTPS (Secure Sockets Layer [SSL]) certificate.
2. On the DirectAccess client, start a command prompt as an administrator.
3. From the Command Prompt window, ping the FQDNs from the URLs or UNC paths for
the CRL distribution points obtained in step 1.
This step ensures that the DirectAccess client can resolve the names of the CRL
distribution point locations and reach the resolved addresses.
4. For a URL-based CRL distribution point, paste it into your Internet browser. You should
see a series of files with the .crl extension. Ensure that you can open all of the .crl files.
To test access to the CRL distribution points of the network location certificate from a DirectAccess client on the intranet
250
5. For a UNC path-based CRL distribution point, click Start, type the path, and then press
ENTER. You should see folder with a series of files with the .crl extension. Ensure that
you can open all of the .crl files.
The DirectAccess client must be able to access at least one of the CRL distribution points and
open the CRL files. Otherwise, certificate revocation fails and the DirectAccess determines that it
is on the Internet.
251
Related Documents
