da design dep guide

DirectAccess for Windows Server 2008 R2

Design, Deployment, and Troubleshooting GuidesMicrosoft Corporation

Published: December 2009

Updated: September 2010

Author: Joe Davies

Editor: Scott Somahano

Abstract

This document contains the Design Guide, Deployment Guide, and Troubleshooting 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 and

troubleshoot common DirectAccess problems. 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. Use the

Troubleshooting Guide for task-oriented information to help you identify and resolve problems

quickly and perform root-cause analysis of incidents and problems with the elements of a

DirectAccess infrastructure.

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, Deployment, and Troubleshooting 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.

This white paper reflects content that was published on Microsoft TechNet as of September 1,

2010. The corresponding content published on TechNet after this date might contain changes. For

the latest information, see the following documents:

DirectAccess Design Guide (http://go.microsoft.com/fwlink/?LinkID=161985)

DirectAccess Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=166398)

DirectAccess Troubleshooting Guide (http://go.microsoft.com/fwlink/?LinkId=165904)

http://go.microsoft.com/fwlink/?LinkId=165904


http://go.microsoft.com/fwlink/?LinkID=161985

Contents

DirectAccess Design Guide..........................................................................................................13

About this guide......................................................................................................................... 13

Understanding the DirectAccess Design Process.........................................................................14

Identifying Your DirectAccess Deployment Goals.........................................................................15

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

Ongoing Management of Remote DirectAccess Clients...............................................................16

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

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

End-to-end Traffic Protection........................................................................................................18

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

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

Evaluating DirectAccess Design Examples..................................................................................19

Full Intranet Access Example........................................................................................................20

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

Selected Server Access Example.................................................................................................22

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

End-to-end Access Example.........................................................................................................24

Planning a DirectAccess Deployment Strategy.............................................................................25

Resources Available to DirectAccess Clients................................................................................26

IPv6 resources on your intranet.................................................................................................26

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

Using an IPv4-only intranet.......................................................................................................28

Limiting connectivity to selected resources...............................................................................28

IPv6 resources on the IPv6 Internet..........................................................................................29

Choose an Intranet IPv6 Connectivity Design...............................................................................30

No existing IPv6 infrastructure...................................................................................................30

Existing ISATAP infrastructure...................................................................................................31

Existing native IPv6 infrastructure.............................................................................................31

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

Choose an Access Model.............................................................................................................34

Full Intranet Access...................................................................................................................... 34

Selected Server Access................................................................................................................35

End-to-End Access....................................................................................................................... 36

Choose a Configuration Method...................................................................................................37

DirectAccess Management Console..........................................................................................37

Custom configuration using the Network Shell (Netsh) command-line tool and Group Policy...37

Design for Remote Management..................................................................................................38

Design for Intranet Server Availability Prior to User Logon...........................................................39

Design Packet Filtering for DirectAccess......................................................................................41

Packet Filters for Your Internet Firewall........................................................................................41

Packet Filters for Your Intranet Firewall........................................................................................42

Confining ICMPv6 Traffic to the Intranet.......................................................................................43

Packet filters for Teredo Connectivity............................................................................................45

Packet filters to allow inbound ICMP Echo Requests on all computers.....................................45

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

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

Packet Filters for Management Computers...................................................................................46

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

Choose an Authentication and Authorization Scheme..................................................................48

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

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

Smart cards for additional authorization....................................................................................49

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

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

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

Design Addressing and Routing for the DirectAccess Server.......................................................52

IPv4 address and routing configuration.....................................................................................52

IPv6 address and routing configuration.....................................................................................53

Design Active Directory for DirectAccess......................................................................................54

Active Directory and the DirectAccess server............................................................................55

Active Directory Sites and Services configuration.....................................................................55

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

Design Your DNS Infrastructure for DirectAccess.........................................................................56

Split-brain DNS.......................................................................................................................... 57

DNS server requirements for ISATAP........................................................................................58

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

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

NRPT rules................................................................................................................................ 59

DNS server querying behavior for DirectAccess clients............................................................60

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

External DNS............................................................................................................................. 61

Design Your PKI for DirectAccess.................................................................................................62

Autoenrollment for computer certificates...................................................................................62

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

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

Using a commercial CA for the IP-HTTPS certificate.................................................................64

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

Smart cards for additional authorization....................................................................................65

Using Suite B certificates for DirectAccess................................................................................66

Design Your Web Servers for DirectAccess..................................................................................66

Choose an Internet Traffic Separation Design..............................................................................67

Configure IPv4 Internet access.................................................................................................69

Enable force tunneling...............................................................................................................69

Modify the NRPT....................................................................................................................... 69

Configure the use of IP-HTTPS.................................................................................................70

Modify Internet firewall settings.................................................................................................70

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

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

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

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

Use the DirectAccess Connectivity Assistant (DCA).....................................................................75

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

When to Install a DirectAccess Server..........................................................................................76

Where to Place the DirectAccess Server......................................................................................77

Planning Redundancy for a DirectAccess Server.........................................................................78

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

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

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

Authentication and authorization for the network location URL.................................................81

DirectAccess server as the network location server..................................................................81

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

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

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

Intranet location for intranet detection.......................................................................................83

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

Planning Redundancy for CRL Distribution Points........................................................................84

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

Configuration changes for the infrastructure tunnel...................................................................85

Configuration changes for the intranet tunnel............................................................................86

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

Planning DirectAccess with Microsoft Forefront Threat Management Gateway...........................88

DirectAccess Capacity Planning...................................................................................................88

Capacity Planning for DirectAccess Servers.................................................................................89

Increasing the number of concurrent Teredo clients..................................................................89

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

Using DirectAccess with UAG...................................................................................................91

Capacity Planning for Network Location Servers..........................................................................91

Capacity Planning for CRL Distribution Points..............................................................................92

Planning for Multi-site DirectAccess.............................................................................................92

IPv6 connectivity for multi-site DirectAccess.............................................................................94

Native IPv6 connectivity.........................................................................................................95

ISATAP connectivity...............................................................................................................95

Active Directory for multi-site DirectAccess...............................................................................98

DNS for multi-site DirectAccess.................................................................................................98

Intranet DNS records.............................................................................................................99

Internet DNS records.............................................................................................................99

NRPT..................................................................................................................................... 99

PKI for multi-site DirectAccess................................................................................................100

Intranet CRL distribution points............................................................................................100

Certificate requirements for network location certificates.....................................................101

Internet CRL distribution point..............................................................................................101

Certificate requirements for IP-HTTPS certificates...............................................................102

Network location servers for multi-site DirectAccess...............................................................102

Force tunneling for multi-site DirectAccess.............................................................................103

Connection security rules for multi-site DirectAccess..............................................................103

Additional DirectAccess Resources............................................................................................105

Appendix A: DirectAccess Requirements....................................................................................106

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

IPv6......................................................................................................................................... 108

IPv6 connectivity across the IPv4 Internet...........................................................................108

6to4................................................................................................................................... 109

Teredo............................................................................................................................... 109

IP-HTTPS......................................................................................................................... 109

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

IPsec........................................................................................................................................ 110

Encryption............................................................................................................................ 110

Data integrity........................................................................................................................ 111

Separation of DNS traffic.........................................................................................................111

NRPT exemptions................................................................................................................112

Network location detection.......................................................................................................113

The network location server.................................................................................................113

How network location detection works..................................................................................113

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

Concepts................................................................................................................................. 115

Goals....................................................................................................................................... 115

Infrastructure design plan........................................................................................................115

Custom configuration plan.......................................................................................................116

Integration strategy..................................................................................................................116

Staging strategy....................................................................................................................... 116

Lessons learned...................................................................................................................... 116

DirectAccess Deployment Guide.................................................................................................117

About this guide....................................................................................................................... 117

Planning Your DirectAccess Deployment....................................................................................118

Reviewing your DirectAccess design.......................................................................................118

Reviewing DirectAccess concepts...........................................................................................119

Implementing Your DirectAccess Design Plan............................................................................119

How to implement your DirectAccess design using this guide.................................................119

Checklist: Staging a DirectAccess Deployment..........................................................................121

Checklist: Preparing Your Infrastructure for DirectAccess...........................................................122

Checklist: Preparing Your DirectAccess Server..........................................................................124

Checklist: Implementing a DirectAccess Design for Full Intranet Access....................................127

Checklist: Implementing a DirectAccess Design for Selected Server Access.............................129

Checklist: Implementing a DirectAccess Design for End-to-End Access....................................131

Checklist: Implementing a Redundant DirectAccess Design......................................................132

Checklist: Configuring Network Access Protection (NAP) with DirectAccess..............................133

Checklist: Moving the IPsec Gateway to Another Server............................................................135

Procedures Used in this Guide...................................................................................................136

Add Servers that are Available to DirectAccess Clients before User Logon...............................137

Configure a CRL Distribution Point for Certificates.....................................................................139

Configure Active Directory Certificate Services for CRL Locations.............................................141

Configure Client Authentication and Certificate Mapping for IP-HTTPS Connections.................143

Configure Computer Certificate Autoenrollment..........................................................................144

Configure Connection Security Rules for End-to-end Access.....................................................145

Configure Connection Security Rules for Traffic Between DirectAccess Clients.........................147

Configure Corporate Connectivity Detection Settings.................................................................148

Configure DirectAccess Connection Security Rules for NAP......................................................150

Configure Firewall Rules to Prevent Traffic between Proxy Servers and DirectAccess Servers.152

Configure Force Tunneling for DirectAccess Clients...................................................................154

Configure IIS for Network Location.............................................................................................155

Configure Packet Filters to Allow ICMP Traffic............................................................................157

Configure Packet Filters to Allow Management Traffic to DirectAccess Clients..........................158

Configure Packet Filters to Block Access to Domain Controllers................................................160

Configure Permissions on the Web Server Certificate Template.................................................161

Configure Settings to Confine ICMPv6 Traffic to the Intranet......................................................162

Configure Strong Certificate Revocation Checking for IPsec Authentication..............................163

Configure the DirectAccess IPsec Gateway on a Different Server..............................................164

Configure the Intra-Server Subnet..............................................................................................165

Configure the IPv6 Connectivity Server......................................................................................166

Configure the IPsec Gateway Server..........................................................................................167

Configure the DirectAccess Server as the Network Location Server..........................................168

Configure the DirectAccess Setup Wizard for End-to-End Access.............................................169

Configure the DirectAccess Setup Wizard for Full Intranet Access.............................................172

Configure the DirectAccess Setup Wizard for Selected Server Access......................................175

Configure the NRPT for an IPv6/IPv4 DNS Gateway..................................................................178

Configure the NRPT with Group Policy.......................................................................................179

Connect to the IPv6 Internet.......................................................................................................180

Create DirectAccess Groups in Active Directory.........................................................................181

Install a Network Location Server Certificate on the DirectAccess Server..................................182

Install an IP-HTTPS Certificate...................................................................................................183

Install and Configure IIS for a Network Location Server Certificate............................................185

Install the DirectAccess Feature.................................................................................................186

Remove ISATAP from the DNS Global Query Block List............................................................187

Appendix A – Manual DirectAccess Server Configuration...........................................................188

Configure Internet access components...................................................................................188

Configure intranet access components...................................................................................189

Configure IPsec DoSP.............................................................................................................190

Configure connection security rules.........................................................................................190

DirectAccess server configuration (full intranet access model)............................................190

Connection security rules for client configuration (full intranet access model).....................191

Appendix B – Manual DirectAccess Client Configuration............................................................192

IPv6 transition technology settings..........................................................................................192

NRPT....................................................................................................................................... 193

Appendix C - DirectAccess User Interface Scripting...................................................................194

Script usage............................................................................................................................ 195

Log file..................................................................................................................................... 195

Limitation of the script..............................................................................................................196

Appendix D - DirectAccessConfig.xsd........................................................................................196

DirectAccess Troubleshooting Guide..........................................................................................211

In this guide............................................................................................................................. 211

Introduction to Troubleshooting DirectAccess.............................................................................211

When to use this guide............................................................................................................211

How to use this guide..............................................................................................................212

Additional resources................................................................................................................212

A-Z List of Problem Topics for DirectAccess...............................................................................212

Tools for Troubleshooting DirectAccess......................................................................................213

Network Diagnostics and Tracing...............................................................................................213

Windows Network Diagnostics................................................................................................213

Troubleshooting item in Control Panel.....................................................................................214

Network tracing for DirectAccess.............................................................................................214

Windows Firewall tracing.........................................................................................................215

Command Line Tools..................................................................................................................215

The Netsh.exe Command Line Tool............................................................................................216

netsh dnsclient show state......................................................................................................216

netsh namespace show effectivepolicy and netsh namespace show policy............................217

netsh interface 6to4 show relay...............................................................................................218

netsh interface teredo show state............................................................................................219

netsh interface httpstunnel show interfaces.............................................................................220

netsh interface istatap show state and netsh interface istatap show router.............................221

netsh advfirewall monitor show mmsa.....................................................................................222

netsh advfirewall monitor show qmsa......................................................................................226

netsh advfirewall monitor show consec rule name=all.............................................................229

netsh advfirewall monitor show currentprofile..........................................................................233

netsh interface ipv6 show interfaces........................................................................................233

netsh interface ipv6 show interfaces level=verbose................................................................234

netsh interface ipv6 show route...............................................................................................241

The Ping.exe Command Line Tool..............................................................................................243

The Nslookup.exe Command Line Tool......................................................................................243

The Ipconfig.exe Command Line Tool.........................................................................................244

The Certutil.exe Command Line Tool..........................................................................................247

The Nltest.exe Command Line Tool............................................................................................248

Snap-in Tools.............................................................................................................................. 249

DirectAccess Management.........................................................................................................249

Log files of the DirectAccess Management snap-in.................................................................249

Group Policy Management Console and Editor..........................................................................250

NRPT rules.............................................................................................................................. 250

IPv6 Transition Technologies settings......................................................................................250

Intranet connectivity settings...................................................................................................252

Connection security rules........................................................................................................253

Windows Firewall with Advanced Security..................................................................................253

Event Viewer............................................................................................................................... 254

Certificates.................................................................................................................................. 254

DirectAccess Connectivity Assistant (DCA)................................................................................255

General Methodology for Troubleshooting DirectAccess Connections.......................................255

Troubleshooting DirectAccess Problems....................................................................................261

Problems with the DirectAccess Setup Wizard...........................................................................261

Fixing problems that Prevent You from Running the DirectAccess Setup Wizard.......................262

Fixing Problems Encountered during the Steps of the DirectAccess Setup Wizard....................263

Step 2-DirectAccess Server....................................................................................................264

Connectivity page.................................................................................................................264

Prefix Configuration page.....................................................................................................266

Certificate Components page...............................................................................................267

Step 3-Infrastructure Servers..................................................................................................268

Location page....................................................................................................................... 268

DNS and Domain Controller page........................................................................................268

Step 4-Application Servers......................................................................................................269

Fixing Problems Encountered when Applying the Settings of the DirectAccess Setup Wizard...269

Problems with DirectAccess Connections...................................................................................270

Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server over the

Internet.................................................................................................................................... 271

Cannot Reach the DirectAccess Server from the IPv6 Internet..................................................271

Cannot Reach the DirectAccess Server with 6to4......................................................................272

Cannot Reach the DirectAccess Server with Teredo..................................................................276

Cannot Reach the DirectAccess Server with IP-HTTPS.............................................................280

IP-HTTPS and authenticating proxies.....................................................................................284

DirectAccess Client Connection is Slow.....................................................................................284

Fixing Issues with Creating Protected Connections to the DirectAccess Server.........................285

DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server................................285

IPsec and certificate revocation checking................................................................................289

NAP health enforcement for the intranet tunnel.......................................................................289

Smart card authorization.........................................................................................................290

NTLM authentication failures...................................................................................................290

Detailed analysis of IPsec negotiation.....................................................................................290

DirectAccess Client Cannot Resolve Names with Intranet DNS Servers....................................290

Fixing Issues with Connecting to an Intranet Resource..............................................................292

DirectAccess Client Cannot Access Intranet Resources.............................................................292

Intranet Management Server Cannot Connect to a DirectAccess Client.....................................297

Fixing Problems with Creating Protected Connections to an Intranet Resource.........................299

Selected server access model.................................................................................................299

End-to-end access model........................................................................................................301

Fixing Issues with Network Location Detection...........................................................................302

DirectAccess Client Determines that it is on the Intranet When on the Internet..........................303

DirectAccess Client Determines that it is on the Internet When on the Intranet..........................304

DirectAccess Technical Reference..............................................................................................306

Network Location Detection........................................................................................................306

Network location detection process.........................................................................................307

Network location detection failures and their consequences...................................................308

Troubleshooting network location detection.............................................................................309

DirectAccess Design Guide

This topic describes design considerations for DirectAccess in Windows Server 2008 R2.

For the design considerations of DirectAccess in Microsoft Forefront Unified Access

Gateway (UAG), see the Forefront UAG DirectAccess Design Guide

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

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.

Important

13


Once you have determined your DirectAccess design, you can use the DirectAccess Deployment

Guide to plan and implement your design.

This guide, combined with the DirectAccess Deployment and Troubleshooting Guides, 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

Important

14



Identifying Your DirectAccess Deployment Goals





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

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

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

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

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

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

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

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

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

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

Important

15


Transparent and Automatic Remote Access for DirectAccess Clients





DirectAccess enhances the productivity of mobile workers by connecting their computers

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

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

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

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

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

Ongoing Management of Remote DirectAccess Clients





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

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

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

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

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



Important Important Important

16





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

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

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

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

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

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

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

based on the name needed by the application.

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

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

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

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

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

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

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

connections.

Reduction of Remote Access-based Servers in your Edge Network





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

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

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

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

the corresponding application servers on the intranet.

End-to-end Traffic Protection





Important Important

17




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

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

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

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

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

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

be tunneled to the DirectAccess server.

Multi-factor Credentials for Intranet Access





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

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

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

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

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

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

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

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

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

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

computers or users can establish an inbound tunnel.

Mapping Your Deployment Goals to a DirectAccess Design





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

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

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

discussed in Identifying Your DirectAccess Deployment Goals.

Important Important

18



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.






Important Important

19



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

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

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

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

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

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

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

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

authentication.

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

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

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

the DirectAccess client.

The following figure shows an example of full intranet access.

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.

To demonstrate full intranet access for DirectAccess, set up the DirectAccess test lab

(http://go.microsoft.com/fwlink/?Linkid=150613).

Note

20

http://go.microsoft.com/fwlink/?Linkid=150613

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.

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.

Important Note

21







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.

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

computer credentials and protect the traffic with Encapsulating Security Payload (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.

To demonstrate selected server access, configure the DirectAccess test lab

(http://go.microsoft.com/fwlink/?Linkid=150613) with the Selected Server Access

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

Important Note

22





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.






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.

Note Important

23


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 Payload (ESP) for data confidentiality (encryption) and integrity.

Planning a DirectAccess Deployment Strategy





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

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

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

Which intranet resources will be available to DirectAccess clients? For more information, see Resources Available to DirectAccess Clients.

How do I either enable Internet Protocol version 6 (IPv6) on my intranet or have DirectAccess use my existing IPv6 infrastructure? For more information, see Choose an Intranet IPv6 Connectivity Design.

What options do I have to make Internet Protocol version 4 (IPv4)-only resources available for DirectAccess clients? For more information, see Choose Solutions for IPv4-only Intranet Resources.

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

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

Which computers do I need to designate as management servers that will initiate connections to DirectAccess clients? For more information, see Design for Remote Management.

What packet filters do I need to add to my firewalls and computers in my organization? For more information, see Design Packet Filtering for DirectAccess.

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

Important

24


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.

Should I use the DirectAccess Connectivity Assistant (DCA)? For more information, see Use the DirectAccess Connectivity Assistant (DCA).

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.

Important

25


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 applications running on versions of Windows:

Windows 7, Windows Server 2008 R2, Windows Vista, and Windows Server 2008 support an IPv6 protocol stack and all built-in components and system services are IPv6-capable. These versions of Windows are highly recommended.

Windows XP and Windows Server 2003 have an IPv6 protocol stack, but many built-in components and system services and applications are not IPv6-capable. Therefore, in most cases, applications running on computers running Windows XP or Windows Server 2003 are not reachable by DirectAccess clients over IPv6. For the solutions for providing DirectAccess connectivity to applications running on Windows XP and Windows Server 2003-based computers, see Choose Solutions for IPv4-only Intranet Resources.

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.

26

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 such as a NAT64/DNS64. For the solutions for providing

connectivity for DirectAccess clients to IPv4-only resources, see Choose Solutions for IPv4-only

Intranet Resources.

Using an IPv4-only intranetIt is possible to use DirectAccess with an IPv4-only intranet, but you must use a NAT64/DNS64

device between your DirectAccess clients and your intranet and you no longer have the ability to

remotely manage DirectAccess clients from the intranet. For information about providing

connectivity for DirectAccess clients to an IPv4-only intranet, see Choose Solutions for IPv4-only

Intranet Resources.

When the DirectAccess client physically connects to your IPv4-only intranet or an IPv4-only

subnet of your intranet, it is possible in some situations for the client to use Internet Protocol over

Secure Hypertext Transfer Protocol (IP-HTTPS) to access the intranet through a proxy server and

the DirectAccess server, instead of using normal IPv4-based connectivity. This can cause

problems for some applications. To prevent this behavior, configure Windows Firewall rules to

block traffic between your proxy servers and your DirectAccess servers. For more information,

see Configure Firewall Rules to Prevent Traffic between Proxy Servers and DirectAccess

Servers.

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.

27

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

28

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

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.

The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) uses ISATAP

for the simulated intranet.

Important Note Note

29



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

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

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

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

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

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

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

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

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

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

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

intranet.

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

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

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

that is connected to the IPv6 Internet.

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

Note Important

30


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. A combination of IPv6/IPv4 translator with IPv6/IPv4 DNS gateway is a NAT64 with DNS64.

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 NAT64 and DNS64 device to provide

IPv6/IPv4 traffic translation and access to IPv4-only application servers on an intranet.

31

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

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.

Important

32









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.

To demonstrate full intranet access for DirectAccess, set up the DirectAccess test lab







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.

Important Note Important

33




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.

To demonstrate selected server access, configure the DirectAccess test lab

(http://go.microsoft.com/fwlink/?Linkid=150613) with the Selected Server Access

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

End-to-End Access





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

communications between DirectAccess clients and all intranet servers perform IPsec peer

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

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

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

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

Note Important

34





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

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.

Important

35


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.

Important

36



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

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

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

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

DirectAccess Setup Wizard. 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 Payload (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.

To demonstrate remote management, configure the DirectAccess test lab

(http://go.microsoft.com/fwlink/?Linkid=150613) with the Remote Management extension


Design for Intranet Server Availability Prior to User Logon

The intranet servers that are available to a DirectAccess client computer depend on whether the

user has logged on. By default, the DirectAccess Setup Wizard for the full intranet access model

creates connection security rules for the following Internet Protocol security (IPsec) tunnels:

Infrastructure tunnel

This rule provides connectivity to specific intranet Domain Name System (DNS) servers and

uses only computer account-based credentials for authentication. This is a required

connection security rule. If the specified DNS servers are also domain controllers, you do not

have to add these domain controllers to the list of intranet servers that are available prior to

user logon. If the domain controllers that you want to make accessible to DirectAccess clients

are separate from the specified DNS servers, you must add them to the intranet servers that

are available prior to user logon.

Intranet tunnel

Notes

37



This rule provides connectivity to all intranet resources reachable by the DirectAccess client

computer and uses a combination of computer and user account-based credentials for

authentication. This is a required connection security rule.

Management tunnel

This rule provides connectivity to DirectAccess client computers on the Internet from

management servers on the intranet and uses only computer-based credentials for

authentication. Management servers can remotely manage DirectAccess clients on the

Internet, such as computers that create remote desktop connections. This is an optional

connection security rule, depending on whether you have defined the IPv6 addresses of

management servers in Step 3 of the DirectAccess Setup Wizard. If you do not configure

management servers, these computers will not be able to initiate communications with

DirectAccess clients until the user has logged on.

The security settings for the connection security rules for the infrastructure and management

tunnels are the same. Therefore, DirectAccess clients can also use the management tunnel rule

to initiate communications with intranet servers in the same way as the infrastructure tunnel rule.

Because these connection security rules do not use user account-based credentials,

DirectAccess client computers will only have connectivity to those intranet endpoints that are

specified for the infrastructure and management tunnel rules before user logon.

Additional computers that should be available to DirectAccess client computers prior to user

logon are the following:

Domain controllers, which are not DNS servers and have already been configured in Step 3 of the DirectAccess wizard

Additional intranet DNS servers that have not been configured in Step 3 of the DirectAccess wizard

When using Network Access Protection (NAP), Health Registration Authorities (HRAs) and remediation servers

Servers needed for computer logon operations and system health updates, such as operating system and anti-malware update servers

If you have configured force tunneling and DirectAccess client computers need to access the Internet prior to user logon, your intranet proxy servers

One way to determine the additional intranet servers that must be made available to the services

of a DirectAccess client computer is to analyze the Windows Logs and Application and Services

Logs with Event Viewer and note the system services that were unable to start or complete

operations prior to computer logon. If the cause of the problem is due to an inability to reach an

intranet server and if these failed system services are crucial to the operation of the computer, the

intranet server for that service should be added to list of servers that are available prior to user

logon.

To add to the set of servers that are available prior to user logon, you can do the following:

Use the Management page of step 3 of the DirectAccess Setup Wizard, which adds more Internet Protocol version 6 (IPv6) addresses to the list of permitted endpoints for the management tunnel.

38

This is the recommended method because it is much easier to configure, especially if you are

not managing a customized DirectAccess deployment and can run the DirectAccess Setup

Wizard without modifying one or more custom settings. For more information, see Add

Servers that are Available to DirectAccess Clients before User Logon.

Use Netsh.exe commands to manually add more IPv6 addresses to the list of permitted endpoints on the infrastructure or management tunnels

This is not recommended because it must be done manually with multiple commands and if

done incorrectly can impair connectivity. However, if you are managing a customized

DirectAccess deployment and cannot run the DirectAccess Setup Wizard without modifying

one or more custom settings, you must use this method. If you have not already defined

management servers with the DirectAccess Setup Wizard, use the infrastructure tunnel.

Otherwise, use the management tunnel. For more information, see Add Servers that are

Available to DirectAccess Clients before User Logon.

Design Packet Filtering for DirectAccess





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

types of traffic:

DirectAccess client traffic to and from DirectAccess servers on the Internet

DirectAccess server traffic to and from the intranet

Encapsulated DirectAccess client traffic to and from the intranet

Teredo discovery traffic for DirectAccess clients located behind network address translators (NATs)

Management server traffic to DirectAccess clients

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

Packet Filters for Your Internet Firewall

Packet Filters for Your Intranet Firewall

Confining ICMPv6 Traffic to the Intranet

Packet filters for Teredo Connectivity

Packet Filters for Management Computers

Packet Filters for Your Internet Firewall



Important Important

39




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.


40


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.


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:

Important Important

41



Internet Control Message Protocol (ICMP) traffic, for both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), is exempted from Internet Protocol security (IPsec) protection

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

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

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

Any computer with a Teredo or 6to4 client can send Internet Control Message Protocol for IPv6 (ICMPv6) traffic to intranet locations through the DirectAccess server to probe for valid intranet destination IPv6 addresses. The amount of this traffic is limited by the Denial of Service Protection (DoSP) component of the DirectAccess server.

A malicious user on the same subnet as a Teredo-based DirectAccess client can determine the IPv6 addresses of intranet servers by capturing ICMPv6 Echo Request and Echo Reply message exchanges.

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

following:

Configure the global IPsec settings for the Group Policy object for DirectAccess clients to not exempt ICMP traffic from IPsec protection (from the IPsec Settings tab for the properties of the Windows Firewall with Advanced Security snap-in).

Configure the global IPsec settings for the Group Policy object for the DirectAccess server to not exempt ICMP traffic from IPsec protection (from the IPsec Settings tab for the properties of the Windows Firewall with Advanced Security snap-in).

For the Group Policy object for the DirectAccess server, create a new connection security rule that exempts ICMPv6 traffic when it is tunneled from the DirectAccess server.

For the Group Policy object for DirectAccess clients, create a new connection security rule that exempts ICMPv6 traffic when it is tunneled to the DirectAccess server.

The last two connection security rules allow unprotected ICMPv6 traffic to and from the IPv6

addresses of the DirectAccess client and server on the Internet to aid in troubleshooting. For

example, you can use the Ping.exe tool from the DirectAccess client to test reachability to the

DirectAccess server without IPsec protection.

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.

For the steps to configure the global IPsec settings and connection security rules, see Configure

Settings to Confine ICMPv6 Traffic to the Intranet in the DirectAccess Deployment Guide.

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:

42

Disable Teredo client functionality on your DirectAccess clients

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

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

State to Disabled.

Disable Teredo server and relay functionality on your DirectAccess server

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

level command prompt on your DirectAccess server.

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

from the DirectAccess server, remove it.

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

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

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

lower performance and higher overhead than Teredo-based connections.

Packet filters for Teredo Connectivity





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

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

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

management servers.

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

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

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

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

overhead than Teredo-based connections.

Packet filters to allow inbound ICMP 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

Important

43


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

all of your intranet hosts. If your intranet is using a NAT64 to translate IPv6 traffic to Internet

Protocol version 4 (IPv4) traffic, you must also allow inbound ICMP for IPv4 (ICMPv4) Echo

Request messages on all of your intranet hosts.

For information about how to configure packet filters for ICMPv6 and ICMPv4 Echo Request

traffic, see Configure Packet Filters to Allow ICMP Traffic.

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

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

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

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

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

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

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

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

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

Packet Filters for Management Computers





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

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

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

can do one of the following:

Configure your existing set of inbound firewall rules for management traffic so that they also apply to the public and private profiles and have edge traversal enabled. Although easier to configure, this option is not recommended because the inbound rules might allow greater exposure what is intended for DirectAccess management functionality.

Create a duplicate set of inbound firewall rules for your management traffic in the Group Policy object for DirectAccess clients so that they only apply to the public and private profiles, have the appropriate source Internet Protocol version 6 (IPv6) addresses of management

Important

44


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:

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,

Note Important

45



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


For more information about Windows Firewall categories, see INetFwProduct Interface


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

Important

46







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.

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)







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

Note Note

47

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.

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

48



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.

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=IntranetIPv6AddressSpace endpoint2=Any

localtunnelendpoint=DirectAccessServerIPv6Address 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



Note Important

49



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

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.

Important Important

50



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.

The DirectAccess server in the DirectAccess test lab (http://go.microsoft.com/fwlink/?

Linkid=150613) does not need a default route or specific routes for the intranet address

space because it is directly connected to a single-subnet simulated Internet and a single-

subnet simulated intranet.

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:

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.

Note Note

51


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 not use a built-in security group, such as Domain Computers or Domain Users,

for the security group for DirectAccess clients.

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 attached to a network that has been

assigned 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) tunnel endpoint are not active. As a result,

DirectAccess clients on the Internet cannot establish the infrastructure and intranet tunnels with

the DirectAccess server.

Important Warning

52


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.

Active Directory Sites and Services configurationWhen you are using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) and 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:1::/64, the equivalent IPv6 address prefix for the IPv6 subnet object is

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

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

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

An IPv6 subnet for the range 2001:0:WWXX:YYZZ::/64, in which WWXX:YYZZ is the colon-hexadecimal version of the first consecutive public IPv4 address (w.x.y.z) assigned to the Internet interface of the DirectAccess server. This IPv6 prefix is for Teredo-based DirectAccess clients.

If you have a native IPv6 infrastructure, an IPv6 subnet for the range 48-bitIntranetPrefix:5555::/64, in which 48-bitIntranetPrefix is the 48-bit native IPv6 prefix that is

53

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.

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


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

Important

54




Contoso’s public Web site and Contoso employees on the Contoso intranet use

http://www.contoso.com to access Contoso’s intranet Web site. A Contoso employee with their

laptop that is not a DirectAccess client on the intranet that accesses http://www.contoso.com sees

the intranet Contoso Web site. When they take their laptop to the local coffee shop and access

that same URL, they will see the public Contoso Web site.

When a DirectAccess client is on the Internet, the Name Resolution Policy Table (NRPT) sends

DNS name queries for intranet resources to intranet DNS servers. A typical NRPT for

DirectAccess will have a rule for the namespace of the organization, such as contoso.com for the

Contoso Corporation, with the Internet Protocol version 6 (IPv6) addresses of intranet DNS

servers. With just this rule in the NRPT, when a user on a DirectAccess client on the Internet

attempts to access the uniform resource locator (URL) for their Web site (such as

http://www.contoso.com), they will see the intranet version. Because of this rule, they will never

see the public version of this URL when they are on the Internet.

If you want users on DirectAccess clients to see the public version of this URL when they are on

the Internet, you must add the fully qualified domain name (FQDN) of the URL as an exemption

rule to the NRPT of DirectAccess clients. However, if you add this exemption rule, users on

DirectAccess clients will never see the intranet version of this URL when they are on the Internet.

For split-brain DNS deployments, you must list the FQDNs that are duplicated on the Internet and

intranet and decide which resources the DirectAccess client should reach, the intranet version or

the public (Internet) version. For each name that corresponds to a resource for which you want

DirectAccess clients to reach the public version, you must add the corresponding FQDN as an

exemption rule to the NRPT for your DirectAccess clients.

In a split-brain DNS environment, if you want both versions of the resource to be available,

configure your intranet resources with alternate names that are not duplicates of the names that

are being used on the Internet and instruct your users to use the alternate name when on the

Intranet. For example, configure and use the alternate name www.internal.contoso.com for the

intranet name www.contoso.com.

In a non-split-brain DNS environment, the Internet namespace is different from the intranet

namespace. For example, the Contoso Corporation uses contoso.com on the Internet and

corp.contoso.com on the intranet. Because all intranet resources use the corp.contoso.com DNS

suffix, the NRPT rule for corp.contoso.com routes all DNS name queries for intranet resources to

intranet DNS servers. DNS name queries for names with the contoso.com suffix do not match the

corp.contoso.com intranet namespace rule in the NRPT and are sent to Internet DNS servers.

With a non-split-brain DNS deployment, because there is no duplication of FQDNs for intranet

and Internet resources, there is no additional configuration needed for the NRPT. DirectAccess

clients can access both Internet and intranet resources for their organization.

The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) uses

contoso.com on the simulated Internet and corp.contoso.com on the simulated intranet.

Note

55


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.

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

56



DNS servers cannot be reached or if there are other types of DNS errors, the intranet server

names will not be leaked to the subnet through local name resolution.

Use local name resolution if the internal network DNS servers determined that the name does not exist or if the internal network DNS servers are not reachable and the DirectAccess client computer is on a private network

This option is moderately secure because it allows the use of local name resolution on a

private network when the intranet DNS servers are unreachable.

Use local name resolution if there is any type of error when attempting to resolve the name using internal network DNS servers

This is the least secure option because the names of intranet network servers can be leaked

to the local subnet through local name resolution.

Choose the option that complies with your security requirements.

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 namespace 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 namespace 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 namespace rules for the 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

57

external Web server. To prevent users who are not on the Contoso intranet from accessing

the site, the external Web site only allows requests from the Internet Protocol version 4 (IPv4)

Internet address of the Contoso Web proxy. Therefore, intranet users can access the Web

site because they are using the Contoso Web proxy but DirectAccess users cannot because

they are not using the Contoso Web proxy. By configuring an NRPT exemption rule for

test.contoso.com that uses the Contoso Web proxy, Web page requests for test.contoso.com

will be routed to the intranet Web proxy server over the IPv4 Internet.

You can also configure NRPT rules from Computer Configuration\Policies\Windows Settings\

Name Resolution Policy in the Group Policy object for DirectAccess clients. 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).

The DirectAccess Setup Wizard in the DirectAccess test lab

(http://go.microsoft.com/fwlink/?Linkid=150613) creates two rules in the NRPT: a

namespace rule for corp.contoso.com with the IPv6 address of the intranet DNS server

and an exemption rule for nls.corp.contoso.com. You can view the NRPT rules configured

with Group Policy from CLIENT1 by running the netsh namespace show policy

command at a command prompt. You can view the active NRPT rules with the netsh

namespace show effectivepolicy command.

DNS server querying behavior for DirectAccess clientsA DirectAccess client with active rules in the NRPT is configured with two sets of DNS servers;

the DNS servers in the namespace rules of the NRPT and interface-configured DNS servers. If

an FQDN matches a namespace rule, only the DNS servers specified in the namespace rule are

queried. Even if the DNS servers in the matching namespace rule are not reachable, the

DirectAccess client does not query the interface-configured DNS servers.

A DirectAccess client with active rules in the NRPT will only query interface-configured DNS

servers in the following cases:

The FQDN matches an exemption rule.

The FQDN does not match any NRPT rules.

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

Notes

58


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

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 crl.contoso.com is

resolvable using Internet DNS servers.

Design Your PKI for DirectAccess



Note Note Important

59



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.

The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) uses

autoenrollment of computer certificates to simplify computer certificate enrollment for

members of the corp.contoso.com domain.

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) corresponding to the Internet name of the DirectAccess server, which must be resolvable with Internet-based DNS servers.

For the Enhanced Key Usage field, the Server Authentication object identifier (OID).

For the CRL Distribution Points field, a certificate revocation list (CRL) distribution point that is accessible by DirectAccess clients that are connected to the Internet.

The HTTPS certificate for the network location server must have the following properties:

In the Subject field, either an Internet Protocol (IP) address of the intranet interface of the network location server or the FQDN of the network location uniform resource locator (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.

Note

60



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 Permissions on the Web Server Certificate Template

Install a Network Location Server Certificate on the DirectAccess Server

Install an IP-HTTPS Certificate

The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) uses manually

enrolled certificates on the network location server and the DirectAccess server.

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 points must be highly available.

CRL distribution points can be accessed through Web servers using an HTTP-based URL, such

as http://crl.corp.contoso.com/crld/corp-DC1-CA.crl.

Checking of CRL distribution points based on a universal naming convention (UNC) path,

such as \\crl.corp.contoso.com\crld\corp-DC1-CA.crl, is disabled by default in Windows 7

and Windows Server 2008 R2. For information about how to enable checking of UNC-

based CRL distribution points, see the following KnowledgeBase article

(http://go.microsoft.com/fwlink/?LinkId=196867). UNC-based CRL distribution points can

be used only for intranet CRL locations. For the Internet location of the CRL distribution

point, you should always use an HTTP-based URL. DirectAccess clients that use IP-

HTTPS to send IPv6 packets across the IPv4 Internet check the Internet CRL distribution

Note Note

61



point. IP-HTTPS-based DirectAccess clients can be located behind proxy servers that do

not forward file and printer sharing traffic.

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.

For ease of configuration, the DirectAccess test lab (http://go.microsoft.com/fwlink/?

Linkid=150613) uses the URL http://crl.contoso.com/crld/corp-DC1-CA.crl for both

Internet and intranet CRL distribution points. For the intranet, an A record in the intranet

DNS resolves the name crl.contoso.com to the intranet IPv4 address of DA1, the

DirectAccess server. For the Internet, an A record in the Internet DNS resolves the name

crl.contoso.com to an Internet IPv4 address of DA1.

Using a commercial CA for the IP-HTTPS certificateYou can also use a certificate issued from a commercial CA for the IP-HTTPS certificate installed

on the DirectAccess server. With a commercial CA certificate, you do not have to create a highly-

available Internet CRL distribution point. This is already set up and maintained by the commercial

CA vendor. If you use a commercial CA certificate, you must also ensure that the root CA

certificate for the IP-HTTPS certificate is installed in the Trusted Root Certification Authorities

folder in the computer certificate store of your DirectAccess clients.

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.

Note Note

62


If you enable strong CRL checking and the DirectAccess server cannot reach the CRL

distribution point, certificate-based IPsec authentication for all DirectAccess connections

will fail.

If you are using Network Access Protection (NAP) with DirectAccess and you enable

strong CRL checking, certificate-based IPsec authentication for all DirectAccess

connections will fail. Health certificates do not contain CRL distribution points because

their lifetime is on the order of hours, instead of years for computer certificates.

Smart cards for additional authorizationTo use smart cards with IPsec tunnel mode authorization, you must first have a PKI deployment

and a smart card infrastructure. After your smart card deployment has been completed, you

enable smart card authorization on the Connectivity page of Step 2 of the DirectAccess Setup

Wizard.

You should design your PKI to replicate the entire smart card certificate chain to the

current user certificate store in a timely manner. If the PKI is slow in replicating the

certificate chain, users will obtain a smart card certificate and leave the intranet, but be

unable to use smart card authorization. To correct this condition, they might have to

return to the intranet and logon with their smart card credentials to force the PKI to install

the entire certificate chain in the local user’s certificate store.

Using Suite B certificates for DirectAccessSuite B is a set of cryptographic algorithms defined by the National Security Agency (NSA). You

can use Suite B-based certificates for DirectAccess by deploying a PKI that uses Suite B

cryptographic algorithms. For information about deploying a Windows-based PKI that supports

Suite B and issues Suite B-based certificates, see Suite B PKI in Windows Server 2008


Appendix A of this white paper describes setting the IKEFlags registry value to 0x40 to

disable the use of the Authenticating IP (AuthIP). DirectAccess cannot function without

AuthIP. Therefore, you must not set this registry value in a DirectAccess deployment.

AuthIP in Windows 7 and Windows Server 2008 R2 supports the use of Diffie Hellman

(DH) for key exchange for AuthIP, which you enable with the netsh advfirewall set

global mainmode mmforcedh yes command.

Design Your Web Servers for DirectAccess





Note Note Note Important Important

63



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)

The intranet CRL distribution points can also be based on a universal naming convention

(UNC) path of a file server.

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 (required)

For more information, see Configure IIS for Network Location in the DirectAccess Deployment

Guide.

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.

The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) uses an

application server as the network location server and the DirectAccess server as the

Internet and intranet CRL distribution point.

Note

64


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

Important

65


access to IPv4 Internet resources, even though they are directly connected to the IPv4 Internet.

To configure force tunneling, you must do the following:

Configure IPv4 Internet access for your DirectAccess clients

Enable force tunneling on DirectAccess clients

Add a special entry in the NRPT on DirectAccess clients

Configure your DirectAccess clients to always use the IP-HTTPS transition technology

Configure your Internet firewall filters to allow only inbound and outbound Secure Sockets Layer (SSL) traffic to and from the DirectAccess server

The following sections describe these elements of configuration in more detail. For more

information about configuring the settings for DirectAccess clients, see Configure Force Tunneling

for DirectAccess Clients 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.

Configure IPv4 Internet accessTo 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 (NAT64) and IPv6/IPv4 DNS gateway (DNS64) in front of your IPv4-based proxy server. The NAT64/DNS64 will translate IPv6-based proxy requests to IPv4-based requests before they are serviced by your IPv4-based proxy server.

Enable force tunnelingYou enable force tunneling on DirectAccess clients with 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.

Modify the NRPTTo 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 DNS64.

Notes

66

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 DNS64

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

Configure the use of IP-HTTPSTo configure DirectAccess clients so that they always use IP-HTTPS, do the following for the

Group Policy object for DirectAccess clients:

Disable the 6to4 transition technology with the Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies\6to4 State Group Policy setting.

Disable the Teredo transition technology with the Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies\Teredo State Group Policy setting.

Enable the IP-HTTPS transition technology with the Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies\IP-HTTPS State Group Policy setting.

Modify Internet firewall settingsIf you followed the directions in Packet Filters for Your Internet Firewall, you configured your

Internet firewall to allow the following traffic for the DirectAccess server:

Protocol 41 inbound and outbound for 6to4 traffic

User Datagram Protocol (UDP) destination port 3544 inbound and UDP source port 3544 outbound for Teredo traffic

Transmission Control Protocol (TCP) destination port 443 inbound and TCP source port 443 outbound for IP-HTTPS traffic

Because a force tunneling deployment only uses IP-HTTPS traffic, you should remove the

following packet filters for the DirectAccess server on your Internet router:



67

If your DirectAccess server is directly attached to the Internet, use the following commands at an

administrator-level Command Prompt:

netsh advfirewall firewall set rule dir=in name=”Core Networking – Teredo (UDP-In)” enable=no

This command blocks inbound Teredo traffic.

netsh advfirewall firewall add rule name=”Protocol 41 (6to4)” dir=in action=block profile=public,private protocol=41

This command blocks 6to4 traffic on the Internet interface.

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

Important

68


Endpoints: Endpoint 1 address for your intranet IPv6 prefix, Endpoint 2 address for your intranet IPv6 prefix

Requirements: No authentication

Protocols and Ports: Any

Profile: Domain, Private, and Public

3. Create an inbound rule for each application that needs to accept unsolicited inbound connection requests.

For example, for Remote Desktop, the inbound rule has the following properties:

Rule Type: Port

Protocols and Ports: Transmission Control Protocol (TCP) 3389

Action: Allow the connection if it is secure, Require the connections to be encrypted

Profile: Private and Public

To configure this Windows Firewall rule for Remote Desktop using Netsh.exe, you can use

the following command:

netsh advfirewall firewall add rule name=RemoteDesktop profile=public,private

program=system action=allow security=authenc protocol=tcp localport=3389

For additional protection, you can require protection for all inbound connections to the

DirectAccess client. You can specify this when creating the rule in the following ways:

From the Windows Firewall with Advanced Security snap-in, on the Requirements page, select Require authentication for inbound connections and request authentication for outbound connections instead of Request authentication for inbound and outbound connections.

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

Important

69


connectivity detection is separate from network location detection. A DirectAccess client can

successfully detect corporate connectivity when it is directly connected to the intranet or when it is

roaming on the Internet. Corporate connectivity determination is used for the following:

Active Directory® Domain Services (AD DS) domain members detect corporate connectivity before initiating updates of Group Policy settings.

Network Access Protection (NAP) clients use successful corporate connectivity detection to perform another health check if the NAP client determines that it is unhealthy because it could not reach a NAP health policy server in a previous heath check.

DirectAccess clients use corporate connectivity detection to determine when to use Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS). If the DirectAccess client cannot access intranet resources using Teredo, it attempts to connect to the DirectAccess server using IP-HTTPS.

Corporate connectivity detection relies on the ability to perform the following checks for different

purposes, depending on the computer’s configuration:

Resolve a specific intranet fully qualified domain name (FQDN) name to a specific Internet Protocol version 6 (IPv6) address.

Determine whether an Internet Protocol security (IPsec) security association (SA) has been established for an IPv6 address that is based on the IPv6 prefix of the intranet.

Access a specific intranet Web site.

The DirectAccess Setup Wizard automatically configures the following for corporate connectivity

detection:

The intranet-specific name and IPv6 address and registers the corresponding AAAA record in an intranet Domain Name System (DNS) server.

The IPv6 prefix of the intranet.

The DirectAccess Setup Wizard does not automatically configure the settings and infrastructure

needed for DirectAccess clients to access a specific intranet Web site. This additional

configuration is required for branch scenarios in which a Web proxy server is between the

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

70

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

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

Note Note Important

71


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


DirectAccess and third-party VPN clientsWhen deploying DirectAccess with third-party VPN clients, it may be necessary to set the

following registry values to enable the seamless coexistence of the two remote access solutions:

Some third-party VPN clients do not create connections in the Network Connections folder. This can cause DirectAccess to determine it has no intranet connectivity when the VPN connection is established and connectivity to the intranet exists. This condition occurs when third-party VPN clients register their interfaces by defining them as Network Device Interface Specification (NDIS) ENDPOINT types. You can enable coexistence with these types of VPN clients by setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\ShowDomainEndpointInterfaces (REG_DWORD) registry value to 1 on DirectAccess clients.

Some third-party VPN clients use a split-tunneling configuration, which allows the VPN client computer to access the Internet directly, without having to send the traffic through the VPN connection to the intranet. Split-tunnel configurations typically leave the Default Gateway setting on the VPN client as either not configured or as all zeros (0.0.0.0) . You can confirm this behavior by establishing a successful VPN connection to your intranet and using the Ipconfig.exe tool at command prompt to display the Default Gateway setting for the VPN connection. By default, the DirectAccess client does not identify these types of configurations. To configure DirectAccess clients to detect these types of VPN client configurations and coexist with them, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\Internet\ EnableNoGatewayLocationDetection (REG_DWORD) registry value to 1.

For more information about third-party VPN clients that provide their own implementations of

Internet Protocol security (IPsec), see Recommendations for Virtual Private Network Client

Coexistence with the Internet Protocol Security Implementation in Microsoft Windows


72




Use the DirectAccess Connectivity Assistant (DCA)

The DirectAccess Connectivity Assistant (DCA) is a free Solution Accelerator download that helps

streamline end-user support for DirectAccess.

The DCA installs on DirectAccess clients and adds an icon to the notification area of the desktop.

With this icon, users can determine their intranet connectivity status. The DCA also provides tools

to help users reconnect on their own if problems arise and creates diagnostics to help mobile

users provide IT staff with key information.

For more information, see Deploying, Managing, and Using the DirectAccess Connectivity

Assistant.

To download the DCA, see Microsoft DirectAccess Connectivity Assistant







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.

Important Important

73




For more information, see the following topics:



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


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.

Important Note

74








To provide service redundancy for DirectAccess, use Forefront UAG for scalability, high-

availability, and enhanced management for a DirectAccess deployment. For more information,

see UAG and DirectAccess (http://go.microsoft.com/fwlink/?LinkId=159955).

To provide hardware redundancy, DirectAccess can be configured inside a Hyper-V Failover

cluster. The recommended configuration consists of two Hyper-V hosts with failover clustering

supporting a single shared DirectAccess server in a virtual machine. The two Hyper-V hosts

protect the system from a single node failure for the DirectAccess server.

In addition to the DirectAccess Setup Wizard, you need the following configuration:

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

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

A fourth network adapter is a requirement if the Hyper-V clustering solution is using iSCSI interfaces.

The Hyper-V servers are joined to the domain and connected to the appropriate networks.

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

Important

75



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

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.






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

Important Important

76



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

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.

The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) uses a

separate application server as the network location server, not the DirectAccess server.

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

Note Note

77


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.

Authentication and authorization for the network location URLA DirectAccess client computer performs intranet detection when it starts up on the network,

before the user has logged on. The Network Location Awareness service on the DirectAccess

client must be able to access the network location URL using the credentials of the computer

account. Therefore, you must choose a network location URL that does not require authentication

or authorization with user account credentials. If authentication or authorization with user account

credentials is required to access the network location URL, the DirectAccess client computer will

not successfully detect the intranet, which might impair intranet connectivity.

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.

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.

78

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






Certificate revocation list (CRL) distribution points are a critical component of the following

aspects of DirectAccess:

DirectAccess clients use certificate revocation checking to validate the DirectAccess server certificate for Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) connections. Without a reachable CRL distribution point on the Internet, all IP-HTTPS-based DirectAccess connections will fail.

DirectAccess clients use certificate revocation checking to validate the certificate for the HTTPS connection to the network location server. Without a reachable CRL distribution point on the intranet, intranet detection fails, which can impair intranet connectivity for DirectAccess clients.

Where to Place the CRL Distribution Points





Important Important Important

79






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.

For ease of configuration, the DirectAccess test lab (http://go.microsoft.com/fwlink/?

Linkid=150613) uses the URL http://crl.contoso.com/crld/corp-DC1-CA.crl for both

Internet and intranet CRL distribution points. For the intranet, an A record in the intranet

DNS resolves the name crl.contoso.com to the intranet IPv4 address of DA1, the

DirectAccess server. For the Internet, an A record in the Internet DNS resolves the name

crl.contoso.com to an Internet IPv4 address of DA1.

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

Note Important

80



over Secure Hypertext Transfer Protocol (IP-HTTPS)-based connections to the DirectAccess

server.

For CRL distribution point redundancy, you can do the following:

For a single CRL distribution point, you can configure redundancy for Internet Information Services (IIS)-based Web servers or Windows Server 2008 R2 or Windows Server 2008-based file servers with Network Load Balancing. For more information, see Overview of the Network Load Balancing Deployment Process (http://go.microsoft.com/fwlink/?LinkId=159956).

You can also configure multiple CRL distribution points on different Web or file servers on your intranet or the Internet.

Planning DirectAccess with Network Access Protection (NAP)





Network Access Protection (NAP) for DirectAccess connections is 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.

For more information about the DirectAccess with NAP solution, see DirectAccess with

Network Access Protection (NAP).

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

Important Note

81




-section:system.webServer/security/authentication/windowsAuthentication /-

providers.[value='Negotiate'] command.

Configuration changes for the infrastructure tunnelTo allow DirectAccess clients the ability to obtain a health certificate from an HRA on the intranet

and to remediate their noncompliant system health, you must make the following configuration

changes:

For the Group Policy object for DirectAccess clients, add the Internet Protocol version 6 (IPv6) addresses of your intranet HRAs and remediation servers to the set of accessible endpoints in the DirectAccess Policy-ClientToDnsDc connection security rule.

For the GPO for DirectAccess servers, add the IPv6 addresses of your intranet HRAs and remediation servers to the set of accessible endpoints in the DirectAccess Policy-DaServerToDnsDc connection security rule.

If you are using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) for intranet IPv6

connectivity, you must assign static Internet Protocol version 4 (IPv4) addresses to your HRAs

and remediation servers. If you are using native IPv6 connectivity, you must assign static IPv6

addresses to your HRAs and remediation servers.







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.

Note

82

For reporting mode and deferred enforcement mode, there are no changes that need to be made

to the settings of the DirectAccess server Group Policy object for the intranet tunnel. For full

enforcement mode, you must require health certificates for the Computer certificate

authentication method and enable authorization for IPsec tunneling in the DirectAccess Policy-

DaServerToCorp connection security rule.

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.







You can demonstrate NAP functionality for DirectAccess with the DirectAccess with NAP

test lab (http://go.microsoft.com/fwlink/?LinkId=186697).

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.

Notes Important

83






For example, you need to ensure that the global main mode IPsec settings of your DirectAccess

clients match the global main mode IPsec settings of your SDI deployment. The DirectAccess

Setup Wizard will configure default global main mode IPsec settings for DirectAccess clients to

match those of the default global main mode IPsec settings for Windows Vista and Windows

Server 2008. If you have changed the global main mode IPsec settings for your SDI deployment

from their default values, you need to configure the global main mode IPsec settings of the Group

Policy object for DirectAccess clients created by the DirectAccess Setup Wizard to match them.

Additional design considerations for deploying DirectAccess in an existing SDI environment are

the following:

To allow for Teredo client discovery, you should exempt Internet Control Message Protocol (ICMP) from IPsec protection in your SDI deployment.

If you are only using SDI for data integrity, you must use Encapsulating Security Payload (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





Important Important

84





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

Planning for Multi-site DirectAccess

Capacity Planning for DirectAccess Servers





Capacity planning for DirectAccess servers can be done in the following ways:

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 Teredo clientsBy default, the DirectAccess server can support 128 concurrent Teredo-based DirectAccess

clients based on the default maximum number of entries in the neighbor cache. To increase the

number of entries allowed in the neighbor cache, run the netsh interface ipv6 set global

neighborcachelimit=Maximum command, in which Maximum is the maximum number of

expected concurrent Teredo-based DirectAccess clients.

Important

85



Moving the IPsec gateway function to a separate serverThe DirectAccess server as configured by the DirectAccess Setup Wizard has the following

functions:

Teredo server and relay

6to4 relay

Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) server

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) router

Native Internet Protocol version 6 (IPv6) router

IPsec gateway

It is possible to move these functions to other computers. One configuration that supports

scalability for many DirectAccess connections is to move the IPsec gateway and ISATAP router

functions to another computer with IPsec offload hardware, which can handle the processor-

intensive cryptographic operations and support many IPsec tunnels. The following figure shows

an example.

In this example, Server 1 provides the 6to4 relay, Teredo server, and IP-HTTPS server functions

and Server 2 provides ISATAP router and IPsec gateway functions. DirectAccess clients use

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.

86

Because Server 2 computer is a native IPv6 router, you must configure outbound firewall rules on the interface on the intra-server subnet to prevent reachability to intranet domain controllers.

The tunnel endpoints in the Group Policy objects for the DirectAccess clients and server must specify the native IPv6 address of Server 2’s interface on the intra-server subnet.

With this configuration, Server 2 acts as the IPsec intranet and infrastructure tunnel endpoint,

providing decryption services for packets from DirectAccess clients and encryption services for

packets to DirectAccess clients.

The following figure shows an example of the traffic between DirectAccess clients and intranet

servers for the full intranet access model.

The traffic over the Internet between the DirectAccess client and Server 2 is encrypted through

the intranet tunnel. The traffic over the intranet between Server 2 and intranet servers is clear

text.

The recommended method to deploy this configuration is the following:

1. While configured with two consecutive public IPv4 addresses, complete the DirectAccess Setup Wizard on Server 2.

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.

For deployment instructions to move the IPsec gateway function to a separate server, see

Checklist: Moving the IPsec Gateway to Another Server.

87

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 NLB for a Forefront UAG DirectAccess array


Capacity Planning for Network Location Servers





The network location function for DirectAccess can be placed on an intranet Web server or the

DirectAccess server. Microsoft highly recommends placing the network location function on a

separate intranet Web server. You must plan the capacity of the network location server so that it

can handle the DirectAccess clients on your intranet performing intranet detection.

To provide capacity for an Internet Information Services (IIS) 7.0-based Web server, including the

DirectAccess server, see the documentation for the Web Server (IIS) role on Windows

Server 2008 R2 or Windows Server 2008 for recommendations on scaling IIS capacity.

Capacity Planning for CRL Distribution Points





The certificate revocation list (CRL) distribution points on the Internet for the Internet Protocol

over Secure Hypertext Transfer Protocol (IP-HTTPS) certificate and on the intranet for the

network location certificate can be located on Web or file servers. You must plan for the capacity

of CRL distribution points so that your Internet and intranet-connected DirectAccess clients can

perform certificate revocation checking for the IP-HTTPS connection and for network location

detection.

For an Internet Information Services (IIS)-based Web server or a Windows-based file server,

including the DirectAccess server, see the documentation for the Web Server (IIS) and File

Services roles on Windows Server 2008 R2 or Windows Server 2008 for recommendations on

scaling capacity.

Important Important

88




Planning for Multi-site DirectAccess

DirectAccess servers can be installed in multiple sites of an organization to increase capacity and

provide more efficient routing when accessing site-specific intranet resources. Setting up multi-

site DirectAccess requires careful design and planning so that the following goals are met:

A DirectAccess client can connect to the DirectAccess server of any site and can access the intranet resources in that site.

A DirectAccess client can be managed by a management server of any site.

A DirectAccess client can travel to any site and determine that it is connected to the intranet.

You can also deploy multi-site DirectAccess with geo-locator services such as Global

Server Load Balancing (GSLB). This topic does not describe planning for multi-site

DirectAccess in conjunction with a geo-locator service. Additional information about using

geo-locator services for multi-site DirectAccess will be added to this topic when it

becomes available.

The following figure shows an example of DirectAccess deployed in two sites of the Contoso

Corporation.

Example of a DirectAccess multi-site deployment

Site 1 is the Contoso Corporation’s main office in the United States, corresponding to the Active

Directory Domain Services (AD DS) domain and Domain Name System (DNS) namespace

usa.corp.contoso.com. Site 2 is the Contoso Corporation’s main office in Europe, corresponding

to the AD DS domain and DNS namespace europe.corp.contoso.com.

Note

89

DirectAccess Client 1 is a member of the usa.corp.contoso.com domain. When on the Internet,

DirectAccess Client 1 connects to the DirectAccess server for the site containing the resources it

needs to access. To access a resource in Site 1, the DirectAccess client creates infrastructure

and intranet tunnels to DirectAccess Server 1. To access a resource in Site 2, the DirectAccess

client creates separate infrastructure and intranet tunnels to DirectAccess Server 2. The following

figure shows an example of the infrastructure and intranet tunnels created by DirectAccess Client

1 to reach resources in Site 1 and Site 2.

Example of the tunnels created by DirectAccess Client 1 to access the resources of

different sites

DirectAccess Client 1 can be managed by the management servers in Site 1 or Site 2.

The following sections describe the design and planning of multi-site DirectAccess for different

elements of DirectAccess and intranet infrastructure.

IPv6 connectivity for multi-site DirectAccessIn a single-site DirectAccess deployment, a DirectAccess server acts as a default Internet

Protocol version 6 (IPv6) router for an organization. Default route traffic that is traveling out of the

site destined for DirectAccess clients on the Internet must go through the DirectAccess server.

90

In a multi-site DirectAccess deployment, DirectAccess servers still act as default routers for a site

to facilitate traffic to Internet destinations. However, additional routing support must be configured

so that IPv6 traffic between computers directly attached to the intranet in different sites does not

flow through the DirectAccess servers. Inter-site IPv6 traffic between intranet computers must

flow through intranet IPv6 routers if you have native IPv6 connectivity or Intra-Site Automatic

Tunnel Addressing Protocol (ISATAP) site border routers if you have ISATAP-based connectivity.

Native IPv6 connectivityFor native IPv6 connectivity, your intranet should support the following:

Reachability between all IPv6 subnets of your organization

Default route traffic destined for the Internet for each site flows through the site’s DirectAccess server

ISATAP connectivityBecause most organizations do not have native IPv6 connectivity on their intranets, the

DirectAccess Setup Wizard can automatically configure the DirectAccess server as an ISATAP

router, deploying ISATAP-based IPv6 connectivity on your intranet. For information about Active

Directory Sites and Services configuration for ISATAP-based intranets, see the “Active Directory

Sites and Services configuration” section of Design Active Directory for DirectAccess.

With a single-site DirectAccess deployment, the single DirectAccess server acting as the ISATAP

router for the site achieves the goals of providing IPv6 reachability throughout the intranet and

default route traffic flows through the DirectAccess server. For a multi-site DirectAccess

deployment using only ISATAP-based IPv6 connectivity, you must also deploy ISATAP site border

routers.

When you deploy DirectAccess servers in multiple sites, by default there is ISATAP-based IPv6

connectivity within each site and the default route traffic flows through the site’s DirectAccess

server. Without ISATAP border routers, the inter-site traffic follows the default route path and

flows to the DirectAccess server, which can then use 6to4 encapsulation to forward the traffic

over the Internet to the DirectAccess server of the destination site. Because there are no

connection security rules for inter-site traffic, by default the DirectAccess server can send the

traffic as clear text across the Internet. If you deploy ISATAP border routers, ISATAP hosts have

additional routes for intranet sites and forward inter-site traffic to the ISATAP border routers.

The ISATAP site border routers have a different role than the DirectAccess server that is acting as

a default router for each site. The DirectAccess server configures each ISATAP host within its site

with the 64-bit IPv6 prefix of the ISATAP subnet for the site and a default route that points to the

DirectAccess server. An ISATAP border router advertises the following routes to ISATAP hosts

within its site:

The 64-bit prefix of the site

This provides fault tolerance for ISATAP hosts to configure their ISATAP address in case they

do not receive the router advertisement from the DirectAccess server.

The 64-bit prefixes of the other sites that are reachable through the ISATAP border router

91

This provides reachability to the other sites.

ISATAP hosts perform router discovery with all ISATAP routers within their sites (the DirectAccess

server and the ISATAP border routers), resulting in the routes needed to reach the following:

All the IPv6 destinations within its own site through the site’s 64-bit prefix route, as received from the DirectAccess server and the ISATAP border routers

All the IPv6 destinations within the other sites in the organization through site-specific 64-bit prefix routes, as received from the ISATAP border routers

DirectAccess clients anywhere on the Internet through the default route, as received from the DirectAccess server

If your ISATAP border routers have multiple physical interfaces and your intranet backbone is

IPv6-capable, attach an interface of the ISATAP border router to the backbone and configure the

appropriate routes to advertise over the ISATAP border router’s ISATAP interface. The following

figure shows an example.

Example of connecting ISATAP border routers to an IPv6-capable backbone

If the intranet backbone is not IPv6-capable or you cannot place physical interfaces of the ISATAP

border routers on the backbone, you can tunnel inter-site IPv6 traffic between ISATAP border

routers using an IPv6-in-Internet Protocol version 4 (IPv4) point-to-point tunnel. This simple

router-to-router tunnel allows an ISATAP border router to forward the traffic destined to another

site directly to the other site’s ISATAP border router by encapsulating IPv6 packets with an IPv4

header. With an IPv6-in-IPv4 point-to-point tunnel, you can set up the ISATAP border router

anywhere within the site. The combination of IPv6-in-IPv4 point-to-point tunnels and routes

provides inter-site reachability.

92

The following figure shows an example of ISATAP border routers within Site 1 and Site 2 that use

an IPv6-in-IPv4 point-to-point tunnel to forward inter-site traffic.

Example of an IPv6-in-IPv4 point-to-point tunnel between ISATAP border routers

To provide fault tolerance for inter-site traffic, you can deploy an additional ISATAP border router

in each site that has the identical routing configuration as the initial ISATAP border routers, but

use their own IPv6-in-IPv4 point-to-point tunnel. The following figure shows an example.

93

Example of using multiple ISATAP border routers between sites

ISATAP routing can be configured using many modern hardware routers. See the documentation

for your router for support and configuration information. A computer running Windows

Server 2008 or later can also act as an ISATAP border router.

Active Directory for multi-site DirectAccessFor the configuration of multi-site DirectAccess discussed in this topic, each site is configured for

a different AD DS domain with a corresponding DNS suffix. For our example, Site 1 uses the

usa.corp.contoso.com AD DS domain and Site 2 uses europe.corp.contoso.com. Other

configurations are possible but are beyond the scope of this topic.

For information about Active Directory and DirectAccess, see Design Active Directory for

DirectAccess.

DNS for multi-site DirectAccessFor the configuration of multi-site DirectAccess discussed in this topic, each site is configured for

a different DNS suffix. For our example, Site 1 uses the usa.corp.contoso.com DNS suffix and

Site 2 uses europe.corp.contoso.com. Other configurations are possible but are beyond the

scope of this topic.

94

Intranet DNS recordsFor a multi-site DirectAccess deployment, you might have to create the following additional DNS

records within each site:

Address (A) or IPv6 address (AAAA) records for the network location server fully qualified domain name (FQDN) with the addresses of the site-specific network location server

A or AAAA records for the intranet certificate revocation list (CRL) distribution point FQDN with the addresses of the site-specific Web or file servers that host the CRL files

For each ISATAP site boundary router within the site, an A record for the name ISATAP with the IPv4 address of an ISATAP boundary router interface that is attached to the local site

You can also create multiple A or AAAA records for the network location server and CRL

distribution points in all your sites and deploy GSLB within your intranet to return the A or AAAA

record for the network location server and CRL distribution point within each site.

Internet DNS recordsFor a multi-site DirectAccess deployment, you must create A records for the Internet FQDN of

each DirectAccess server and the FQDN of each CRL distribution point server. These records

allow the DirectAccess client to resolve the address of the DirectAccess server of the site in

which it is a domain member for Internet Protocol over Secure Hypertext Transfer Protocol (IP-

HTTPS)-based connections and validate the DirectAccess server’s Secure Sockets Layer (SSL)

certificate.

For our example, the following A records are needed:

The name da1.contoso.com and the public IPv4 address of DirectAccess Server 1.

The name da2.contoso.com and the public IPv4 address of DirectAccess Server 2.

The name crl.contoso.com and the public IPv4 address of CRL distribution point server.

NRPTIn a multi-site DirectAccess deployment, DirectAccess clients create infrastructure and intranet

tunnels to the DirectAccess server that is connected to the site containing the destination of the

traffic. To create the infrastructure tunnel to the DirectAccess server for each site and send DNS

query traffic for site-specific resources to site-specific DNS servers, DirectAccess clients must be

configured with Name Resolution Policy Table (NRPT) namespace rules that include the DNS

suffixes of all sites.

For our example, the DirectAccess client Group Policy objects (GPOs) for both Site 1 and Site 2

must be configured with the following namespace rules:

usa.corp.contoso.com suffix with the IPv6 address of a DNS server in Site 1

europe.corp.contoso.com suffix with the IPv6 address of a DNS server in Site 2

You can configure the namespace rules for other sites in step 3 of the DirectAccess Setup Wizard

or in the Computer Configuration\Policies\Windows Settings\Name Resolution Policy node

of the GPO for DirectAccess clients.

95

PKI for multi-site DirectAccessTo distribute computer certificates to DirectAccess clients and servers with your public key

infrastructure (PKI), enabling computer certificate autoenrollment for the domains in all sites

containing a DirectAccess server is recommended. You can also use manual enrollment.

Intranet CRL distribution pointsDirectAccess clients use the intranet CRL distribution point to perform certificate revocation

checking and validate the SSL certificate of the network location server.

The recommended configurations of intranet CRL distributions points are the following:

A single CRL path (a uniform resource locator [URL] or universal naming convention [UNC]) with a single, highly-available, organization-wide intranet CRL distribution point server

This is the easiest to deploy, but requires certificate revocation checking traffic to cross site

boundaries. Intranet DNS records resolve the FQDN in the CRL path to the CRL distribution

point server.

For our example, the certification authority (CA) publishes its CRL files to a hosting server

named crl.corp.contoso.com in Site 1. The issued certificates contain the CRL path

http://crl.corp.contoso.com and all of the DirectAccess clients in both sites obtain the CRL

files from this server for certificate revocation checking. An intranet DNS record resolves

crl.corp.contoso.com to the IP address of the CRL distribution point server.

A single CRL path with per-site, highly-available, intranet CRL distribution point servers

In this configuration, the CA publishes its CRL files to a specific server and the files are

automatically replicated or shared to CRL distribution point servers within each site. DNS

records within each site resolve the FQDN in the path to per-site server IP addresses.

For our example, the Contoso CA publishes its CRL files to a Web server in Site 1, which

automatically replicate to a Web server in Site 2. The issued certificates contain the CRL path

http://crl.corp.contoso.com. In Site 1, a DNS record resolves crl.corp.contoso.com to the IP

addresses of Web servers in Site 1. In Site 2, a DNS record resolves crl.corp.contoso.com to

the IP addresses of Web servers in Site 2. DirectAccess clients and servers obtain CRL files

from the CRL distribution point servers within their site.

Per-site CRL path with per-site, highly-available, intranet CRL distribution point servers

This configuration requires a CA for each site with a site-specific CRL path and CRL

distribution point server. DNS records within each site resolve the FQDN in the path to a per-

site server IP address. A DirectAccess client on the intranet that is not connected to its own

site must cross site boundaries to obtain CRL files for its own CA.

For our example, a CA in Site 1 publishes its CRL files to Web servers in Site 1. The

certificates issued by the CA in Site 1 contain the CRL path http://crl_site1.corp.contoso.com.

In Site 1, a DNS record resolves crl_site1.corp.contoso.com to the IP addresses of the Web

servers in Site 1. The CA in Site 2 publishes its CRL files to Web servers in Site 2. The

certificates issued by the CA in Site 2 contain the CRL path http://crl_site2.corp.contoso.com.

96

In Site 2, a DNS record resolves crl_site2.corp.contoso.com to the IP addresses of the Web

servers in Site 2.

Certificate requirements for network location certificatesFor the network location server SSL certificate with a single network location URL and

organization-wide CRL paths:

In the Subject field, the FQDN of the single network location URL

In the Enhanced Key Usage field, the Server Authentication object identifier (OID)

In the CRL Distribution Points field, the organization-wide CRL distribution points

For the network location server SSL certificate with a single network location URL and per-site

CRL paths:

In the Subject field, the FQDN of the single network location URL

In the Enhanced Key Usage field, the Server Authentication OID

In the CRL Distribution Points field, the site-specific intranet CRL distribution points

Internet CRL distribution pointDirectAccess clients use the Internet CRL distribution point to perform certificate revocation

checking and validate the SSL certificate of the DirectAccess server when using IP-HTTPS-based

connections. The combinations of Internet CRL distributions points depend on the CAs that issue

the SSL certificates to the DirectAccess servers:

A single, highly-available, organization-wide CA and highly-available Internet CRL distribution point servers

A single CA publishes the CRL files to Internet-facing CRL distribution point servers and

Internet DNS records map the FQDN in the CRL path to Internet-accessible IP addresses.

For our example, a single CA issues SSL certificates to both DirectAccess servers and the

CRL files are hosted by highly-available Internet-facing Web servers using the CRL path

crl.contoso.com.

Per-site CAs and multiple Internet CRL distribution point servers

Each CA publishes its CRL files to site specific Internet-facing Web servers and Internet DNS

records map the FQDN in the CRL paths to Internet-accessible IP addresses.

For our example, the CA in Site 1 issues an SSL certificate to DirectAccess Server 1 and the

CRL files are hosted by Internet-facing Web servers in Site 1 using the FQDN

crl_site1.contoso.com. Internet DNS records resolve crl_site1.contoso.com to the IP

addresses of the Internet-facing Web servers for Site 1. The CA in Site 2 issues an SSL

certificate to DirectAccess Server 2 and the CRL files are hosted by Internet-facing Web

servers in Site 2 using the FQDN crl_site2.contoso.com. Internet DNS records resolve

crl_site2.contoso.com to the IP addresses of the Internet-facing Web servers for Site 2.

97

Certificate requirements for IP-HTTPS certificatesFor a single CA that issues SSL certificates that are installed on DirectAccess servers for IP-

HTTPS connections:

In the Subject field, either an IPv4 address of the Internet interface of the site-specific DirectAccess server or the FQDN (recommended) of the IP-Secure Hypertext Transfer Protocol (HTTPS) URL


In the CRL Distribution Points field, the organization-wide CRL distribution points on the Internet

For per-site CAs that issue SSL certificates that are installed on DirectAccess servers for IP-

HTTPS connections:

In the Subject field, either an IPv4 address of the Internet interface of the site-specific DirectAccess server or the FQDN (recommended) of the IP-HTTPS URL


In the CRL Distribution Points field, the site-specific CRL distribution points on the Internet

Network location servers for multi-site DirectAccessThe following are combinations of deploying network location servers for multi-site DirectAccess:

A single organization-wide network location URL with highly-available Web servers located in a single site

This is the easiest to deploy, but network location detection traffic for DirectAccess clients that

are not connected to the site containing the Web servers must cross site boundaries. Intranet

DNS records resolve the FQDN in the network location URL to the Web servers.

For our example, Web servers in Site 1 host the URL https://nls.corp.contoso.com and all the

DirectAccess clients in Site 1 and Site 2 attempt to access it during network location

detection.

A single, organization-wide network location URL with per-site, highly-available Web servers

All of the DirectAccess clients are configured with the same network location URL but

network location detection traffic stays within the site to which the DirectAccess client is

attached. DNS records within each site resolve the FQDN in the network location URL to the

IP addresses of the Web servers in the site. This is the recommended configuration.

For our example, DNS records in Site 1 resolve the name nls.corp.contoso.com to Web

servers in Site 1 that host the https://nls.corp.contoso.com URL. DNS records in Site 2

resolve the name nls.corp.contoso.com to Web servers in Site 2 that host the

https://nls.corp.contoso.com URL.

A site-specific network location URL with per-site Web servers is not recommended

because it requires either inter-site network location detection traffic or multiple DNS

records and Web servers in each site, one for each site-specific URL.

Note

98

Force tunneling for multi-site DirectAccessDirectAccess clients configured for force tunneling send all of their Internet traffic through their

DirectAccess server. Force tunneling configuration consists of enabling the Route all traffic

through the internal network Group Policy setting and adding an NRPT rule to send DNS

queries for all names to either a dual protocol (IPv4 and IPv6) proxy server or an IPv6/IPv4

translator and IPv6/IPv4 DNS gateway in front of your IPv4-based proxy server. Because both of

these settings are stored in the Group Policy objects for DirectAccess clients, you can define

force tunneling on a per-site basis.

For our example, you can configure force tunneling behavior for the DirectAccess clients of Site 1

but not for the DirectAccess clients of Site 2. Additionally, you can configure all of your

DirectAccess clients in multiple sites to use a single, common dual protocol proxy server or

IPv6/IPv4 translator and IPv6/IPv4 DNS gateway that are in a specific site. For example, you can

configure force tunneling for both Site 1 and Site 2, but DirectAccess clients from both sites use a

dual protocol proxy server or IPv6/IPv4 translator and IPv6/IPv4 DNS gateway that are located in

Site 1.

Connection security rules for multi-site DirectAccessDirectAccess clients use connection security rules to determine when to create the tunnels

needed to access intranet resources, for management traffic, end-to-end protection, and for

correct intranet behavior. In a single-site DirectAccess deployment, the default set of connection

security rules can consist of the following, based on your selections in the DirectAccess Setup

Wizard:

The intranet tunnel rule

Used by the DirectAccess client to access intranet resources. The intranet tunnel rule has the

default name DirectAccess Policy-ClientToCorp.

The network location exemption rule

Used by the DirectAccess client to exempt Internet Protocol security (IPsec) protection when

the network location server is only available over IPv6. The network location server

exemption rule has the default name DirectAccess Policy-clientToNlaExempt.

The management tunnel rule

If you specified management servers in Step 3 of the DirectAccess Setup Wizard, this rule is

used to allow incoming connections from management servers on the intranet. The

management tunnel rule for a DirectAccess client GPO of a site has the default name

DirectAccess Policy-ClientToMgmt.

Selected server transport rule

If you specified selected servers in Step 4 of the DirectAccess Setup Wizard, this rule is used

by DirectAccess clients to protect traffic end-to-end between the DirectAccess client and the

99

intranet resource. The selected server transport rule for a DirectAccess client GPO of a site

has the default name DirectAccess Policy-clientToAppServer.

To ensure that every DirectAccess client from any home site operates properly from the Internet

and when connected to any site, DirectAccess clients must be configured with the connection

security rules for the DirectAccess client GPOs of all sites. Therefore, for the DirectAccess client

GPO of each site, you must add the following connection security rules:

The infrastructure tunnel rules for all other sites

For each site, you must create rules with different names that have the settings of the

DirectAccess Policy-ClientToDnsDc connection security rules of the other sites.

For our example, you create a connection security rule named DirectAccess Policy-

ClientToDnsDc_Site2 in the DirectAccess client GPO of Site 1 with the settings of the

DirectAccess Policy-ClientToDnsDc connection security rule in the DirectAccess client GPO

of Site 2. You also create a connection security rule named DirectAccess Policy-

ClientToDnsDc_Site1 in the DirectAccess client GPO of Site 2 with the settings of the

DirectAccess Policy-ClientToDnsDc connection security rule in the DirectAccess client GPO

of Site 1.

The intranet tunnel rules for all other sites


DirectAccess Policy-ClientToCorp connection security rules of the other sites.


ClientToCorp_Site2 in the DirectAccess client GPO of Site 1 with the settings of the

DirectAccess Policy-ClientToCorp connection security rule in the DirectAccess client GPO of

Site 2. You also create a connection security rule named DirectAccess Policy-

ClientToCorp_Site1 in the DirectAccess client GPO of Site 2 with the settings of the

DirectAccess Policy-ClientToCorp connection security rule in the DirectAccess client GPO of

Site 1.

The network location server exemption rules for all other sites


DirectAccess Policy-clientToNlaExempt connection security rules of the other sites.


ClientToNlaExempt_Site2 in the DirectAccess client GPO of Site 1 with the settings of the

DirectAccess Policy-ClientToNlaExempt connection security rule in the DirectAccess client

GPO of Site 2. You also create a connection security rule named DirectAccess Policy-

ClientToNlaExempt_Site1 in the DirectAccess client GPO of Site 2 with the settings of the

DirectAccess Policy-ClientToNlaExempt connection security rule in the DirectAccess client

GPO of Site 1.

The management tunnel rules for all other sites


DirectAccess Policy-ClientToMgmt connection security rules of the other sites.

For our example, management servers have been specified for both sites. You create a

connection security rule named DirectAccess Policy-ClientToMgmt_Site2 in the DirectAccess

100

client GPO of Site 1 with the settings of the DirectAccess Policy-ClientToMgmt connection

security rule in the DirectAccess client GPO of Site 2. You also create a connection security

rule named DirectAccess Policy-ClientToMgmt_Site1 in the DirectAccess client GPO of Site 2

with the settings of the DirectAccess Policy-ClientToMgmt connection security rule in the

DirectAccess client GPO of Site 1.

The selected server transport rules for all other sites


DirectAccess Policy-clientToAppServer connection security rules of the other sites.

For our example, selected servers have been specified for both sites. You create a

connection security rule named DirectAccess Policy-clientToAppServer_Site2 in the

DirectAccess client GPO of Site 1 with the settings of the DirectAccess Policy-

clientToAppServer connection security rule in the DirectAccess client GPO of Site 2. You also

create a connection security rule named DirectAccess Policy-clientToAppServer_Site1 in the

DirectAccess client GPO of Site 2 with the settings of the DirectAccess Policy-

clientToAppServer connection security rule in the DirectAccess client GPO of Site 1.

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

how to troubleshoot DirectAccess issues in the DirectAccess test lab, see Step-by-Step Guide:

Troubleshoot DirectAccess in a Test Lab (http://go.microsoft.com/fwlink/?LinkId=181160).

For design, deployment, and troubleshooting information about the DirectAccess with Network

Access Protection (NAP) solution, see DirectAccess with Network Access Protection (NAP).

Appendix A: DirectAccess Requirements





Important Important

101









Review this section for information about DirectAccess server, DirectAccess client, and network

infrastructure requirements.

Hardware and software requirements for Windows 7-based computers described in this section

apply to both x86 (32-bit) and x64 (64-bit) systems.

Element Requirements

DirectAccess client Operating system: Windows 7 Ultimate or later, Windows 7 Enterprise or later, Windows Server 2008 R2 or later

Member of an Active Directory Domain Services (AD DS) domain

Computer certificate for Internet Protocol security (IPsec) authentication

DirectAccess server Operating system: Windows Server 2008 R2 or later

Member of an AD DS domain

At least two network adapters that are connected to the Internet and your intranet

2 consecutive, public Internet Protocol version 4 (IPv4) addresses configured on the Internet network adapter (cannot be behind a network address translator [NAT])

Certificates: Computer certificate for IPsec authentication, Secure Sockets Layer (SSL) certificate for Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS)

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.

102

Element Requirements

Workgroups are not supported. For more

information about installing Active Directory, see

the AD DS Installation and Removal Step-by-

Step Guide (http://go.microsoft.com/fwlink/?

Linkid=139657).

Group Policy Required for centralized administration and

deployment of DirectAccess settings. The

DirectAccess Setup wizard creates a set of

Group Policy objects and settings for

DirectAccess clients, the DirectAccess server,

and selected servers.

Public key infrastructure (PKI) Required to issue computer certificates for

authentication, and optionally, health certificates

when using Network Access Protection (NAP).

External certificates are not required. For more

information about setting up a PKI with Active

Directory Certificate Services (AD CS), see

Active Directory Certificate Services


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






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 network location

Important

103






detection that DirectAccess clients use to determine when they are on the intranet. The following

sections describe the role that these technologies have in providing DirectAccess clients with

transparent access to intranet resources.

IPv6IPv6 is the new version of the Network layer of the TCP/IP protocol stack that is designed to

replace Internet Protocol version 4 (IPv4), which is in wide use today on intranets and the

Internet. IPv6 provides an address space large enough to accommodate end-to-end addressing

of nodes on the IPv6 Internet, and with IPv6 transition technologies, of nodes on the IPv4

Internet. DirectAccess uses this capability to provide end-to-end addressing from DirectAccess

clients on the IPv4 or IPv6 Internet to computers on an intranet.

Because most of the current Internet is IPv4-based and many organizations have not deployed

native IPv6 addressing and routing on their intranets, DirectAccess uses IPv6 transition

technologies to provide IPv6 connectivity over these IPv4-only networks. Teredo, 6to4, Internet

Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS), and the Intra-Site Automatic

Tunnel Addressing Protocol (ISATAP) are examples of IPv6 transition technologies. These

technologies allow you to use IPv6 on the IPv4 Internet and your IPv4-only intranet. IPv6

transition technologies can simplify and reduce the costs of an IPv6 deployment.

IPv6 connectivity across the IPv4 InternetTo send IPv6 packets across the IPv4 Internet, a DirectAccess client can use 6to4, Teredo, or IP-

HTTPS. If the DirectAccess client has been assigned a public IPv4 address, it will use 6to4. If

assigned a private IPv4 address, it will use Teredo. If the DirectAccess client cannot connect to

the DirectAccess server with either 6to4 or Teredo, it will use IP-HTTPS.

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

104




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


The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) demonstrates

DirectAccess connectivity across a simulated Internet subnet using 6to4, Teredo, and IP-

HTTPS.

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.

The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) uses ISATAP

across the simulated intranet.

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


DirectAccess uses IPsec settings in the form of connection security rules in the Windows Firewall

with Advanced Security snap-in and the Network Shell (Netsh) command-line tool advfirewall

context for peer authentication, data integrity, and data confidentiality (encryption) of

DirectAccess connections. Multiple rules can be applied to a computer simultaneously, each

providing a different function. The result of all of these rules working together is a DirectAccess

client that can have protected communications with the DirectAccess server and intranet servers,

encrypting traffic sent over the Internet and optionally protecting traffic from end-to-end.

Note Notes

105






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

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.

Note Note

106

Separation of DNS trafficTo separate Internet traffic from intranet traffic for DirectAccess, Windows 7 and Windows

Server 2008 R2 include the NRPT, a new feature that allows DNS servers to be defined per DNS

namespace, rather than per interface. The NRPT stores a list of rules. Each rule defines a DNS

namespace and configuration settings that define the DNS client’s behavior for that namespace.

When a DirectAccess client is on the Internet, each name query request is compared against the

namespace rules stored in the NRPT. If a match is found, the request is processed according to

the settings in the NRPT rule. The settings determine which DNS servers to which the request will

be sent.

If a name query request does not match a namespace listed in the NRPT, it is sent to the DNS

servers configured in the TCP/IP settings for the specified network interface. For a remote client,

this will typically be the Internet DNS servers as configured through the Internet service provider

(ISP). For a DirectAccess client on the intranet, this will typically be the intranet DNS servers as

configured through the Dynamic Host Configuration Protocol (DHCP).

Single-label names, such as http://internal, will typically have configured DNS search suffixes

appended to the name before they are checked against the NRPT. If no DNS search suffixes are

configured and the single-label name does not match any other single-label name rules in the

NRPT, the request will be sent to the DNS servers specified in the client’s TCP/IP settings.

Namespaces, such as .internal.contoso.com, are added to the NRPT followed by the IPv6

addresses of the DNS servers to which requests matching that namespace should be directed. If

an IP address is entered for the DNS server, then all DNS requests will be sent directly to the

DNS server over the DirectAccess connection. There is no need to specify any additional security

for this configuration.

However, if a name is specified for the DNS server (such as dns.contoso.com) in the NRPT, then

that name must be publicly resolvable when the client queries the DNS servers specified in its

TCP/IP settings. To prevent an attacker from hijacking this external name query request and

injecting a malicious reply, enabling IPsec protection for the DNS message exchanges is strongly

recommended in this configuration.

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.

107

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.

The DirectAccess Setup Wizard in the DirectAccess test lab

(http://go.microsoft.com/fwlink/?Linkid=150613) creates two rules in the NRPT: a

namespace rule for corp.contoso.com with the IPv6 address of the intranet DNS server

and an exemption rule for nls.corp.contoso.com. You can view the NRPT rules configured

with Group Policy from CLIENT1 by running the netsh namespace show policy

command at a command prompt. You can view the active NRPT rules with the netsh


Network location detectionDirectAccess clients use network location detection to determine if they are on the intranet by

attempting to access a network location server. If the DirectAccess client can successfully access

a Secure Hypertext Transfer Protocol (HTTPS)-based uniform resource locator (URL) on the

network location server, it determines that it is on the intranet and removes the DirectAccess rules

from the NRPT.

The network location serverA network location server is an intranet Web server that hosts an HTTPS-based URL. The

DirectAccess server can be the network location server but a separate, highly-available 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 highly available and 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 network location detection worksWhen a DirectAccess client starts up or experiences a network change event (such as change in

link status or a new IP address), it adds the DirectAccess rules to the NRPT. 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 DirectAccess rules, this FQDN should either

Note

108


match an exemption rule or no rules in the NRPT so that the DirectAccess client can use normal

name resolution and 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. The

network location server should not require any type of user credentials for authentication or

authorization. Certificate verification includes validating the certificate and verifying that it has not

been revoked by accessing the CRL location defined in the network location server’s SSL

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.

For more information, see Network Location Detection.

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 normal

name resolution and 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.

The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) uses APP1, a

separate application server, as the network location server and the network location URL

https://nls.corp.contoso.com. The SSL certificate on APP1 has the CRL distribution point

http://crl.contoso.com/crld/corp-DC1-CA.crl, which for ease of configuration is hosted on

DA1, the DirectAccess server. To demonstrate network location detection, do the

following:

1. Connect CLIENT1 to the Internet subnet.

2. Open a Command Prompt.

3. From the Command Prompt window, run the netsh dnsclient show state command.

Notice that the Machine Location field states Outside corporate network.

4. Run the netsh namespace show effectivepolicy command.

Notice that there are two active NRPT rules: A namespace rule for corp.contoso.com and an

exemption rule for nls.corp.contoso.com.

5. Disconnect CLIENT1 from the Internet subnet and connect it to the Corpnet subnet.


Notice that the Machine Location field states Inside corporate network.


Notice that there are now no active NRPT rules.

Notes

109


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:

Important

110


IPv6 connectivity. Describe how you deployed Internet Protocol version 6 (IPv6) connectivity across your intranet. Include details on routers, default routing design, and IPv6 Internet connectivity.

Servers, devices, and roles. List all servers and devices, including their roles, in your DirectAccess design. Include computers and other devices used for DirectAccess certificate validation and connectivity.

Packet filtering. List the packet filters configured on Internet and intranet firewalls, across intranet hosts, and for DirectAccess clients.

Capacity management and redundancy. Describe your expectations for capacity management and redundancy in the DirectAccess design.

Scaling plan. Describe changes that will be required to support the expansion of the DirectAccess deployment to include additional capacity.

Custom configuration planUse this section to document how you had to customize the default configuration of DirectAccess

to implement specific requirements on your network.

Baseline configuration. List the steps in the DirectAccess Setup Wizard and the options chosen for your initial configuration.

NRPT rules. List any additional Name Resolution Policy Table (NRPT) rules for intranet namespaces or exemptions that you needed for your deployment.

Connection security rules. List any changes made to the default connection security rules in the form of Network Shell (Netsh) commands, including the Group Policy object, the rule name, and the changes made.

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.

111

Timeline. Provide details of your proposed timeline to deploy DirectAccess on your intranet. Include your initial timeline and any deviation from that timeline.

Staging results. Provide the results for each stage of your DirectAccess deployment.

Trends. Describe any trends in connectivity issues encountered.

Lessons learnedUse this section to describe problems that were encountered and solutions that were

implemented during your DirectAccess deployment.

DirectAccess Deployment Guide

This topic describes deployment of DirectAccess in Windows Server 2008 R2. For

deployment of DirectAccess in Microsoft Forefront Unified Access Gateway (UAG), see

the Forefront UAG DirectAccess Deployment Guide (http://go.microsoft.com/fwlink/?

LinkId=179989).

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

Important

112


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.

This guide, combined with the DirectAccess Design and Troubleshooting Guides, is also available

as a Microsoft Word file (http://go.microsoft.com/fwlink/?LinkId=163662) in the Microsoft

Download Center.

Planning Your DirectAccess Deployment




LinkId=179989).

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:




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.

Important

113



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.

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


Test Lab Guide: Demonstrate DirectAccess (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




LinkId=179989).

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.

Important

114





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.

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

115

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:

Checklist: Implementing a Redundant DirectAccess Design

Checklist: Configuring Network Access Protection (NAP) with DirectAccess

Checklist: Moving the IPsec Gateway to Another Server

Checklist: Staging a DirectAccess Deployment




LinkId=179989).

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 Test Lab Guide:

Demonstrate DirectAccess (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

Implementing Your

DirectAccess Design Plan

Important Note

116




Task Reference

deployed DirectAccess for the

scope of your pilot.

Scale out; implement

redundancy as needed;

reevaluate goals and assess

benefits.

DirectAccess Capacity

Planning

Planning Redundancy for a

DirectAccess Server

Checklist: Preparing Your Infrastructure for DirectAccess




LinkId=179989).

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.




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

Important Note

117


Task Reference

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

Add intranet A records as

needed for your network location

server and CRL distribution

points.

Design Your DNS


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


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

118

Task Reference

Configure autoenrollment of

computer certificates.

Configure Computer

Certificate Autoenrollment

Modify the permissions on the

Web Server certificate template.

Configure Permissions on the

Web Server 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

a custom SSL certificate on your

separate network location server.

Install and Configure IIS for a

Network Location Server

Certificate





LinkId=179989).

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.





Task Reference

Install two network

adapters (interfaces) on

your DirectAccess server.

Connect the internal

network interface to your

See your hardware documentation.

iImportant Note

119


Task Reference

internal network.

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)

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.


DirectAccess Server

IPv4 General tab


Configure your Internet

and intranet interfaces

with different connection-

specific Domain Name

System (DNS) suffixes.

Configure your intranet

interface with the DNS


DirectAccess Server

IPv4 and IPv6 Advanced DNS tab


120






Task Reference

suffix for your

organization.

Configure static routes for

your intranet on the

DirectAccess server.


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

Key Usage (EKU).

View Certificates


Install a Secure Sockets

Layer (SSL) certificate for

Internet Protocol over

Secure Hypertext Transfer

Protocol (IP-HTTPS)

authentication.


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



Important

121



LinkId=179989).

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.




Checklist: Implementing a DirectAccess design for full intranet access

Task Reference

Review important

concepts and the example

for the DirectAccess full

intranet access model.



(Optional, but

recommended)

Demonstrate full intranet

access in a test lab.

DirectAccess test lab


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


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

Note

122



Task Reference

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


plan, configure force

tunneling.

Configure Force Tunneling for DirectAccess

Clients


plan, configure a

connection or routing to

the Internet Protocol

version 6 (IPv6) Internet.

Connect to the IPv6 Internet


plan, configure client

authentication and

certificate mapping for



Protocol (IP-HTTPS)

connections.

Configure Client Authentication and

Certificate Mapping for IP-HTTPS Connections


plan, configure connection

security rules to protect

traffic sent between


Configure Connection Security Rules for

Traffic Between DirectAccess Clients

Checklist: Implementing a DirectAccess Design for Selected Server Access




LinkId=179989).

Important

123



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.




Checklist: Implementing a DirectAccess design for selected server access

Task Reference

Review important

concepts and the example

for the DirectAccess

selected server access

model.



(Optional, but

recommended)

Demonstrate selected

server access in a test lab.

DirectAccess test lab


with the Selected Server Access extension



infrastructure for

DirectAccess.

Checklist: Preparing Your Infrastructure for

DirectAccess

Prepare the DirectAccess

server computer for the

DirectAccess Setup

Wizard.

Checklist: Preparing Your DirectAccess

Server


feature on the



Configure the

DirectAccess server for

the selected server access

method with the

DirectAccess Setup

Wizard.

Configure the DirectAccess Setup Wizard

for Selected Server Access


Website Probe URL and

Corporate Site Prefix List

Group Policy settings.

Design Your Intranet for Corporate

Connectivity Detection

Configure Corporate Connectivity Detection

Settings

Note

124



Task Reference


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


plan, configure force

tunneling.

Configure Force Tunneling for DirectAccess

Clients


plan, configure a

connection or routing to

the Internet Protocol

version 6 (IPv6) Internet.



plan, configure client

authentication and

certificate mapping for



Protocol (IP-HTTPS)

connections.

Configure Client Authentication and

Certificate Mapping for IP-HTTPS Connections


plan, configure connection

security rules to protect

traffic sent between


Configure Connection Security Rules for

Traffic Between DirectAccess Clients

Checklist: Implementing a DirectAccess Design for End-to-End Access




LinkId=179989).

Important

125



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.




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



infrastructure for DirectAccess.

Checklist: Preparing Your


Prepare the DirectAccess server

computer for the DirectAccess

Setup Wizard.

Checklist: Preparing Your

DirectAccess Server

Install the DirectAccess feature

on the DirectAccess server.


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


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

for DirectAccess Clients


configure a connection or routing

to the Internet Protocol version 6


Note

126

Task Reference

(IPv6) Internet.


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


configure connection security

rules to protect traffic sent

between DirectAccess clients.

Configure Connection

Security Rules for Traffic

Between DirectAccess Clients

Checklist: Implementing a Redundant DirectAccess Design




LinkId=179989).

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.




Checklist: Implementing a redundant DirectAccess design

Task Reference


using Hyper-V to provide

redundancy for DirectAccess.


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


DirectAccess Design for

Important Note

127


Task Reference



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.


DirectAccess Server

Checklist: Configuring Network Access Protection (NAP) with DirectAccess




LinkId=179989).

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.




Checklist: Configuring NAP with DirectAccess

Task Reference

Review important

concepts for using NAP

with DirectAccess.

Planning DirectAccess with Network Access

Protection (NAP)

(Optional, but

recommended)

Demonstrate DirectAccess

with NAP in a test lab.

DirectAccess with NAP test lab


Deploy NAP with the

Internet Protocol security

Implementing Your NAP Design Plan

Important Note

128



Task Reference

(IPsec) enforcement

method.

Checklist: Implementing an IPsec

Enforcement Design

As needed by your NAP

design plan, install an

IPsec enforcement

exemption certificate on


Create an IPsec NAP Exemption Group

As needed by your

DirectAccess 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


Design for Selected Server Access


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

Checklist: Moving the IPsec Gateway to Another Server

This checklist includes cross-reference links to important concepts about adding capacity to your

DirectAccess deployment by moving the Internet Protocol security (IPsec) gateway function to

another server when you are using the full intranet or selected server access models. It also

contains links to procedures and other checklists that will help you complete the tasks that are

required to implement this design.




Checklist: Moving the IPsec gateway to another server

Note

129

Task Reference


moving the IPsec gateway to

another server.

Capacity Planning for

DirectAccess Servers

As needed by your design plan,

configure the second server (the

IPsec gateway) for the full

intranet or selected server

access model.


DirectAccess Design for Full

Intranet Access


DirectAccess Design for


Configure both servers on an

intra-server subnet to support

the dual-server configuration.

Configure the Intra-Server

Subnet

Configure the IPv6 connectivity

server as the 6to4 relay, Teredo

server, and Internet Protocol

over Secure Hypertext Transfer

Protocol (IP-HTTPS) server.

Configure the IPv6

Connectivity Server

Configure the IPsec gateway

server and the Group Policy

settings for the new

configuration.

Configure the IPsec Gateway

Server

Procedures Used in this Guide




LinkId=179989).

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 Active Directory Certificate Services for CRL Locations

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

Important

130


Configure Corporate Connectivity Detection Settings

Configure DirectAccess Connection Security Rules for NAP

Configure Firewall Rules to Prevent Traffic between Proxy Servers and DirectAccess Servers

Configure Force Tunneling for DirectAccess Clients

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 IPsec Gateway on a Different 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


Create DirectAccess Groups in Active Directory



Install and Configure IIS for a Network Location Server Certificate


Remove ISATAP from the DNS Global Query Block List

Add Servers that are Available to DirectAccess Clients before User Logon




LinkId=179989).

To add intranet servers that are available to DirectAccess clients prior to user logon, you can add

them as management servers with the DirectAccess Setup Wizard (recommended) or add their

Internet Protocol version 6 (IPv6) addresses to the list of permitted endpoints for the infrastructure

or management tunnel with the Netsh.exe tool, depending on whether you are managing a

customized DirectAccess deployment and can run the DirectAccess Setup Wizard without

Important

131


modifying one or more custom settings. For more information, see Design for Intranet Server

Availability Prior to User Logon.

To complete these procedures, 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 or modify Group Policy settings. Review details about using the appropriate

accounts and group memberships at Local and Domain Default Groups


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

4. On the Location page, click Next.

5. On the DNS and Domain Controller page, click Next.

6. On the Management page, right-click the empty row, and then click New.

7. In the IPv4 Address dialog box, specify either the host name or IPv4 address of the intranet server, and then click OK. In the IPv6 Address/Prefix dialog box, specify either the host name or IPv6 address or prefix of the intranet server, and then click OK.

8. Repeat steps 6 and 7 for additional intranet servers.

9. Click Finish.

10. Click Save, and then click Finish.

11. In the DirectAccess Review dialog box, click Apply. In the DirectAccess Policy Configuration message box, click OK.

1. On a domain controller, start a command prompt as an administrator.

2. From the Command Prompt window, run the netsh –c advfirewall command.

3. From the netsh advfirewall prompt, run the set store gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}” command.

4. From the netsh advfirewall prompt, run the consec show rule name=“DirectAccess Policy-ClientToMgmt” command.

5. From the display of the consec show rule command, note the IPv6 addresses for Endpoint2.

6. From the netsh advfirewall prompt, run the consec set rule “DirectAccess Policy-ClientToMgmt” new endpoint2=ExistingIPv6Addresses,ListOfAdditionalServerIPv6Addresses command, where ExistingIPv6Addresses is the comma-separated list of IPv6-addresses from step 5.

7. From the netsh advfirewall prompt, run the set store gpo=”DomainName\DirectAccess Policy-{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300}" command.

8. From the netsh advfirewall prompt, run the consec set rule “DirectAccess Policy-DaServerToMgmt” new

To make intranet servers available to DirectAccess clients before user logon using the DirectAccess Setup Wizard

To make intranet servers available to DirectAccess clients before user logon using the Netsh.exe tool and the management tunnel

132


endpoint1=ExistingIPv6Addresses,ListOfAdditionalServerIPv6Addresses command.




4. From the netsh advfirewall prompt, run the consec show rule name=“DirectAccess Policy-ClientToDnsDc” command.


6. From the netsh advfirewall prompt, run the consec set rule “DirectAccess Policy-ClientToDnsDc” new endpoint2=ExistingIPv6Addresses,ListOfAdditionalServerIPv6Addresses command, where ExistingIPv6Addresses is the comma-separated list of IPv6-addresses from step 5.


8. From the netsh advfirewall prompt, run the consec set rule “DirectAccess Policy-DaServerToDnsDc” new endpoint1=ExistingIPv6Addresses,ListOfAdditionalServerIPv6Addresses command.

DirectAccess clients and servers update their connection security rules in the next update of

computer configuration Group Policy.

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 CRL Distribution Point for Certificates




LinkId=179989).

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:

To make intranet servers available to DirectAccess clients before user logon using the Netsh.exe tool and the infrastructure tunnel

Important

133


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

7. Click Add, and then click Object Types.

8. Select Computers, and then click OK.

To create a Web-based CRL distribution pointTo configure permissions on the CRL distribution file shared folder

134

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



Configure Active Directory Certificate Services for CRL Locations




LinkId=179989).

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:

To publish the CRLImportant

135


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 Local and Domain

Default Groups (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 then click OK.

17. Click Yes to restart Active Directory Certificate Services.

Note To configure CRL distribution settings

136



18. Go to the location specified in step 11 and verify that CRL files exist.

19. Access the UNC or URL specified in step 4 and verify that the same CRL files exist.



Configure Client Authentication and Certificate Mapping for IP-HTTPS Connections




LinkId=179989).

This procedure helps mitigate possible security issues for Internet Protocol over Secure Hypertext

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


otherwise be delegated permissions to configure HTTPS settings. Review details about using the

appropriate accounts and group memberships at Local and Domain Default Groups


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=enable 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.

Important To configure client authentication and certificate mapping for the IP-HTTPS certificate

Note

137






Configure Computer Certificate Autoenrollment




LinkId=179989).

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.


otherwise be delegated permissions to change Group Policy settings. Review details about using

the appropriate accounts and group memberships at Local and Domain Default Groups


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.



Configure Connection Security Rules for End-to-end Access

Important To configure computer certificate auto-enrollment

138






LinkId=179989).

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

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.





In this procedure, you configure end-to-end access connection security rules to require encryption

only when DirectAccess clients are on the Internet.



3. From the netsh advfirewall prompt, run the following commands:

set store gpo="DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-

a4420a810f12}"

consec set rule name=”DirectAccess Policy-clientToAppServer” new

qmsecmethods=”ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-

AES128+60min+100000kb” action=requireinrequireout

consec set rule name=”DirectAccess Policy-ClientToCorp” new

exemptipsecprotectedconnections=yes

consec set rule name=”DirectAccess Policy-ClientToDnsDc” new


consec set rule name=”DirectAccess Policy-ClientToMgmt” new


set store gpo="DomainName\DirectAccess Policy-{ab991ef0-6fa9-4bd9-bc42-

3c397e8ad300}”

Important To configure end-to-end access connection security rules to require encryption only

when DirectAccess clients are on the Internet

139



consec set rule name=”DirectAccess Policy-DaServerToMgmt” new


consec set rule name=”DirectAccess Policy-DaServerToCorp” new


consec set rule name=”DirectAccess Policy-DaServerToDnsDc” new


set store gpo=”DomainName\DirectAccess Policy-{f7b77f47-7c33-4d8c-bb9a-

a913c5675d8d}”

consec set rule name=”DirectAccess Policy-appServerToIpHttpsClientPolicy” new


AES128+60min+100000kb”

consec set rule name=”DirectAccess Policy-appServerToClient” new


AES128+60min+100000kb”

In this procedure, you configure end-to-end access connection security rules to always require

encryption.




set store gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-

a4420a810f12}”

consec set rule name=”DirectAccess Policy-clientToAppServer” new

endpoint2=any qmsecmethods=”ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-

AES128+60min+100000kb”

consec set rule name=”DirectAccess Policy-ClientToCorp” new


consec set rule name=”DirectAccess Policy-ClientToDnsDc” new


consec set rule name=”DirectAccess Policy-ClientToMgmt” new


set store gpo=”DomainName\DirectAccess Policy-{ab991ef0-6fa9-4bd9-bc42-

3c397e8ad300}”

consec set rule name=”DirectAccess Policy-DaServerToMgmt” new


consec set rule name=”DirectAccess Policy-DaServerToCorp” new


consec set rule name=”DirectAccess Policy-DaServerToDnsDc” new


To configure end-to-end access connection security rules to always require encryption

140

set store gpo=”DomainName\DirectAccess Policy-{f7b77f47-7c33-4d8c-bb9a-

a913c5675d8d}”

consec set rule name=”DirectAccess Policy-appServerToIpHttpsClientPolicy” new


AES128+60min+100000kb”

consec set rule name=”DirectAccess Policy-appServerToClient” new


AES128+60min+100000kb”



Configure Connection Security Rules for Traffic Between DirectAccess Clients




LinkId=179989).

To protect the traffic sent between DirectAccess clients, you must configure additional connection

security rules.








4. To exempt the traffic between DirectAccess clients and intranet resources when the DirectAccess clients are connected to the intranet, from the netsh advfirewall prompt, run the consec add rule name=RuleName endpoint1=IntranetIPv6Prefix endpoint2=IntranetIPv6Prefix action=noauthentication profile=domain,public,private command.

5. To create an inbound firewall rule for an application that needs to accept unsolicited inbound connection requests, from the netsh advfirewall prompt, run the 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, run the

Important To configure connection security rules for traffic between DirectAccess clients

141



firewall add rule name=RemoteDesktop profile=public,private program=system

action=allow security=authenc protocol=tcp localport=3389 command.

6. To request protection of traffic between DirectAccess clients for all applications, from the netsh advfirewall prompt, run the consec add rule name=RuleName endpoint1=any endpoint2=any action=requestinrequestout profile=public,private auth1=computercert auth1ca=CANameString command.

7. To require protection of traffic between DirectAccess clients for all applications, from the netsh advfirewall prompt, run the consec add rule name=RuleName endpoint1=any endpoint2=any action=requireinrequestout profile=public,private auth1=computercert auth1ca=CANameString command.



Configure Corporate Connectivity Detection Settings




LinkId=179989).

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.


otherwise be delegated permissions to configure Group Policy settings. Review details about

using the appropriate accounts and group memberships at Local and Domain Default Groups


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

Important To configure the NRPT with Group Policy

142



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.



11. From the netsh advfirewall prompt, run the consec show rule name=“DirectAccess Policy-ClientToDnsDc”command.

12. From the display of the consec show rule command, note the IPv6 address expressed as a range for Endpoint2.

13. In the details pane of the Group Policy Management Editor, double-click Corporate Site Prefix List in the details pane.

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

15. Click Apply, and then click OK.



Configure DirectAccess Connection Security Rules for NAP




LinkId=179989).

Configuring DirectAccess with Network Access Protection (NAP) consists of the following:

Adding the Health Registration Authorities (HRAs) and remediation servers on your intranet to the list of management servers.

If you are using NAP full enforcement, configuring the intranet tunnel connection security rule on the DirectAccess server to require health certificates for authentication.





Important

143



The following procedure uses the DirectAccess Setup Wizard to add your HRAs and remediation

servers to the list of management servers.




4. On the Location page, click Next.

5. On the DNS and Domain Controller page, click Next.

6. On the Management page, right-click the empty row, and then click New.

7. In the IPv4 Address dialog box, specify either the host name or Internet Protocol version 4 (IPv4) address of the HRA or remediation server, and then click OK. In the IPv6 Address/Prefix dialog box, specify either the host name or Internet Protocol version 6 (IPv6) address or prefix of the HRA or remediation server, and then click OK.

8. Repeat steps 6 and 7 for additional servers.

9. Click Finish.



The following procedure uses Netsh.exe commands to modify the connection security rules for

the management tunnel to allow DirectAccess clients to access the HRAs and remediation

servers on the intranet.

Before performing this procedure, you must determine the list of IPv6 addresses for the

HRAs and remediation servers on your intranet.




This is the Group Policy object (GPO) for DirectAccess clients.

4. From the netsh advfirewall prompt, run the consec show rule name=“DirectAccess Policy-ClientToMgmt” command.


6. From the netsh advfirewall prompt, run the consec set rule “DirectAccess Policy-ClientToMgmt” new endpoint2=ExistingIPv6Addresses,ListOfAdditionalServerIPv6Addresses command, where ExistingIPv6Addresses is the comma-separated list of IPv6 addresses from step 5 and ListOfAdditionalServerIPv6Addresses is the comma-separated list of IPv6 addresses for your HRAs and remediation servers on the intranet.

To add HRAs and remediation servers as management servers using the DirectAccess Setup Wizard

Note To add HRAs and remediation servers as management servers using the Netsh.exe tool

144


This is the GPO for the DirectAccess server.

8. From the netsh advfirewall prompt, run the consec set rule “DirectAccess Policy-DaServerToMgmt” new endpoint1=ExistingIPv6Addresses,ListOfAdditionalServerIPv6Addresses command.

The following procedure modifies the intranet tunnel connection security rule on the DirectAccess

server to require the use of health certificates by DirectAccess clients. Perform this procedure

only when you are using NAP full enforcement for DirectAccess connections.



3. From the netsh advfirewall prompt, run the set store gpo=”DomainName\DirectAccess Policy-{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300}” command.

This is the GPO for the DirectAccess server.

4. From the netsh advfirewall prompt, run the consec show rule name=“DirectAccess Policy-DaServerToCorp” command.

5. From the display of the consec show rule command, note the certification authority (CA) name string for Auth1CAName.

6. From the netsh advfirewall prompt, run the consec set rule “DirectAccess Policy-DaServerToCorp” new auth1=computercert auth1ca=CANameString auth1healthcert=yes applyauthz=yes command.

When you use Netsh.exe to customize connection security rules for DirectAccess, those

changes are overwritten the next time you apply the settings of the DirectAccess Setup

Wizard. To ensure that the custom settings are maintained, you should either no longer

use the DirectAccess Setup Wizard for configuration changes or compile a list of custom

changes in a script and run the script each time you apply the DirectAccess Setup Wizard

settings.



Configure Firewall Rules to Prevent Traffic between Proxy Servers and DirectAccess Servers



To modify the connection security rule for the intranet tunnelImportant Important

145


LinkId=179989).

To prevent DirectAccess clients from using IP-HTTPS to connect to your intranet through your

proxy servers and DirectAccess servers when they are connected to your IPv4-only intranet or an

IPv4-only subnet of your intranet, you can do one of the following:

On your DirectAccess servers, create an inbound rule that blocks all traffic from the IPv4 addresses of your proxy servers.

On your proxy servers, create an outbound rule that blocks all traffic to the external (Internet) IPv4 addresses of your DirectAccess servers.

1. On the DirectAccess server, click Start, click Run, type wf.msc, and then press ENTER.

2. In the console tree of the Windows Firewall with Advanced Security snap-in, right-click Inbound Rules, and then click New Rule.

3. On the Rule Type page, click Custom, and then click Next.

4. On the Programs page, click Next.

5. On the Protocols and Ports page, click Next.

6. On the Scope page, under Which remote IP addresses does this rule apply?, click These IP addresses.

7. Click Add, type the IPv4 address of a proxy server in This IP address or subnet, and then click OK. Repeat this step for the additional IPv4 addresses of your proxy servers.

8. When you have added all of the IPv4 addresses of your proxy servers, click Next.

9. On the Action page, click Block the connection, and then click Next.

10. On the Profile page, click Next.

11. On the Name page, for Name, type Drop inbound proxy server traffic, and then click Finish.

1. On a proxy server running Windows Server 2008 or later, click Start, click Run, type wf.msc, and then press ENTER.

2. In the console tree of the Windows Firewall with Advanced Security snap-in, right-click Outbound Rules, and then click New Rule.


4. On the Programs page, click Next.

5. On the Protocols and Ports page, click Next.

6. On the Scope page, under Which remote IP addresses does this rule apply?, and then click These IP addresses.

7. Click Add, type the IPv4 address assigned to an external (Internet) interface of a DirectAccess server in This IP address or subnet, and then click OK. Repeat this step for the additional external IPv4 addresses of your DirectAccess servers.

8. When you have added all of the external IPv4 addresses of your DirectAccess servers,

To create an inbound rule on a DirectAccess server to drop traffic from your proxy servers

To create an outbound rule on a proxy server to drop traffic to your DirectAccess servers

146


click Next.

9. On the Action page, click Block the connection, and then click Next.

10. On the Profile page, click Next.

11. On the Name page, for Name, type Drop outbound DirectAccess server traffic, and then click Finish.

Configure Force Tunneling for DirectAccess Clients




LinkId=179989).

Before configuring force tunneling settings for DirectAccess clients, you should have deployed

and 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 (NAT64)

and IPv6/IPv4 DNS gateway (DNS64) 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.





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

Important To configure force tunneling

147



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 NAT64/DNS64 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.

11. In the console tree of the Group Policy Management Editor snap-in, open Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies.

12. In the details pane, double-click 6to4 State.

13. In the 6to4 State dialog box, click Enabled, click Disabled State in Select from the following states, click Apply, and then click OK.

14. In the details pane, double-click Teredo State.

15. In the Teredo State dialog box, click Enabled, click Disabled State in Select from the following states, click Apply, and then click OK.

16. In the details pane, double-click IP-HTTPS State.

17. In the IP-HTTPS State dialog box, click Enabled State in Select Interface state from the following options, click Apply, and then click OK.

DirectAccess clients will apply these settings the next time they update their Computer

Configuration Group Policy.



Configure IIS for Network Location




LinkId=179989).

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

administrator creates an A record in the corp.contoso.com forward lookup zone that has the IPv4

address of app1.corp.contoso.com.

Important

148


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.


otherwise be delegated permissions to configure IIS global settings. Review details about using



To mitigate security risks posed by computers on the Internet, you must install the IP and Domain

Restrictions role service for IIS on the network location server.

1. On the IIS server, click Start, click Run, type servermanager.msc, and then press ENTER.

2. In the console tree, click Roles, and then click Web Server (IIS). In the details pane, in Role Services, click Add Role Services.

3. On the Select Role Services page, in Role services, under Security, click IP and Domain Restrictions, and then click Next.

4. Click Install.

5. Verify that all installations were successful, and then click Close.

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.



Note To install the IP and Domain Restrictions role service To configure the HTTPS security binding

Note

149


Configure Packet Filters to Allow ICMP Traffic




LinkId=179989).

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 Internet

Control Message Protocol for Internet Protocol version 6 (IPv6) (ICMPv6) Echo Request

messages and, when using a NAT64 to translate IPv6 to IPv4 traffic on your intranet, Internet

Control Message Protocol for Internet Protocol version 4 (IPv4) (ICMPv4) Echo Request

messages.


otherwise be delegated permissions to configure Group Policy settings. Review details about



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

6. In the console tree, right-click Outbound 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 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.

The following procedure is only needed when you are using a NAT64 on your intranet.

Important To create and enable firewall rules for ICMPv6 trafficTo create and enable firewall rules for ICMPv4 traffic

150




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.



Configure Packet Filters to Allow Management Traffic to DirectAccess Clients




LinkId=179989).

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






2. In the console tree, open Forest\Domains\YourDomain, right-click the appropriate Group Policy object (GPO), and then click Edit.

Important To enable edge traversal for an inbound rule with the Windows Firewall with Advanced

Security snap-in

151



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


3. From the netsh advfirewall prompt, run the set store gpo=DomainName\GPOName command.

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 set store gpo=”corp.contoso.com\DirectAccess Policy-{3491980e-ef3c-

4ed3-b176-a4420a810f12}".

4. From the netsh advfirewall prompt, run the firewall show rule name=all command.

5. From the display of this command, copy or write down the names of the inbound rules for management traffic to DirectAccess clients.

6. From the netsh advfirewall prompt, run the firewall name=RuleName edge=yes command for each rule noted in step 5.



Configure Packet Filters to Block Access to Domain Controllers




LinkId=179989).

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

To enable edge traversal for an inbound rule with the Netsh.exe command-line toolImportant

152


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.


otherwise be delegated permissions to create Windows Firewall rules. Review details about using



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.


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







LinkId=179989).

The DirectAccess server requires and network location servers might require certificates for

Secure Sockets Layer (SSL) authentication that have customized certificate properties. To

request and modify these certificates from an Active Directory Certificate Services (AD CS)-based

To add packet filters to prevent access to domain controllers from the Internet interfaceImportant

153



certification authority (CA), you must modify the permissions of the Web Server certificate

template.


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

Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

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

3. Click the Security tab, and then click Add.

4. In Enter the object names to select, type the name of the security group that contains the computers that are allowed to request customized certificates, and then click OK.

This security group should contain, at least temporarily when requesting custom

certificates, the computer accounts of the DirectAccess server and network location

server. As a security best practice, do not use the Authenticated Users group.

5. In Permissions, click Enroll under Allow, and then click OK.



Configure Settings to Confine ICMPv6 Traffic to the Intranet




LinkId=179989).

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.


otherwise be delegated permissions to modify Group Policy settings. Review details about using

To configure permissions for the Web Server certificate templateImportant

154








set store gpo="DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-

a4420a810f12}"

consec show rule name=”DirectAccess Policy-ClientToDnsDc”

consec show rule name=”DirectAccess Policy-ClientToCorp”

4. From the display of the last two commands, copy or write down the IPv6 addresses for the RemoteTunnelEndpoint.


set global ipsec defaultexemptions neighbordiscovery,dhcp

consec add rule name=”Exempt ICMPv6 to Tunnel endpoint” profile=private,public

action=noauthentication mode=tunnel endpoint1=any

endpoint2=IPv6AddressesOfTheRemoteTunnelEndpoints protocol=icmpv6

set store gpo="DomainName\DirectAccess Policy-{ab991ef0-6fa9-4bd9-bc42-

3c397e8ad300}"

set global ipsec defaultexemptions neighbordiscovery,dhcp

consec add rule name=”Exempt ICMPv6 from Tunnel endpoint”

profile=private,public action=noauthentication mode=tunnel

endpoint1=IPv6AddressesOfTheRemoteTunnelEndpoints endpoint2=any

protocol=icmpv6

6. Click Start, type gpmc.msc, and then press ENTER.

7. In the console tree, open Forest/Domains/YourDomain, right-click the DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} GPO, and then click Edit.

8. In the console tree of the Group Policy Management Editor, open Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security.

9. Right-click Windows Firewall with Advanced Security, and then click Properties.

10. Click the IPsec Settings tab. In IPsec exemptions, in Exempt ICMP from IPsec, click No, and then click OK.

11. Close the Group Policy Management Editor.

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

13. In the console tree of the Group Policy Management Editor, open Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security.

To confine ICMPv6 traffic to the intranet

155


14. Right-click Windows Firewall with Advanced Security, and then click Properties.

15. Click the IPsec Settings tab. In IPsec exemptions, in Exempt ICMP from IPsec, click No, and then click OK.



Configure Strong Certificate Revocation Checking for IPsec Authentication




LinkId=179989).

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.








set store gpo=”DomainName\DirectAccess Policy-{ab991ef0-6fa9-4bd9-bc42-

3c397e8ad300}”

set global ipsec strongcrlcheck 2

exit

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

Important To configure strong certificate revocation checking for IPsec authentication

Notes

156



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.



Configure the DirectAccess IPsec Gateway on a Different Server

Configuring the DirectAccess Internet Protocol security (IPsec) gateway on a different server

consists of the following procedures:

Configure the Intra-Server Subnet

Configure the IPv6 Connectivity Server

Configure the IPsec Gateway Server

See Checklist: Moving the IPsec Gateway to Another Server for information about when these

procedures need to be performed.

Configure the Intra-Server Subnet

When configuring the DirectAccess Internet Protocol security (IPsec) gateway on a different

server, the intra-server subnet exists between the two servers and provides a way for the Internet

Protocol version 6 (IPv6) connectivity server to forward and receive tunneled packets to and from

DirectAccess clients on the Internet.

With this procedure, you attach both servers to the intra-server subnet and configure the IPv6

connectivity server to be an advertising, default IPv6 router for the subnet.

Before performing this procedure, you should determine a 64-bit prefix for the intra-server subnet.

For example, you can use the following:

6to4-basedPrefix:3::/64 if you are using a 6to4-based prefix based on the first public Internet Protocol version 4 (IPv4) address assigned to Internet interface of the IPv6 connectivity server.

NativePrefix:SubnetID::/64 if you are using a 48-bit native IPv6 prefix.


otherwise be delegated permissions to modify IPv6 interface settings. Review details about using



1. On the IPsec gateway server, remove the two consecutive public IPv4 addresses

To configure the intra-server subnet

157


assigned to the Internet interface.

2. On the IPv6 connectivity server, configure the two consecutive public IPv4 addresses on the Internet interface, and then connect it to the Internet.

3. Connect an interface of the IPv6 connectivity server and the IPsec gateway server to the same switch to create a subnet.

4. On the IPv6 connectivity server, start a command prompt as an administrator.

5. In the Command Prompt window, type the netsh interface ipv6 show interfaces command.

This command lists the interfaces and their interface indexes.

6. In the Command Prompt window, run the following commands:

netsh interface ipv6 SubnetInterfaceNameOrIndex forwarding=enabled

advertise=enabled advertisedefaultroute=enabled

netsh interface ipv6 add route 64BitPrefixOfSubnet publish=yes

7. On the IPsec gateway server, start a command prompt as an administrator.

8. In the Command Prompt window, type the netsh interface ipv6 show addresses command.

9. In the display, copy or note the public address assigned to the subnet interface of the IPsec gateway server. You will need this address for the Configure the IPsec Gateway Server procedure.



Configure the IPv6 Connectivity Server

This procedure configures the Internet Protocol version 6 (IPv6) connectivity server to act as a

6to4 relay, Teredo server, and Internet Protocol over Secure Hypertext Transfer Protocol (IP-

HTTPS) server.

Before performing this procedure, you should determine the following:

The public Internet Protocol version 4 (IPv4) address or publically resolvable fully qualified domain name (FQDN) to use in the uniform resource locator (URL) for the IP-HTTPS server.

The 64-bit prefix for the logical IP-HTTPS subnet between the IPsec connectivity server and IP-HTTPS-based DirectAccess clients. The DirectAccess Setup Wizard uses the following:

6to4-basedPrefix:2::/64 if you are using a 6to4-based prefix based on the first public IPv4 address assigned to Internet interface of the IPsec connectivity server.

NativePrefix:SubnetID::/64 if you are using a 48-bit native IPv6 prefix.


otherwise be delegated permissions to modify IPv6 settings. Review details about using the



158


1. On the IPv6 connectivity server, start a command prompt as an administrator.




netsh interface ipv6 set interface InternetInterfaceIndex forwarding=enabled

netsh interface teredo set state type=server servername=FirstPublicIPv4Address

netsh interface ipv6 set interface TeredoInterfaceIndex forwarding=enabled

netsh interface 6to4 set state enabled

netsh interface ipv6 set interface 6to4InterfaceIndex forwarding=enabled

netsh interface ipv6 set interface IPHTTPSInterface forwarding=enabled

advertise=enabled

4. Install a Secure Sockets Layer (SSL) certificate using manual enrollment. For more information, see Install an IP-HTTPS Certificate.

5. Use the netsh http add sslcert command to configure the SSL binding.


netsh interface httpstunnel add interface type=server

url=https://PublicIPv4AddressOrFQDN:443/iphttps state=enabled

authmode=certificates

netsh interface ipv6 add route IP-HTTPSPrefix::/64 IPHTTPSInterface publish=yes



Configure the IPsec Gateway Server

In this procedure, you configure the Internet Protocol security (IPsec) gateway server to act only

as the IPsec tunnel endpoint and Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

router and modify Group Policy settings for the new dual-server configuration.

Before performing this procedure, you should have determined the public IPv6 address that is

assigned to the intra-server subnet interface on the IPsec gateway server

(PublicIpv6AddressOfIPsecGWServerSubnetInterface). For more information, see Configure the

Intra-Server Subnet.


otherwise be delegated permissions to modify IPv6 and Group Policy settings. Review details

about using the appropriate accounts and group memberships at Local and Domain Default

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

1. On the IPsec gateway server, start a command prompt as an administrator.

To configure the IPv6 connectivity server To configure the IPsec gateway server

159





3. In the Command Prompt window, type the following commands:

netsh interface ipv6 set teredo default

netsh interface ipv6 set interface TeredoInterfaceIndex forwarding=disabled

netsh interface 6to4 set state default

netsh interface ipv6 set interface 6to4InterfaceIndex forwarding=disabled

netsh interface ipv6 set interface IPHTTPSInterface forwarding=disabled

advertise=disabled

netsh interface httpstunnel add interface state=default


5. From the Command Prompt window, type the following commands

netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-

4ed3-b176-a4420a810f12}"

netsh advfirewall consec set rule name=”DirectAccess Policy-ClientToCorp” new

remotetunnelendpoint=PublicIpv6AddressOfIPsecGWServerSubnetInterface

netsh advfirewall consec set rule name=”DirectAccess Policy-ClientToDnsDc” new


netsh advfirewall consec set rule name=”DirectAccess Policy-ClientToMgmt” new


netsh advfirewall set store gpo=”DomainName\DirectAccess Policy-{ab991ef0-6fa9-

4bd9-bc42-3c397e8ad300}"

netsh advfirewall consec set rule name=”DirectAccess Policy-DaServerToMgmt”

new localtunnelendpoint=PublicIpv6AddressOfIPsecGWServerSubnetInterface

netsh advfirewall consec set rule name=”DirectAccess Policy-DaServerToCorp”


netsh advfirewall consec set rule name=”DirectAccess Policy-DaServerToDnsDc”




Configure the DirectAccess Server as the Network Location Server



Important

160


LinkId=179989).

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.


otherwise be delegated permissions to install a server role. Review details about using the



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.



Configure the DirectAccess Setup Wizard for End-to-End Access




LinkId=179989).

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.

Prior to running the DirectAccess Setup Wizard for end-to-end access, you should have

determined the following:

If you have an existing IPv6 infrastructure, the

48-bit address prefix used by your organization

and the 64-bit address prefix that you have

designated for IP-HTTPS-based DirectAccess

To install the IIS server roleImportant

161




clients. For more information, see Choose an

Intranet IPv6 Connectivity Design.

Whether you are using the DirectAccess server

or a separate server as the network location

server. For more information, see Design Your

Web Servers for DirectAccess.

The list of additional NRPT rules. For more

information, see Design Your DNS

Infrastructure for DirectAccess.

The option for local name resolution behavior.

For more information, see Design Your DNS


The list of names or IP addresses of

management computers that will be initiating

connections to DirectAccess clients. For more

information, see Design for Remote

Management.

Prior to running the DirectAccess Setup Wizard for end-to-end access, you should have

completed the following:

Created at least one Active Directory security

group for DirectAccess client computers. For

more information, see Create DirectAccess

Groups in Active Directory.

Installed an additional certificate on the

DirectAccess server computer for IP-HTTPS

connections. For more information, see Install

an IP-HTTPS Certificate.

If you are using the DirectAccess server as the

network location server, installed the Web

Server (IIS) role with the IP and Domain

Restrictions role service and an additional

certificate for network location on the

DirectAccess server computer. For more

information, see Configure the DirectAccess

Server as the Network Location Server.

162

To complete this procedure, you must be a member of the local Administrators group, or


Setup Wizard. Review details about using the appropriate accounts and group memberships at





4. On the DirectAccess Client Setup page, click Add.

5. In the Select Group dialog box, specify the names of the security groups that you created to contain DirectAccess client computers, click OK, and then click Finish.

Do not specify the names of built-in security groups, such as Domain Computers or

Domain Users.

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


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 end-to-end access

163


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.


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.





Configure the DirectAccess Setup Wizard for Full Intranet Access




LinkId=179989).

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.

Prior to running the DirectAccess Setup Wizard for full intranet access, you should have


Whether you are using smart card

authorization. For more information, see

Choose an Authentication and Authorization

Scheme.




Important

164



















Management.

Prior to running the DirectAccess Setup Wizard for full intranet access, you should have



group for DirectAccess client computers. For

more information, see Create DirectAccess

Groups in Active Directory.













165











Domain Users.


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.








To run the DirectAccess Setup wizard for full intranet access

166


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.



16. On the DirectAccess Application Server Setup page, click Finish.





Configure the DirectAccess Setup Wizard for Selected Server Access




LinkId=179989).

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.

Prior to running the DirectAccess Setup Wizard for selected server access, you should have


Whether you are using smart card

authorization. For more information, see

Choose an Authentication and Authorization

Scheme.








Important

167















Management.

The type of selected server access for your

organization. For more information, see

Selected Server Access.

Prior to running the DirectAccess Setup Wizard for selected server access, you should have



group for DirectAccess client computers and at

least one Active Directory security group for

selected servers. For more information, see

Create DirectAccess Groups in Active

Directory.













168











Domain Users.


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.








To run the DirectAccess Setup wizard for selected server access

169


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.



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.





Configure the NRPT for an IPv6/IPv4 DNS Gateway




LinkId=179989).

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.

Important

170






1. Identify the intranet namespaces that contain only IPv4-only resources.




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.



Configure the NRPT with Group Policy




LinkId=179989).

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






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

To configure the NRPT for an IPv6/IPv4 DNS gatewayImportant

To configure the NRPT with Group Policy

171




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.







LinkId=179989).

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.


otherwise be delegated permissions to configure IPv6 settings. Review details about using the




2. From the Command Prompt window, type the netsh interface ipv6 add route ::/0 InterfaceNameOrIndex NextHopIPv6Address command.


Important To configure a default IPv6 route for a direct connection to the IPv6 InternetTo configure a 6to4-tunneled connection to the IPv6 Internet

172



2. From the Command Prompt window, type the netsh interface ipv6 6to4 set relay name=6to4RelayAddress state=enabled command.


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



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.


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 Local

and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).




LinkId=179989).

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.

To configure an IPv6-in-IPv4-tunnel to the IPv6 InternetImportant

To create a security group for DirectAccess client computersTo create a security group for selected servers

173




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.







LinkId=179989).

A DirectAccess server acting as a network location server must obtain an additional customized

Secure Sockets Layer (SSL) certificate using the Web Server certificate template.


otherwise be delegated permissions to obtain a customized certificate. Review details about



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 Web Server certificate template, and then click More information is required to enroll for this certificate.

Note Important To install a certificate for network location

174



If the Web Server certificate template does not appear, ensure that the DirectAccess

server computer account has enroll permissions for the Web Server certificate template.

For more information, see Configure Permissions on the Web Server Certificate

Template.

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. Click OK, click Enroll, and then click Finish.

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

12. Right-click the certificate, and then click Properties.

13. In Friendly Name, type Network Location Certificate, and then click OK.

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.







LinkId=179989).

The DirectAccess server needs a customized Secure Sockets Layer (SSL) certificate to

authenticate Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS)-based

DirectAccess connections.


otherwise be delegated permissions to request and customize an SSL certificate. Review details



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.


Note Important To obtain an additional certificate for IP-HTTPS

175







If the Web Server certificate template does not appear, ensure that the DirectAccess



Template.

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.



12. Right-click the certificate, and then click Properties.

13. In Friendly Name, type IP-HTTPS Certificate, and then click OK.

Steps 12 and 13 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.

The DirectAccess Setup Wizard by default configures the URL of the IP-HTTPS server in

the DirectAccess client and server GPOs based on the following format:

https://SubjectFieldIP-HTTPSCertificate:443://IPHTTPS. This URL must not be more than

256 characters long. Otherwise, the IP-HTTPS component on the DirectAccess client and

server will not operate correctly. Therefore, the FQDN in Step 9 of this procedure must

not be more than 234 characters.



Install and Configure IIS for a Network Location Server Certificate




LinkId=179989).

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

Note Warning Important

176



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 Local and Domain Default Groups


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.





If the Web Server certificate template does not appear, ensure that the network location



Template.

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.



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.

To obtain an additional SSL certificate for network location To configure the HTTPS security binding

177








LinkId=179989).

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.


otherwise be delegated permissions to install features from Server Manager. Review details



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.



Remove ISATAP from the DNS Global Query Block List




LinkId=179989).

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

Important To install the DirectAccess feature from Server Manager

Important

178





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 Local and

Domain Default Groups (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.



net stop dns

net start dns



Appendix A – Manual DirectAccess Server Configuration




LinkId=179989).

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

Component Purpose Command

Teredo server Configure Teredo with

the name or IPv4

netsh interface ipv6 set teredo server

FirstIPv4AddressOfDirectAccessServer

To remove ISATAP from the DNS global query block list on a DNS serverImportant

179





address of the Teredo

server.

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:


InterfaceIndex forwarding=enabled

3. For the IP-HTTPS interface, run the following command:


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

180

Configure intranet access components


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.


ISATAPInterfaceIndex

forwarding=enabled advertise=enabled

Network Interface If you have native IPv6,

configure intranet

interface forwarding and

advertising on the LAN

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

(DoSP) on the Internet interface.

netsh ipsecdosp add interface

InternetInterfaceName public

Enable IPsec DoSP on the intranet interface. netsh ipsecdosp add interface

intranetInterfaceName internal

181

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.


ClientToMgMt" mode=tunnel profile=public,private

Endpoint1=ManagementServerIPv6 Addresses Endpoint2=Any



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


ClientToCorp" mode=tunnel profile=public,private

Endpoint1=IntranetIPv6Prefix Endpoint2=Any



Auth1=ComputerCert Auth1CA=

Auth1CA=CANameString Auth2=UserKerb qmsecmethods=ESP:SHA1-

AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb

Connection security rules for client configuration (full intranet access model)

Purpose Command

Connection

security rule for


ClientToDNSDC" mode=tunnel profile=public,private Endpoint1=Any

182

Purpose Command

traffic to the

intranet DNS

server and

domain controller

(the

infrastructure

tunnel).

Endpoint2=DNS-DCIPv6Address LocalTunnelEndpoint=Any

RemoteTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface

Action=RequireInRequireOut Auth1=ComputerCert

Auth1CA=CANameString Auth2=UserNTLM qmsecmethods=ESP:SHA1-


Connection

security rule for

traffic to

management

servers.


ClientToCorp" mode=tunnel profile=public,private Endpoint1=Any

Endpoint2=IntranetIPv6Prefix LocalTunnelEndpoint=Any


Action=RequireInRequireOut Auth1=ComputerCert Auth1CA=

Auth1CA=CANameString Auth2=UserKerb qmsecmethods=ESP:SHA1-


Connection

security rule for

traffic to the

intranet (the

intranet tunnel).


ClientToMgmt" mode=tunnel profile=public,private Endpoint1=Any

Endpoint2=ManagementServerIPv6 Addresses LocalTunnelEndpoint=Any


Action=RequireInRequireOut Auth1=ComputerCert

Auth1CA=CANameString Auth2=UserNTLM qmsecmethods=ESP:SHA1-


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

Appendix B – Manual DirectAccess Client Configuration




LinkId=179989).

Manual configuration of DirectAccess clients consist of IPv6 transition technology settings and the

Name Resolution Policy Table (NRPT).

Important

183


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



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



Settings\Ipv6 transition Technologies\6to4

Relay

Name=FirstPublicIPv4AddressOfDirectAcce

ssServer

Enable the

IP-HTTPS

client and

configure

the IP-

HTTPS

Uniform

Resource

Locator

(URL).

netsh interface httpstunnel add

interface client https://SubjectOfIP-

HPPTSCertificate/IPHTTPS



Settings\Ipv6 transition Technologies\IP-

HTTPS State set to Enabled and the IP-

HTTPS URL of https://SubjectOfIP-

HPPTSCertificate:443/IPHTTPS

184

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




LinkId=179989).

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>

.

.

</ServerData>

.

Important

185



.

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

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

186

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




LinkId=179989).

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" />

<xs:element name="InternalNetworkInterface" type="interface" />

<xs:element name="TransitionTechnologies">

Important

187


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

<xs:element name="IpHttpsPrefix" type="ipv6Prefix" />

<xs:element name="IpHttpsCertHash" type="xs:hexBinary" />

188

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


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>

<xs:sequence>

<xs:element maxOccurs="unbounded" name="Address" type="ipAddress" />

189

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


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" />

</xs:sequence>

</xs:complexType>

190

</xs:element>

<xs:element name="DnsServers">

<xs:complexType>

<xs:sequence>


type="ipv6Address" />

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="MgmtServers" minOccurs="0">

<xs:complexType>

<xs:sequence>


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

<xs:complexType>

<xs:all>

191

<xs:element name="Option">

<xs:simpleType>


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


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>

<xs:element name="SecurityGroup" type="sg" maxOccurs="unbounded"

/>

</xs:sequence>

192

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

<xs:element name="DnsFallBackOptions">

<xs:simpleType>

193


<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" />

<xs:element name="ClientToApplicationServerPolicy" type="xs:string"

default="DirectAccess Policy-clientToAppServer" minOccurs="0" />

194

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


Policy-{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300}" />

</xs:complexType>

</xs:element>

<xs:element name="AppServerPolicies">

195

<xs:complexType>

<xs:all>

<xs:element name="SecurityGroups" minOccurs="0">

<xs:annotation>


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


Whether IPsec connection security rules on application servers

should allow null encryption.

MUST be specified in case AuthorizationOption is other than

NoAuthorization.

196

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


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>

<xs:all>

197

<xs:element name="Name" type="xs:string" />

<xs:element name="Type">

<xs:simpleType>


<xs:enumeration value="computer"/>

<xs:enumeration value="group"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:all>

</xs:complexType>

<xs:complexType name="interface">

<xs:annotation>


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>


The representation of an IPv4 address

</xs:documentation>

</xs:annotation>


198

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


The representation of an IPv6 address

</xs:documentation>

</xs:annotation>


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


The representation of an IPv6 prefix

</xs:documentation>

</xs:annotation>


<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+)" />

</xs:restriction>

199

</xs:simpleType>

<xs:simpleType name="ipv6PrefixOrAddress">

<xs:annotation>


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>


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>


The representation of a GUID, generally the id of an element.

</xs:documentation>

</xs:annotation>


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

</xs:simpleType>

200

<xs:simpleType name="domainName">

<xs:annotation>

<xs:documentation>

The domainName type represents a DNS domain name.

</xs:documentation>

</xs:annotation>


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

201

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

To learn how to use DirectAccess troubleshooting tools and techniques in the DirectAccess test

lab (http://go.microsoft.com/fwlink/?Linkid=150613), see the Test Lab Guide: Troubleshoot

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

This guide, combined with the DirectAccess Design and Deployment Guides, is also available as

a Microsoft Word file (http://go.microsoft.com/fwlink/?LinkId=163662) in the Microsoft Download

Center.

For a list of all the DirectAccess troubleshooting resources, see Troubleshoot DirectAccess in

Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?LinkId=190435).

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.

202








You want to learn about troubleshooting techniques to use with DirectAccess.

How to use this guideThis guide contains the following topics:


This topic lists problem topics alphabetically. You can use it to find a problem topic quickly.


This topic describes how to use command line tools, services, and logs on your computer to

gather information for troubleshooting DirectAccess.


This topic provides a step-by-step process for troubleshooting DirectAccess connections.


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.

Additional resourcesTo learn how to use DirectAccess troubleshooting tools and techniques in a test lab, see the Test

Lab Guide: Troubleshoot DirectAccess (http://go.microsoft.com/fwlink/?LinkId=181160).

For a list of all the DirectAccess troubleshooting resources, see Troubleshoot DirectAccess in

Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?LinkId=190435).


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

203





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


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

Command Line Tools

Snap-in Tools

DirectAccess Connectivity Assistant (DCA)

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.

204

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.

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

To start the DirectAccess troubleshooterNote

To capture a network trace for a DirectAccess client

205


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

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

To capture a network trace for WFP

206

The Netsh.exe Command Line Tool

The following Network Shell (Netsh) commands can be used to gather information when

troubleshooting DirectAccess:

netsh dnsclient show state

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 advfirewall monitor show mmsa

netsh advfirewall monitor show qmsa

netsh advfirewall monitor show consec rule name=all

netsh advfirewall monitor show currentprofile

netsh interface ipv6 show interfaces

netsh interface ipv6 show interfaces level=verbose

netsh interface ipv6 show route

The example displays of Netsh.exe commands in this topic were obtained from the

DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613).

netsh dnsclient show stateThis command shows the settings for the Name Resolution Policy Table (NRPT) on a

DirectAccess client, including where the client is located (either on the intranet or on the Internet),

whether the client has been configured with DirectAccess NRPT rules, and whether they are

enabled.

The following is an example of output from the netsh dnsclient show state command.

Name Resolution Policy Table Options

--------------------------------------------------------------------

Query Failure Behavior : Only use LLMNR and NetBIOS if the name does not

exist in DNS

Query Resolution Behavior : Resolve only IPv6 addresses for names

Network Location Behavior : Let Network ID determine when DirectAccess

settings are to be used

Machine Location : Inside corporate network

DirectAccess Settings : Configured and Disabled

DNSSEC Settings : Not Configured

Note

207


In this example, the DirectAccess client is located on the intranet (Machine location: Inside

corporate network) and has been configured with DirectAccess NRPT rules, but they are

disabled (DirectAccess Settings: Configured and Disabled).

You use the netsh dnsclient show state command to determine the results of network location

detection (the Machine location field) and the state of DirectAccess NRPT rules (the

DirectAccess Settings field).

netsh namespace show effectivepolicy and netsh namespace show policyThis command shows the rules in the 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

208

DirectAccess (Proxy Settings) : Bypass proxy

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.

Note

209

The following is an example of output from the netsh interface teredo show state command on

a DirectAccess client.

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

210

6to4 source address 0, native IPv6 source address 0

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

211

URL : https://da1.contoso.com:443/IPHTTPS

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


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.

212

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.

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


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

----------------------------------------------------------------------



Auth1: ComputerCert

Auth2: UserNTLM


Cookie Pair: 9e355ec21d66e39b:d748c6e2ddd09424

Health Cert: No

Main Mode SA at 09/11/2009 10:43:59

----------------------------------------------------------------------


Remote IP Address: 2002:836b:2:1:0:5efe:10.0.0.3

Auth2 Local ID: CORP\User1

213

Auth2 Remote ID: host/APP1.corp.contoso.com

Auth1: ComputerCert

Auth2: UserKerb


Cookie Pair: 912ff504e979e831:4eb6fb986fa84eb9

Health Cert: No

Main Mode SA at 09/11/2009 10:43:59

----------------------------------------------------------------------



Auth2 Local ID: host/CLIENT2.corp.contoso.com

Auth2 Remote ID: CORP\DA1$

Auth1: ComputerCert

Auth2: UserKerb


Cookie Pair: 96d2b451be5756e9:0d2515c811c26034

Health Cert: No

Main Mode SA at 09/11/2009 10:43:59

----------------------------------------------------------------------



Auth2 Local ID: NT AUTHORITY\SYSTEM

Auth2 Remote ID: host/da1.corp.contoso.com

Auth1: ComputerCert

Auth2: UserKerb


Cookie Pair: 2ba50b46a6820026:24b64b78e8f7ac0d

Health Cert: No

Main Mode SA at 09/11/2009 10:43:59

----------------------------------------------------------------------


214


Auth2 Local ID: CORP\User1

Auth2 Remote ID: host/da1.corp.contoso.com

Auth1: ComputerCert

Auth2: UserKerb


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

----------------------------------------------------------------------



Auth1: ComputerCert

Auth2: UserNTLM


Cookie Pair: a075a1437682ad8e:0afed90d0f2a8cac

Health Cert: No

Main Mode SA at 09/11/2009 10:44:03

----------------------------------------------------------------------



Auth1: ComputerCert

Auth2: UserNTLM


Cookie Pair: 9e355ec21d66e39b:d748c6e2ddd09424

Health Cert: No

Main Mode SA at 09/11/2009 10:44:03

----------------------------------------------------------------------


215


Auth2 Local ID: NT AUTHORITY\SYSTEM

Auth2 Remote ID: host/CLIENT2.corp.contoso.com

Auth1: ComputerCert

Auth2: UserKerb


Cookie Pair: 96d2b451be5756e9:0d2515c811c26034

Health Cert: No

Main Mode SA at 09/11/2009 10:44:03

----------------------------------------------------------------------



Auth2 Local ID: host/da1.corp.contoso.com

Auth2 Remote ID: CORP\CLIENT2$

Auth1: ComputerCert

Auth2: UserKerb


Cookie Pair: 2ba50b46a6820026:24b64b78e8f7ac0d

Health Cert: No

Main Mode SA at 09/11/2009 10:44:03

----------------------------------------------------------------------



Auth2 Local ID: host/da1.corp.contoso.com

Auth2 Remote ID: CORP\User1

Auth1: ComputerCert

Auth2: UserKerb


Cookie Pair: 4775f7dd32e268b2:b0ad96d598518fa7

Health Cert: No

Ok.

216

You can correlate the main mode SAs on the DirectAccess client and server through the Cookie

Pair.

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


Quick Mode SA at 09/11/2009 10:56:38

----------------------------------------------------------------------



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 Port: Any

Remote Port: Any

Protocol: Any

Direction: Both


PFS: None

217

Quick Mode SA at 09/11/2009 10:56:38

----------------------------------------------------------------------


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 Port: Any

Remote Port: Any

Protocol: Any

Direction: Both


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 Port: Any

Remote Port: Any

Protocol: Any

Direction: Both


PFS: None

218

Quick Mode SA at 09/11/2009 10:56:47

----------------------------------------------------------------------



Local Port: Any

Remote Port: Any

Protocol: Any

Direction: Both


PFS: None

Quick Mode SA at 09/11/2009 10:56:47

----------------------------------------------------------------------



Local Port: Any

Remote Port: Any

Protocol: Any

Direction: Both


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.

219

The following is an example of the output from the netsh advfirewall monitor show consec rule

name=all command on a DirectAccess client.

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


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

220

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:SHA256-None+60min+100000kb,AH:SHA256+6

0min+100000kb,AuthNoEncap:SHA256+60min+100000kb

Rule Name: DirectAccess Policy-ClientToMgmt

----------------------------------------------------------------------

Enabled: Yes


Type: Dynamic

Mode: Tunnel


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


A



Auth1CertType: Root

Auth1HealthCert: No

Auth2: UserNTLM


221


QuickModeSecMethods: ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-AE

S128+60min+100000kb



Rule Name: DirectAccess Policy-ClientToCorp

----------------------------------------------------------------------

Enabled: Yes


Type: Dynamic

Mode: Tunnel



Endpoint1: Any

Endpoint2: 2002:836b:2:1::/64

Protocol: Any


Auth1: ComputerCert


A



Auth1CertType: Root

Auth1HealthCert: No

Auth2: UserKerb




S128+60min+100000kb



Rule Name: DirectAccess Policy-ClientToDnsDc

222

----------------------------------------------------------------------

Enabled: Yes


Type: Dynamic

Mode: Tunnel



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


Auth1: ComputerCert


A



Auth1CertType: Root

Auth1HealthCert: No

Auth2: UserNTLM




S128+60min+100000kb



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.

223

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.

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 network location 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


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

224

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

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

225

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 isatap.corp.contoso.com Parameters

----------------------------------------------

IfLuid : tunnel_4

IfIndex : 13

State : connected

Metric : 25





DAD Transmits : 0


Site Id : 1

Forwarding : enabled

Advertising : enabled

Neighbor Discovery : enabled










Advertise Default Route : enabled



226


Interface isatap.isp.example.com Parameters

----------------------------------------------

IfLuid : tunnel_5

IfIndex : 14

State : connected

Metric : 25





DAD Transmits : 0


Site Id : 1

Forwarding : disabled
















Interface Corpnet Parameters

----------------------------------------------

227

IfLuid : ethernet_6

IfIndex : 11

State : connected

Metric : 20





DAD Transmits : 1


Site Id : 1




Neighbor Unreachability Detection : enabled


Managed Address Configuration : enabled

Other Stateful Configuration : enabled










Interface 6TO4 Adapter Parameters

----------------------------------------------

IfLuid : tunnel_6

IfIndex : 15

State : connected

Metric : 25

228





DAD Transmits : 0


Site Id : 1



Neighbor Discovery : disabled














Interface Teredo Tunneling Pseudo-Interface Parameters

----------------------------------------------

IfLuid : tunnel_7

IfIndex : 16

State : connected

Metric : 50





229

DAD Transmits : 0


Site Id : 1

















Interface IPHTTPSInterface Parameters

----------------------------------------------

IfLuid : tunnel_8

IfIndex : 17

State : connected

Metric : 50





DAD Transmits : 1


Site Id : 1


230

Advertising : enabled















Interface Internet Parameters

----------------------------------------------

IfLuid : ethernet_9

IfIndex : 12

State : connected

Metric : 20





DAD Transmits : 1


Site Id : 1






231

Managed Address Configuration : enabled

Other Stateful Configuration : enabled










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

232

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

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 name resolution and

reachability. For example, you can use Ping.exe for the following:

233

Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6)-based reachability of the DirectAccess server across the Internet

IPv6-based reachability of intranet resources beyond the DirectAccess server, such as the intranet DNS server

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

If your computer has determined that it is on the intranet, the netsh namespace show

effectivepolicy command will display no intranet DNS servers.

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


234

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 the DirectAccess client

in the DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) when it is connected

to the intranet subnet.

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


Ethernet adapter Local Area Connection:



Tunnel adapter isatap.{3119B40F-CEC7-404A-B368-0BE67966EBF5}:

Important

235




Tunnel adapter isatap.{04076670-7AF6-4B18-BF7E-8CB8393C4B4D}:



Tunnel adapter 6TO4 Adapter:


IPv6 Address. . . . . . . . . . . : 2002:836b:65::836b:65

Default Gateway . . . . . . . . . : 2002:836b:2::836b:2

Tunnel adapter iphttpsinterface:



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 the DirectAccess server

in the DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613).

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

236



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


Tunnel adapter isatap.corp.contoso.com:

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


Tunnel adapter isatap.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


Tunnel adapter 6TO4 Adapter:


IPv6 Address. . . . . . . . . . . : 2002:836b:2::836b:2

IPv6 Address. . . . . . . . . . . : 2002:836b:3::836b:3


Tunnel adapter Teredo Tunneling Pseudo-Interface:


237

Link-local IPv6 Address . . . . . : fe80::8000:f227:7c94:fffd%16


Tunnel adapter IPHTTPSInterface:


IPv6 Address. . . . . . . . . . . : 2002:836b:2:2:6d5c:17f7:69e8:dd2b

Link-local IPv6 Address . . . . . : fe80::6d5c:17f7:69e8:dd2b%17


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.

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 the

DirectAccess client in the DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613).

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

Note

238


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.

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 the

DirectAccess client in the DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613).

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:

239


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.

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.

When you click the Monitoring node in the console tree, the DirectAccess Management

snap-in begins recording trace data in the DAMontr.log and continues until all instances

of the DirectAccess Management snap-in have been closed, including the DirectAccess

Management console in the Administrative Tools group, the DirectAccess Management

snap-in for a custom console, or from within Server Manager. This continuous tracing

adds 80 Megabytes (MB) of data per day to the DAMontr.log file, which can result a large

file size over time. The logging continues regardless of which node you select in the

DirectAccess Management console tree. When you close all instances of the

DirectAccess Management snap-in, run it again, then click the Monitoring node in the

console tree, the DirectAccess Management snap-in automatically deletes DaMontr.log

when the file size is larger than 10 MB. If you want to keep an instance of the

To view the status of the DirectAccess server with DirectAccess monitoringWarning

240

DirectAccess Management snap-in open continuously, you can create and run a script to

delete the DaMontr.log file at regular intervals.

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.

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

The first consecutive Internet

Protocol version 4 (IPv4)

address of the DirectAccess

241


Setup Wizard

gateway for IPv6 network traffic

sent by the 6to4 host.

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.

The qualification process brings

it out of a dormant state.

Set to enabled 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 N/A

242


Setup Wizard

of the Teredo service.

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



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.

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.

243

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

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.

Note To use the Windows Firewall with Advanced Security snap-in

244

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, network location

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 network location 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.

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.


To start the Event Viewer snap-in To view certificates in the computer store with the Certificates snap-in

245

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.

DirectAccess Connectivity Assistant (DCA)

The DirectAccess Connectivity Assistant (DCA) is a free Solution Accelerator download that helps

streamline end-user support for DirectAccess.

The DCA installs on DirectAccess clients and adds an icon to the notification area of the desktop.

With this icon, users can determine their intranet connectivity status. The DCA also provides tools

to help users reconnect on their own if problems arise and creates diagnostics to help mobile

users provide IT staff with key information.

For more information, see Deploying, Managing, and Using the DirectAccess Connectivity

Assistant.

For information about the messages displayed by the DCA and how to use them for

troubleshooting DirectAccess, see Using the DCA Software.

To download the DCA, see Microsoft DirectAccess Connectivity Assistant



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.

246


3. The DirectAccess client 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-

{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. For more information, see Cannot Reach the DirectAccess Server with IP-

HTTPS.

If you have configured force tunneling, only the Tunnel adapter iphttpsinterface will

be enabled.

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.

Notes

247

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.

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 with Service Pack 2 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 a NAT64, the intranet server might

not have a global IPv6 address. In this case, ensure that the NAT64 has a global

IPv6 address.

8. The DirectAccess client on the Internet must correctly determine that it is not on the intranet.

Type the netsh dnsclient show state command. The determined network location is

displayed in the Machine Location field (Outside corporate network or Inside corporate

network).

If the DirectAccess client has correctly determined that it is outside the corporate network (not

on the intranet), go to step 9.

If the DirectAccess client has incorrectly determined that it is inside the corporate network (on

the intranet), use the netsh namespace show policy command to display the Name

Resolution Policy Table (NRPT) rules configured through Group Policy. 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.

Determine the network location uniform resource locator (URL) from the reg query HKLM\

software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\

CorporateConnectivity /v DomainLocationDeterminationUrl command.

Determine whether the FQDN from this URL either does not match the DNS suffix for your

intranet namespace in the NRPT or matches an exemption rule in the NRPT.

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.

Note

248

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 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, test DNS name resolution from an

intranet computer with the nslookup –q=aaaa IntranetFQDN IntranetDNSServerIPv6Address

command. If there is no response, ensure that the DNS Server service on Windows-based

DNS servers is listening on its assigned IPv6 addresses. Use the Interfaces tab for the

properties of the DNS server in the DNS Manager snap-in. Otherwise, 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 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.

Note Note

249

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 must use an intermediate NAT64/DNS64, such as the Microsoft Forefront Unified

Access Gateway (UAG) 2010.

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, ensure that the Windows Firewall service is running using the

Services snap-in or the sc query mpssvc command at a Windows command prompt. If you

are using a third-party host firewall, see DirectAccess and Third-party Host Firewalls.

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

server. For example, for 131.107.0.1, the corresponding IPv6 address is 2002:836b:1::836b:1

(131=0x83, 107=0x6b).


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.



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

250

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

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.



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 Service

Location (SRV) records in DNS that are not specific to an Active Directory site.

Ensure that the DirectAccess client and intranet or selected server have the proper

certificates for IPsec peer authentication.

251

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.

To troubleshoot DirectAccess connections on the DirectAccess client using the DirectAccess

Connectivity Assistant (DCA), see Using the DCA Software.


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


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.

Problems with network location detection

See Fixing Issues with Network Location Detection.

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:




252


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.

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

253


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


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.


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

254

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.


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

w.x.y.1, w.x.y.10, w.x.y.2. Use a


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

255


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

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,

256


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.


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

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.


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

257


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.


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

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

258

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

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.

259

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.


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.


Registration of Intra-Site Automatic Tunnel

Addressing Protocol (ISATAP) in Domain Name

System (DNS) failed.

The DirectAccess server computer cannot use

DNS dynamic update 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.

Troubleshoot DNS dynamic update between

the DirectAccess server and its configured DNS

server.

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


command to display the state of the IP-HTTPS

interface.


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

260


state enabled command.


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

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 Creating Protected Connections to the DirectAccess Server

Fixing Issues with Connecting 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:



261





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

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 Payload (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.



4. From the netsh advfirewall prompt, run the consec show rule name=”DirectAccess Policy-ClientToDnsDc” command.

5. From the netsh advfirewall prompt, run the exit command.

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

To troubleshoot connectivity from a DirectAccess client on the IPv6 Internet to the DirectAccess server

262

the route to the destination.

7. From the Command Prompt window, run the netsh advfirewall consec show rule name=”DirectAccess Policy-ClientToCorp” command.

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


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.

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:




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

Note

263

small office network, in which the local Internet router is providing 6to4 router

functionality.


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.


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.





10. From the Command Prompt window, note the IPv6 address in RemoteTunnelEndpoint.

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

To verify 6to4 functionality and configuration on a DirectAccess client

264


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.






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

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.


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.


2. From the Command Prompt window, run the netsh interface 6to4 show relay command.


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


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



6. From the netsh advfirewall prompt, run the set store gpo=”DomainName\

To verify 6to4 functionality and configuration on the DirectAccess serverTo troubleshoot connectivity from a 6to4-based DirectAccess client on the IPv4 Internet to the DirectAccess server

265

DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}” command.




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.






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.


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:



266




You should see a Tunnel adapter Teredo Tunneling Pseudo-Interface with an IPv6

address that begins with 2001. If you do not, go to step 3.


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. If it does, see “To verify

Teredo functionality and configuration on the DirectAccess server” in this topic.






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.


DirectAccess server’s Internet interface. If there is no IPv4 address, your DirectAccess

client has not been properly configured with the Group Policy settings for DirectAccess

clients.

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

To verify Teredo functionality and configuration on a DirectAccess client

267

Teredo state Description

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. See “To troubleshoot

connectivity from a Teredo-based DirectAccess client on the IPv4 Internet to the DirectAccess

server” in this topic.

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

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.



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.






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

To verify Teredo functionality and configuration on the DirectAccess server

268

command.

This command should display server in Type and online in State.

5. From the Command Prompt window, run the netsh interface ipv6 show global command.

Note the number in the Neighbor Cache Limit field, which by default is 256.

6. From the Command Prompt window, run the netsh interface ipv6 show neighbors command.

Count the number of neighbor cache entries for the interface named Teredo Tunneling

Pseudo-Interface. If there are a large number of them, run the netsh interface ipv6

show neighbors > neighbors.txt command, open the Neighbors.txt file in a Word

processor or text editor that supports the display of line numbers, then delete all the lines

except for the neighbor cache entries for the Teredo Tunneling Pseudo-Interface. If the

number of entries in the neighbor cache is comparable to the value of the Neighbor

Cache Limit field, you might have run out of space to store neighbor cache entries for

additional Teredo-based DirectAccess clients. To increase the number of entries allowed

in the neighbor cache, run the netsh interface ipv6 set global

neighborcachelimit=Maximum command, in which Maximum is the maximum number of

expected Teredo-based DirectAccess clients.


2. From the Command Prompt window, run the netsh interface teredo show state command.


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


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





8. From another Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint. This is the IPv6 address of the DirectAccess server for the infrastructure tunnel.

To troubleshoot connectivity from a Teredo-based DirectAccess client on the IPv4 Internet to the DirectAccess server

269



9. From the Command Prompt window with the netsh advfirewall prompt, run the consec show rule name=”DirectAccess Policy-ClientToCorp” command.

10. From the other Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint. This is the IPv6 address of the DirectAccess server for the intranet tunnel.



11. If the DirectAccess client cannot connect to an intranet resource using a specific application, use the Windows Firewall with Advanced Security snap-in on the DirectAccess client to determine if there is an inbound rule for the application’s traffic. If there is, right-click the rule, click the Advanced tab, then check the Edge traversal setting. If it is set to Block edge traversal, change the setting to the appropriate level for the application.


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.


that allows Transmission Control Protocol (TCP) destination port 443 traffic for HTTPS-

encapsulated traffic to the DirectAccess server and TCP source port 443 traffic for HTTPS-

encapsulated traffic from the DirectAccess server.

270







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 client in Role and the IP-HTTPS URL in URL.

4. If the netsh interface httpstunnel show interfaces command displays More data is available, your IP-HTTPS URL is longer than 256 characters. Run the reg delete HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition\iphttps\iphttpsinterface /f command, install an IP-HTTPS certificate on the DirectAccess server that has a Subject field value less than 235 characters, configure the DirectAccess server with the DirectAccess Setup Wizard to use the new certificate, apply the DirectAccess server settings, and update the computer configuration Group Policy on your DirectAccess clients. For more information, see Install an IP-HTTPS Certificate.

If the DirectAccess client is on an intranet behind a proxy server, it must be able to locate and use

the intranet proxy server for IP-HTTPS-based connections. To quickly check this, use your

Internet browser and attempt to reach an Internet website (such as www.microsoft.com). If

successful, the DirectAccess client has determined the proper intranet proxy server. If not

successful accessing any Internet locations, perform the following procedure.

1. Configure your Internet browser to use the intranet proxy server.

For Internet Explorer:

Click Tools, and then click Internet Options.

Click the Connections tab, and then click LAN settings.


From the Command Prompt window, run the netsh winhttp import proxy source=ie

command.

If you must reconfigure the proxy server settings after leaving the intranet, repeat the previous

procedure with the original proxy settings.




To verify IP-HTTPS functionality and configuration on a DirectAccess clientTo configure the DirectAccess client to use an intranet proxy serverTo verify IP-HTTPS functionality and configuration on the DirectAccess server

271




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.


This command should display server in Role, the IP-HTTPS URL in URL, and IPHTTPS

interface active in Interface Status.

4. If the netsh interface httpstunnel show interfaces command displays More data is available, your IP-HTTPS URL is longer than 256 characters. Run the reg delete HKLM\CurrentControlSet\services\iphlpsvc\Parameters\IPHTTPS\IPHTTPSInterface /f command, install an IP-HTTPS certificate on the DirectAccess server that has a Subject field value less than 235 characters, configure the DirectAccess server with the DirectAccess Setup Wizard to use the new certificate, apply the DirectAccess server settings, and update the computer configuration Group Policy on your DirectAccess server. For more information, see Install an IP-HTTPS Certificate.

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.



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.


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

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 4 into your Internet browser and attempt to access it.

Ensure that the IP-HTTPS website 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.

To troubleshoot connectivity from an IP-HTTPS-based DirectAccess client on the IPv4 Internet to the DirectAccess server

272


8. From the netsh advfirewall prompt, run the set store gpo="DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}" command.










1. From the display of the netsh interface httpstunnel show interfaces command on the DirectAccess client, note the value in the Last Error Code.

For an explanation of the IP-HTTPS error code, find the Last Error Code number in the

list of COM Error Codes (Security and Setup) (http://go.microsoft.com/fwlink/?

LinkId=180807).

2. Ensure that the FQDN in the IP-HTTPS URL on the DirectAccess client 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.

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

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

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

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

To troubleshoot certificate problems for an IP-HTTPS-based connection to the DirectAccess server

273


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 website. You might be prompted for

authentication. Open a second Internet browser window or tab and browse a different public

website. If you can get to the second website 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 website, IP-HTTPS might be blocked.


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:

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

274

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:



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.

275


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

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.


To verify whether the DirectAccess client can successfully create the infrastructure tunnel

276

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


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

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.

277

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.


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.


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.


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

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 verify whether the DirectAccess client can successfully create the intranet tunnel

278




records in DNS.




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

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.

279

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

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.

280

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.


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.


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


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

To troubleshoot why a DirectAccess client cannot resolve names with an intranet DNS server

281

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:




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 of an IPv6/IPv4 translator, such as a NAT64.

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

282

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.


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.

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

To troubleshoot why a DirectAccess client cannot connect to an intranet resource

283

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.


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

To determine the IPv6 addresses that an intranet resource registers in DNS

284

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.






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.


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

To troubleshoot why an intranet ISATAP host does not configure an ISATAP address

285

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.






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.


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.


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.

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

To troubleshoot an ISATAP router

286

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.


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:

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.

287

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.












DirectAccess Policy, including a rule named DirectAccess Policy-ClientToMgmt.






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


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.


To verify whether the management server can successfully create the management tunnel

288



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








records in DNS.




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.


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

289

client cannot successfully create the transport mode SAs, the DirectAccess client cannot connect

to the selected servers on the intranet.












DirectAccess Policy, including a rule named DirectAccess Policy-clientToAppServer.






6. Double-click the DirectAccess Policy- clientToAppServer rule and then click the 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.


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.



of the selected server.

To verify whether the DirectAccess client can successfully create transport mode IPsec SAs to selected servers

290

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.


2. Click Start, type wf.msc, and then press ENTER.





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

Wizard.



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.





6. Initiate communication with an intranet server. For example, use an appropriate client application or the net view \\IntranetServer command.


To verify whether the DirectAccess client can successfully create transport mode IPsec SAs to intranet resources

291

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.



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 Network Location 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


After a network state change and before network location detection is complete, the DirectAccess

client has the DirectAccess-based rules in its effective Name Resolution Policy Table (NRPT). If

network location detection determines that the DirectAccess client is on the intranet, the

DirectAccess-based rules in the effective NRPT are removed. If network location 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 network location detection are the following:



292


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, network location 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

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


For more information about the technical details of the network location detection process, see

Network Location Detection.

293


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, network location 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.



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




The determined network location is displayed in the Machine Location field (Outside

corporate network or Inside corporate network).

4. To investigate the details of network location detection, 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 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.

To determine the results of network location detection on a DirectAccess client

294

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.


2. From the Command Prompt window, run the reg query HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\CorporateConnectivity /v 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.


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.


3. From the Command Prompt window, ping the FQDNs from the URLs or UNC paths for

Note To troubleshoot why a DirectAccess client on the intranet cannot successfully access

the network location URLTo test access to the CRL distribution points of the network location certificate from a

DirectAccess client on the intranet

295

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.

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.

For more information about the technical details of the network location detection process, see

Network Location Detection.

DirectAccess Technical Reference Network Location Detection

This topic describes the technical details of the DirectAccess client network location detection

process.

Network Location Detection

Along with settings for Internet Protocol version 6 (IPv6) transition technologies, DirectAccess

clients that are connected to the Internet rely on the following to perform transparent connectivity

to intranet resources:

Name Resolution Policy Table (NRPT) rules for DirectAccess. These rules specify that the DirectAccess client forward Domain Name System (DNS) queries for fully qualified domain names (FQDNs) that match the intranet namespace to the IPv6 addresses of intranet DNS servers. This separates intranet traffic from Internet traffic.

Connection security rules for DirectAccess. These rules specify that the DirectAccess client create encrypted Internet Protocol security (IPsec) tunnels to access intranet resources. There is an infrastructure tunnel that allows the client to access intranet DNS servers and domain controllers and an intranet tunnel that allows access to the entire intranet. These tunnels require computer (infrastructure and intranet tunnels) and user (intranet tunnel) credentials. The connection security rules for DirectAccess tunnels are specified for the Private and Public firewall profiles.

When the DirectAccess client is connected to the intranet, the NRPT rules and connection

security rules must be deactivated so that the DirectAccess client uses normal DNS name

resolution methods and does not use IPsec tunnels to access intranet resources. Therefore, a

296

DirectAccess client must be able to determine when it is connected to the intranet. This is known

as network location detection.

Network location detection processThe Windows Network Location Awareness (NLA) service performs network location detection for

every network state change, such as an Internet Protocol (IP) address change, and attempts to

access a specific Secure Hypertext Transfer Protocol (HTTPS)-based uniform resource locator

(URL). You configure the network location URL through the Location page of step 3 of the

DirectAccess Setup Wizard:

If you select Network location server is run on a highly available server, the network location URL is the URL that you specify.

If you select Network location server is run on the DirectAccess server, the DirectAccess Setup Wizard determines the network location URL from the Subject field of the specified certificate.

DirectAccess clients receive the configuration of the network location URL from the DirectAccess

client Group Policy object (Computer Configuration\Policies\Administrative Templates\Network\

Network Connectivity Status Indicator\Domain Location Determination URL) and store it in the

Windows Registry at HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\

NetworkConnectivityStatusIndicator\CorporateConnectivity\DomainLocationDeterminationUrl.

When the network state changes, the NLA service adds the DirectAccess rules to the effective

NRPT. If the client can access the network location URL successfully over SSL and receive a

valid HTTP response indicating a successful connection, the NLA service removes the

DirectAccess NRPT rules. Otherwise, the rules remain in the NRPT.

The detailed process is the following:

1. Attempt to resolve the FQDN in the network location URL.

2. The FQDN matches an exemption rule in the NRPT, which is configured by default by the DirectAccess Setup Wizard. Because the FQDN matches an exemption rule, perform a normal name resolution, which includes using interface-configured DNS servers.

3. Using the IP address returned from name resolution, perform an HTTP GET of the network location URL (an HTTPS connection).

4. Establish a Transmission Control Protocol (TCP) connection with port 443 at the resolved IP address.

5. Perform Secure Sockets Layer (SSL) authentication for HTTPS and validate the SSL certificate from the network location server.

6. Perform a certificate revocation check for the SSL certificate by checking the certificate revocation list (CRL) files in the CRL Distribution Point field.

If the DirectAccess client can also locate and authenticate with a domain controller, it switches the

network to the Domain profile. Because the DirectAccess connection security rules are specified

only for the Private and Public profiles, they are deactivated.

With the combination of network location detection and computer domain logon, the DirectAccess

client configures itself for normal intranet access.

297

To demonstrate network location detection and its impact on the NRPT and connection

security rules in the DirectAccess test lab (http://go.microsoft.com/fwlink/?

Linkid=150613), do the following:

1. Connect CLIENT1 to the Internet subnet.

2. Open a Command Prompt.


Notice that the Machine Location field states Outside corporate network.


Notice that there are two active NRPT rules: A namespace rule for corp.contoso.com and an

exemption rule for nls.corp.contoso.com.

5. Open the Windows Firewall with Advanced Security snap-in (wf.msc).

6. From the console tree of the Windows Firewall with Advanced Security snap-in, open Monitoring\Connection Security Rules.

In the details pane, notice that there are three connection security rules: DirectAccess Policy-

ClientToCorp, DirectAccess Policy-ClientToDnsDc, and DirectAccess Policy-

clientToNlaExempt.

7. Disconnect CLIENT1 from the Internet subnet and connect it to the Corpnet subnet.


Notice that the Machine Location field states Inside corporate network.


Notice that there are now no active NRPT rules.

10. Refresh the details pane of the Windows Firewall with Advanced Security snap-in (Monitoring\Connection Security Rules).

Notice that there are now no connection security rules.

Network location detection failures and their consequencesThere are many reasons why the HTTP GET of the network location URL could fail, including the

following:

Network location server is offline

A link failure makes the network location server unreachable

Cannot resolve FQDN of the network location URL

Incorrect address for the FQDN of the network location URL

Cannot establish the SSL session (TCP)

Cannot validate the SSL certificate due to certificate expiration, incorrect object identifier (OID), incorrect Subject field

Cannot resolve the FQDN of the CRL distribution point

Cannot reach the CRL distribution point

Notes

298


Cannot read the CRL files

The behavior of a DirectAccess client on the intranet when it cannot perform a successful network

location detection depends on the name used by applications to access intranet resources, either

FQDN or single-label, and whether the DirectAccess client can reach the Internet interface of the


If the DirectAccess client cannot reach the Internet interface of the DirectAccess server and tries

to resolve an intranet FQDN, name resolution fails because there is no fall back behavior for

FQDNs. Therefore, the DirectAccess client cannot reach the intranet resource.

If the DirectAccess client cannot reach the Internet interface of the DirectAccess server and tries

to resolve a single-label name, fall back behavior can use LLMNR or NetBIOS methods, including

WINS. Therefore, connectivity to the intranet resource can use IPv4, rather than IPv6.

A DirectAccess client on the intranet can use Internet Protocol over Secure Hypertext Transfer

Protocol (IP-HTTPS) and an intranet proxy server to reach the Internet interface of the

DirectAccess server. In this case, all DirectAccess tunneled traffic is exchanged with the

DirectAccess server over the IP-HTTPS session out to the Internet and back to the intranet via


In this configuration, the DirectAccess client behaves in much the same way as if it were located

on the Internet. However, intranet resources that are not available over DirectAccess are still

unavailable, even though the DirectAccess client is connected to the intranet. Additionally,

intranet access can have decreased performance because the traffic is routed through the IP-

HTTPS session, out to the Internet, and back through the DirectAccess server.

Troubleshooting network location detectionTo troubleshoot problems with network location detection, see the following:



299

da design dep guide

Documents

directaccess design

directaccess servers

directaccess design

directaccess infrastructure

directaccess deployment

microsoft technet

deployment design team

common directaccess