Académique Documents
Professionnel Documents
Culture Documents
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)
Contents
DirectAccess Design Guide.......................................................................................................... 13
About this guide......................................................................................................................... 13
End-to-End Access....................................................................................................................... 36
Add Servers that are Available to DirectAccess Clients before User Logon...............................137
Configure Firewall Rules to Prevent Traffic between Proxy Servers and DirectAccess Servers. 152
Appendix D - DirectAccessConfig.xsd........................................................................................196
DirectAccess Troubleshooting Guide.......................................................................................... 211
In this guide............................................................................................................................. 211
Certificates.................................................................................................................................. 254
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
Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server over the
Internet.................................................................................................................................... 271
13
Important
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.
14
Important
Evaluate predefined DirectAccess deployment Transparent and Automatic Remote Access for
goals that are provided in this section of the DirectAccess Clients
guide and combine one or more goals to reach Ongoing Management of Remote DirectAccess
your organizational objectives. Clients
Efficient Routing of Intranet and Internet Traffic
Reduction of Remote Access-based Servers in
your Edge Network
End-to-end Traffic Protection
Multi-factor Credentials for Intranet Access
Map one goal or a combination of any of the Mapping Your Deployment Goals to a
predefined DirectAccess deployment goals to a DirectAccess Design
DirectAccess design.
Document your deployment goals and other Appendix C: Documenting Your DirectAccess
important details for your DirectAccess design. Design
15
Important Important Important
16
Important Important
17
Important Important
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.
18
Important Important
DirectAccess deployment goal DirectAccess elements or features
Transparent and automatic remote access for Functionality in the DirectAccess server and
DirectAccess clients clients
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
Multi-factor credentials for intranet access Smart card authorization on the intranet tunnel
19
Note
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).
20
Important Note
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.
21
Important Note
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).
22
Note Important
Using authentication with null encapsulation for
selected server access
Authentication with null encapsulation is a new feature of Windows Firewall with Advanced
Security for Windows 7 and Windows Server 2008 R2. Some intranets contain hardware that
cannot parse or forward IPsec-protected traffic. With authentication with null encapsulation
enabled, IPsec peers perform normal IPsec peer authentication and include IPsec data integrity
on the first packet exchanged. Subsequent packets are sent as clear text with no IPsec
protection. This feature allows you to use IPsec for peer authentication in environments that do
not support IPsec-protected traffic flows. You can enable authentication with null encapsulation
for DirectAccess when using selected server access.
Authentication with null encapsulation is not the same as using ESP-NULL for per-packet
data integrity.
23
Important
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.
24
Important
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).
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.
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.
27
For more information, see Selected Server Access Example.
28
Important Note
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.
29
Note Note Important
30
Gateway (UAG), see the Forefront UAG DirectAccess Design Guide
(http://go.microsoft.com/fwlink/?LinkId=179988).
A DirectAccess client sends only Internet Protocol version 6 (IPv6) traffic to the DirectAccess
server. When DirectAccess clients send Domain Name System (DNS) name query requests
across the infrastructure tunnel to the IPv6 address of an intranet DNS server, they request only
IPv6 records (AAAA DNS records). Internet Protocol version 4 (IPv4)-only applications on the
DirectAccess client will never send IPv4 traffic across the DirectAccess intranet tunnel. The same
DirectAccess client, when directly connected to the intranet, sends DNS name queries to intranet
DNS servers and requests all records, both IPv4 and IPv6. For an IPv4-only server application,
intranet DNS servers send back IPv4 records and the client application uses IPv4 to
communicate.
The end result is that an IPv6-capable client application on a DirectAccess client can use IPv4 to
access an IPv4-only server application while connected to the intranet, but cannot by default
reach the same server application when connected to the Internet.
The solutions for providing connectivity for IPv6-capable applications on DirectAccess clients to
IPv4-only intranet applications are the following:
Upgrade or update the IPv4-only intranet application to support IPv6. This update might
include updating the operating system of the server, updating the application running on the
server, or both. This is the recommended solution. For built-in applications and system
services on computers running Windows XP or Windows Server 2003, you must upgrade
Windows XP to Windows 7 or Windows Vista and upgrade Windows Server 2003 to Windows
Server 2008 R2 or Windows Server 2008.
Use a conventional remote access virtual private network (VPN) connection on the
DirectAccess client to reach the IPv4-only application.
Use an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway, which perform IPv6/IPv4 traffic
translation and IPv6-to-IPv4 DNS name resolution services for traffic between DirectAccess
clients and IPv4-only intranet application servers. 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
31
Important
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.
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.
32
Important Note Important
33
Note Important
The DirectAccess Setup Wizard allows you to configure one of the following for the selected
server access model:
The only servers that DirectAccess clients can communicate with are selected intranet
servers using Internet Protocol security (IPsec) peer authentication and end-to-end data
integrity.
The only servers that DirectAccess clients can communicate with are selected intranet
servers using IPsec peer authentication but no IPsec protection.
Communications between DirectAccess clients and selected intranet servers must perform
IPsec peer authentication and end-to-end data integrity. Communications with all other
intranet endpoints use clear text.
Communications between DirectAccess clients and intranet servers must perform IPsec peer
authentication but no IPsec protection. Communications with all other intranet endpoints use
clear text.
In each of these cases, the traffic sent between the DirectAccess client and the DirectAccess
server is encrypted over the Internet. See Selected Server Access Example for more information.
The following are the benefits of the selected server access model:
You can easily confine the access of DirectAccess clients to specific application servers.
Provides additional end-to-end authentication and data protection beyond that provided with
traditional virtual private network (VPN) connections.
Can be used with smart cards for an additional level of authorization.
Is fully configurable with the DirectAccess Setup Wizard.
By customizing the default Windows Firewall with Advanced Security connection security
rules created by the DirectAccess Setup Wizard, you can restrict certain users or computers
from accessing particular application servers or specify that certain client applications will not
be able to access intranet resources remotely. However, customization of connection security
rules requires knowledge of and experience with connection security rule design and
configuration.
The following are the limitations of the selected server access model:
Selected servers must run Windows Server 2008 or later. Selected servers cannot run
Windows Server 2003 or earlier.
Selected servers when using IPsec peer authentication without IPsec protection must be
running Windows Server 2008 R2 or later.
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
This topic describes design considerations for DirectAccess in Windows Server 2008 R2.
For the design considerations of DirectAccess in Microsoft Forefront Unified Access
34
Important
35
Important
The following sections describe the benefits and limitations of each of these methods.
36
Notes
37
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
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
38
Important
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.
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.
39
Important
40
Important
DirectAccess on the IPv6 Internet uses the Internet Protocol security (IPsec) Encapsulating
Security Payload (ESP) to protect the packets to and from the DirectAccess server without
the encapsulation headers required for IPv6 transition technologies. In the IPv6 header, the
Protocol field is set to 50 to indicate an ESP-protected payload.
UDP destination port 500 inbound and UDP source port 500 outbound
DirectAccess on the IPv6 Internet uses the Internet Key Exchange (IKE) and Authenticated
Internet Protocol (AuthIP) protocols to negotiate IPsec security settings. The DirectAccess
server is listening on UDP port 500 for incoming IKE and AuthIP traffic.
UDP destination port 4500 inbound and UDP source port 4500 outbound
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
41
Important
42
Important
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:
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.
43
Important
Packet filters to allow inbound ICMP Echo
Requests on all computers
DirectAccess clients that are behind NATs on the Internet attempt to use Teredo for IPv6
connectivity to the DirectAccess server. DirectAccess clients are Teredo clients to the
DirectAccess server, which is acting as a Teredo server and relay. To ensure that a destination is
reachable, Teredo clients send an Internet Control Message Protocol for IPv6 (ICMPv6) Echo
Request message and wait for an ICMPv6 Echo Reply message.
For a Teredo-based DirectAccess client to communicate with an intranet resource, that resource
must accept inbound ICMPv6 Echo Request messages. Therefore, for DirectAccess clients to
reach any location on the intranet, you must allow inbound ICMPv6 Echo Request messages on
all of your intranet hosts. 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.
44
Note
To allow management computers to initiate connections with your intranet computers, you might
already have in place a set of inbound firewall rules for management traffic on your intranet. To
allow DirectAccess clients to be managed in the same way when they are on the Internet, you
can do one of the following:
Configure your existing set of inbound firewall rules for management traffic so that they also
apply to the public and private profiles and have edge traversal enabled. Although easier to
configure, this option is not recommended because the inbound rules might allow greater
exposure what is intended for DirectAccess management functionality.
Create a duplicate set of inbound firewall rules for your management traffic in the Group
Policy object for DirectAccess clients so that they only apply to the public and private profiles,
have the appropriate source Internet Protocol version 6 (IPv6) addresses of management
computers or the IPv6 prefix of your intranet, and have edge traversal enabled. This is the
recommended option because it applies the rules only to DirectAccess clients, is scoped for
your intranet IPv6 addresses or prefix, and does not affect other domain computers on the
intranet or Internet.
For information about creating inbound rules, see Create an Inbound Program or Service Rule
(http://go.microsoft.com/fwlink/?LinkId=159864). For more information, see Configure Packet
Filters to Allow Management Traffic to DirectAccess Clients in the DirectAccess Deployment
Guide.
You can enable edge traversal for a Windows Firewall inbound rule in the following ways:
Using the Windows Firewall with Advanced Security snap-in, obtain properties of an inbound
rule. On the Advanced tab, in Edge traversal, select Allow edge traversal.
Use the edge=yes option for the netsh advfirewall firewall command when adding or
changing an inbound rule.
Here is an example of how to use a Network Shell (Netsh) command-line tool command to enable
edge traversal for the built-in Remote Desktop (TCP-In) inbound rule:
netsh advfirewall firewall set rule name=”Remote Desktop (TCP-In)” dir=in new edge=yes
To further ensure that the Remote Desktop connection is authenticated and encrypted, use the
following Netsh command:
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.
45
Important
46
Important Note
47
Note
48
Note
prompt that users can ignore without loss of connectivity. The solutions to this issue are the
following:
Move the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) routing function to a
separate server and then add packet filters to this server that block all User Datagram
Protocol (UDP) traffic for Internet Key Exchange (IKE) and AuthIP from the Internet Protocol
version 6 (IPv6) address prefix of the intranet to the IPv6 address of the DirectAccess
server’s tunnel endpoint. These filters will drop the tunnel establishment traffic sent by
DirectAccess clients while intranet detection is in progress. For an example of moving the
ISATAP routing function to another server, see Capacity Planning for DirectAccess Servers.
Add a connection security rule that sends tunnel endpoint traffic to an invalid destination while
intranet detection is occurring. For example, use the following Network Shell (netsh)
command-line tool command: netsh advfirewall consec add rule name="Corp
connectivity to prevent smart card prompt" endpoint1=IntranetIPv6Prefix
endpoint2=IntranetIPv6Prefix localtunnelendpoint=InvalidIPv6Address mode=tunnel
action=requireinrequireout auth1=computercert auth1ca="CN=NonExistentCA".
Both of these solutions prevent the tunnel negotiation with the DirectAccess server during intranet
detection when the DirectAccess client is on the intranet. By preventing tunnel negotiation, smart
card authorization will never occur and the user will not be prompted for their smart card
credentials.
49
Important
50
Important Important Note
The DirectAccess Management console sorts the public IPv4 addresses assigned to the
Internet adapter alphabetically. Therefore, the DirectAccess Management console does
not consider the following sets of addresses as consecutive: w.x.y.9 and w.x.y.10, which
is sorted as w.x.y.10, w.x.y.9; w.x.y.99 and w.x.y.100, which is sorted as w.x.y.100,
w.x.y.99; w.x.y.1, w.x.y.2, and w.x.y.10, which is sorted as w.x.y.1, w.x.y.10, w.x.y.2. Use a
different set of consecutive addresses.
For intranet interfaces on the DirectAccess server that are connected to your IPv4-based intranet,
manually configure the following:
An IPv4 intranet address with the appropriate subnet mask.
A connection-specific DNS suffix of your intranet namespace.
Do not configure a default gateway on any intranet interfaces.
To configure the DirectAccess server to reach all the locations on your intranet, do the following:
1. List the IPv4 address spaces for all the locations on your intranet.
2. Use the route add -p or netsh interface ipv4 add route commands to add the IPv4 address
spaces as static routes in the IPv4 routing table of the DirectAccess server.
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.
51
Note Important Warning
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.
52
Active Directory and the DirectAccess server
The DirectAccess server must be a domain member and cannot be a domain controller.
Additionally, an Active Directory domain controller cannot be reachable from the Internet interface
of DirectAccess server; the Internet interface cannot be 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.
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.
53
Important
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
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.
54
Gateway (UAG), see the Forefront UAG DirectAccess Design Guide
(http://go.microsoft.com/fwlink/?LinkId=179988).
The design of your Domain Name System (DNS) infrastructure can impact how you configure
DirectAccess. The biggest design aspect of your DNS infrastructure is whether you use split-brain
DNS.
Split-brain DNS
Split-brain DNS is the use of the same DNS domain for both Internet and intranet resources. For
example, the Contoso Corporation is using split brain DNS; contoso.com is the domain name for
intranet resources and Internet resources. Internet users use http://www.contoso.com to access
Contoso’s public Web site and Contoso employees on the Contoso intranet use
http://www.contoso.com to access Contoso’s intranet Web site. A Contoso employee with their
laptop that is not a DirectAccess client on the intranet that accesses http://www.contoso.com sees
the intranet Contoso Web site. When they take their laptop to the local coffee shop and access
that same URL, they will see the public Contoso Web site.
When a DirectAccess client is on the Internet, the Name Resolution Policy Table (NRPT) sends
DNS name queries for intranet resources to intranet DNS servers. A typical NRPT for
DirectAccess will have a rule for the namespace of the organization, such as contoso.com for the
Contoso Corporation, with the Internet Protocol version 6 (IPv6) addresses of intranet DNS
servers. With just this rule in the NRPT, when a user on a DirectAccess client on the Internet
attempts to access the uniform resource locator (URL) for their Web site (such as
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
55
Note
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.
56
In Step 3 of the DirectAccess Setup Wizard, you configure the local name resolution behavior
based on the types of responses received from intranet DNS servers. You have the following
options:
Use local name resolution only if the internal network DNS servers determined that the name
does not exist
This option is the most secure because the DirectAccess client will only perform local name
resolution for server names that cannot be resolved by intranet DNS servers. If the intranet
DNS servers can be reached, the names of intranet servers will be resolved. If the intranet
DNS servers cannot be reached or if there are other types of DNS errors, the intranet server
names will not be leaked to the subnet through local name resolution.
Use local name resolution if the internal network DNS servers determined that the name does
not exist or if the internal network DNS servers are not reachable and the DirectAccess client
computer is on a private network
This option is moderately secure because it allows the use of local name resolution on a
private network when the intranet DNS servers are unreachable.
Use local name resolution if there is any type of error when attempting to resolve the name
using internal network DNS servers
This is the least secure option because the names of intranet network servers can be leaked
to the local subnet through local name resolution.
Choose the option that complies with your security requirements.
NRPT rules
In step 3 of the DirectAccess Setup Wizard, you configure the rules in the NRPT, an internal table
used by the DNS Client service to determine where to send DNS name queries. The
DirectAccess Setup Wizard automatically creates two rules for DirectAccess clients:
A 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.
57
Notes
If you are redirecting traffic to an external Web site through your intranet Web proxy servers,
the external Web site is only available from the intranet, and the external Web site is using
the addresses of your Web proxy servers to permit the inbound requests, then you must add
an exemption rule for the FQDN of the external Web site and specify that the rule use your
intranet Web proxy server, rather than the IPv6 addresses of intranet DNS servers.
For example, the Contoso Corporation is testing an external Web site named
test.contoso.com. This name is not resolvable via Internet DNS servers, but Contoso’s Web
proxy server knows how to resolve the name and to direct requests for the Web site to the
external Web server. To prevent users who are not on the Contoso intranet from accessing
the site, the external Web site only allows requests from the Internet Protocol version 4 (IPv4)
Internet address of the Contoso Web proxy. Therefore, intranet users can access the Web
site because they are using the Contoso Web proxy but DirectAccess users cannot because
they are not using the Contoso Web proxy. By configuring an NRPT exemption rule for
test.contoso.com that uses the Contoso Web proxy, Web page requests for test.contoso.com
will be routed to the intranet Web proxy server over the IPv4 Internet.
You can also configure NRPT rules from Computer Configuration\Policies\Windows
Settings\Name Resolution Policy in the Group Policy object for DirectAccess clients. 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.
58
Note Note
External DNS
The DirectAccess Setup wizard configures DirectAccess clients with the IPv4 addresses of the
6to4 relay and the Teredo server with Group Policy settings in Computer
Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition
Technologies. For the URL for the Internet Protocol over Secure Hypertext Transfer Protocol (IP-
HTTPS) server (the IP-HTTPS State setting), the DirectAccess Setup Wizard configures
https://Subject:443/IPHTTPS, in which Subject is the Subject field of the HTTPS certificate that
you specify in Step 2 of the DirectAccess Setup Wizard. If the Subject field of the IP-HTTPS
certificate is an FQDN, you must ensure that the FQDN is resolvable using Internet DNS servers.
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
59
Important Note
60
Note
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.
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.
61
Note Note Note
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
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.
62
Note Note Note Important
revocation checking fails only if the validating computer confirms that the certificate has been
revoked in the CRL. Revoking computer certificates is one way of blocking DirectAccess for
specific DirectAccess clients. A simpler and preferred method is to disable the computer account
in Active Directory. This method immediately prevents DirectAccess connections, such as when a
laptop computer is lost or stolen, and does not have the delay associated with propagating CRL
updates to CRL distribution points.
For an additional level of protection, you can configure strong CRL checking, in which certificate
revocation checking fails if the validating computer confirms that the certificate has been revoked
or for any error encountered during certificate revocation checking, including the inability to
access the CRL distribution point. For more information, see Configure Strong Certificate
Revocation Checking for IPsec Authentication in the DirectAccess Deployment Guide.
If you enable strong CRL checking and the DirectAccess server cannot reach the CRL
distribution point, certificate-based IPsec authentication for all DirectAccess connections
will fail.
If you are using Network Access Protection (NAP) with DirectAccess and you enable
strong CRL checking, certificate-based IPsec authentication for all DirectAccess
connections will fail. Health certificates do not contain CRL distribution points because
their lifetime is on the order of hours, instead of years for computer certificates.
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.
64
Note Important
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.
65
Notes
66
Enable force tunneling
You 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.
67
Important
68
Requirements: Request authentication for inbound and outbound connections
Authentication Method: Computer Certificate for the first authentication
Profile: Private and Public
To configure this connection security rule using the Network Shell (Netsh) command-line tool,
you can use the following command:
netsh advfirewall consec add rule endpoint1=any endpoint2=any
action=requestinrequestout profile=public,private auth1=computercert
auth1ca=CAName
2. Create a connection security rule with the following properties:
Rule Type: Custom
Endpoints: Endpoint 1 address for your intranet IPv6 prefix, Endpoint 2 address for your
intranet IPv6 prefix
Requirements: No authentication
Protocols and Ports: Any
Profile: Domain, Private, and Public
3. Create an inbound rule for each application that needs to accept unsolicited inbound
connection requests.
For example, for Remote Desktop, the inbound rule has the following properties:
Rule Type: Port
Protocols and Ports: Transmission Control Protocol (TCP) 3389
Action: Allow the connection if it is secure, Require the connections to be encrypted
Profile: Private and Public
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.
69
Important
70
Note Note Important
1. Determine a Web site on your intranet that is not accessible from the Internet, is highly
available, and is reachable with IPv6. To ensure its ongoing reachability with IPv6, either
assign a static IPv6 address if you have a native IPv6 infrastructure or a static Internet
Protocol version 4 (IPv4) address if you are using Intra-Site Automatic Tunnel Addressing
Protocol (ISATAP). For example, the Contoso Corporation uses cweb.corp.contoso.com as its
central, highly-available intranet Web site. This Web server uses ISATAP and a static IPv4
address.
2. Enable the Computer Configuration/Policies/Administrative
Templates/Network/Network Connectivity Status Indicator/Corporate Website Probe
URL Group Policy setting in the Group Policy object for DirectAccess clients and configure it
for the highly available intranet URL. For example, enable and configure the Corporate
Website Probe URL setting with http://cweb.corp.contoso.com.
If the name of the highly-available intranet Web site changes, you will have to update the
Corporate Website Probe URL setting with the new URL.
You also need to add the IPv6 address for the infrastructure tunnel endpoint to the Computer
Configuration/Policies/Administrative Templates/Network/Network Connectivity Status
Indicator/Corporate Site Prefix List Group Policy setting in the Group Policy object (GPO) for
DirectAccess clients. The IPv6 address for the infrastructure tunnel endpoint is configured in the
Windows Firewall with Advanced Security connection security rule named DirectAccess Policy-
ClientToDnsDc in the GPO for DirectAccess clients.
For more information, see Configure Corporate Connectivity Detection Settings in the
DirectAccess Deployment Guide.
If you use the Use local name resolution if the internal network DNS servers
determined that the name does not exist or if the internal network DNS servers are
not reachable and the DirectAccess client computer is on a private network option
for local host name resolution, the Corporate Website Probe URL setting must be
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.
71
Windows Vista or Windows XP can continue to use your remote access VPN solution and
computers running Windows 7 can begin to use DirectAccess.
If a computer running Windows 7 is both a DirectAccess client and a remote access VPN client,
ensure the following:
The remote access VPN server is not blocking access to the network location server on the
intranet, even when the network access of VPN clients is restricted. When the remote access
VPN connection is active, the DirectAccess client should successfully detect that it is located
on the intranet, regardless of its VPN-based network access status (restricted or full access).
Firewall or connection security rules of the DirectAccess client should not block access to
locations needed to remediate the system health of the computer when it has its access
restricted as a remote access VPN client.
The fully qualified domain name (FQDN) of the VPN server on the Internet either does not
match the intranet namespace or there is a corresponding exemption rule for the FQDN in the
Name Resolution Policy Table (NRPT).
The same computer acting as a DirectAccess server and a remote access VPN server with
Routing and Remote Access is not a supported configuration, except when used with Microsoft
Forefront Unified Access Gateway (UAG). For more information, see Overview of Forefront UAG
(http://go.microsoft.com/fwlink/?LinkId=160322).
72
Important Important
73
Important Note
The DirectAccess server must be joined to an Active Directory domain, running Windows
Server 2008 R2, and have at least two physical network adapters installed.
The DirectAccess server must have at least two, consecutive public Internet Protocol version 4
(IPv4) addresses assigned to the interface that is connected to the perimeter network, or, in the
absence of an Internet firewall, connected directly to the Internet. Addresses in the ranges
10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are private IPv4 addresses and cannot be used.
The DirectAccess server requires two consecutive public IPv4 addresses so that it can act as a
Teredo server and Windows-based Teredo clients can use the DirectAccess server to perform
detection of the type of network address translator (NAT) that they are behind. For more
information, see Teredo Overview (http://go.microsoft.com/fwlink/?Linkid=157322).
The DirectAccess Management console sorts the public IPv4 addresses assigned to the
Internet adapter alphabetically. Therefore, the DirectAccess Management console does
not consider the following sets of addresses as consecutive: w.x.y.9 and w.x.y.10, which
is sorted as w.x.y.10, w.x.y.9; w.x.y.99 and w.x.y.100, which is sorted as w.x.y.100,
w.x.y.99; w.x.y.1, w.x.y.2, and w.x.y.10, which is sorted as w.x.y.1, w.x.y.10, w.x.y.2. Use a
different set of consecutive addresses.
74
Important
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.
75
Important Important
Oakley\NLBSFlags registry value to 1 on the DirectAccess virtual machine for faster idle
timeout of IPsec security associations (SAs). With the NLBSFlags registry value set to 1, the
total time it takes for IPsec to fail over is two minutes; one minute for the idle time to expire
plus one minute for IKE to renegotiate SAs. The Hyper-V nodes do not need this
configuration change.
With Hyper-V and Failover Clustering the primary failover mechanisms are the following:
Live migration
There should be no discernable client connectivity outage when the clustered DA server is
live migrated.
Quick migration
With the NLBSFlags registry value set to 1, the maximum client connectivity outage on a
quick migration should be less than two minutes.
Resource move
With the NLBSFlags registry value set to 1, the maximum client connectivity outage on a
manual resource move should be less than two minutes.
Hyper-V and Failover Clustering also support automatic recovery from a single node failure.
When failover occurs a client should be reconnected within two minutes; there is no action
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.
76
Note Note
The network location server is a critical part of a DirectAccess deployment. If DirectAccess client
computers on the intranet cannot successfully locate and access the secure Web page on the
network location server, they might not be able to access intranet resources.
When DirectAccess clients obtain a physical connection to the intranet or experience a network
status change on the intranet (such as an address change when roaming between subnets), they
attempt a Secure Hypertext Transfer Protocol (HTTPS) connection to a configured uniform
resource locator (URL). If the DirectAccess client can successfully obtain an HTTPS connection
to the configured URL, including a revocation check of the Web server’s certificate, they
determine that they are on the intranet.
To ensure that the FQDN of the network location server is reachable for a DirectAccess client with
DirectAccess-based rules in the NRPT, the DirectAccess Setup Wizard by default adds the FQDN
of the network location server as an exemption rule to the NRPT. When the DirectAccess client
attempts to resolve the FQDN of the network location server, the FQDN matches the exemption
rule in the NRPT and the DirectAccess client uses interface-configured DNS servers, which are
reachable to resolve the name and connect to the network location server.
Because the FQDN of network location URL is added as an exemption rule to the NRPT,
the intranet Web server at that FQDN will not be accessible to DirectAccess clients on the
Internet.
To ensure that DirectAccess clients can correctly detect when they are on the Internet,
DirectAccess clients on the Internet must not be able to successfully access the network location
URL. You can accomplish this by ensuring that the FQDN cannot be resolved using Internet DNS
servers, configuring the Web server to deny connections from Internet-based clients, or by
ensuring that the certificate validation process fails when DirectAccess clients are on the Internet.
In the DirectAccess Setup Wizard, you can specify that the DirectAccess server act as the
network location server or you can type the HTTPS-based URL for network location, specifying a
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.
78
Important Important
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.
79
Important Note
80
Important Important
81
Note Note
82
Notes Important
In reporting mode, DirectAccess clients will be able to perform peer authentication for the
intranet tunnel on the DirectAccess server even when they are not compliant with system
health requirements. Users on noncompliant DirectAccess clients receive no notification that
they are not compliant.
In deferred enforcement mode, DirectAccess clients will be able to perform peer
authentication for the intranet tunnel on the DirectAccess server even when they are not
compliant with system health requirements. However, users on noncompliant DirectAccess
clients receive a notification that they are not compliant and a date by which they will no
longer be able to connect if they are still noncompliant.
In full enforcement mode, DirectAccess clients will not be able to perform peer authentication
for the intranet tunnel when they are not compliant with system health requirements. Users on
noncompliant DirectAccess clients will receive a notification that they are not compliant.
For reporting mode and deferred enforcement mode, there are no changes that need to be made
to the settings of the 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.
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.
You can demonstrate NAP functionality for DirectAccess with the DirectAccess with NAP
test lab (http://go.microsoft.com/fwlink/?LinkId=186697).
83
Important
and helps prevent unauthorized access to trusted networked resources, achieve regulatory
compliance, and reduce operational costs. For more information, see Server and Domain
Isolation (http://go.microsoft.com/fwlink/?Linkid=95395).
Both DirectAccess and SDI use a set of Windows Firewall with Advanced Security connection
security rules in Group Policy objects (GPOs) to determine when and how to protect intranet
traffic. You should perform a careful analysis of your existing SDI global IPsec settings and
connection security rules and the global IPsec settings and rules created by the DirectAccess
Setup Wizard to determine whether they are compatible. A mismatch in global IPsec or
connection security rule settings between DirectAccess and SDI can cause an IPsec negotiation
failure and a lack of connectivity when a DirectAccess client attempts to access an intranet
resource protected with SDI.
For example, you need to ensure that the global main mode IPsec settings of your DirectAccess
clients match the global main mode IPsec settings of your SDI deployment. The DirectAccess
Setup Wizard will configure default global main mode IPsec settings for DirectAccess clients to
match those of the default global main mode IPsec settings for Windows Vista and Windows
Server 2008. If you have changed the global main mode IPsec settings for your SDI deployment
from their default values, you need to configure the global main mode IPsec settings of the Group
Policy object for DirectAccess clients created by the DirectAccess Setup Wizard to match them.
Additional design considerations for deploying DirectAccess in an existing SDI environment are
the following:
To allow for Teredo client discovery, you should exempt Internet Control Message Protocol
(ICMP) from IPsec protection in your SDI deployment.
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.
Forefront TMG also allows Internet Control Message Protocol (ICMP) traffic through by default,
which is required to support Teredo-based DirectAccess clients.
For more information, see Forefront Threat Management Gateway and DirectAccess
(http://go.microsoft.com/fwlink/?LinkId=169278).
85
Increasing the number of concurrent Teredo
clients
By 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.
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:
86
Both Server 1 and Server 2 must have two physical interfaces, one classified as a public
interface and one classified as a domain interface. Server 1 has its public interface on the
Internet.
The subnet for the link between the Server 1 and Server 2, the intra-server subnet, must use
native IPv6 addressing. You cannot use 6to4 or ISATAP tunneling on this link. You must pick
a unique 64-bit prefix for your intranet and configure static IPv6 addresses for each interface
on this subnet.
You must configure a default IPv6 route (::/0) on Server 2 that points to Server 1’s interface
on the intra-server subnet.
Because Server 2 computer is a native IPv6 router, you must configure outbound firewall
rules on the interface on the intra-server subnet to prevent reachability to intranet domain
controllers.
The tunnel endpoints in the Group Policy objects for the DirectAccess clients and server must
specify the native IPv6 address of Server 2’s interface on the intra-server subnet.
With this configuration, Server 2 acts as the IPsec intranet and infrastructure tunnel endpoint,
providing decryption services for packets from DirectAccess clients and encryption services for
packets to DirectAccess clients.
The following figure shows an example of the traffic between DirectAccess clients and intranet
servers for the full intranet access model.
The traffic over the Internet between the DirectAccess client and Server 2 is encrypted through
the intranet tunnel. The traffic over the intranet between Server 2 and intranet servers is clear
text.
The recommended method to deploy this configuration is the following:
1. While configured with two consecutive public IPv4 addresses, complete the DirectAccess
Setup Wizard on Server 2.
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.
87
Important Important
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.
88
Note
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.
89
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.
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.
90
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.
91
Native IPv6 connectivity
For 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 connectivity
Because 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
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
92
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.
93
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.
94
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.
95
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.
NRPT
In 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.
96
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.
In Site 2, a DNS record resolves crl_site2.corp.contoso.com to the IP addresses of the Web
servers in Site 2.
97
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.
98
Note
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.
99
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
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
For each site, you must create rules with different names that have the settings of the
DirectAccess Policy-ClientToCorp connection security rules of the other sites.
For our example, you create a connection security rule named DirectAccess Policy-
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-
100
Important
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
For each site, you must create rules with different names that have the settings of the
DirectAccess Policy-clientToNlaExempt connection security rules of the other sites.
For our example, you create a connection security rule named DirectAccess Policy-
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
For each site, you must create rules with different names that have the settings of the
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
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
For each site, you must create rules with different names that have the settings of the
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.
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).
Element Requirements
102
Element Requirements
Note
There are no built-in limitations on the
number of simultaneous DirectAccess
connections that a DirectAccess server
can support.
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),
103
Important
Element Requirements
IPv6
IPv6 is the new version of the Network layer of the TCP/IP protocol stack that is designed to
replace Internet Protocol version 4 (IPv4), which is in wide use today on intranets and the
Internet. IPv6 provides an address space large enough to accommodate end-to-end addressing
of nodes on the IPv6 Internet, and with IPv6 transition technologies, of nodes on the IPv4
Internet. DirectAccess uses this capability to provide end-to-end addressing from DirectAccess
clients on the IPv4 or IPv6 Internet to computers on an intranet.
Because most of the current Internet is IPv4-based and many organizations have not deployed
native IPv6 addressing and routing on their intranets, DirectAccess uses IPv6 transition
technologies to provide IPv6 connectivity over these IPv4-only networks. Teredo, 6to4, Internet
Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS), and the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) are examples of IPv6 transition technologies. These
technologies allow you to use IPv6 on the IPv4 Internet and your IPv4-only intranet. IPv6
transition technologies can simplify and reduce the costs of an IPv6 deployment.
104
Note Notes
assigned a private IPv4 address, it will use Teredo. If the DirectAccess client cannot connect to
the DirectAccess server with either 6to4 or Teredo, it will use IP-HTTPS.
6to4
6to4, defined in RFC 3056, is an IPv6 transition technology that provides IPv6 connectivity across
the IPv4 Internet for hosts or sites that have a public IPv4 address. For more information, see
IPv6 Transition Technologies (http://go.microsoft.com/fwlink/?Linkid=117205).
Teredo
Teredo, defined in RFC 4380, is an IPv6 transition technology that provides IPv6 connectivity
across the IPv4 Internet for hosts that are located behind an IPv4 network address translation
(NAT) device and are assigned a private IPv4 address. For more information, see Teredo
Overview (http://go.microsoft.com/fwlink/?Linkid=157322).
IP-HTTPS
IP-HTTPS is a new protocol for Windows 7 and Windows Server 2008 R2 that allows hosts
behind a Web proxy server or firewall to establish connectivity by tunneling IPv6 packets inside
an IPv4-based HTTPS session. HTTPS is used instead of HTTP so that Web proxy servers will
not attempt to examine the data stream and terminate the connection. IP-HTTPS is typically used
only if the client is unable to connect to the DirectAccess server using the other IPv6 connectivity
methods or if force tunneling has been configured.
For the details of IP-HTTPS, see the IP over HTTPS (IP-HTTPS) Tunneling Protocol Specification
(http://go.microsoft.com/fwlink/?Linkid=157309).
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.
105
Note
IPsec
IPsec is a framework of open standards for ensuring private, secure communications over
Internet Protocol (IP) networks through the use of cryptographic security services. IPsec provides
aggressive protection against attacks through end-to-end security. The only computers that must
know about IPsec protection are the sender and receiver in the communication. IPsec provides
the ability to protect communication between workgroups, local area network computers, domain
clients and servers, branch offices (which might be physically remote), extranets, and roaming
clients.
IPsec protection can be used in two different modes: transport mode and tunnel mode. Transport
mode is designed to protect an Internet Protocol (IP) packet payload. Tunnel mode is designed to
protect an entire IP packet. For more information, see IPsec Protocol Types
(http://go.microsoft.com/fwlink/?Linkid=157319).
DirectAccess uses IPsec settings in the form of connection security rules in the Windows Firewall
with Advanced Security snap-in and the Network Shell (Netsh) command-line tool advfirewall
context for peer authentication, data integrity, and data confidentiality (encryption) of
DirectAccess connections. Multiple rules can be applied to a computer simultaneously, each
providing a different function. The result of all of these rules working together is a DirectAccess
client that can have protected communications with the DirectAccess server and intranet servers,
encrypting traffic sent over the Internet and optionally protecting traffic from end-to-end.
Windows Server 2003 and earlier versions of Windows Server do not fully support the
use of IPsec with IPv6. IPv6-capable resources on servers running Windows Server 2003
will only be available to DirectAccess clients if you use the full intranet access model.
IPv4-only resources on servers running Windows Server 2003, including most built-in
applications and system services, require an IPv6/IPv4 translator and IPv6/IPv4 DNS
gateway to be available to DirectAccess clients.
Encryption
When a DirectAccess client sends data to the intranet, the traffic is encrypted over the Internet.
For the full intranet and selected server access models, multiple connection security rules
configured on the DirectAccess client defines tunnel mode IPsec settings for communication
between the DirectAccess client and the intranet:
The first rule for the infrastructure tunnel requires authentication with a computer certificate
and encrypts traffic with IPsec and the Encapsulating Security Payload (ESP). This rule
provides protected communication with Active Directory domain controllers, DNS servers, and
other intranet resources before the user has logged on.
The second rule for the intranet tunnel requires authentication with a computer certificate and
user-based Kerberos credentials. This rule provides protected communication to intranet
resources after the user has logged on.
For the 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
106
Note
DirectAccess server. This component can be located on a separate server with an IPsec offload
network adapter to increase performance.
Data integrity
Data integrity allows the receiving IPsec peer to cryptographically verify that the packet was not
changed in transit. When encrypting data with IPsec, data integrity is also provided. It is possible
to specify data integrity without encryption. This might be helpful in order to mitigate the threat of
spoofing or man-in-the-middle attacks and allow you to ensure that DirectAccess clients are
connecting to their intended servers.
When sensitive data is being transmitted, IPsec with only data integrity should only be
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.
107
Note
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 exemptions
There are some names that need to be treated differently from all others with regards to name
resolution; these names must not be resolved using intranet DNS servers. To ensure that these
names are resolved with interface-configured DNS servers, you must add them as NRPT
exemptions.
If no DNS server addresses are specified in the NRPT rule, the rule is an exemption. If a DNS
name matches a rule in the NRPT that does not contain addresses of DNS servers or does not
match a rule in the NRPT, the DirectAccess client sends the name query to interface-configured
DNS servers.
If any of the following servers have a name suffix that matches an NRPT rule for the intranet
namespace, that server name must be an NRPT exemption:
Network location servers
Intranet certificate revocation list (CRL) distribution points
System health remediation servers
These servers must always be resolved with interface-configured DNS servers.
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.
108
Notes
Network location detection
DirectAccess 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.
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.
6. From the Command Prompt window, run the netsh dnsclient show state command.
Notice that the Machine Location field states Inside corporate network.
7. Run the netsh namespace show effectivepolicy command.
Notice that there are now no active NRPT rules.
Concepts
Provide a brief description of how DirectAccess works or use the following description:
110
DirectAccess gives users the experience of being seamlessly connected to their corporate
network (intranet) any time they have Internet access. With DirectAccess, users are able to
access intranet resources (such as e-mail servers, shared folders, or intranet Web sites)
securely without connecting to a virtual private network (VPN). DirectAccess provides
increased productivity for mobile workforce by offering the same connectivity experience both
in and outside of the office. DirectAccess is on whenever the user has an Internet connection,
giving users access to intranet resources whether they are traveling, at the local coffee shop,
or at home. DirectAccess is supported by Windows 7 Ultimate or later, Windows 7 Enterprise
or later, and Windows Server 2008 R2 or later.
Goals
List your reasons for deploying DirectAccess and state how your design plan will achieve these
goals. Also provide the following:
Benefits. Describe the pre-deployment state of the network and the benefits you expect to
see as a result of the DirectAccess deployment.
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.
111
Important
Baseline configuration. List the steps in the DirectAccess Setup Wizard and the options
chosen for your initial configuration.
NRPT rules. List any additional Name Resolution Policy Table (NRPT) rules for intranet
namespaces or exemptions that you needed for your deployment.
Connection security rules. List any changes made to the default connection security rules
in the form of Network Shell (Netsh) commands, including the Group Policy object, the rule
name, and the changes made.
Integration strategy
Describe your design for integrating DirectAccess with the following technologies and solutions:
VPN. Describe the changes made to your VPN configuration to accommodate DirectAccess
detection of the intranet when connected and for third-party VPN clients.
NAP. Describe the changes to DirectAccess settings and connection security rules for
Network Access Protection (NAP) health evaluation and enforcement of DirectAccess
connections.
Server and domain isolation. Describe changes made to your existing server and domain
isolation deployment to accommodate DirectAccess client connectivity to intranet resources.
Staging strategy
Describe how you staged the deployment of DirectAccess in your organization. Include the
following information:
Staging milestones. List the set of infrastructure and deployment milestones and their
requirements.
Timeline. Provide details of your proposed timeline to deploy DirectAccess on your intranet.
Include your initial timeline and any deviation from that timeline.
Staging results. Provide the results for each stage of your DirectAccess deployment.
Trends. Describe any trends in connectivity issues encountered.
Lessons learned
Use this section to describe problems that were encountered and solutions that were
implemented during your DirectAccess deployment.
112
Important
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.
113
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.
114
Important
115
Use the following checklist to become familiar with the options for staging a DirectAccess
deployment in your organization:
Checklist: Staging a DirectAccess Deployment
Use the following checklist to become familiar with the deployment tasks to prepare your
infrastructure for DirectAccess:
Checklist: Preparing Your Infrastructure for DirectAccess
Use the following checklist to become familiar with preparing your DirectAccess server prior to
configuring the DirectAccess feature for your organization's DirectAccess access model:
Checklist: Preparing Your DirectAccess Server
Use the following checklists to become familiar with the deployment tasks when implementing
your organization's access model:
Checklist: Implementing a DirectAccess Design for Full Intranet Access
Checklist: Implementing a DirectAccess Design for Selected Server Access
Checklist: Implementing a DirectAccess Design for End-to-End Access
Use the following checklists to become familiar with the deployment tasks for implementing
optional DirectAccess configuration options:
Checklist: Implementing a Redundant DirectAccess Design
116
Important Note
Task Reference
117
Important Note
Task Reference
118
Task Reference
119
iImportant Note
Task Reference
Task Reference
120
Task Reference
Configure static routes for Design Addressing and Routing for the
your intranet on the DirectAccess Server
DirectAccess server.
121
Important Note
Task Reference
122
Task Reference
123
Important Note
Task Reference
Task Reference
124
Task Reference
125
Important Note
Task Reference
Task Reference
126
Task Reference
127
Important Note
Task Reference
Task Reference
128
Important Note
Task Reference
129
Note
Task Reference
Task Reference
130
Important
Task Reference
131
Important
To make intranet servers available to DirectAccess clients before user logon using the
DirectAccess Setup Wizard
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.
132
To make intranet servers available to DirectAccess clients before user logon using the
Netsh.exe tool and the infrastructure
management tunnel
tunnel
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.
133
Important
To create a Web-based CRL distribution point
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.
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-
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.
1. On the IIS server, click Start, point to Administrative Tools, and then click Internet
Information Services (IIS) Manager.
134
To
2.configure permissions
In the console onthe
tree, open theserver
CRL distribution file shared
name, and then Sites. folder
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.
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.
135
Important Note
To publish the CRL
1. On the computer running AD CS, click Start, point to Administrative Tools, and then
click Certification Authority.
2. In the console tree, double-click the CA name, right-click Revoked Certificates, point to
All Tasks, and then click Publish.
3. If prompted, click New CRL, and then click OK.
4. Click Start, type \\IisServer\SharedFolder$, and then press ENTER.
5. In the SharedFolder$ window, you should see two CRL files named CAName and
CAName+.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
136
To configure CRL distribution settings
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.
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.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
137
Important Note
To configure client authentication and certificate mapping for the IP-HTTPS certificate
138
Important Important
To configure computer certificate auto-enrollment
1. On a domain controller, click Start, type gpmc.msc, and then press ENTER.
2. In the console tree of the Group Policy Management console, open the domain that
contains DirectAccess client and server computer accounts.
3. In the console tree, right-click the Group Policy object that applies to all of your domain
accounts, and then click Edit.
4. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Windows Settings\Security Settings\Public Key Policies.
5. In the details pane, right-click Automatic Certificate Request Settings, point to New,
and then click Automatic Certificate Request.
6. In the Automatic Certificate Request Wizard, click Next.
7. On the Certificate Template page, click Computer, click Next, and then click Finish.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
139
To configure end-to-end access connection security rules to require encryption only
when DirectAccess clients are on the Internet
140
To configure end-to-end access connection security rules to always require encryption
exemptipsecprotectedconnections=yes
consec set rule name=”DirectAccess Policy-DaServerToCorp” new
exemptipsecprotectedconnections=yes
consec set rule name=”DirectAccess Policy-DaServerToDnsDc” new
exemptipsecprotectedconnections=yes
set store gpo=”DomainName\DirectAccess Policy-{f7b77f47-7c33-4d8c-bb9a-
a913c5675d8d}”
consec set rule name=”DirectAccess Policy-appServerToIpHttpsClientPolicy” new
qmsecmethods=”ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-
AES128+60min+100000kb”
consec set rule name=”DirectAccess Policy-appServerToClient” new
qmsecmethods=”ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-
AES128+60min+100000kb”
In this procedure, you configure end-to-end access connection security rules to always require
encryption.
141
Important
To configure connection security rules for traffic between DirectAccess clients
a913c5675d8d}”
consec set rule name=”DirectAccess Policy-appServerToIpHttpsClientPolicy” new
endpoint2=any qmsecmethods=”ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-
AES128+60min+100000kb”
consec set rule name=”DirectAccess Policy-appServerToClient” new
endpoint2=any qmsecmethods=”ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-
AES128+60min+100000kb”
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
1. On a domain controller, click Start, click Run, type gpmc.msc, and then press ENTER.
2. In the console tree, open the domain.
3. In the console tree, right-click the DirectAccess Policy-{3491980e-ef3c-4ed3-b176-
a4420a810f12} Group Policy object, and then click Edit.
4. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Administrative Templates\Network\Network Connectivity
Status Indicator, and then double-click Corporate Website Probe URL in the details
pane.
5. Click Enabled.
6. In Corporate Website Probe URL, type the uniform resource locator (URL) of a highly
available intranet Web server that is available to any computer connected to the intranet,
either through a local area network (LAN) connection (such as wired or wireless) or
DirectAccess.
143
Important
Note
This URL is different that the network location server URL, which is designed to
be accessible only from a computer connected to the intranet through a LAN
connection.
7. Click Apply, and then click OK.
8. Start a command prompt as an administrator.
9. From the Command Prompt window, run the netsh –c advfirewall command.
10. From the netsh advfirewall prompt, run the set store
gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}”
command.
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.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
144
Note
To add HRAs and remediation servers as management servers using the Netsh.exe
DirectAccess
tool
Setup Wizard
The following procedure uses the DirectAccess Setup Wizard to add your HRAs and remediation
servers to the list of management servers.
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 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.
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.
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.
146
Important
To create an outbound
inbound rule
ruleon
ona aDirectAccess
proxy serverserver
to droptotraffic
drop traffic
to yourfrom
DirectAccess
your proxy
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.
3. On the Rule Type page, click Custom, and then click Next.
4. On the Programs page, click Next.
147
Important
To configure force tunneling
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,
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.
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.
148
Important
5. In the Route all traffic through the internal network dialog box, click Enabled, and
then click OK.
6. In the console tree of the Group Policy Management Editor snap-in, open Computer
Configuration\Policies\Windows Settings\Name Resolution Policy.
7. In the details pane, in To which part of the namespace does this rule apply?, click
Any.
8. Click the DNS Settings for Direct Access tab, and then click Enable DNS settings for
Direct Access in this rule.
9. In DNS servers (optional), click Add. In DNS server, type the IPv6 address of your dual
protocol (IPv4 and IPv6) proxy server or your 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.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
149
Note Note
To install the IP and Domain Restrictions role service To configure the HTTPS security binding
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.
Once you have determined the FQDN of the network location server, construct the URL
https://FQDN (without the trailing “/”). This is the network location URL that you configure in Step
3 of the DirectAccess Setup Wizard.
If you are not using an alias name, you cannot connect to the IIS server that is acting as
a network location server from a DirectAccess client that is on the Internet.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to configure IIS global settings. Review details about using
the appropriate accounts and group memberships at Local and Domain Default Groups
(http://go.microsoft.com/fwlink/?LinkId=83477).
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
150
Important
To create and enable firewall rules for ICMPv6 traffic
configured for HTTPS bindings is for the alias name and HTTPS connections using other
FQDNs will not validate.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
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
151
Important
To create and enable firewall rules for ICMPv4 traffic
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.
1. Click Start, click Run, type gpmc.msc, and then press ENTER.
2. In the console tree, open Forest/Domains/YourDomain, right-click the Group Policy
object (GPO) that applies to all of your intranet domain members, and then click Edit.
3. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security.
4. In the console tree, right-click Inbound Rules, and then click New Rule.
5. On the Rule Type page, click Custom, and then click Next. On the Program page, click
Next. On the Protocols and Ports page, for Protocol type, click ICMPv4, and then click
Customize. In the Customize ICMP Settings dialog box, click Specific ICMP types,
select Echo Request, and then click OK. Click Next. On the Scope page, click Next. On
the Action page, click Next. On the Profile page, click Next. On the Name page, for
Name, type Inbound ICMPv4 Echo Requests, and then click Finish.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
152
To enable edge traversal for an inbound rule with the Netsh.exe
Windows Firewall
command-line
with Advanced
tool
Security snap-in
1. Click Start, click Run, type gpmc.msc, and then press ENTER.
2. In the console tree, open Forest\Domains\YourDomain, right-click the appropriate Group
Policy object (GPO), and then click Edit.
For example, your inbound rules for management traffic that are specific to DirectAccess
clients would reside in the DirectAccess client GPO named DirectAccess Policy-
{3491980e-ef3c-4ed3-b176-a4420a810f12}.
3. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Inbound Rules.
4. In the contents pane, right-click a rule for management traffic, and then click Properties.
5. Click the Advanced tab, in Edge traversal, select Allow edge traversal, and then click
OK.
6. Repeat steps 4 and 5 for the additional rules for management traffic.
153
Important
To add packet filters to prevent access to domain controllers from the Internet interface
1. On the DirectAccess server, click Start, click Run, type wf.msc, and then press ENTER.
2. In the console tree, right-click Outbound Rules, and then click New Rule.
3. On the Rule Type page, click Custom, and then click Next.
4. On the Program page, click Next.
5. On the Protocol and Ports page, click Next.
6. On the Scope page, in Which local IP addresses does this rule apply to?, click These
IP addresses, and then click Add. In IP Address, specify the Internet Protocol version 4
(IPv4) and Internet Protocol version 6 (IPv6) addresses of the Internet interface of the
DirectAccess server, and then click OK.
7. In Which remote IP addresses does this rule apply to?, click These IP addresses,
and then click Add. In IP Address, specify the IPv4 or IPv6 addresses of the domain
controllers that are reachable from the Internet interface of the DirectAccess server, and
then click OK.
8. Click Next.
9. On the Action page, click Next.
10. On the Profile page, clear Domain, and then click Next.
11. On the Name page, specify a name for the rule, and then click Finish.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
154
Important Important
To configure permissions for the Web Server certificate template
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.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
155
To confine ICMPv6 traffic to the intranet
Any computer with a Teredo or 6to4 client can send Internet Control Message Protocol for
IPv6 (ICMPv6) traffic to intranet locations through the DirectAccess server to probe for valid
intranet destination IPv6 addresses. The amount of this traffic is limited by the Denial of
Service Protection (DoSP) feature of the DirectAccess server.
A malicious user on the same subnet as a Teredo-based DirectAccess client can determine
the IPv6 addresses of intranet servers by capturing ICMPv6 Echo Request and Echo Reply
message exchanges.
This procedure allows you to prevent these possible security issues.
To complete these procedures, you must be a member of the Domain Administrators group, or
otherwise be delegated permissions to modify Group Policy settings. Review details about using
the appropriate accounts and group memberships at Local and Domain Default Groups
(http://go.microsoft.com/fwlink/?LinkId=83477).
156
Important
To configure strong certificate revocation checking for IPsec authentication
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.
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.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
157
Notes
3. From the netsh advfirewall prompt, run the following commands:
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.
If you are using Network Access Protection (NAP) with DirectAccess and you enable
strong CRL checking, certificate-based IPsec authentication for all DirectAccess
connections will fail. Health certificates do not contain CRL distribution points because
their lifetime is on the order of hours, instead of years for computer certificates.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
158
To configure the intra-server subnet
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.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to modify IPv6 interface 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, remove the two consecutive public IPv4 addresses
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.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
159
To configure the IPv6 connectivity server
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.
To complete these procedures, you must be a member of the local Administrators group, or
otherwise be delegated permissions to modify IPv6 settings. Review details about using the
appropriate accounts and group memberships at Local and Domain Default Groups
(http://go.microsoft.com/fwlink/?LinkId=83477).
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
160
To configure the IPsec gateway server
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
1. On the DirectAccess server, click Start, click Run, type servermanager.msc, and then
press ENTER.
2. In the console tree, click Roles. In the details pane, click Add Roles, and then click Next.
3. On the Select Server Roles page, click Web Server (IIS), and then click Next twice.
4. On the Select Role Services page, in Role services, under Security, click IP and
Domain Restrictions, and then click Next.
5. Click Install.
6. Verify that all installations were successful, and then click Close.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
162
Important
Prior to running the DirectAccess Setup Wizard for end-to-end access, you should have
completed the following:
163
To run the DirectAccess Setup wizard for end-to-end access
Created at least one Active Directory security
group for DirectAccess client computers. For
more information, see Create DirectAccess
Groups in Active Directory.
To complete this procedure, you must be a member of the local Administrators group, or
otherwise be delegated permissions to create and apply the configuration of the DirectAccess
Setup Wizard. Review details about using the appropriate accounts and group memberships at
Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
1. Click Start, click Run, type damgmt.msc, and then press ENTER.
2. In the console tree, click Setup.
3. In the details pane, click Configure for step 1.
4. On the DirectAccess Client Setup page, click Add.
5. In the Select Group dialog box, specify the names of 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
164
client certificates must chain, click Browse. In the list of certificates, click the root
certificate for your public key infrastructure (PKI) that issues computer certificates to your
DirectAccess clients and servers, and then click OK.
10. For Select the certificate that will be used to secure remote client connectivity over
HTTPS, click Browse. In the list of certificates, click the certificate installed on the
DirectAccess server computer for IP-HTTPS connections, and then click OK. Click
Finish.
11. Click Configure for step 3.
12. On the Location page:
If you are using a separate network location server, click Network Location server
is run on a highly available server, type the Secure Hypertext Transfer Protocol
(HTTPS)-based uniform resource locator (URL) for network location without a trailing
/ (such as https://nls.corp.contoso.com), click Validate, and then click Next.
If you are using the DirectAccess server as the network location server, click
Network Location server is run on the DirectAccess server, click Browse, click
the certificate for network location, click OK, and then click Next.
13. On the DNS and Domain Controller page, add the appropriate rules for the Name
Resolution Policy Table (NRPT) as needed by your design. To add an NRPT rule, right-
click the empty row, and then click New. Select the appropriate local name resolution
option, and then click Next.
14. On the Management page, add the Internet Protocol (IP) addresses of computers that
will be initiating connections to DirectAccess clients as needed by your design. To add a
management computer, right-click the empty row, and then click New. Click Finish.
15. Click Configure for step 4.
16. On the DirectAccess Application Server Setup page:
a. Click Require end-to-end authentication and traffic protection for the specified
servers.
b. Click Add. In the Select Group dialog box, specify the Domain Computers group for
each of the domains of your organization.
c. Select Allow access to only those servers in the selected security groups.
17. Click Finish.
18. Click Save, and then click Finish.
19. In the DirectAccess Review dialog box, click Apply. In the DirectAccess Policy
Configuration message box, click OK.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
165
Important
166
To run the DirectAccess Setup wizard for full intranet access
Prior to running the DirectAccess Setup Wizard for full intranet access, you should have
completed the following:
To complete this procedure, you must be a member of the local Administrators group, or
otherwise be delegated permissions to create and apply the configuration of the DirectAccess
Setup Wizard. Review details about using the appropriate accounts and group memberships at
Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
1. Click Start, click Run, type damgmt.msc, and then press ENTER.
2. In the console tree, click Setup.
3. In the details pane, click Configure for step 1.
4. On the DirectAccess Client Setup page, click Add.
5. In the Select Group dialog box, specify the names of 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. If you are using
smart card authorization, select Require smart card login for remote users, and
enforce this policy on the DirectAccess server. Click Next.
8. If you have an existing Internet Protocol version 6 (IPv6) infrastructure, a Prefix
167
Configuration page displays. In The IPv6 prefix that is used in your internal network,
type the 48-bit address prefix used by your organization. In The IPv6 prefix that is used
to assign IPv6 addresses to remote client computers, type the 64-bit address prefix
that you have designated for Internet Protocol over Secure Hypertext Transfer Protocol
(IP-HTTPS)-based IPv6 DirectAccess clients.
9. On the Certificate Components page, for Select the root certificate to which remote
client certificates must chain, click Browse. In the list of certificates, click the root
certificate for your public key infrastructure (PKI) that issues computer certificates to your
DirectAccess clients and servers, and then click OK.
10. For Select the certificate that will be used to secure remote client connectivity over
HTTPS, click Browse. In the list of certificates, click the certificate installed on the
DirectAccess server computer for IP-HTTPS connections, and then click OK. Click
Finish.
11. Click Configure for step 3.
12. On the Location page:
If you are using a separate network location server, click Network Location server
is run on a highly available server, type the Secure Hypertext Transfer Protocol
(HTTPS)-based uniform resource locator (URL) for network location without a trailing
/ (such as https://nls.corp.contoso.com), click Validate, and then click Next.
If you are using the DirectAccess server as the network location server, click
Network Location server is run on the DirectAccess server, click Browse, click
the certificate for network location, click OK, and then click Next.
13. On the DNS and Domain Controller page, add the appropriate rules for the Name
Resolution Policy Table (NRPT) as needed by your design. To add an NRPT rule, right-
click the empty row, and then click New. Select the appropriate local name resolution
option, and then click Next.
14. On the Management page, add the Internet Protocol (IP) addresses of computers that
will be initiating connections to DirectAccess clients as needed by your design. To add a
management computer, right-click the empty row, and then click New. Click Finish.
15. Click Configure for step 4.
16. On the DirectAccess Application Server Setup page, click Finish.
17. Click Save, and then click Finish.
18. In the DirectAccess Review dialog box, click Apply. In the DirectAccess Policy
Configuration message box, click OK.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
168
Important
169
To run the DirectAccess Setup wizard for selected serverFor
organization. access
more information, see
Selected Server Access.
Prior to running the DirectAccess Setup Wizard for selected server access, you should have
completed the following:
To complete this procedure, you must be a member of the local Administrators group, or
otherwise be delegated permissions to create and apply the configuration of the DirectAccess
Setup Wizard. Review details about using the appropriate accounts and group memberships at
Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
1. Click Start, click Run, type damgmt.msc, and then press ENTER.
2. In the console tree, click Setup.
3. In the details pane, click Configure for step 1.
4. On the DirectAccess Client Setup page, click Add.
5. In the Select Group dialog box, specify the names of 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. If you are using
170
smart card authorization, select Require smart card login for remote users, and
enforce this policy on the DirectAccess server. Click Next.
8. If you have an existing Internet Protocol version 6 (IPv6) infrastructure, a Prefix
Configuration page displays. In The IPv6 prefix that is used in your internal network,
type the 48-bit address prefix used by your organization. In The IPv6 prefix that is used
to assign IPv6 addresses to remote client computers, type the 64-bit address prefix
that you have designated for Internet Protocol over Secure Hypertext Transfer Protocol
(IP-HTTPS)-based IPv6 DirectAccess clients.
9. On the Certificate Components page, for Select the root certificate to which remote
client certificates must chain, click Browse. In the list of certificates, click the root
certificate for your public key infrastructure (PKI) that issues computer certificates to your
DirectAccess clients and servers, and then click OK.
10. For Select the certificate that will be used to secure remote client connectivity over
HTTPS, click Browse. In the list of certificates, click the certificate installed on the
DirectAccess server computer for IP-HTTPS connections, and then click OK. Click
Finish.
11. Click Configure for step 3.
12. On the Location page:
If you are using a separate network location server, click Network Location server
is run on a highly available server, type the Secure Hypertext Transfer Protocol
(HTTPS)-based uniform resource locator (URL) for network location without a trailing
/ (such as https://nls.corp.contoso.com), click Validate, and then click Next.
If you are using the DirectAccess server as the network location server, click
Network Location server is run on the DirectAccess server, click Browse, click
the certificate for network location, click OK, and then click Next.
13. On the DNS and Domain Controller page, add the appropriate rules for the Name
Resolution Policy Table (NRPT) as needed by your design. To add an NRPT rule, right-
click the empty row, and then click New. Select the appropriate local name resolution
option, and then click Next.
14. On the Management page, add the Internet Protocol (IP) addresses of computers that
will be initiating connections to DirectAccess clients as needed by your design. To add a
management computer, right-click the empty row, and then click New. Click Finish.
15. Click Configure for step 4.
16. On the DirectAccess Application Server Setup page:
a. Click Require end-to-end authentication and traffic protection for the specified
servers.
b. Click Add. In the Select Group dialog box, specify the names of the security groups
that contain the selected servers.
c. If you want to confine the access of DirectAccess clients to only the selected servers,
select Allow access to only those servers in the selected security groups.
d. If you want to use authentication with null encapsulation, select Configure the IPsec
connection security rules on these servers to perform authentication without
traffic protection.
171
Important
To configure the NRPT for an IPv6/IPv4 DNS gateway
17. Click Finish.
18. Click Save, and then click Finish.
19. In the DirectAccess Review dialog box, click Apply. In the DirectAccess Policy
Configuration message box, click OK.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
172
Important Important
To configure the NRPT with 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.
1. Click Start, click Run, type gpmc.msc, and then press ENTER.
2. In the console tree, open the domain.
3. In the console tree, right-click the DirectAccess Policy-{3491980e-ef3c-4ed3-b176-
a4420a810f12} Group Policy object, and then click Edit.
4. In the console tree of the Group Policy Management Editor, open Computer
Configuration\Policies\Windows Settings, and then click Name Resolution Policy.
To create a new NRPT rule for DirectAccess, in the details pane, click DNS Settings
for Direct Access, select Enable DNS settings for DirectAccess in this rule.
Specify the namespace to which the rule applies, the certification authority and
Internet Protocol version 6 (IPv6) addresses of Domain Name System (DNS) servers
(if needed), and then click Create.
To modify an existing rule, click the rule in the NRPT, and then click Edit Rule. When
you are done making changes, click Update.
To delete an existing rule, click the rule in the NRPT, and then click Delete Rule.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
173
To configure an
a 6to4-tunneled
default
IPv6-in-IPv4-tunnel
IPv6 route
connection
forto
a direct
theto
IPv6
the
connection
Internet
IPv6 Internet
to the IPv6 Internet
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
174
Important Note
To create a security group for selected
DirectAccess
servers
client computers
175
Important
To install a certificate for network location
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.
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.
176
Note Important
To obtain an additional certificate for IP-HTTPS
Steps 14 and 15 are optional, but make it easier for you to select the certificate for
network location in Step 3 of the DirectAccess Setup Wizard.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
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.
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) of the Internet name of the
DirectAccess server (for example, da1.contoso.com), and then click Add.
10. Click OK, click Enroll, and then click Finish.
177
Note Warning Important
To obtain an additional SSL certificate for network location
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 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.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
1. On the network location server, click Start, type mmc, and then press ENTER.
2. Click File, and then click Add/Remove Snap-in.
3. Click Certificates, click Add, select Computer account, click Next, select Local
computer, click Finish, and then click OK.
4. In the console tree of the Certificates snap-in, open Certificates (Local
Computer)\Personal\Certificates.
178
Important
To configure the HTTPS security binding
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.
If the Web Server certificate template does not appear, ensure that the network location
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) of the network location server (for
example, nls.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.
In this procedure, you configure the HTTPS security binding on the network location server to use
the new SSL certificate.
1. On the network location server, click Start, type inetmgr.exe, and then press ENTER.
2. In the console tree of Internet Information Services (IIS) Manager, open the site that
contains the network location Web page.
3. In the Actions pane, click Bindings.
4. In the Site Bindings dialog box, click Add.
5. In the Add Site Binding dialog box, in Type, click https. In SSL Certificate, click the
certificate with the FQDN.
6. Click OK, and then click Close.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
179
Important
To remove
install the
ISATAP
DirectAccess
from thefeature
DNS global
from query
Serverblock
Manager
list on a DNS server
about using the appropriate accounts and group memberships at Local and Domain Default
Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
1. On the DirectAccess server, click Start, click Run, type servermanager.msc, and then
press ENTER.
2. In the main window, under Features Summary, click Add features.
3. On the Select Features page, select DirectAccess Management Console.
4. In the Add Features Wizard window, click Add Required Features.
5. On the Select Features page, click Next.
6. On the Confirm Installation Selections page, click Install.
7. On the Installation Results page, click Close.
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
180
Important
5. Start a command prompt as an administrator.
6. In the Command Prompt window, run the following commands:
net stop dns
net start dns
If you arrived at this page by clicking a link in a checklist, use your browser’s Back button to
return to the checklist.
Teredo server Configure Teredo with netsh interface ipv6 set teredo server
the name or IPv4 FirstIPv4AddressOfDirectAccessServer
address of the Teredo
server.
IPv6 interfaces Configure the IPv6 1. Run the following command for the 6to4 and
interfaces for the Teredo interfaces:
correct forwarding netsh interface ipv6 set interface
and advertising InterfaceIndex forwarding=enabled
behavior. 2. If a LAN interface is present with a native
IPv6 address, run the following command:
netsh interface ipv6 set interface
InterfaceIndex forwarding=enabled
3. For the IP-HTTPS interface, run the
following command:
netsh interface ipv6 set interface
IPHTTPSInterface forwarding=enabled
181
Component Purpose Command
advertise=enabled
SSL certificates for IP- Configure the 1. Install the SSL certificate using manual
HTTPS connections certificate binding. enrollment.
2. Use the netsh http add sslcert command
to configure the certificate binding.
IP-HTTPS Interface Configure the IP- netsh interface httpstunnel add interface
HTTPS interface. server
https://PublicIPv4AddressOrFQDN:443/iphttps
enabled certificates
IP-HTTPS Routing Configure IPv6 netsh interface ipv6 add route IP-
routing for the IP- HTTPSPrefix::/64 IPHTTPSInterface
HTTPS interface. 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.
182
Component Purpose Command
Network Interface If you have native IPv6, netsh interface ipv6 set interface
configure intranet LANInterfaceIndex forwarding=enabled
interface forwarding and advertise=enabled
advertising on the LAN
interface.
Enable IPsec DoSP on the intranet interface. netsh ipsecdosp add interface
intranetInterfaceName internal
Purpose Command
183
Purpose Command
infrastructure qmsecmethods=ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-
tunnel). AES128+60min+100000kb
Purpose Command
184
Important
Purpose Command
AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb
185
Purpose Command Group Policy Setting
Protocol ssServer
version 4
(IPv4)
address of
the Teredo
server (the
DirectAcce
ss server).
NRPT
For 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.
186
Important
<ServerData>
<CorpPrefix>2002:836b:1::/48</CorpPrefix>
</ServerData>
</root>
187
Executing Internet Protocol security (IPsec) or Windows Firewall-related Netsh.exe
commands
netshipseccmdexec(string setstorecommand, string ipseccommand, string description)
Script usage
The 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>]
Log file
The script generates a log file named DirectAccessLog.txt when run, which contains the details
of what actions the script performed, with timestamps. The log file contents have the following
format:
Time Stamp Step: description
Executing: the command being run
Output: output of the command
188
Important
Appendix D - DirectAccessConfig.xsd
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).
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="TransitionTechnologies">
<xs:complexType>
<xs:all>
<xs:annotation>
<xs:documentation xml:lang="en-us">
</xs:documentation>
</xs:annotation>
<xs:complexType>
189
<xs:all>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="Teredo">
<xs:complexType>
<xs:all>
</xs:all>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="IPHttps">
<xs:complexType>
<xs:all>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="DOSPConfig">
<xs:complexType>
<xs:all>
190
</xs:all>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:annotation>
<xs:documentation xml:lang="en-us">
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:all>
<xs:element name="IpHttpsAddresses">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="InOutAddresses">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
191
<xs:element name="GPO">
<xs:complexType>
<xs:all>
<xs:element name="Common">
<xs:complexType>
<xs:all>
<xs:annotation>
<xs:documentation xml:lang="en-us">
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="DnsServers">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType>
<xs:sequence>
192
</xs:sequence>
</xs:complexType>
</xs:element>
<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>
<xs:element name="Option">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="NoSmartCard"/>
<xs:enumeration value="RemoteSmartCard"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:annotation>
<xs:documentation xml:lang="en-us">
</xs:documentation>
</xs:annotation>
193
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="DistinguishedDomainName"
type="distinguishedDomainName" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="ClientPolicies">
<xs:complexType>
<xs:all>
<xs:element name="SecurityGroups">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="NRPT">
<xs:complexType>
<xs:sequence>
<xs:complexType>
<xs:all>
<xs:element name="DirectAccessDNSServers"
type="xs:string">
<xs:annotation>
<xs:documentation>
194
specified in Name element above. Can be empty if
specifying NRPT exepmption.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:unique name="NRPTRuleName">
</xs:unique>
</xs:element>
<xs:element name="DnsFallBackOptions">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="DnsFallbackNameDoesNotExist"/>
<xs:enumeration value="DnsAlwaysFallbackForAnyError"/>
<xs:enumeration value="DnsAlwaysFallbackPrivateOnly"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="NCSI">
<xs:complexType>
<xs:all>
</xs:all>
</xs:complexType>
195
</xs:element>
<xs:element name="NID">
<xs:complexType>
<xs:all>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="ClientToApplicationServerExemptPolicy"
type="xs:string" default="DirectAccess Policy-clientToAppServerExempt" minOccurs="0" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="ServerPolicies">
<xs:complexType>
<xs:all>
<xs:element name="SecurityGroups">
<xs:complexType>
<xs:sequence>
196
<xs:element name="SecurityGroup" type="sg" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="AppServerPolicies">
<xs:complexType>
<xs:all>
<xs:annotation>
<xs:documentation xml:lang="en-us">
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
197
<xs:element name="AuthenticationOption">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="NoAuthentication"/>
<xs:enumeration value="SelectedServerEndToEnd"/>
<xs:enumeration value="EndToEndAuthentication"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:annotation>
<xs:documentation xml:lang="en-us">
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ApplicationServerToIpHttpsClientPolicy"
type="xs:string" default="DirectAccess Policy-appServerToIpHttpsClientPolicy"
minOccurs="0" />
</xs:all>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
<xs:unique name="GPONames">
</xs:unique>
198
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:complexType name="sg">
<xs:annotation>
<xs:documentation xml:lang="en">
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="Type">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="computer"/>
<xs:enumeration value="group"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:all>
</xs:complexType>
<xs:complexType name="interface">
<xs:annotation>
<xs:documentation xml:lang="en">
</xs:documentation>
199
</xs:annotation>
<xs:all>
</xs:all>
</xs:complexType>
<xs:simpleType name="ipv4Address">
<xs:annotation>
<xs:documentation xml:lang="en">
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="((0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-
9]?))\.){3}(0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ipv6Address">
<xs:annotation>
<xs:documentation xml:lang="en">
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4}))|((([0-9a-fA-F]
{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})))|((([0-9a-fA-F]{1,4}:)*([0-
9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*)|((([0-9a-fA-F]{1,4}:)*([0-
9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0-9]{1,3}\.[0-9]{1,3}\.[0-
9]{1,3}\.[0-9]{1,3})))" />
</xs:restriction>
</xs:simpleType>
200
<xs:simpleType name="ipv6Prefix">
<xs:annotation>
<xs:documentation xml:lang="en">
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})/\d+)|((([0-9a-fA-F]
{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\d+)|((([0-9a-fA-F]
{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*/\d+)|((([0-9a-
fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0-9]
{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\d+)" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ipv6PrefixOrAddress">
<xs:annotation>
<xs:documentation xml:lang="en">
</xs:documentation>
</xs:annotation>
</xs:simpleType>
<xs:annotation>
<xs:documentation xml:lang="en">
</xs:documentation>
</xs:annotation>
201
</xs:simpleType>
<xs:simpleType name="guid">
<xs:annotation>
<xs:documentation xml:lang="en">
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="\{[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-
fA-F0-9]{12}\}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="domainName">
<xs:annotation>
<xs:documentation>
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="([a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*[a-zA-Z][a-zA-Z0-9\-]*[a-
zA-Z0-9]" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="distinguishedDomainName">
<xs:annotation>
<xs:documentation>
</xs:documentation>
</xs:annotation>
202
<xs:restriction base="xs:string">
<xs:pattern value="(DC=[a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9],)*DC=[a-zA-Z][a-zA-Z0-
9\-]*[a-zA-Z0-9]" />
</xs:restriction>
</xs:simpleType>
</xs:schema>
In this guide
This 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).
203
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.
Additional resources
To 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).
204
Cannot Reach the DirectAccess Server from the IPv6 Internet
Cannot Reach the DirectAccess Server with 6to4
Cannot Reach the DirectAccess Server with IP-HTTPS
Cannot Reach the DirectAccess Server with Teredo
DirectAccess Client Cannot Access Intranet Resources
DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server
DirectAccess Client Cannot Resolve Names with Intranet DNS Servers
DirectAccess Client Determines that it is on the Internet When on the Intranet
DirectAccess Client Determines that it is on the Intranet When on the Internet
DirectAccess Client Connection is Slow
Fixing Problems Encountered during the Steps of the DirectAccess Setup Wizard
Fixing Problems Encountered when Applying the Settings of the DirectAccess Setup Wizard
Fixing problems that Prevent You from Running the DirectAccess Setup Wizard
Fixing Problems with Creating Protected Connections to an Intranet Resource
Intranet Management Server Cannot Connect to a DirectAccess Client
205
Note
To start the DirectAccess troubleshooter
Windows Network Diagnostics
To 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.
206
To capture a network trace for a DirectAccess client To capture a network trace for WFP
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.
207
Note
--------------------------------------------------------------------
208
Query Failure Behavior : Only use LLMNR and NetBIOS if the name does not
exist in DNS
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).
----------------------------------------------------------------------
C1-CA
209
Note
----------------------------------------------------------------------
C1-CA
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.
In this example, the DirectAccess client has been configured with the 6to4 relay IPv4 address of
131.107.0.2 through Group Policy.
210
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.
---------------------------------------------
Type : client
State : offline
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
State : online
211
Failure : 0 (Hdr 0, Src 0, Dest 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.
------------------------------------------------------------
Role : client
URL : https://da1.contoso.com:443/IPHTTPS
212
Interface Status : IPHTTPS interface deactivated
In this example, the DirectAccess client has been configured as an IP-HTTPS client with the URL
https://da1.contoso.com:443/IPHTTPS.
The following is an example of output from the netsh interface httpstunnel show interfaces
command on a DirectAccess server.
Interface IPHTTPSInterface Parameters
------------------------------------------------------------
Role : server
URL : https://da1.contoso.com:443/IPHTTPS
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.
In this example, the DirectAccess server has the ISATAP component enabled.
The following is an example of output from the netsh interface istatap show router command
on the DirectAccess server.
Router Name : isatap.corp.contoso.com
213
Resolution Interval : default
In this example, the DirectAccess server has constructed the ISATAP router name from the name
ISATAP and the DNS suffix assigned to the computer (corp.contoso.com).
You use the netsh interface istatap show state and netsh interface istatap show router
commands on the DirectAccess server to ensure that it is configured to act as an ISATAP router.
You use the netsh interface istatap show state and netsh interface istatap show router
commands on an intranet node to ensure that it has a default configuration.
To determine if an ISATAP host has successfully configured an ISATAP-based address, use the
ipconfig command and look for an interface named Tunnel adapter isatap.ComputerDNSSuffix.
Ensure that it has been assigned an ISATAP-based IPv6 address that begins with 2 or 3 and a
default gateway.
----------------------------------------------------------------------
Auth1: ComputerCert
Auth2: UserNTLM
MM Offer: None-AES128-SHA256
Health Cert: No
----------------------------------------------------------------------
Auth1: ComputerCert
Auth2: UserNTLM
MM Offer: None-AES128-SHA256
Health Cert: No
214
Main Mode SA at 09/11/2009 10:43:59
----------------------------------------------------------------------
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Health Cert: No
----------------------------------------------------------------------
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Health Cert: No
----------------------------------------------------------------------
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
215
Health Cert: No
----------------------------------------------------------------------
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
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
MM Offer: None-AES128-SHA256
Health Cert: No
----------------------------------------------------------------------
Auth1: ComputerCert
Auth2: UserNTLM
MM Offer: None-AES128-SHA256
Health Cert: No
216
Main Mode SA at 09/11/2009 10:44:03
----------------------------------------------------------------------
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Health Cert: No
----------------------------------------------------------------------
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
Health Cert: No
----------------------------------------------------------------------
Auth1: ComputerCert
Auth2: UserKerb
MM Offer: None-AES128-SHA256
217
Cookie Pair: 4775f7dd32e268b2:b0ad96d598518fa7
Health Cert: No
Ok.
You can correlate the main mode SAs on the DirectAccess client and server through the Cookie
Pair.
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.
----------------------------------------------------------------------
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
PFS: None
----------------------------------------------------------------------
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
218
PFS: None
----------------------------------------------------------------------
Protocol: Any
Direction: Both
QM Offer: ESP:SHA256-None+60min+100000kb
PFS: None
----------------------------------------------------------------------
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
PFS: None
Ok.
The following is an example of output from the netsh advfirewall monitor show qmsa
command on the DirectAccess server of the DirectAccess client.
Quick Mode SA at 09/11/2009 10:56:47
----------------------------------------------------------------------
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
219
PFS: None
----------------------------------------------------------------------
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
PFS: None
----------------------------------------------------------------------
Protocol: Any
Direction: Both
QM Offer: ESP:SHA1-AES192+60min+100000kb
PFS: None
Ok.
You can correlate the quick mode SAs on the DirectAccess client and server through the local
and remote Internet Protocol (IP) address pairs and Quick Mode (QM) offers.
You use the netsh advfirewall monitor show qmsa command to verify that the DirectAccess
client and server can successfully negotiate quick mode IPsec SAs. If there are no quick mode
IPsec SAs on the DirectAccess client after attempting to access an intranet resource, investigate
the correlation of quick mode settings between the DirectAccess client, the DirectAccess server,
and the intranet node.
----------------------------------------------------------------------
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
----------------------------------------------------------------------
Enabled: Yes
Profiles: Private,Public
Type: Dynamic
Mode: Transport
Endpoint1: Any
Endpoint2: 2002:836b:2:1:0:5efe:10.0.0.3-2002:836b:2:
1:0:5efe:10.0.0.3
Protocol: Any
Action: RequestInRequestOut
Auth1: ComputerCert,ComputerKerb
221
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
----------------------------------------------------------------------
Enabled: Yes
Profiles: Private,Public
Type: Dynamic
Mode: Tunnel
LocalTunnelEndpoint: Any
RemoteTunnelEndpoint: 2002:836b:2::836b:2
Endpoint1: Any
Endpoint2: 2002:836b:2:1:200:5efe:157.60.79.2-2002:83
6b:2:1:200:5efe:157.60.79.2
Protocol: Any
Action: RequireInRequireOut
Auth1: ComputerCert
Auth1CertMapping: No
Auth1ExcludeCAName: No
Auth1CertType: Root
Auth1HealthCert: No
Auth2: UserNTLM
MainModeSecMethods: DHGroup2-AES128-SHA256,DHGroup2-AES128-SHA
1,DHGroup2-3DES-SHA1
222
QuickModeSecMethods: ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-AE
S128+60min+100000kb
ExemptIPsecProtectedConnections: No
ApplyAuthorization: No
----------------------------------------------------------------------
Enabled: Yes
Profiles: Private,Public
Type: Dynamic
Mode: Tunnel
LocalTunnelEndpoint: Any
RemoteTunnelEndpoint: 2002:836b:3::836b:3
Endpoint1: Any
Endpoint2: 2002:836b:2:1::/64
Protocol: Any
Action: RequireInRequireOut
Auth1: ComputerCert
Auth1CertMapping: No
Auth1ExcludeCAName: No
Auth1CertType: Root
Auth1HealthCert: No
Auth2: UserKerb
MainModeSecMethods: DHGroup2-AES128-SHA256,DHGroup2-AES128-SHA
1,DHGroup2-3DES-SHA1
QuickModeSecMethods: ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-AE
S128+60min+100000kb
ExemptIPsecProtectedConnections: No
ApplyAuthorization: No
----------------------------------------------------------------------
223
Enabled: Yes
Profiles: Private,Public
Type: Dynamic
Mode: Tunnel
LocalTunnelEndpoint: Any
RemoteTunnelEndpoint: 2002:836b:2::836b:2
Endpoint1: Any
Endpoint2: 2002:836b:2:1:0:5efe:10.0.0.1-2002:836b:2:
1:0:5efe:10.0.0.1
Protocol: Any
Action: RequireInRequireOut
Auth1: ComputerCert
Auth1CertMapping: No
Auth1ExcludeCAName: No
Auth1CertType: Root
Auth1HealthCert: No
Auth2: UserNTLM
MainModeSecMethods: DHGroup2-AES128-SHA256,DHGroup2-AES128-SHA
1,DHGroup2-3DES-SHA1
QuickModeSecMethods: ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-AE
S128+60min+100000kb
ExemptIPsecProtectedConnections: No
ApplyAuthorization: No
Ok.
You use the netsh advfirewall monitor show consec rule name=all command to verify that a
DirectAccess client, DirectAccess server, or selected server has been configured with the correct
connection security rules.
224
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.
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).
225
netsh interface ipv6 show interfaces
level=verbose
This 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
DAD Transmits : 0
Site Id : 1
Forwarding : disabled
Advertising : disabled
226
Directed MAC Wake up patterns : disabled
----------------------------------------------
IfLuid : tunnel_4
IfIndex : 13
State : connected
Metric : 25
DAD Transmits : 0
Site Id : 1
Forwarding : enabled
Advertising : enabled
----------------------------------------------
227
IfLuid : tunnel_5
IfIndex : 14
State : connected
Metric : 25
DAD Transmits : 0
Site Id : 1
Forwarding : disabled
Advertising : disabled
----------------------------------------------
IfLuid : ethernet_6
IfIndex : 11
State : connected
Metric : 20
228
Link MTU : 1500 bytes
DAD Transmits : 1
Site Id : 1
Forwarding : enabled
Advertising : disabled
----------------------------------------------
IfLuid : tunnel_6
IfIndex : 15
State : connected
Metric : 25
229
DAD Transmits : 0
Site Id : 1
Forwarding : enabled
Advertising : disabled
----------------------------------------------
IfLuid : tunnel_7
IfIndex : 16
State : connected
Metric : 50
DAD Transmits : 0
Site Id : 1
Forwarding : enabled
230
Advertising : disabled
----------------------------------------------
IfLuid : tunnel_8
IfIndex : 17
State : connected
Metric : 50
DAD Transmits : 1
Site Id : 1
Forwarding : enabled
Advertising : enabled
231
Managed Address Configuration : disabled
----------------------------------------------
IfLuid : ethernet_9
IfIndex : 12
State : connected
Metric : 20
DAD Transmits : 1
Site Id : 1
Forwarding : enabled
Advertising : disabled
232
Use Automatic Metric : 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.
nterface
oso.com
face
233
nterface
com
com
udo-Interface
nterface
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.
234
Important
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).
235
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
Default Gateway . . . . . . . . . :
236
Media State . . . . . . . . . . . : Media disconnected
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
Default Gateway . . . . . . . . . :
237
Link-local IPv6 Address . . . . . : fe80::45d1:e335:2f5e:865c%11
Default Gateway . . . . . . . . . :
Default Gateway . . . . . . . . . :
Default Gateway . . . . . . . . . :
Default Gateway . . . . . . . . . :
Default Gateway . . . . . . . . . :
238
Note
Default Gateway . . . . . . . . . :
In this example, the DirectAccess server has an ISATAP address (on the interface named Tunnel
adapter isatap.corp.contoso.com) and is using 6to4, Teredo, and IP-HTTPS.
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.
Subject: CN=CLIENT2.corp.contoso.com
Non-root Certificate
Cert Hash(sha1): d2 48 b0 ac d0 75 d2 17 d3 a2 52 73 03 fb 6d 93 05 d6 c5 9c
d8a0337
239
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.
Address: \\2002:836b:2:1:0:5efe:10.0.0.1
DNS_FOREST FULL_SECRET WS
You use the Nltest.exe command line tool (the nltest /dsgetdc: /force command) for
DirectAccess troubleshooting to determine whether DirectAccess clients, DirectAccess servers,
and intranet resources can locate and contact domain controllers for Internet Protocol security
(IPsec) authentication.
Snap-in Tools
Windows 7 and Windows Server 2008 R2 also provide a set of snap-ins to gather troubleshooting
information or modify settings to correct problems. The following snap-ins can be used for
DirectAccess troubleshooting:
DirectAccess Management
Group Policy Management Console and Editor
Windows Firewall with Advanced Security
Event Viewer
Certificates
240
Warning
To view the status of the DirectAccess server with DirectAccess monitoring
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.
241
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 rules
Rules 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.
6to4 Relay Name Allows you to specify a 6to4 The first consecutive Internet
relay name for a 6to4 host. A Protocol version 4 (IPv4)
6to4 relay is used as a default address of the DirectAccess
gateway for IPv6 network traffic server’s Internet interface.
sent by the 6to4 host.
6to4 Relay Name Resolution Allows you to specify the N/A (not configured)
Interval interval at which the 6to4 relay
242
Setting name Description Value set by the DirectAccess
Setup Wizard
name is resolved.
Teredo Default Qualified Allows you to set Teredo to be Set to enabled state.
ready to communicate. By
default, Teredo enters a
dormant state when not in use.
The qualification process brings
it out of a dormant state.
Teredo Server Name Allows you to specify the name The first consecutive IPv4
of the Teredo server. address of the DirectAccess
server’s Internet interface.
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.
243
Intranet connectivity settings
Settings for the intranet and network location detection processes are configured by the
DirectAccess Setup Wizard in the Computer Configuration\Policies\Administrative
Templates\Network\Network Connection Status Indicator node of the Group Policy object for
DirectAccess clients.
Corporate Site Prefix List The list of IPv6 addresses The IPv6 prefix of the intranet.
and prefixes that define the
address space of the
corporate network.
Domain Location The Secure Hypertext The URL specified during the
Determination URL Transfer Protocol (HTTPS)- DirectAccess Setup Wizard or
based URL of the network obtained from the Subject field of
location server. the certificate on the DirectAccess
server that was selected for
network location.
Use the Group Policy Management Editor snap-in to verify the configuration of these corporate
connectivity settings—most importantly for DirectAccess, the Domain Location Determination
URL setting—and modify them as needed.
244
Note
To use the Windows Firewall with Advanced Security snap-in To start the Event Viewer snap-in
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.
On a DirectAccess client, if there are active connection security rules whose names begin with
DirectAccess Policy, the DirectAccess client has determined that it is not connected to your
intranet. If there are active connection security rules but no main mode or quick mode SAs after
attempting to access an intranet resource, the DirectAccess client is unable to negotiate IPsec
protection with the DirectAccess server.
Event Viewer
Use the Event Viewer snap-in on a DirectAccess client to examine Windows events for
operational Internet Protocol security (IPsec) and Windows Firewall events, network location
detection events, and IPsec negotiation events.
245
To view certificates in the computer store with the Certificates snap-in
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.
246
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
(http://go.microsoft.com/fwlink/?Linkid=181782).
247
Notes
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.
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
248
Note
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\Corpo
rateConnectivity /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.
If any of your networks has been assigned the domain profile, determine if you have an active
remote access virtual private network (VPN) connection or a domain controller that is
available on the Internet.
10. The DirectAccess client must have IPv6 reachability to its intranet DNS servers.
From the display of the netsh namespace show effectivepolicy command, obtain the IPv6
addresses of your intranet DNS servers. Ping these IPv6 addresses from the DirectAccess
client.
If successful, go to step 11.
If not successful, troubleshoot the IPv6 reachability between the DirectAccess client and the
intranet DNS servers.
249
Note Note
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 successful, go to step 13.
If not successful, troubleshoot the IPv6 reachability between the DirectAccess client and the
intranet servers.
The use of the Ping.exe tool assumes the default global IPsec settings that exempt
ICMP traffic from IPsec protection.
13. The DirectAccess client must be able to communicate with intranet servers using application
layer protocols.
Use the appropriate program to access the intranet server. If File and Printer Sharing is
enabled on the intranet server, test application layer protocol access with the net
view \\IntranetFQDN command. The application on the DirectAccess client must be IPv6-
capable. If not, you must use an intermediate NAT64/DNS64, such as the Microsoft Forefront
Unified Access Gateway (UAG) 2010.
If not successful, go to step 14.
250
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 successful, go to step 15.
If not successful, use the nltest /dsgetdc: /force command on the DirectAccess server to
ensure that it can access a domain controller. If there are no domain controllers listed,
troubleshoot the lack of discoverability and connectivity between the DirectAccess server and
an Active Directory domain controller.
Ensure that the DirectAccess client and DirectAccess server have the proper certificates for
IPsec peer authentication.
If the proper certificates are installed on the DirectAccess client and DirectAccess server, use
Windows Firewall tracing on the DirectAccess client and analyze the contents of the
Wfpdiag.xml file. For more information, see Network Diagnostics and Tracing.
15. For the end-to-edge or selected server access models, the DirectAccess client must be able
to successfully negotiate main mode and quick mode IPsec SAs with the DirectAccess server
for the intranet tunnel.
Verify that you have logged on to the DirectAccess client computer with a domain account.
Local computer accounts do not have the credentials to authenticate the intranet tunnel.
On the DirectAccess client, use the Windows Firewall with Advanced Security snap-in or the
netsh advfirewall monitor show mmsa and netsh advfirewall monitor show qmsa
commands to determine if there are main mode and quick mode SAs to the IPv6 address
2002:RRSS:TTUU::RRSS:TTUU. RRSS:TTUU is the colon-hexadecimal representation of
the second consecutive IPv4 address assigned to the Internet interface of the DirectAccess
server.
If the SAs exist and you are using an IPv6/IPv4 translator such as NAT64 to reach the
intranet server, verify that the IPv6/IPv4 translator supports translating the application
protocol. Some protocols embed IP address information in the packet payload and cannot be
used across some IPv6/IPv4 translators.
If successful, go to step 16.
If not successful, use the nltest /dsgetdc: /force command on the DirectAccess server to
ensure that it has access to a domain controller. If there are no domain controllers listed,
251
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.
On the DirectAccess client, use the Windows Firewall with Advanced Security snap-in or the
netsh advfirewall monitor show mmsa and netsh advfirewall monitor show qmsa
commands to determine if there are main mode and quick mode SAs to the IPv6 address of
the intranet or selected server.
If not successful, use the nltest /dsgetdc: /force command on the intranet or selected server
to ensure that it has access to a domain controller. If there are no domain controllers listed,
troubleshoot the lack of discoverability and connectivity between the intranet or selected
server and Active Directory.
Use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it has
access to a domain controller. If there are no domain controllers listed, ensure that the IPv6-
capable domain controllers that are being used by DirectAccess clients are using 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.
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.
The current security context is not associated The DirectAccess server cannot reach a
or accessible to Active Directory Domain domain controller of the domain in which it is a
Services (AD DS). member. Verify the connection to your intranet
and name resolution and reachability to an
intranet domain controller.
The Active Directory domain is unreachable. The DirectAccess server cannot reach a
Unable to get domain information. 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 The DirectAccess server requires two physical
more physical network interfaces. Verify that network adapters corresponding to two local
you have two or more interfaces and then try area network (LAN) or wireless LAN (WLAN)
again. network adapters that are installed in the
DirectAccess server computer.
At least two network interfaces must be The network connections corresponding to the
configured with static IP addresses. Please network adapters for the DirectAccess server’s
contact the network administrator to obtain and connection to the Internet and intranet must be
assign static IP addresses to this server. 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 At least one of the network connections
consecutive public IPv4 addresses configured corresponding to the network adapters installed
on the same physical interface. Configure IPv4 in the DirectAccess server must have two,
addresses and try again. consecutive public IPv4 addresses statically
assigned. These two consecutive addresses are
needed by the DirectAccess server to act as a
Teredo server. Obtain two consecutive
addresses and assign them to a network
adapter on the DirectAccess server.
Note
The DirectAccess Management console
sorts the public IPv4 addresses
alphabetically. Therefore, the
DirectAccess Management console
does not consider the following sets of
addresses as consecutive: w.x.y.9 and
w.x.y.10, which is sorted as w.x.y.10,
w.x.y.9; w.x.y.99 and w.x.y.100, which is
sorted as w.x.y.100, w.x.y.99; w.x.y.1,
w.x.y.2, and w.x.y.10, which is sorted as
w.x.y.1, w.x.y.10, w.x.y.2. Use a different
254
Error message Error condition and the steps to correct
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.
Connectivity page
On 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 The interface that you select must have two,
consecutive global Internet Protocol version 4 consecutive public IPv4 addresses statically
(IPv4) addresses configured. Select an assigned. These two consecutive addresses are
interface with two consecutive global IPv4 needed by the DirectAccess server to act as a
addresses. Teredo server.
Note
The DirectAccess Management console
255
Error message Error condition and the steps to correct
The Internet interface must not be classified as The interface that you have specified for the
a domain network. Internet is connected to a network that contains
a domain controller (the network has been
assigned the domain firewall profile). The
Internet interface must be connected to a
network that has been assigned the Public or
Private profiles. Select a different interface or
add outbound packet filters to the selected
interface that block connectivity to the IP
addresses of the domain controllers. For more
information, see Configure Packet Filters to
Block Access to Domain Controllers.
You can use the netsh advfirewall monitor
show currentprofile command to display the
networks to which your computer is attached
and their assigned profiles. Then, use the
Network Connections window to determine the
networks to which the interfaces are connected.
The internal network interface must be The interface that you have specified for the
classified as a domain network. 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
256
Error message Error condition and the steps to correct
The internal network interface does not have The intranet (internal network) interface must be
Domain Name System (DNS) server settings manually configured with the IPv4 or IPv6
configured. Select an interface with DNS server addresses of at least one intranet DNS server.
settings configured. 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 The intranet (internal network) interface must be
connection-specific DNS suffix. Select an manually configured with a connection-specific
interface with a connection-specific DNS suffix. 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. Your Internet interface has a native IPv6
DirectAccess setup will apply settings without address assigned. The DirectAccess Setup
considering the IPv6 settings on the Internet Wizard will configure IPv6 for the intranet
interface. without regard to the IPv6 configuration of the
Internet interface.
However, you will need to configure packet
filters on the Internet interface to prevent the
Internet interface from being assigned the
Domain firewall profile. For more information,
see Configure Packet Filters to Block Access to
Domain Controllers.
The IPv6 prefix you provided for the internal You have not specified a valid global or unique
network is not valid. Provide a valid IPv6 prefix. local address prefix for your organization.
257
Error message Error condition and the steps to correct
The IPv6 prefix you provided to assign to the You have not specified a valid 64-bit global or
IPv6 addresses of remote client computers is unique local address prefix for your IP-HTTPS-
not valid. Provide a valid IPv6 prefix. based DirectAccess clients.
The network prefix you provided to assign to The 64-bit prefix for your IP-HTTPS-based
IPv6 addresses must be a subset of the internal DirectAccess clients must be based on the IPv6
network IPv6 prefix. Provide a valid IPv6 prefix. 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.
The selected certificate has a subject name that The certificate that you selected does not have
is not valid. Select a certificate with a valid a valid value in the Subject field. A valid Subject
subject name. field is required to configure DirectAccess
clients with a Secure Hypertext Transfer
Protocol (HTTPS)-based uniform resource
locator (URL) of the IP-HTTPS server (the
DirectAccess server). To see the value of the
Subject field, use the Certificates snap-in for the
local computer store, obtain properties of the
certificate, and then click the Details tab.
The selected certificate does not have a subject The certificate that you selected does not have
name. Select a certificate with a subject name. a value in the Subject field. The Subject field is
or required to configure DirectAccess clients with
an HTTPS-based URL of the IP-HTTPS server
The selected certificate does not contain a
(the DirectAccess server).
subject name.
The selected certificate does not have Server The certificate that you selected does not have
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
258
Error message Error condition and the steps to correct
Unable to resolve the subject name of the The DirectAccess Setup Wizard cannot resolve
certificate to a valid Internet Protocol (IP) the fully qualified domain name (FQDN) in the
address. 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.
Location page
On 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
259
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.
260
Error message Error condition and the steps to correct
Registration of Intra-Site Automatic Tunnel The DirectAccess server computer cannot use
Addressing Protocol (ISATAP) in Domain Name DNS dynamic update to create an Address (A)
System (DNS) failed. 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, You must log on to the DirectAccess server
or equivalent, is the minimum required to computer with a user account that has local
complete this operation. administrator privileges.
DirectAccess server configuration failed The IP-HTTPS interface is not active. Use the
because the IP-HTTPS interface cannot be netsh interface httpstunnel show interfaces
configured. command to display the state of the IP-HTTPS
interface.
DirectAccess server configuration failed The 6to4 service is not active. Use the netsh
because the 6to4 interface is not operational. interface 6to4 show state command to display
the state of the 6to4 service. If needed, start the
6to4 service with the netsh interface 6to4 set
state enabled command.
DirectAccess server configuration failed The Teredo service is not active. Use the netsh
because the Teredo interface is not operational. 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
261
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 Problems with Creating Protected Connections to an Intranet Resource
262
To troubleshoot connectivity from a DirectAccess client on the IPv6 Internet to the
DirectAccess server
263
Note
To verify 6to4 functionality and configuration on a DirectAccess client
colon hexadecimal representation of w.x.y.z, a public IPv4 address), the DirectAccess client
encapsulates IPv6 traffic directly to the DirectAccess server. If the DirectAccess server is only on
the IPv6 Internet (the DirectAccess tunnel endpoints are not 6to4 addresses), the DirectAccess
client encapsulates IPv6 traffic and sends it to a 6to4 relay. The 6to4 relay then forwards the
native IPv6 traffic across the IPv6 Internet to the DirectAccess server.
On the IPv4 Internet, there must be a routing path between the DirectAccess client and server
that allows IPv4 protocol 41 traffic. If the traffic is also traveling on the IPv6 Internet, there must
be a routing path between the DirectAccess client and server that allows the following types of
traffic:
Internet Control Message Protocol for IPv6 (ICMPv6) (IPv6 Next Header value of 58)
Internet Key Exchange (IKE)/Authenticating Internet Protocol (AuthIP) (User Datagram
Protocol [UDP] port 500)
Internet Protocol security (IPsec) Encapsulating Security Payload (ESP) (IPv6 Next Header
value of 50)
6to4 addresses can also take the form 2002:WWXX:YYZZ:SubnetID:InterfaceID. In this
form, 6to4 is being used to generate a 48-bit global IPv6 address prefix based on a public
IPv4 address (w.x.y.z). When 6to4 is used this way, hosts use the 6to4-derived address
prefix for native IPv6 addressing and the 6to4-based address is assigned to a LAN
interface, not the Tunnel Adapter 6TO4 Adapter. This type of 6to4-based addressing can
be used on an intranet or used for native IPv6 addressing of a single-subnet home or
small office network, in which the local Internet router is providing 6to4 router
functionality.
264
To verify
This 6to4 functionality
command and configuration
should display on the DirectAccess
the first consecutive server
public IPv4 address of the
DirectAccess server’s Internet interface in Relay Name.
5. From the Command Prompt window, run the netsh interface 6to4 show state
command.
This command should display default or enabled in 6to4 Service State.
The 6to4 service state should not show disabled. A value of disabled means that the
DirectAccess client will never bring up a 6to4 interface. A value of default means that the
DirectAccess client will bring up a 6to4 interface if it does not have a global IPv6 address
assigned already and it has a public IPv4 address. A value of enabled means that the
DirectAccess client will bring up a 6to4 interface whenever it has a public IPv4 address
assigned.
6. From the Command Prompt window, run the netsh –c advfirewall command.
7. From the netsh advfirewall prompt, run the set store
gpo=”DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}”
command.
8. From the netsh advfirewall prompt, run the consec show rule name=”DirectAccess
Policy-ClientToDnsDc” command.
9. From the netsh advfirewall prompt, run the exit command.
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.
265
To troubleshoot
This commandconnectivity fromenabled
should display a 6to4-based
in 6to4DirectAccess
Service State.client on the
The 6to4 IPv4 state
service Internet
to the DirectAccess
should server A value of disabled means that the DirectAccess server will
not show disabled.
never bring up a 6to4 interface. A value of default means that the DirectAccess server
will bring up a 6to4 interface if it does not have a global IPv6 address assigned already
and it has a public IPv4 address. A value of enabled means that the DirectAccess server
will bring up a 6to4 interface whenever it has a public IPv4 address assigned.
5. From the Command Prompt window, run the route print command.
The IPv6 route table should have 2002::/16 route with the interface index of the Microsoft
6to4 Adapter and the Gateway address set to On-link.
266
To verify Teredo functionality and configuration on a DirectAccess client
267
If DisabledComponents is present and it is not 0, convert it to a binary number. If the first
or fourth bit from the right in the binary number is 1, DisabledComponents has disabled
Teredo. You must change the first and fourth bit from the right to 0 to enable Teredo.
5. From the Command Prompt window, run the reg query
HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition /v
Teredo_ServerName command.
This command should display the first consecutive public IPv4 address of the
DirectAccess server’s Internet interface. 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.
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
268
To verify Teredo functionality and configuration on the DirectAccess server
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.
269
To troubleshoot connectivity from acommand,
neighborcachelimit=Maximum Teredo-based DirectAccess
in which Maximum isclient on the IPv4
the maximum number of
Internet to the
expected DirectAccess
Teredo-based server
DirectAccess clients.
270
To verify IP-HTTPS functionality and configuration on a DirectAccess client
271
To verify
configure
IP-HTTPS
the DirectAccess
functionalityclient
and configuration
to use an intranet
on the
proxy
DirectAccess
server server
nterface /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.
If you must reconfigure the proxy server settings after leaving the intranet, repeat the previous
procedure with the original proxy settings.
272
To troubleshoot
DirectAccessconnectivity from
Setup Wizard an the
to use IP-HTTPS-based
new certificate,DirectAccess client on server
apply the DirectAccess the IPv4
Internet to the
settings, andDirectAccess server configuration Group Policy on your DirectAccess
update the computer
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.
2. Start a command prompt as an administrator.
3. From the Command Prompt window, run the ipconfig command.
Check the configuration of the Tunnel adapter iphttpsinterface. If IP-HTTPS is being
used, there should be an IPv6 address assigned. If there is no IPv6 address assigned,
look at the other interfaces for a global IPv6 address (one beginning with 2 or 3). If there
is an interface with a public IPv4 address, IP-HTTPS will not be used.
4. From the Command Prompt window, run the netsh interface httpstunnel show
interfaces command.
This command displays the IP-HTTPS URL in URL.
5. From the Command Prompt window, ping the fully qualified domain name (FQDN) from
the URL in step 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.
7. From the Command Prompt window, run the netsh –c advfirewall command.
8. From the netsh advfirewall prompt, run the set store
gpo="DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}"
command.
9. From the netsh advfirewall prompt, run the consec show rule name=”DirectAccess
Policy-ClientToDnsDc” command.
10. From the netsh advfirewall prompt, run the exit command.
11. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint.
This is the IPv6 address of the DirectAccess server for the infrastructure tunnel.
If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the
tracert –d IPv6Address command to trace the route to the destination.
12. From the Command Prompt window, run the netsh advfirewall consec show rule
name=”DirectAccess Policy-ClientToCorp” command.
13. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint.
This is the IPv6 address of the DirectAccess server for the intranet tunnel.
273
To troubleshoot certificate
If the IPv6 address problems
is not for an and
a 6to4 address IP-HTTPS-based connection
you cannot reach this IPv6 to the
address, use the
DirectAccess
tracert –d server
IPv6Address command to trace the route to the destination.
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
certificate of the DirectAccess client.
274
DirectAccess Client Connection is Slow
DirectAccess performance is dependent on many factors such as the speed of the DirectAccess
client’s connection to the Internet, Internet latency and congestion between the DirectAccess
client and server, and the current load on the DirectAccess server. Another reason might be the
type of Internet Protocol version 6 (IPv6) encapsulation being used over the Internet Protocol
version 4 (IPv4) Internet. 6to4 and Teredo tend to have higher performance because the
encapsulation is simpler to process. Internet Protocol over Secure Hypertext Transfer Protocol
(IP-HTTPS) tends to have lower performance because of the higher protocol overhead and the
additional Secure Hypertext Transfer Protocol (HTTPS)-based encryption and decryption. When
examining performance issues, one of the first places to look is the display of the ipconfig
command on the DirectAccess server, which indicates the type of encapsulation based on the
interface that has a global IPv6 address assigned.
A DirectAccess client on a private IPv4 network behind a network address translator (NAT) must
connect to the DirectAccess server using either Teredo or IP-HTTPS. Each of these transition
technologies requires particular types of traffic between the DirectAccess client and the
DirectAccess server:
Teredo requires IPv4 and User Datagram Protocol (UDP) destination port 3544 for traffic to
the two public IPv4 addresses of the Teredo server and relay (the DirectAccess server). The
Teredo relay requires Internet Control Message Protocol for IPv6 (ICMPv6) Echo Request
and Echo Reply messages to be allowed for all intranet destinations, including the
DirectAccess server.
IP-HTTPS requires IPv4 and Transmission Control Protocol (TCP) destination port 443 traffic
between the DirectAccess client and the first consecutive public IPv4 address of the
DirectAccess server.
The DirectAccess client needs to determine which of these two transition technologies to use. IP-
HTTPS and Teredo both attempt qualification of their interface state at the same time. If the
Teredo interface is qualified, the IP-HTTPS client waits in an offline state for a computed delay for
the DirectAccess client to detect corporate connectivity. The computed delay is either ten seconds
or a network delay larger than ten seconds based on the round trip time of TCP packets from the
client to the public IPv4 address of the DirectAccess server. If the DirectAccess client detects
corporate connectivity within this network delay, the IP-HTTPS client will remain in an offline
state. If the DirectAccess client does not detect corporate connectivity within this network delay,
the IP-HTTPS client will attempt to qualify again.
Using IP-HTTPS for DirectAccess connectivity has higher overhead and lower performance than
Teredo. If the DirectAccess client is using IP-HTTPS instead of Teredo, the DirectAccess client
will have a lower performance connection.
However, due to network timing issues, it is possible for the DirectAccess client to have both
Teredo and IP-HTTPS interfaces active, but use only the IP-HTTPS interface for traffic to the
intranet. This condition occurs when the DirectAccess client takes more than the computed delay
for the DirectAccess client to determine corporate connectivity over the Teredo interface. To test
for this condition, run the ipconfig command at a command prompt. If you have global addresses
on both the Teredo and IP-HTTPS tunnel interfaces, this condition has occurred.
275
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:
DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server
DirectAccess Client Cannot Resolve Names with Intranet DNS Servers
If you have specified management servers in Step 3 of the DirectAccess Wizard, there is an
additional management tunnel that is typically initiated by a management server on the intranet.
For more information, see Intranet Management Server Cannot Connect to a DirectAccess Client.
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.
277
To verify whether the DirectAccess client can successfully create the intranet tunnel
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.
You can view the certificates in the local computer store on the DirectAccess client and server
with the Certificates snap-in.
To ensure that the DirectAccess server can access a domain controller to validate the credentials
of the DirectAccess client, run the nltest /dsgetdc: /force command at an elevated command
prompt. If there are no domain controllers listed, troubleshoot the lack of discoverability and
connectivity between the DirectAccess server and Active Directory.
Similarly, use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it
has access to a domain controller. If there are no domain controllers listed, ensure that the IPv6-
capable domain controllers that are being used by DirectAccess clients are using site-less locator
records in DNS.
To perform detailed IPsec negotiation analysis, use IPsec audit events in the Windows
Logs\Security event log and network tracing for DirectAccess. For more information, see Event
Viewer and Network Diagnostics and Tracing.
If 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 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.
279
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.
280
To troubleshoot why a DirectAccess client cannot resolve names with an intranet DNS
server
SymbolicName=ERROR_IPSEC_IKE_STRONG_CRED_AUTHORIZATION_FAILURE. SA
establishment is not authorized because of lack of a PKINIT-based credential of sufficient
strength.
281
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).
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.
282
To troubleshoot why a DirectAccess client cannot connect to an intranet resource
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
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.
283
To
5.determine
From the the IPv6 addresses
Command that anuse
Prompt window, intranet resource–q=aaaa
the nslookup registers in DNS
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
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.
284
To troubleshoot why
configure an an intranet
ISATAP addressISATAP host in
procedure does
this not configure an ISATAP address
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
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.
285
To
5.troubleshoot an ISATAP
From the Command router
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
the name isatap unless you remove it from the global query block list. Verify that the
name isatap has been removed from the global query block list. For more information,
see Remove ISATAP from the DNS Global Query Block List.
The next step in troubleshooting ISATAP connectivity is the ISATAP router.
1. On the DirectAccess server acting as the ISATAP router, start a command prompt as
an administrator.
2. From the Command Prompt window, run the reg query
HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters /v
DisabledComponents command.
If the DisabledComponents registry value is present, the command displays its value. If
the DisabledComponents registry value is not present, the command displays ERROR:
The system was unable to find the specified registry key or value.
If DisabledComponents is present and it is not 0, convert it to a binary number. If the first
or third bit from the right in the binary number is 1, DisabledComponents has disabled
ISATAP. You must change the first and third bit from the right to 0 to enable ISATAP.
3. From the Command Prompt window, run the reg query
HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition /v
ISATAP_RouterName command.
This command should display ERROR: The system was unable to find the specified
registry key or value. If it does not, note the value.
4. From the Command Prompt window, run the reg query
HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition /v
ISATAP_State command.
This command should display ERROR: The system was unable to find the specified
registry key or value. If it does not, ensure that the value is set to enabled.
5. From the Command Prompt window, run the netsh interface isatap show state
command.
286
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
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.
287
To verify whether the management server can successfully create the management
tunnel
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.
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.
288
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
2002:WWXX:YYZZ::WWXX:YYZZ, corresponding to the first public IPv4 address
assigned to the Internet interface of the DirectAccess server. For example, if the first
public IPv4 address is 131.107.0.2, the corresponding 6to4 IPv6 address is
2002:836b:2::836b:2 (836b:2 is the colon-hexadecimal notation for 131.107.0.2). The
main mode SA should also have ComputerCert for Auth1 and UserNTLM for Auth2.
9. From the Command Prompt window, run the netsh advfirewall monitor show qmsa
command.
There should be a quick mode SA with the Remote IP Address set to the IPv6 address
2002:WWXX:YYZZ::WWXX:YYZZ, corresponding to the first public IPv4 address
assigned to the Internet interface of the DirectAccess server.
If the DirectAccess client computer cannot establish the main and quick mode SAs for the
management tunnel using the default connection security rules created by the DirectAccess
Setup Wizard, the most likely problem is a certificate authentication failure. For more information,
see the “IKE certificate selection process” and “IKE certificate acceptance process” sections of
Public Key Certificate.
You can view the certificates in the local computer store on the DirectAccess client and server
with the Certificates snap-in
To ensure that the DirectAccess server can access a domain controller to validate the credentials
of the DirectAccess client, run the nltest /dsgetdc: /force command at an elevated command
prompt. If there are no domain controllers listed, troubleshoot the lack of discoverability and
connectivity between the DirectAccess server and Active Directory.
Similarly, use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it
has access to a domain controller. If there are no domain controllers listed, ensure that the IPv6-
capable domain controllers that are being used by DirectAccess clients are using site-less locator
records in DNS.
To perform detailed IPsec negotiation analysis, use IPsec audit events in the Windows
Logs\Security event log and network tracing for DirectAccess. For more information, see Event
Viewer and Network Diagnostics and Tracing.
If you have configured DirectAccess for the end-to-end access model, verify that the
management server has been configured with compatible connection security rules to use
transport mode IPsec when initiating communication with DirectAccess clients.
289
To verify whether the DirectAccess client can successfully create transport mode IPsec
SAs to selected servers
290
To verify whether
selected theare
servers DirectAccess client can
listed in Endpoint successfully
2. This list of IPv6 create transport
addresses mode IPsec
was configured
SAsbased
to intranet
on theresources
selected server security groups specified in step 4 of the DirectAccess
Setup Wizard.
7. Initiate communication with the selected server. For example, use the appropriate
application or the net view \\SelectedServerName command.
8. From the Command Prompt window, run the netsh advfirewall monitor show mmsa
command.
There should be a main mode SA with the Remote IP Address set to the IPv6 address of
the selected server. The main mode SA should also have ComputerCert or
ComputerKerb for Auth1 and UserKerb for Auth2.
9. From the Command Prompt window, run the netsh advfirewall monitor show qmsa
command.
There should be a quick mode SA with the Remote IP Address set to the IPv6 address
of the selected server.
If the DirectAccess client computer cannot establish the main and quick mode SAs to the
selected server using the default connection security rules created by the DirectAccess Setup
Wizard, the most likely problem is the lack of corresponding connection security rules on the
selected server. Verify that a rule named DirectAccess Policy-appServerToClient appears in
the Connection Security Rules and Monitoring\Connection Security Rules nodes in the
console tree of the Windows Firewall with Advanced Security snap-in on the selected server.
291
Monitoring\Connection Security Rules.
In the details pane, you should see a list of connection security rules that begin with
DirectAccess Policy, including a rule named DirectAccess Policy-clientToAppServer.
5. If you do not see this rule, from the Command Prompt window, run the netsh advfirewall
monitor show currentprofile command.
This command displays the attached networks and their determined firewall profiles.
None of your networks should be in the domain profile. If any of your networks has been
assigned the domain profile, determine if you have an active remote access virtual
private network (VPN) connection or a domain controller that is available on the Internet.
6. Initiate communication with an intranet server. For example, use an appropriate client
application or the net view \\IntranetServer command.
7. From the Command Prompt window, run the netsh advfirewall monitor show mmsa
command.
There should be a main mode SA with the Remote IP Address set to the IPv6 address of
the intranet server. The main mode SA should also have ComputerCert or
ComputerKerb for Auth1 and UserKerb for Auth2.
8. From the Command Prompt window, run the netsh advfirewall monitor show qmsa
command.
There should be a quick mode SA with the Remote IP Address set to the IPv6 address
of the intranet server.
If the DirectAccess client computer cannot establish the main and quick mode SAs to intranet
server using the modified connection security rules, the most likely problem is the lack of
corresponding connection security rules on intranet servers. Verify that a rule named
DirectAccess Policy-appServerToClient appears in the Connection Security Rules and
Monitoring\Connection Security Rules nodes in the console tree of the Windows Firewall with
Advanced Security snap-in on your intranet servers.
292
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:
DirectAccess Client Determines that it is on the Intranet When on the Internet
DirectAccess Client Determines that it is on the Internet When on the Intranet
Internet browser to access the network location URL. If you can resolve the name and access
the URL, remove the Internet DNS records for the FQDN or remove the network location
server from the Internet. If the DirectAccess server is acting as the network location server,
ensure that the IP and Domain Restrictions role service is installed for the Web server (IIS)
role to prevent DirectAccess clients on the Internet from reaching the network location URL
on the DirectAccess server.
For more information about the technical details of the network location detection process, see
Network Location Detection.
294
Note
To troubleshoot why a DirectAccess client on the intranet cannot successfully access
5. In thethe
console tree,location
network open Application
URL 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.
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.
295
To test access to the CRL distribution points of the network location certificate from a
DirectAccess client on the intranet
1. On the network location server, obtain the CRL distribution points—the Hypertext
Transfer Protocol (HTTP) URL without the file name or the universal naming convention
(UNC) path without the file name—from the CRL Distribution Points field of the certificate
being used for HTTPS-based connections. If the network location server is running
Windows, use the Certificates snap-in for the local computer store and view the Details
tab for the properties of the HTTPS (Secure Sockets Layer [SSL]) certificate.
2. On the DirectAccess client, start a command prompt as an administrator.
3. From the Command Prompt window, ping the FQDNs from the URLs or UNC paths for
the CRL distribution points obtained in step 1.
This step ensures that the DirectAccess client can resolve the names of the CRL
distribution point locations and reach the resolved addresses.
4. For a URL-based CRL distribution point, paste it into your Internet browser. You should
see a series of files with the .crl extension. Ensure that you can open all of the .crl files.
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.
296
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
DirectAccess client must be able to determine when it is connected to the intranet. This is known
as network location detection.
297
Notes
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.
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.
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. 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.
8. From the Command Prompt window, run the netsh dnsclient show state command.
Notice that the Machine Location field states Inside corporate network.
9. Run the netsh namespace show effectivepolicy command.
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.
298
Network location detection failures and their
consequences
There 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
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
DirectAccess server.
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
the DirectAccess server.
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.
299
300