Beruflich Dokumente
Kultur Dokumente
Microsoft Corporation Published: October 2009 Author: Joe Davies Editor: Scott Somahano
Abstract
This document contains both the Design Guide and the Deployment Guide for DirectAccess in Windows Server 2008 R2. These guides help you to design and deploy DirectAccess servers, DirectAccess clients, and infrastructure servers on your intranet. Use the Design Guide to answer the What, Why, and When questions a deployment design team might ask before deploying DirectAccess in a production environment. Use the Deployment Guide to answer the How questions a deployment team might ask when implementing a DirectAccess design. If you are using DirectAccess in Microsoft Forefront Unified Access Gateway (UAG), see the Forefront UAG Design Guide and the Forefront UAG Deployment Guide.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. The DirectAccess Design and Deployment Guides are for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Server, Windows Vista, and Active Directory are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Contents
DirectAccess for Windows Server 2008 R2..............................................................................1 Design and Deployment Guides...............................................................................................1 Abstract.................................................................................................................................1 Contents..........................................................................................................................................3 DirectAccess Design Guide..........................................................................................................12 About this guide.........................................................................................................................12 Understanding the DirectAccess Design Process.........................................................................13 Identifying Your DirectAccess Deployment Goals.........................................................................13 Transparent and Automatic Remote Access for DirectAccess Clients..........................................14 Ongoing Management of Remote DirectAccess Clients...............................................................15 Efficient Routing of Intranet and Internet Traffic............................................................................15 Reduction of Remote Access-based Servers in your Edge Network.............................................16 End-to-end Traffic Protection........................................................................................................16 Multi-factor Credentials for Intranet Access...................................................................................16 Mapping Your Deployment Goals to a DirectAccess Design.........................................................16 Evaluating DirectAccess Design Examples...................................................................................17 Full Intranet Access Example........................................................................................................17 Full Intranet Access with Smart Cards Example...........................................................................18 Selected Server Access Example.................................................................................................19 Using authentication with null encapsulation for selected server access...................................20 End-to-end Access Example.........................................................................................................21 Planning a DirectAccess Deployment Strategy.............................................................................21 Resources Available to DirectAccess Clients................................................................................23 IPv6 resources on your intranet.................................................................................................23 IPv4-only resources on the intranet...........................................................................................24 Limiting connectivity to selected resources................................................................................24 IPv6 resources on the IPv6 Internet...........................................................................................25
Choose an Intranet IPv6 Connectivity Design...............................................................................25 No existing IPv6 infrastructure...................................................................................................26 Existing ISATAP infrastructure...................................................................................................27 Existing native IPv6 infrastructure..............................................................................................27 Choose Solutions for IPv4-only Intranet Resources......................................................................28 Choose an Access Model..............................................................................................................30 Full Intranet Access.......................................................................................................................30 Selected Server Access................................................................................................................31 End-to-End Access.......................................................................................................................31 Choose a Configuration Method...................................................................................................32 DirectAccess Management Console..........................................................................................32 Custom configuration using the Network Shell (Netsh) command-line tool and Group Policy...33 Design for Remote Management..................................................................................................33 Design Packet Filtering for DirectAccess......................................................................................34 Packet Filters for Your Internet Firewall.........................................................................................35 Packet Filters for Your Intranet Firewall.........................................................................................36 Confining ICMPv6 Traffic to the Intranet.......................................................................................36 Packet filters for Teredo Connectivity............................................................................................38 Packet filters to allow inbound ICMPv6 Echo Requests on all computers.................................38 Enable edge traversal on inbound management traffic..............................................................38 Enable inbound ICMPv6 Echo Requests for management traffic..............................................39 Packet Filters for Management Computers...................................................................................39 DirectAccess and Third-party Host Firewalls................................................................................40 Choose an Authentication and Authorization Scheme..................................................................41 Additional end-to-end peer authentication for selected server access.......................................41 Peer authentication for end-to-end access................................................................................42 Smart cards for additional authorization....................................................................................42 Allowing access for users with unusable smart cards............................................................42 Prompts for smart card credentials while on the intranet........................................................43 Under the covers: Smart card authorization...........................................................................43 Design Addressing and Routing for the DirectAccess Server.......................................................44 IPv4 address and routing configuration.....................................................................................44 IPv6 address and routing configuration.....................................................................................45
Design Active Directory for DirectAccess......................................................................................46 Active Directory and the DirectAccess server............................................................................47 DirectAccess and user profiles for remote users.......................................................................47 Design Your DNS Infrastructure for DirectAccess.........................................................................47 Split-brain DNS..........................................................................................................................48 DNS server requirements for ISATAP........................................................................................49 AAAA records for servers that do not perform DNS dynamic update.........................................49 Local name resolution behavior for DirectAccess clients...........................................................49 NRPT rules................................................................................................................................50 Unqualified, single-label names and DNS search suffixes.........................................................51 External DNS.............................................................................................................................52 Design Your PKI for DirectAccess.................................................................................................52 Autoenrollment for computer certificates...................................................................................52 Manual enrollment for network location server and IP-HTTPS certificates................................53 Certificate revocation checking and CRL distribution points......................................................53 Enabling strong CRL checking for IPsec authentication............................................................54 Smart cards for additional authorization....................................................................................55 Design Your Web Servers for DirectAccess..................................................................................55 Choose an Internet Traffic Separation Design..............................................................................56 Design Protection for Traffic between DirectAccess Clients..........................................................58 Design Your Intranet for Corporate Connectivity Detection...........................................................60 Choose a DirectAccess and VPN Coexistence Design.................................................................61 DirectAccess and third-party VPN clients..................................................................................62 Planning the Placement of a DirectAccess Server........................................................................63 When to Install a DirectAccess Server..........................................................................................63 Where to Place the DirectAccess Server......................................................................................63 Planning Redundancy for a DirectAccess Server.........................................................................64 Planning the Placement of a Network Location Server.................................................................65 Where to Place the Network Location Server...............................................................................66 Highly available intranet Web server as the network location server.........................................66 DirectAccess server as the network location server..................................................................67 Planning Redundancy for a Network Location Server...................................................................68 Planning the Placement of CRL Distribution Points......................................................................68
Where to Place the CRL Distribution Points..................................................................................68 Intranet location for intranet detection........................................................................................68 Internet location for IP-HTTPS connections...............................................................................69 Planning Redundancy for CRL Distribution Points........................................................................69 Planning DirectAccess with Network Access Protection (NAP).....................................................69 Configuration changes for the infrastructure tunnel...................................................................70 Configuration changes for the intranet tunnel............................................................................71 Planning DirectAccess with an Existing Server and Domain Isolation Deployment......................72 Planning DirectAccess with Microsoft Forefront Threat Management Gateway............................72 DirectAccess Capacity Planning...................................................................................................73 Capacity Planning for DirectAccess Servers.................................................................................73 Increasing the number of concurrent authentications................................................................73 Moving the IPsec gateway function to a separate server...........................................................74 Using DirectAccess with UAG...................................................................................................76 Capacity Planning for Network Location Servers..........................................................................76 Capacity Planning for CRL Distribution Points..............................................................................76 Additional DirectAccess Resources..............................................................................................76 Appendix A: DirectAccess Requirements......................................................................................77 Appendix B: Reviewing Key DirectAccess Concepts....................................................................78 IPv6...........................................................................................................................................79 IPv6 connectivity across the IPv4 Internet..............................................................................79 6to4.....................................................................................................................................79 Teredo.................................................................................................................................79 IP-HTTPS............................................................................................................................79 IPv6 connectivity across an IPv4-only intranet.......................................................................80 IPsec..........................................................................................................................................80 Encryption..............................................................................................................................81 Data integrity..........................................................................................................................81 Separation of DNS traffic...........................................................................................................82 NRPT exemptions..................................................................................................................82 Network location servers...........................................................................................................83 How intranet detection works.................................................................................................83 Appendix C: Documenting Your DirectAccess Design..................................................................84 Concepts...................................................................................................................................84 Goals.........................................................................................................................................84 Infrastructure design plan..........................................................................................................84
Custom configuration plan.........................................................................................................85 Integration strategy....................................................................................................................85 Staging strategy.........................................................................................................................85 Lessons learned........................................................................................................................86 DirectAccess Deployment Guide..................................................................................................86 About this guide.........................................................................................................................86 Planning Your DirectAccess Deployment......................................................................................87 Reviewing your DirectAccess design.........................................................................................87 Reviewing DirectAccess concepts.............................................................................................88 Implementing Your DirectAccess Design Plan..............................................................................88 How to implement your DirectAccess design using this guide...................................................88 Checklist: Staging a DirectAccess Deployment............................................................................90 Checklist: Preparing Your Infrastructure for DirectAccess.............................................................91 Checklist: Preparing Your DirectAccess Server............................................................................93 Checklist: Implementing a DirectAccess Design for Full Intranet Access......................................95 Checklist: Implementing a DirectAccess Design for Selected Server Access...............................97 Checklist: Implementing a DirectAccess Design for End-to-End Access.......................................98 Checklist: Implementing a Redundant DirectAccess Design.......................................................100 Checklist: Configuring Network Access Protection (NAP) with DirectAccess..............................101 Procedures Used in this Guide...................................................................................................102 Configure a CRL Distribution Point for Certificates.....................................................................103 Configure a Custom Certificate Template....................................................................................105 Configure Active Directory Certificate Services for CRL Locations.............................................106 Configure Client Authentication and Certificate Mapping for IP-HTTPS Connections.................107 Configure Computer Certificate Autoenrollment..........................................................................108 Configure Connection Security Rules for End-to-end Access.....................................................109 Configure Connection Security Rules for Traffic Between DirectAccess Clients.........................111 Configure Corporate Connectivity Detection Settings.................................................................112 Configure DirectAccess Connection Security Rules for NAP......................................................113 Configure Force Tunneling..........................................................................................................115
Configure IIS for Network Location..............................................................................................116 Configure Packet Filters to Allow ICMP Traffic............................................................................117 Configure Packet Filters to Allow Management Traffic to DirectAccess Clients...........................118 Configure Packet Filters to Block Access to Domain Controllers................................................120 Configure Settings to Confine ICMPv6 Traffic to the Intranet......................................................121 Configure Strong Certificate Revocation Checking for IPsec Authentication...............................122 Configure the DirectAccess Server as the Network Location Server..........................................123 Configure the DirectAccess Setup Wizard for End-to-End Access..............................................124 Configure the DirectAccess Setup Wizard for Full Intranet Access.............................................126 Configure the DirectAccess Setup Wizard for Selected Server Access......................................127 Configure the NRPT for an IPv6/IPv4 DNS Gateway..................................................................129 Configure the NRPT with Group Policy.......................................................................................130 Connect to the IPv6 Internet.......................................................................................................131 Create DirectAccess Groups in Active Directory.........................................................................132 Install a Network Location Server Certificate on the DirectAccess Server..................................133 Install an IP-HTTPS Certificate...................................................................................................134 Install and Configure IIS for a Network Location Server Certificate............................................135 Install the DirectAccess Feature.................................................................................................136 Remove ISATAP from the DNS Global Query Block List.............................................................137 Appendix A Manual DirectAccess Server Configuration...........................................................137 Configure Internet access components...................................................................................138 Configure intranet access components....................................................................................139 Configure IPsec DoSP.............................................................................................................139 Configure connection security rules.........................................................................................140 DirectAccess server configuration (full intranet access model)............................................140 Connection security rules for client configuration (full intranet access model).....................141 Appendix B Manual DirectAccess Client Configuration............................................................141 IPv6 transition technology settings..........................................................................................142 NRPT.......................................................................................................................................143 Appendix C - DirectAccess User Interface Scripting...................................................................143
Script usage.............................................................................................................................144 Log file.....................................................................................................................................144 Limitation of the script..............................................................................................................145 Appendix D - DirectAccessConfig.xsd........................................................................................145 DirectAccess Troubleshooting Guide..........................................................................................159 In this guide.............................................................................................................................159 Introduction to Troubleshooting DirectAccess.............................................................................160 When to use this guide............................................................................................................160 How to use this guide..............................................................................................................160 A-Z List of Problem Topics for DirectAccess...............................................................................160 Tools for Troubleshooting DirectAccess......................................................................................161 Network Diagnostics and Tracing................................................................................................161 Windows Network Diagnostics................................................................................................161 Troubleshooting item in Control Panel.....................................................................................162 Network tracing for DirectAccess.............................................................................................162 Windows Firewall tracing.........................................................................................................163 Command Line Tools..................................................................................................................163 The Netsh.exe Command Line Tool............................................................................................164 netsh namespace show effectivepolicy and netsh namespace show policy............................164 netsh interface 6to4 show relay...............................................................................................166 netsh interface teredo show state............................................................................................166 netsh interface httpstunnel show interfaces.............................................................................167 netsh interface istatap show state and netsh interface istatap show router.............................168 netsh advfirewall monitor show mmsa.....................................................................................169 netsh advfirewall monitor show qmsa......................................................................................173 netsh advfirewall monitor show consec rule name=all.............................................................176 netsh advfirewall monitor show currentprofile..........................................................................180 netsh interface ipv6 show interfaces........................................................................................180 netsh interface ipv6 show interfaces level=verbose.................................................................181 netsh interface ipv6 show route...............................................................................................188 The Ping.exe Command Line Tool..............................................................................................190 The Nslookup.exe Command Line Tool......................................................................................190 The Ipconfig.exe Command Line Tool.........................................................................................191 The Certutil.exe Command Line Tool..........................................................................................194 The Nltest.exe Command Line Tool............................................................................................195
Snap-in Tools..............................................................................................................................195 DirectAccess Management.........................................................................................................196 Log files of the DirectAccess Management snap-in.................................................................196 Group Policy Management Console and Editor..........................................................................196 NRPT rules..............................................................................................................................197 IPv6 Transition Technologies settings......................................................................................197 Intranet connectivity settings...................................................................................................198 Connection security rules........................................................................................................199 Windows Firewall with Advanced Security..................................................................................200 Event Viewer...............................................................................................................................200 Certificates..................................................................................................................................201 General Methodology for Troubleshooting DirectAccess Connections.......................................201 Troubleshooting DirectAccess Problems....................................................................................207 Problems with the DirectAccess Setup Wizard...........................................................................207 Fixing problems that Prevent You from Running the DirectAccess Setup Wizard.......................207 Fixing Problems Encountered during the Steps of the DirectAccess Setup Wizard....................209 Step 2-DirectAccess Server.....................................................................................................209 Connectivity page.................................................................................................................209 Prefix Configuration page.....................................................................................................211 Certificate Components page...............................................................................................212 Step 3-Infrastructure Servers...................................................................................................213 Location page.......................................................................................................................213 DNS and Domain Controller page........................................................................................214 Step 4-Application Servers......................................................................................................214 Fixing Problems Encountered when Applying the Settings of the DirectAccess Setup Wizard...215 Problems with DirectAccess Connections...................................................................................216 Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server over the Internet....................................................................................................................................216 Cannot Reach the DirectAccess Server from the IPv6 Internet..................................................216 Cannot Reach the DirectAccess Server with 6to4......................................................................218 Cannot Reach the DirectAccess Server with Teredo...................................................................221 Cannot Reach the DirectAccess Server with IP-HTTPS.............................................................225 IP-HTTPS and authenticating proxies......................................................................................228
DirectAccess Client Connection is Slow......................................................................................228 Fixing Issues with Creating Protected Connections to the DirectAccess Server.........................229 DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server................................230 IPsec and certificate revocation checking................................................................................233 NAP health enforcement for the intranet tunnel.......................................................................234 Smart card authorization..........................................................................................................234 NTLM authentication failures...................................................................................................234 Detailed analysis of IPsec negotiation.....................................................................................235 DirectAccess Client Cannot Resolve Names with Intranet DNS Servers....................................235 Fixing Issues with Connecting to an Intranet Resource..............................................................236 DirectAccess Client Cannot Access Intranet Resources.............................................................236 Intranet Management Server Cannot Connect to a DirectAccess Client.....................................241 Fixing Problems with Creating Protected Connections to an Intranet Resource.........................244 Selected server access model.................................................................................................244 End-to-end access model........................................................................................................245 Fixing Issues with Intranet Detection..........................................................................................246 DirectAccess Client Determines that it is on the Intranet When on the Internet..........................247 DirectAccess Client Determines that it is on the Internet When on the Intranet..........................248
12
This guide, combined with the DirectAccess Deployment Guide, is also available as a Microsoft Word file (http://go.microsoft.com/fwlink/?LinkId=163662) in the Microsoft Download Center.
After you identify your deployment goals and map them to a DirectAccess design, you can begin documenting your design, based on the processes that are described in the following topics: Planning a DirectAccess Deployment Strategy Planning the Placement of a DirectAccess Server Planning the Placement of a Network Location Server Planning the Placement of CRL Distribution Points Planning DirectAccess with Network Access Protection (NAP) Planning DirectAccess with an Existing Server and Domain Isolation Deployment DirectAccess Capacity Planning Additional DirectAccess Resources Appendix A: DirectAccess Requirements Appendix B: Reviewing Key DirectAccess Concepts
vision statement. Make sure that the members of this team understand the direction in which your deployment project must move in order to reach your DirectAccess deployment goals. When you write your vision statement, take steps to identify, clarify, and refine your deployment goals. Prioritize and, if necessary, combine your deployment goals so that you can design and deploy DirectAccess by using an iterative approach. You can take advantage of existing, documented, and predefined DirectAccess deployment goals that are relevant to the DirectAccess designs and develop a working solution for your scenarios. The following table lists the three main tasks for articulating, refining, and documenting your DirectAccess deployment goals.
Deployment goal tasks Reference links
Evaluate predefined DirectAccess deployment goals that are provided in this section of the guide and combine one or more goals to reach your organizational objectives.
Transparent and Automatic Remote Access for DirectAccess Clients Ongoing Management of Remote DirectAccess Clients Efficient Routing of Intranet and Internet Traffic Reduction of Remote Access-based Servers in your Edge Network End-to-end Traffic Protection Multi-factor Credentials for Intranet Access
Map one goal or a combination of any of the predefined DirectAccess deployment goals to a DirectAccess design. Document your deployment goals and other important details for your DirectAccess design.
Mapping Your Deployment Goals to a DirectAccess Design Appendix C: Documenting Your DirectAccess Design
14
15
The following table shows how well the DirectAccess designs meet the deployment goals discussed in Identifying Your DirectAccess Deployment Goals.
DirectAccess deployment goal DirectAccess elements or features
Transparent and automatic remote access for DirectAccess clients Ongoing management of remote DirectAccess clients Efficient routing of intranet and Internet traffic
Functionality in the DirectAccess server and clients Bidirectional connections whenever the computer is connected to the Internet Use of the Name Resolution Policy Table (NRPT) and Internet Protocol version 6 (IPv6) to separate Internet and intranet traffic Access to intranet resources through the DirectAccess server The selected server and end-to-end access models Smart card authorization on the intranet tunnel
Reduction of remote access-based servers in your edge network End-to-end traffic protection Multi-factor credentials for intranet access
You can use these examples to determine the design or combination of designs that best suits the needs of your organization.
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.
18
When a user on the DirectAccess client logs on to their computer with the smart card, they obtain transparent access to intranet resources. If they log in to the computer using domain credentials, such as a username and password combination, and attempt to access the intranet, Windows displays a message in the notification area instructing them to enter their smart card credentials. The user then inserts their smart card and provides their smart card personal identifier (PIN) to access intranet resources. This notification message will fade away in five seconds or may be covered by other notifications in a shorter amount of time, but an icon displaying a pair of keys will stay in the notification area. If the user misses the notification, the keys icon will be available in the overflow tray, which will allow them to launch the credential prompt again by clicking on it. Note If the user closes the smart card credential prompt from the notification area, there is no way of relaunching it, nor will the keys show up in the overflow tray again. The user must lock their computer and then unlock it with their smart card to access the intranet.
19
The DirectAccess client and selected servers by default perform IPsec peer authentication using computer credentials and protect the traffic with Encapsulating Security Protocol (ESP)-NULL for data integrity. You can also use selected server access to require end-to-end IPsec protection from the DirectAccess client to specified servers and allow access to all other locations on the intranet. Traffic to other intranet application servers is not protected with IPsec peer authentication and data integrity. The intranet tunnel between the DirectAccess client and server provides encryption for both types of intranet traffic across the Internet.
20
The DirectAccess client and intranet application servers should be configured to perform IPsec peer authentication using computer credentials and to protect the traffic with Encapsulating Security Protocol (ESP) for data confidentiality (encryption) and integrity.
21
What options do I have to make Internet Protocol version 4 (IPv4)-only resources available for DirectAccess clients? For more information, see Choose Solutions for IPv4-only Intranet Resources. Which access models are there to choose from? For more information, see Choose an Access Model. What options do I have to configure DirectAccess? For more information, see Choose a Configuration Method. Which computers do I need to designate as management servers that will initiate connections to DirectAccess clients? For more information, see Design for Remote Management. What packet filters do I need to add to my firewalls and computers in my organization? For more information, see Design Packet Filtering for DirectAccess. What packet filters do I need to add to my firewalls and computers in my organization? For more information, see Design Packet Filtering for DirectAccess. What support is needed from third-party host firewalls? For more information, see DirectAccess and Third-party Host Firewalls. What authentication and authorization options do I have? For more information, see Choose an Authentication and Authorization Scheme. What addressing and routing do I need to configure on my DirectAccess server? For more information, see Design Addressing and Routing for the DirectAccess Server. How does DirectAccess leverage or utilize Active Directory Domain Services (AD DS)? For more information, see Choose an Authentication and Authorization Scheme. How do I design my Domain Name System (DNS) infrastructure for DirectAccess? For more information, see Design Your DNS Infrastructure for DirectAccess. How do I design my public key infrastructure (PKI) for DirectAccess? For more information, see Design Your PKI for DirectAccess. How do I design my internal and external Web infrastructure for DirectAccess? For more information, see Design Your Web Servers for DirectAccess. What options are there for separating or combining intranet and Internet traffic for DirectAccess clients? For more information, see Choose an Internet Traffic Separation Design. How do I ensure that traffic between DirectAccess clients on the Internet is protected? For more information, see Design Protection for Traffic between DirectAccess Clients. How do I ensure that DirectAccess clients can detect connectivity to the intranet? For more information, see Design Your Intranet for Corporate Connectivity Detection. How does DirectAccess co-exist with my current remote access virtual private network (VPN) solution? For more information, see Choose a DirectAccess and VPN Coexistence Design.
22
23
XP and Windows Server 2003 have an IPv6 protocol stack, but many built-in system services and applications for these operating systems are not IPv6-capable. For applications running on non-Windows operating systems, verify that both the operating system and the applications support IPv6 and are reachable over native IPv6 or ISATAP.
25
The default IPv6 route ensures that intranet ISATAP hosts can reach DirectAccess clients. When your Windows-based ISATAP hosts obtain an ISATAP-based IPv6 address, they begin to use ISATAP-encapsulated traffic to communicate if the destination is also an ISATAP host. Because ISATAP uses a single 64-bit subnet for your entire intranet, your communication goes from a segmented, multi-subnet Internet Protocol version 4 (IPv4) communication model to a flat, single-subnet communication model with IPv6. This can affect the behavior of Active Directory Domain Services (AD DS) and other applications that rely on your Active Directory Sites and Services configuration. For example, if you used the Active Directory Sites and Services snap-in to configure sites, IPv4-based subnets, and inter-site transports for forwarding of requests to servers within sites, this configuration is not used by ISATAP hosts. To configure Active Directory sites and services for forwarding within sites for ISATAP hosts, you have to configure an IPv6 subnet object equivalent to each IPv4 subnet object, in which the IPv6 address prefix for the subnet expresses the same range of ISATAP host addresses as the IPv4 subnet. For example, for the IPv4 subnet 192.168.99.0/24 and the 64-bit ISATAP address prefix 2002:836b:1:0:1::/64, the equivalent IPv6 address prefix for the IPv6 subnet object is 2002:836b:1:1:0:5efe:192.168.99.0/120. For an arbitrary IPv4 prefix length (set to 24 in the example), the corresponding IPv6 prefix length is 96 + IPv4PrefixLength. For the IPv6 addresses of DirectAccess clients, you should add the following: An IPv6 subnet for the range 2001:0:WWXX:YYZZ::/64, in which WWXX:YYZZ is the colon-hexadecimal version of the first consecutive public IPv4 address (w.x.y.z) assigned to
26
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 48bitIntranetPrefix: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/ipv4address-space/ipv4-address-space.xml). These IPv6 prefixes are for 6to4-based DirectAccess clients.
Note If you are using IPv6 addresses that are not based on a 6to4 prefix on your intranet, a 6to4-based DirectAccess client computer that uses IP-HTTPS to connect to the DirectAccess server will not be able to reach intranet locations. To correct this condition, add a 6to4 route (2002::/16) to your intranet that points to the DirectAccess server or reconfigure the DirectAccess server to use IPv6 addresses from your intranet prefix on its Internet interface rather than 6to4 addresses and change the client and server tunnel endpoints in your DirectAccess client and server Group Policy objects to the assigned IPv6 address.
DNS-ALG is based on older Internet standards. NAT64 with DNS64 are based on new Internet drafts that are in the Internet standards process. The types of DirectAccess connectivity that are possible for IPv6-capable and IPv4-only client and server applications are summarized in the following: IPv6-capable client application on the DirectAccess client with an IPv6-capable server application on the intranet End-to-end connectivity for DirectAccess clients. IPv6-capable client application on the DirectAccess client with an IPv4-only server application on the intranet Translated connectivity for DirectAccess clients only with an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway. IPv4-only client application on the DirectAccess client with either an IPv6-capable or IPv4-only server application on the intranet No connectivity for DirectAccess clients. When you deploy an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway, you typically configure it to provide coverage for specific portions of your intranet DNS namespace. Once deployed, the IPv6/IPv4 translator and IPv6/IPv4 DNS gateway will make the necessary DNS resolutions and IPv6/IPv4 traffic translations, allowing IPv6-capable applications on DirectAccess clients to access IPv4-only resources located within that portion of the DNS namespace. The following figure shows an example of using a separate NAT-PT or NAT64 device to provide IPv6/IPv4 traffic translation and access to IPv4-only application servers on an intranet.
If you are using an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway in your DirectAccess deployment, you must identify the portions of your intranet namespace that contain IPv4-only application servers and add them to the Name Resolution Policy Table (NRPT) of your DirectAccess clients with the IPv6 addresses of your IPv6/IPv4 DNS gateway. For more information, see Configure the NRPT for an IPv6/IPv4 DNS Gateway in the DirectAccess Deployment Guide.
29
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.
The following topics describe the benefits and limitations of these access models.
The following are the limitations of the full intranet access model: Because the DirectAccess server is terminating the IPsec tunnels, there is extra processing load on DirectAccess server to perform encryption and decryption. This load can be mitigated by moving the IPsec gateway function to a different server with IPsec offload network adapters. For more information, see Capacity Planning for DirectAccess Servers.
30
By customizing the default Windows Firewall with Advanced Security connection security rules created by the DirectAccess Setup Wizard, you can restrict certain users or computers from accessing particular application servers or specify that certain client applications will not be able to access intranet resources remotely. However, customization of connection security rules requires knowledge of and experience with connection security rule design and configuration. The following are the limitations of the selected server access model: Selected servers must run Windows Server 2008 or later. Selected servers cannot run Windows Server 2003 or earlier. Selected servers when using IPsec peer authentication without IPsec protection must be running Windows Server 2008 R2 or later.
End-to-End Access
The end-to-end access model allows you to configure DirectAccess clients so that communications between DirectAccess clients and all intranet servers perform IPsec peer
31
authentication, data confidentiality (encryption), and data integrity from the DirectAccess client to the intranet resource. The traffic sent between DirectAccess clients and servers is encrypted over both the Internet and the intranet. For more information, see the End-to-end Access Example. The following are the benefits of the end-to-end access model: Provides additional end-to-end authentication, data integrity, and data confidentiality beyond that provided with traditional virtual private network (VPN) connections. There is less processing overhead on the DirectAccess server, which is acting only as a router and providing denial of service protection (DoSP) for the IPsec-encrypted DirectAccess traffic. By customizing the default Windows Firewall with Advanced Security connection security rules created by the DirectAccess Setup Wizard, you can define policies that restrict certain users or computers from accessing particular application servers or specify that certain applications will not be able to access intranet resources remotely. However, customization of the default connection security rules requires knowledge of and experience with connection security rule design and configuration. The following are the limitations of the end-to-end access model: All intranet application servers accessible to DirectAccess clients must run Windows Server 2008 or later. Application servers cannot run Windows Server 2003 or earlier. Your intranet must allow the forwarding of IPsec-encrypted traffic. Is not fully configurable with the DirectAccess Setup Wizard. You use the DirectAccess Setup Wizard to create the initial set of DirectAccess client and server Group Policy objects and settings and then you must customize the default Windows Firewall with Advanced Security connection security rules. Cannot use smart cards for an additional level of authorization. Cannot access IPv4-only intranet resources, even with an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway.
32
DirectAccess deployment should proceed, and before the changes are applied, you have the option of saving the settings into an Extensible Markup Language (XML) file. The XML file can be modified and provides a way to examine which options are being set. You can also use the engine.ps1 PowerShell script to run the XML file. For more information, see Appendix C - DirectAccess User Interface Scripting in the DirectAccess Deployment Guide and Perform DirectAccess Scripting (http://go.microsoft.com/fwlink/?LinkID=157388).
Custom configuration using the Network Shell (Netsh) command-line tool and Group Policy
For customized DirectAccess deployments that need to be modified from the default settings of the DirectAccess Setup Wizard to meet a unique set of needs, you can use Network Shell (Netsh) commands and Group Policy settings for the Group Policy objects for DirectAccess clients, DirectAccess servers, and selected servers. Custom configuration allows for maximum flexibility and the creation of unique solutions, including many permutations that are not covered in this Design Guide. For information about Netsh commands for DirectAccess, see Appendix A Manual DirectAccess Server Configuration and Appendix B Manual DirectAccess Client Configuration. For information about Group Policy settings for DirectAccess, see Group Policy Management Console and Editor.
In some cases, intranet servers or computers must initiate connections to DirectAccess clients. For example, helpdesk department computers can use remote desktop connections to connect to and troubleshoot remote DirectAccess clients. To ensure that DirectAccess clients will accept incoming traffic from these types of computers and require the protection of that traffic over the Internet, you must identify the set of these intranet management computers and configure their addresses in Step 3 of the DirectAccess Setup Wizard. Once you have identified the computers, record their names, their Internet Protocol version 4 (IPv4) addresses (if you have no Internet Protocol version 6 (IPv6) infrastructure), or their IPv6 addresses (if you have an IPv6 infrastructure, either their public native or Intra-Site Automatic
33
Tunnel Addressing Protocol [ISATAP] addresses) and configure them in Step 3 of the DirectAccess Setup Wizard. The DirectAccess Setup Wizard creates an additional set of connection security rules for a management tunnel between DirectAccess clients and the DirectAccess server. This management tunnel is encrypted with Internet Protocol security (IPsec), uses computer credentials for authentication, and is separate from the intranet and infrastructure tunnels in the full intranet and selected server access models. Because DirectAccess clients can be behind network address translators (NATs) and use Teredo for the IPv6 connectivity across the Internet, any inbound rules for Windows Firewall with Advanced Security that permit unsolicited incoming traffic from management computers must be modified to enable edge traversal and must have an inbound ICMPv6 Echo Request rule with edge traversal enabled. For more information, see Packet Filters for Management Computers Note When you are using end-to-end peer authentication with data integrity and remote management traffic is sent within the intranet tunnel, you should use Encapsulating Security Protocol (ESP)-Null instead of Authentication Header (AH) for data integrity. Note If the computer that is managing a DirectAccess client from the intranet is running Windows Vista or Windows Server 2008 and IPsec transport mode is required between the managing computer and the DirectAccess client, both computers must have the same quick mode lifetimes.
Teredo discovery traffic for DirectAccess clients located behind network address translators (NATs) Management server traffic to DirectAccess clients Packet Filters for Your Internet Firewall Packet Filters for Your Intranet Firewall Confining ICMPv6 Traffic to the Intranet Packet filters for Teredo Connectivity Packet Filters for Management Computers
34
The following topics describe the required packet filtering for each of these types of traffic:
35
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
intranet destination IPv6 addresses. The amount of this traffic is limited by the Denial of Service Protection (DoSP) component of the DirectAccess server. A malicious user on the same subnet as a Teredo-based DirectAccess client can determine the IPv6 addresses of intranet servers by capturing ICMPv6 Echo Request and Echo Reply message exchanges. To prevent these possible security issues, you can modify the default configuration for the following: Configure the global IPsec settings for the Group Policy object for DirectAccess clients to not exempt ICMP traffic from IPsec protection (from the IPsec Settings tab for the properties of the Windows Firewall with Advanced Security snap-in). Configure the global IPsec settings for the Group Policy object for the DirectAccess server to not exempt ICMP traffic from IPsec protection (from the IPsec Settings tab for the properties of the Windows Firewall with Advanced Security snap-in). For the Group Policy object for the DirectAccess server, create a new connection security rule that exempts ICMPv6 traffic when it is tunneled from the DirectAccess server. For the Group Policy object for DirectAccess clients, create a new connection security rule that exempts ICMPv6 traffic when it is tunneled to the DirectAccess server. With these modifications: All ICMPv6 traffic sent through the DirectAccess server must be sent using a tunnel. Only DirectAccess clients can send ICMPv6 traffic to intranet locations. Malicious users on the same subnet as the DirectAccess client will only be able to determine the IPv6 addresses of the DirectAccess client and the DirectAccess server. Intranet IPv6 addresses will be tunneled and encrypted with IPsec. Although these modifications address the security issues of the default configuration, Teredo discovery messages can no longer pass through the DirectAccess server and DirectAccess clients cannot use Teredo as a connectivity method. Therefore, if you make these changes, you must also do the following: Disable Teredo client functionality on your DirectAccess clients From the Group Policy object for DirectAccess clients, set Computer Configuration\Administrative Templates\Networking\TCPIP Settings\IPv6 Transition Technologies\Teredo State to Disabled. Disable Teredo server and relay functionality on your DirectAccess server Type the netsh interface teredo set state state=disabled command from an administratorlevel 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.
37
For more information, see Configure Settings to Confine ICMPv6 Traffic to the Intranet in the DirectAccess Deployment Guide.
38
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. Note If the computer that is managing a DirectAccess client from the intranet is running Windows Vista or Windows Server 2008 and Internet Protocol security (IPsec) transport mode is required between the managing computer and the DirectAccess client, both computers must have the same quick mode lifetimes.
40
For more information, see Enabling Third Party Firewall DirectAccess Clients (http://go.microsoft.com/fwlink/?LinkId=163777). For more information about Windows Firewall categories, see INetFwProduct Interface (http://go.microsoft.com/fwlink/?LinkId=157401). For more information about third-party firewall requirements for Teredo, see Teredo co-existence with third-party firewalls (http://go.microsoft.com/fwlink/?Linkid=157705).
41
Note If you modify the connection security rules created by the DirectAccess Setup Wizard, you must use Network Shell (Netsh) commands. There are connection security rule settings that cannot be modified with the Windows Firewall with Advanced Security snapin. 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.
42
To grant access to a user that cannot use their smart card, temporarily add their user account to the Active Directory security group. Remove the user account from the group when the smart card is usable.
3. Click the Users tab. You should see the NT AUTHORITY\This Organization Certificate as an authorized user. Note If you manually configure this setting with the Users tab, you must specify the name LocalComputerName\This Organization Certificate rather than NT AUTHORITY\This Organization Certificate. To perform the equivalent configuration of the DirectAccess Setup Wizard with the Network Shell (Netsh) command-line tool, use the following commands: netsh advfirewall consec add rule name=Smart card tunnel endpoint1=Intranet IPv6 address space endpoint2=Any localtunnelendpoint=DirectAccess server IPv6 address remotetunnelendpoint=any auth1=Computercert auth1ca=Certificate Auth name certmapping:yes auth2=userkerb applyauthz=yes netsh advfirewall set global ipsec authzusergrp=O:LSD:(A;;CC;;;S-1-5-65-1)
If your intranet is connected to the Internet Protocol version 6 (IPv6) Internet, reachability from the IPv6 Internet for native IPv6 traffic If your intranet has deployed native IPv6 connectivity, reachability from your intranet for native IPv6 traffic The following sections describe the address and routing configuration of the DirectAccess server to support these reachability requirements.
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). Important 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.
Important 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.
command ensures that additional default routes pointing to intranet routers will not be added to the IPv6 routing table. You can obtain the InterfaceIndex of your intranet interfaces from the display of the netsh interface show interface command. Additionally, you must configure a connection-specific DNS suffix of your intranet namespace on the intranet interface. To configure the DirectAccess server to reach all the IPv6 locations on your intranet, do the following: 1. List the IPv6 address spaces for all the locations on your intranet. 2. Use the netsh interface ipv6 add route command to add the IPv6 address spaces as static routes in the IPv6 routing table of the DirectAccess server. Note 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.
You must create and populate these groups before running the DirectAccess Setup Wizard. For more information, see Create DirectAccess Groups in Active Directory in the DirectAccess Deployment Guide. The DirectAccess Setup Wizard creates GPOs for the following: DirectAccess clients that contains settings for Internet Protocol version 6 (IPv6) transition technologies, Name Resolution Policy Table (NRPT) rules, intranet detection settings, and Windows Firewall with Advanced Security connection security rules (required). The DirectAccess server that contains settings for IPv6 transition technologies and Windows Firewall with Advanced Security connection security rules (required). Selected servers that contain settings for Windows Firewall with Advanced Security connection security rules (optional). If you remove a computer from a DirectAccess client or selected server security group, the next update of Group Policy will remove the DirectAccess settings from the computer.
46
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 Contosos public Web site and Contoso employees on the Contoso intranet use http://www.contoso.com to access Contosos intranet Web site. A Contoso employee with their laptop that is not a DirectAccess client on the intranet that accesses http://www.contoso.com sees the intranet Contoso Web site. When they take their laptop to the local coffee shop and access that same URL, they will see the public Contoso Web site. When a DirectAccess client is on the Internet, the Name Resolution Policy Table (NRPT) sends DNS name queries for intranet resources to intranet DNS servers. A typical NRPT for DirectAccess will have a rule for the namespace of the organization, such as contoso.com for the Contoso Corporation, with the Internet Protocol version 6 (IPv6) addresses of intranet DNS servers. With just this rule in the NRPT, when a user on a DirectAccess client on the Internet attempts to access the uniform resource locator (URL) for their Web site (such as http://www.contoso.com), they will see the intranet version. Because of this rule, they will never see the public version of this URL when they are on the Internet. If you want users on DirectAccess clients to see the public version of this URL when they are on the Internet, you must add the fully qualified domain name (FQDN) of the URL as an exemption rule to the NRPT of DirectAccess clients. However, if you add this exemption rule, users on DirectAccess clients will never see the intranet version of this URL when they are on the Internet. For split-brain DNS deployments, you must list the FQDNs that are duplicated on the Internet and intranet and decide which resources the DirectAccess client should reach, the intranet version or the public (Internet) version. For each name that corresponds to a resource for which you want DirectAccess clients to reach the public version, you must add the corresponding FQDN as an exemption rule to the NRPT for your DirectAccess clients. In a split-brain DNS environment, if you want both versions of the resource to be available, configure your intranet resources with alternate names that are not duplicates of the names that are being used on the Internet and instruct your users to use the alternate name when on the Intranet. For example, configure and use the alternate name www.internal.contoso.com for the intranet name www.contoso.com. In a non-split-brain DNS environment, the Internet namespace is different from the intranet namespace. For example, the Contoso Corporation uses contoso.com on the Internet and corp.contoso.com on the intranet. Because all intranet resources use the corp.contoso.com DNS suffix, the NRPT rule for corp.contoso.com routes all DNS name queries for intranet resources to intranet DNS servers. DNS name queries for names with the contoso.com suffix do not match the corp.contoso.com intranet namespace rule in the NRPT and are sent to Internet DNS servers. With a non-split-brain DNS deployment, because there is no duplication of FQDNs for intranet and Internet resources, there is no additional configuration needed for the NRPT. DirectAccess clients can access both Internet and intranet resources for their organization.
48
AAAA records for servers that do not perform DNS dynamic update
For servers running IPv6-capable non-Windows operating systems that do not support DNS dynamic update for IPv6 addresses, manually add AAAA records for the names and IPv6 addresses of these servers.
49
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 DNS suffix rule for the domain name of the DirectAccess server and the IPv6 addresses corresponding to the intranet DNS servers configured on the DirectAccess server. For example, if the DirectAccess server is a member of the corp.contoso.com domain, the DirectAccess Setup Wizard creates a rule for the .corp.contoso.com DNS suffix. An exemption rule for the FQDN of the network location server. For example, if the network location server URL is https://nls.corp.contoso.com, the DirectAccess Setup Wizard creates an exemption rule for the FQDN nls.corp.contoso.com. You might need to configure additional NRPT rules in step 3 of the DirectAccess Setup Wizard in the following cases: You need to add more DNS suffixes for your intranet namespace. If the FDQN of your intranet and Internet CRL distribution points are based on your intranet namespace, you must add exemption rules for the FQDNs of your Internet and intranet CRL distribution points. If you have a split-brain DNS environment, you must add exemption rules for the names of resources for which you want DirectAccess clients located on the Internet to access the public (Internet) version, rather than the intranet version. If you are redirecting traffic to an external Web site through your intranet Web proxy servers, the external Web site is only available from the intranet, and the external Web site is using the addresses of your Web proxy servers to permit the inbound requests, then you must add an exemption rule for the FQDN of the external Web site and specify that the rule use your intranet Web proxy server, rather than the IPv6 addresses of intranet DNS servers. For example, the Contoso Corporation is testing an external Web site named test.contoso.com. This name is not resolvable via Internet DNS servers, but Contosos Web
50
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. Notes 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).
home network server is named Server1 and there is an intranet server of the same name, you will always connect to the intranet Server1. To connect to the local subnet resource, append .local to the name of the server. For example, to connect to the local subnet server named Server1, use the name Server1.local.
External DNS
The DirectAccess Setup wizard configures DirectAccess clients with the IPv4 addresses of the 6to4 relay and the Teredo server with Group Policy settings in Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies. For the URL for the Internet Protocol over Secure Hypertext Transfer Protocol (IPHTTPS) server (the IP-HTTPS State setting), the DirectAccess Setup Wizard configures https://Subject:443/IPHTTPS, in which Subject is the Subject field of the HTTPS certificate that you specify in Step 2 of the DirectAccess Setup Wizard. If the Subject field of the IP-HTTPS certificate is an FQDN, you must ensure that the FQDN is resolvable using Internet DNS servers. If you modify the 6to4 Relay Name or Teredo Server Name Group Policy settings to use FQDNs rather than an IPv4 address, you must ensure that the FQDNs are resolvable using Internet DNS servers. You must also ensure that the FQDNs for your Internet-accessible certificate revocation list (CRL) distribution points are resolvable using Internet DNS servers. For example, if the URL http://crl.contoso.com/crld/corp-DC1-CA.crl is in the CRL Distribution Points field of the IP-HTTPS certificate of the DirectAccess server, you must ensure that the FQDN crld.contoso.com is resolvable using Internet DNS servers.
52
If the certificate revocation check fails, DirectAccess clients cannot successfully access an HTTPS-based URL on the network location server. Therefore, an intranet-based CRL distribution point location must be present in the network location server certificate and be accessible by DirectAccess clients that are connected to the intranet, even when there are DirectAccess rules in the NRPT. The IPsec tunnels between the DirectAccess client and the DirectAccess server. See Enabling strong CRL checking for IPsec authentication in this topic. For both Internet and intranet-based CRLs, the CRL distribution point must be highly accessible. CRL distribution points can be accessed through the following: Web servers using an HTTP-based URL, such as http://crl.corp.contoso.com/crld/corpDC1-CA.crl File servers and accessed through a universal naming convention (UNC) path, such as \\crl.corp.contoso.com\crld\ corp-DC1-CA.crl For more information, see Configure a CRL Distribution Point for Certificates in the DirectAccess Deployment Guide. Note If your intranet CRL distribution points are only reachable over IPv6, you must configure a Windows Firewall with Advanced Security connection security rule to exempt IPsec protection from the IPv6 address space of your intranet to the IPv6 addresses of your CRL distribution points.
Note 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.
55
If the DirectAccess client on the intranet is unable to reach the HTTPS-based URL of the network location server, a DirectAccess client cannot detect when it is on the intranet and might not be able to access intranet resources. If the DirectAccess client on the intranet is unable to reach the intranet CRL distribution point to perform certificate revocation checking for the network location server, a DirectAccess client cannot detect when it is on the intranet and might not be able to access intranet resources. If the DirectAccess client on the Internet is unable to reach the Internet CRL distribution point to perform certificate revocation checking for the IP-HTTPS certificate, a DirectAccess client cannot use IP-HTTPS. Because IP-HTTPS is the last transition technology that is used for Internet Protocol version 6 (IPv6) connectivity to the DirectAccess server, DirectAccess clients will not be able to establish a connection to the DirectAccess server when behind a firewall or Web proxy or behind a network address translator (NAT) when the Teredo client has been disabled. If you configure strong CRL checking on the DirectAccess server and it cannot reach the CRL distribution points in the DirectAccess clients certificate, certificate-based authentication for the IPsec tunnels will fail and DirectAccess clients will be unable to access intranet resources. For Internet Information Services (IIS)-based Web servers, see Planning Redundancy for a Network Location Server and Planning Redundancy for CRL Distribution Points for information about high availability for Web servers.
56
is sent over the VPN connection and traffic to all other locations is sent using the physical interface connected to the Internet. You can configure DirectAccess clients to send all of their traffic through the tunnels to the DirectAccess server with force tunneling. When force tunneling is configured, DirectAccess clients that detect that they are on the Internet modify their IPv4 default route so that default route IPv4 traffic is not sent. With the exception of local subnet traffic, all traffic sent by the DirectAccess client is IPv6 traffic that goes through tunnels to the DirectAccess server. Enabling force tunneling has the following consequences: DirectAccess clients use only Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) to obtain IPv6 connectivity to the DirectAccess server over the IPv4 Internet. IPHTTPS-based connections have lower performance and higher overhead on the DirectAccess server than 6to4 and Teredo-based connections. The only locations that a DirectAccess client can reach by default with IPv4 traffic are those on its local subnet. All other traffic sent by the applications and services running on the DirectAccess client is IPv6 traffic sent over the DirectAccess connection. Therefore, IPv4-only applications on the DirectAccess client cannot be used to reach Internet resources, except those on the local subnet. Connectivity to the IPv4 Internet must be done through servers and devices on the intranet that translate the IPv6 traffic from DirectAccess clients to IPv4 traffic for the IPv4 Internet. If you do not have the appropriate servers or translators, your DirectAccess clients will not have access to IPv4 Internet resources, even though they are directly connected to the IPv4 Internet. To configure force tunneling, you must enable force tunneling on DirectAccess clients through Group Policy and add a special entry in the NRPT. To enable force tunneling with Group Policy, enable the Computer Configuration\Policies\Administrative Templates\Network\Network Connections\Route all traffic through the internal network setting in the Group Policy object for DirectAccess clients. To make IPv4-based Internet resources available to DirectAccess clients that use force tunneling, you can do one of the following: Use a dual protocol (IPv4 and IPv6) proxy server, which can receive IPv6-based requests for Internet resources and translate them to requests for IPv4-based Internet resources. Place an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway in front of your IPv4-based proxy server. The IPv6/IPv4 translator and IPv6/IPv4 DNS gateway will translate IPv6-based proxy requests to IPv4-based requests before they are serviced by your IPv4-based proxy server. To route DNS name resolution and connection traffic to these servers or devices for translation and forwarding to the IPv4 Internet, you must add a rule to the NRPT for DirectAccess clients that specifies any DNS suffix and the IPv6 address of the IPv6/IPv4 DNS gateway. If you are configuring the NRPT through the DirectAccess Setup Wizard, add a rule for the following: Name suffix is set to .
57
DNS server IPv4 or IPv6 addresses are set to the static IPv4 or IPv6 addresses of the dual-protocol proxy server or IPv6/IPv4 DNS gateway If you are configuring the NRPT through the Computer Configuration\Policies\Windows Settings\Name Resolution Policy Group Policy setting, create a rule with the following: The Any suffix Enabled for DirectAccess
For DNS servers, add the static IPv6 addresses of the dual-protocol proxy server or IPv6/IPv4 DNS gateway With this NRPT rule, a DirectAccess client sends DNS name queries that do not match any of the other rules in the NRPT to the IPv6 address of the dual-protocol proxy server or IPv6/IPv4 DNS gateway. For more information, see Configure Force Tunneling in the DirectAccess Deployment Guide. Notes Due to the infrastructure requirements and reduced performance for accessing IPv4 Internet resources, Microsoft does not recommend the use of force tunneling for DirectAccess. Force tunneling relies on modifying the IPv4 default route in the IPv4 routing table to prevent the DirectAccess client computer from sending traffic directly to IPv4 Internet locations. A user with administrative rights can modify their IPv4 default route to point to their Internet service providers router on the subnet.
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 nonDirectAccess clients is sent as clear text. For more information, see Configure Connection Security Rules for Traffic Between DirectAccess Clients in the DirectAccess Deployment Guide.
59
Protocol (ISATAP). For example, the Contoso Corporation uses cweb.corp.contoso.com as its central, highly-available intranet Web site. This Web server uses ISATAP and a static IPv4 address. 2. Enable the Computer Configuration/Policies/Administrative Templates/Network/Network Connectivity Status Indicator/Corporate Website Probe URL Group Policy setting in the Group Policy object for DirectAccess clients and configure it for the highly available intranet URL. For example, enable and configure the Corporate Website Probe URL setting with http://cweb.corp.contoso.com. Note If the name of the highly-available intranet Web site changes, you will have to update the Corporate Website Probe URL setting with the new URL. You also need to add the IPv6 address for the infrastructure tunnel endpoint to the Computer Configuration/Policies/Administrative Templates/Network/Network Connectivity Status Indicator/Corporate Site Prefix List Group Policy setting in the Group Policy object (GPO) for DirectAccess clients. The IPv6 address for the infrastructure tunnel endpoint is configured in the Windows Firewall with Advanced Security connection security rule named DirectAccess PolicyClientToDnsDc in the GPO for DirectAccess clients. For more information, see Configure Corporate Connectivity Detection Settings in the DirectAccess Deployment Guide. Note If you use the Use local name resolution if the internal network DNS servers determined that the name does not exist or if the internal network DNS servers are not reachable and the DirectAccess client computer is on a private network option for local host name resolution, the Corporate Website Probe URL setting must be specified as a FQDN, rather than an unqualified, single-label name. If you use an unqualified, single-label name, corporate connectivity detection might incorrectly detect that corporate connectivity exists and diagnostics for DirectAccess can be affected.
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).
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
63
detection of the type of network address translator (NAT) that they are behind. For more information, see Teredo Overview (http://go.microsoft.com/fwlink/?Linkid=157322). Note The DirectAccess Management console sorts the public IPv4 addresses assigned to the Internet adapter alphabetically. Therefore, the DirectAccess Management console does not consider the following sets of addresses as consecutive: w.x.y.9 and w.x.y.10, which is sorted as w.x.y.10, w.x.y.9; w.x.y.99 and w.x.y.100, which is sorted as w.x.y.100, w.x.y.99; w.x.y.1, w.x.y.2, and w.x.y.10, which is sorted as w.x.y.1, w.x.y.10, w.x.y.2. Use a different set of consecutive addresses. On the DirectAccess server, you install the DirectAccess Management Console feature through Server Manager. You use the DirectAccess management console to configure DirectAccess settings for the DirectAccess server and clients and monitor the status of the DirectAccess server. DirectAccess servers should not host any other primary functions; they should be dedicated to DirectAccess.
To improve overall performance, configure the following in the properties for the virtual machine in Failover Cluster Manager: Do not set a preferred owner. Set Failback to Prevent Failback. If Failback is enabled, unnecessary outages may occur when the DirectAccess VM resource is migrated or recovers from a node failure. To speed up client reconnection in the event of a quick migration or node failure, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\ Oakley\NLBSFlags registry value to 1 on the DirectAccess virtual machine for faster idle timeout of IPsec security associations (SAs). With the NLBSFlags registry value set to 1, the total time it takes for IPsec to fail over is two minutes; one minute for the idle time to expire plus one minute for IKE to renegotiate SAs. The Hyper-V nodes do not need this configuration change. With Hyper-V and Failover Clustering the primary failover mechanisms are the following: Live migration There should be no discernable client connectivity outage when the clustered DA server is live migrated. Quick migration With the NLBSFlags registry value set to 1, the maximum client connectivity outage on a quick migration should be less than two minutes. Resource move With the NLBSFlags registry value set to 1, the maximum client connectivity outage on a manual resource move should be less than two minutes. Hyper-V and Failover Clustering also support automatic recovery from a single node failure. When failover occurs a client should be reconnected within two minutes; there is no action 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.
65
The certificate used by the Web server to act as a network location server has the following requirements: In the Subject field, either an Internet Protocol (IP) address of the intranet interface of the Web server or the FQDN of the network location URL. For the Enhanced Key Usage field, the Server Authentication object identifier (OID). For the CRL Distribution Points field, a certificate revocation list (CRL) distribution point that is accessible by DirectAccess clients that are connected to the intranet. The FQDN in the URL or the universal naming convention (UNC) path of the CRL distribution point location should either match an exemption rule or no rules in the NRPT so that the DirectAccess client can use interface-configured intranet DNS servers to resolve the name. If the DirectAccess client cannot resolve the FQDN in the URL or UNC of the CRL distribution point, access the CRL distribution point, and verify that the network location servers certificate has not been revoked, intranet detection fails. For more information, see Install and Configure IIS for a Network Location Server Certificate in the DirectAccess Deployment Guide.
67
68
HRAs on the intranet NAP certification authorities (CAs) Remediation servers NAP client settings
For information about how to deploy IPsec enforcement, see IPsec Enforcement Design. In your deployment of IPsec enforcement, on the DirectAccess server, you need to install an IPsec exemption certificate. Note To prevent timing problems that might occur when obtaining Kerberos authentication and accessing the Web location on the intranet HRA, you can configure Internet Information Services (IIS) on the HRA to use NTLM authentication with the %windir %\system32\inetsrv\appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication /-providers.[value='Negotiate'] command.
70
71
Forefront TMG integrates with the Internet Protocol security (IPsec) Denial of Service Protection (DoSP) component of DirectAccess to ensure that only IPsec-protected traffic is allowed to pass through. For this reason, you must configure DirectAccess before installing Forefront TMG. Forefront TMG also allows Internet Control Message Protocol (ICMP) traffic through by default, which is required to support Teredo-based DirectAccess clients. For more information, see Forefront Threat Management Gateway and DirectAccess (http://go.microsoft.com/fwlink/?LinkId=169278).
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\ MaxConcurrentApi (REG_DWORD) registry value on the DirectAccess server to 5, and then restart the NETLOGON service.
It is possible to move these functions to other computers. One configuration that supports scalability for many DirectAccess connections is to move the IPsec gateway and ISATAP router functions to another computer with IPsec offload hardware, which can handle the processorintensive cryptographic operations and support many IPsec tunnels. The following figure shows an example.
In this example, Server 1 provides the 6to4 relay, Teredo server, and IP-HTTPS server functions and Server 2 provides ISATAP router and IPsec gateway functions. DirectAccess clients use Server 1 to tunnel traffic across the IPv4 Internet and establish the infrastructure and intranet IPsec tunnels with Server 2. Intranet computers forward traffic to DirectAccess clients to Server 2. The requirements of this configuration are the following: Both Server 1 and Server 2 must have two physical interfaces, one classified as a public interface and one classified as a domain interface. Server 1 has its public interface on the Internet. The subnet for the link between the Server 1 and Server 2, the intra-server subnet, must use native IPv6 addressing. You cannot use 6to4 or ISATAP tunneling on this link. You must
74
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 1s 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 2s interface on the intra-server subnet. With this configuration, Server 2 acts as the IPsec intranet and infrastructure tunnel endpoint, providing decryption services for packets from DirectAccess clients and encryption services for packets to DirectAccess clients. The following figure shows an example of the traffic between DirectAccess clients and intranet servers for the full intranet access model.
The traffic over the Internet between the DirectAccess client and Server 2 is encrypted through the intranet tunnel. The traffic over the intranet between Server 2 and intranet servers is clear text. The recommended method to deploy this configuration is the following: 1. While configured with two consecutive public IPv4 addresses, complete the DirectAccess Setup Wizard on Server 2. 2. Set up the intra-server subnet and the static IPv6 addressing of Server 1. Reconfigure Server 2 with the appropriate IPv4 addresses for the intra-server subnet and remove the two consecutive public IPv4 addresses. Configure Server 1 with the two consecutive public IPv4 addresses on the Internet interface. 3. Configure Server 1 as a default advertising router for the intra-server subnet, and a 6to4 relay, Teredo server and relay, and IP-HTTPS server on the Internet. 4. Disable the 6to4 relay, Teredo server and relay, and IP-HTTPS server functionality on Server 2. 5. Configure Group Policy settings for the new IPsec tunnel endpoint on Server 2.
75
DirectAccess client
Operating system: Windows 7 Ultimate or later, Windows 7 Enterprise or later, Windows Server 2008 R2 or later Member of an Active Directory Domain Services (AD DS) domain Computer certificate for Internet Protocol security (IPsec) authentication
DirectAccess server
Operating system: Windows Server 2008 R2 or later Member of an AD DS domain At least two network adapters that are connected to the Internet and your intranet 2 consecutive, public Internet Protocol version 4 (IPv4) addresses configured on the Internet network adapter (cannot be behind a network address translator [NAT]) Certificates: Computer certificate for IPsec authentication, Secure Sockets Layer (SSL) certificate for Internet Protocol over Secure Hypertext Transfer Protocol (IPHTTPS) If acting as a network location server, Internet Information Services (IIS) and an additional SSL certificate installed Note There are no built-in limitations on the number of simultaneous DirectAccess connections that a DirectAccess server can support.
Active Directory
At least one Active Directory domain must be deployed with at least one Windows Server 2008 R2 or Windows Server 2008-based
77
Element
Requirements
domain controller (an Internet Protocol version 6 [IPv6]-capable domain controller and global catalog). Windows Server 2008 R2 domain or forest functional levels are not required. Workgroups are not supported. For more information about installing Active Directory, see the AD DS Installation and Removal Step-byStep Guide (http://go.microsoft.com/fwlink/? Linkid=139657). Group Policy Required for centralized administration and deployment of DirectAccess settings. The DirectAccess Setup wizard creates a set of Group Policy objects and settings for DirectAccess clients, the DirectAccess server, and selected servers. Required to issue computer certificates for authentication, and optionally, health certificates when using Network Access Protection (NAP). External certificates are not required. For more information about setting up a PKI with Active Directory Certificate Services (AD CS), see Active Directory Certificate Services (http://go.microsoft.com/fwlink/?Linkid=106710). At least one running Windows Server 2008 R2, Windows Server 2008 with the Q958194 hotfix (http://go.microsoft.com/fwlink/?LinkID=159951), Windows Server 2008 SP2 or later, or a thirdparty DNS server that supports DNS message exchanges over the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
following sections describe the role that these technologies have in providing DirectAccess clients with transparent access to intranet resources.
IPv6
IPv6 is the new version of the Network layer of the TCP/IP protocol stack that is designed to replace Internet Protocol version 4 (IPv4), which is in wide use today on intranets and the Internet. IPv6 provides an address space large enough to accommodate end-to-end addressing of nodes on the IPv6 Internet, and with IPv6 transition technologies, of nodes on the IPv4 Internet. DirectAccess uses this capability to provide end-to-end addressing from DirectAccess clients on the IPv4 or IPv6 Internet to computers on an intranet. Because most of the current Internet is IPv4-based and many organizations have not deployed native IPv6 addressing and routing on their intranets, DirectAccess uses IPv6 transition technologies to provide IPv6 connectivity over these IPv4-only networks. Teredo, 6to4, Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS), and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) are examples of IPv6 transition technologies. These technologies allow you to use IPv6 on the IPv4 Internet and your IPv4-only intranet. IPv6 transition technologies can simplify and reduce the costs of an IPv6 deployment.
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
79
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).
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. Note Windows Server 2003 and earlier versions of Windows Server do not fully support the use of IPsec with IPv6. IPv6-capable resources on servers running Windows Server 2003 will only be available to DirectAccess clients if you use the full intranet access model.
80
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 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. Note 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 endto-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.
81
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.
82
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
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.
Concepts
Provide a brief description of how DirectAccess works or use the following description: DirectAccess gives users the experience of being seamlessly connected to their corporate network (intranet) any time they have Internet access. With DirectAccess, users are able to access intranet resources (such as e-mail servers, shared folders, or intranet Web sites) securely without connecting to a virtual private network (VPN). DirectAccess provides increased productivity for mobile workforce by offering the same connectivity experience both in and outside of the office. DirectAccess is on whenever the user has an Internet connection, giving users access to intranet resources whether they are traveling, at the local coffee shop, or at home. DirectAccess is supported by Windows 7 Ultimate or later, Windows 7 Enterprise or later, and Windows Server 2008 R2 or later.
Goals
List your reasons for deploying DirectAccess and state how your design plan will achieve these goals. Also provide the following: Benefits. Describe the pre-deployment state of the network and the benefits you expect to see as a result of the DirectAccess deployment. 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.
84
IPv6 connectivity. Describe how you deployed Internet Protocol version 6 (IPv6) connectivity across your intranet. Include details on routers, default routing design, and IPv6 Internet connectivity. Servers, devices, and roles. List all servers and devices, including their roles, in your DirectAccess design. Include computers and other devices used for DirectAccess certificate validation and connectivity. Packet filtering. List the packet filters configured on Internet and intranet firewalls, across intranet hosts, and for DirectAccess clients. Capacity management and redundancy. Describe your expectations for capacity management and redundancy in the DirectAccess design. Scaling plan. Describe changes that will be required to support the expansion of the DirectAccess deployment to include additional capacity.
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:
85
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.
Use the checklists in Implementing Your DirectAccess Design Plan to determine how best to use the instructions in this guide to deploy your particular design. For information about hardware and software requirements for deploying DirectAccess, see Appendix A: DirectAccess Requirements in the DirectAccess Design Guide. This guide, combined with the DirectAccess Design Guide, is also available as a Microsoft Word file (http://go.microsoft.com/fwlink/?LinkId=163662) in the Microsoft Download Center.
It is possible that the design team might leave the subject of DirectAccess server placement for the deployment team. The deployment team is then responsible for documenting and implementing the physical topology of DirectAccess and dependent servers. The deployment team can review the preceding topics and also the DirectAccess Capacity Planning and Appendix A: DirectAccess Requirements topics in the DirectAccess Design Guide to help determine the number of servers and the hardware requirements for the organization. Ensure that members of the deployment team understand the reasons the selected DirectAccess design is being deployed and how client and server computers will be affected. Ensure that members of the deployment team also understand the stages of the DirectAccess deployment and what decisions govern when to advance from one deployment stage to the next. For more information, see Planning a DirectAccess Deployment Strategy.
87
After the design teams and deployment teams agree on these issues, they can proceed with the deployment of the DirectAccess design. For more information, see Implementing Your DirectAccess Design Plan.
Step-by-Step Guide: Demonstrate DirectAccess in a Test Lab (http://go.microsoft.com/fwlink/?LinkID=150613) DirectAccess overviews, Webcasts, and other resources are available at the DirectAccess Web site (http://go.microsoft.com/fwlink/?LinkId=160519)
88
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
89
Checklist: Moving the IPsec Gateway to Another Server (this document is in progress and not yet available).
Identify and prioritize goals; decide on an access model; identify pilot computers; document deployment decisions and processes.
Identifying Your DirectAccess Deployment Goals Choose an Access Model Appendix C: Documenting Your DirectAccess Design
Implement a DirectAccess pilot Implementing Your deployment; start with a single DirectAccess Design Plan DirectAccess server and expand the number of DirectAccess clients until you have fully deployed DirectAccess for the scope of your pilot. Scale out; implement redundancy as needed; reevaluate goals and assess benefits. DirectAccess Capacity Planning Planning Redundancy for a DirectAccess Server
90
Review important concepts for DirectAccess. Review the client, server, and network infrastructure requirements for DirectAccess. Create Active Directory security groups for DirectAccess clients (required) and selected servers (optional) and add members. Configure packet filtering on Internet and intranet firewalls.
Appendix B: Reviewing Key DirectAccess Concepts Appendix A: DirectAccess Requirements Create DirectAccess Groups in Active Directory
Packet Filters for Your Internet Firewall Packet Filters for Your Intranet Firewall
Configure packet filtering for Internet Control Message Protocol for IPv6 (ICMPv6) traffic. Configure packet filtering for remote management computers.
Configure Packet Filters to Allow ICMP Traffic Configure Settings to Confine ICMPv6 Traffic to the Intranet Design for Remote Management Configure Packet Filters to Allow Management Traffic to DirectAccess Clients
Task
Reference
namespace or exemption rules. Add intranet A records as needed for your network location server and CRL distribution points. Add Internet Domain Name System (DNS) Address (A) records as needed for the DirectAccess server as Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) server and certificate revocation list (CRL) distribution points. Configure your DNS servers running Windows Server 2008 R2 or Windows Server 2008 to support resolution of the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) name. Configure your public key infrastructure (PKI) for CRL distribution points. Design Your DNS Infrastructure for DirectAccess
Configure a CRL Distribution Point for Certificates Configure Active Directory Certificate Services for CRL Locations Configure Computer Certificate Autoenrollment
Configure Active Directory Certificate Services (AD CS) for autoenrollment of computer certificates. Configure AD CS for a custom certificate template for Secure Sockets Layer (SSL) certificates. If needed by your design, configure an Secure Hypertext Transfer Protocol (HTTPS) uniform resource locator (URL) on your separate network location server.
92
Task
Reference
If needed by your design, install Install and Configure IIS for a a custom SSL certificate on your Network Location Server separate network location server. Certificate
Install two network adapters (interfaces) on your DirectAccess server. Connect the internal network interface to your internal network. From the Network Connections folder, configure your network connections (interfaces) with meaningful names indicating the network to which they are attached, such as Internet and Internal network. Configure your internal network interface with a static Internet Protocol
Design Addressing and Routing for the DirectAccess Server IPv4 General tab
93
Task
Reference
(http://go.microsoft.com/fwlink/?LinkId=145843)
Join the DirectAccess Active Directory Domain Services Home server computer to the page on Microsoft Technet appropriate Active (http://go.microsoft.com/fwlink/?Linkid=127814) Directory Domain Services (AD DS) domain. Connect the Internet interface to the Internet. On the Internet interface, configure at least two consecutive, static, public IPv4 addresses that are resolvable and reachable on the Internet. Addresses within the address ranges 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 are not public IPv4 addresses. Configure your Internet and intranet interfaces with different connectionspecific Domain Name System (DNS) suffixes. Configure your intranet interface with the DNS suffix for your organization. Configure static routes for your intranet on the DirectAccess server. If a domain controller is reachable from the Internet interface, configure packet filters to prevent access. Verify that the DirectAccess server has a computer certificate Design Addressing and Routing for the DirectAccess Server IPv4 General tab (http://go.microsoft.com/fwlink/?LinkId=145843)
Design Addressing and Routing for the DirectAccess Server IPv4 and IPv6 Advanced DNS tab (http://go.microsoft.com/fwlink/?LinkId=145844)
Design Addressing and Routing for the DirectAccess Server Configure Packet Filters to Block Access to Domain Controllers
94
Task
Reference
installed with the computer authentication Enhanced Key Usage (EKU). Install a Secure Sockets Layer (SSL) certificate for Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) authentication. If the DirectAccess server is acting as the network location server, install the IIS (Web server) role. If the DirectAccess server is acting as the network location server, install an additional SSL certificate. Install an IP-HTTPS Certificate
Review important concepts and the example for the DirectAccess full intranet access model.
95
Task
Reference
Prepare the DirectAccess server Checklist: Preparing Your computer for the DirectAccess DirectAccess Server Setup Wizard. Install the DirectAccess feature on the DirectAccess server. Install the DirectAccess Feature
Configure the DirectAccess Configure the DirectAccess server for the full intranet access Setup Wizard for Full Intranet method with the DirectAccess Access Setup Wizard. Configure the Corporate Website Probe URL and Corporate Site Prefix List Group Policy settings. If needed by your design plan, deploy and configure IPv6/IPv4 translator and IPv6/IPv4 DNS gateway devices. Design Your Intranet for Corporate Connectivity Detection Configure Corporate Connectivity Detection Settings Choose Solutions for IPv4only Intranet Resources See the IPv6/IPv4 translator and IPv6/IPv4 DNS gateway device documentation. Configure the NRPT for an IPv6/IPv4 DNS Gateway If needed by your design plan, configure force tunneling. If needed by your design plan, configure a connection or routing to the Internet Protocol version 6 (IPv6) Internet. If needed by your design plan, configure client authentication and certificate mapping for Internet Protocol over Secure Hypertext Transfer Protocol (IPHTTPS) connections. If needed by your design plan, configure connection security rules to protect traffic sent Configure Force Tunneling Connect to the IPv6 Internet
Task
Reference
Review important concepts and the example for the DirectAccess selected server access model. Configure the required infrastructure for DirectAccess.
Selected Server Access Selected Server Access Example Checklist: Preparing Your Infrastructure for DirectAccess
Prepare the DirectAccess server Checklist: Preparing Your computer for the DirectAccess DirectAccess Server Setup Wizard. Install the DirectAccess feature on the DirectAccess server. Configure the DirectAccess server for the selected server access method with the DirectAccess Setup Wizard. Configure the Corporate Website Probe URL and Corporate Site Prefix List Group Policy settings. Install the DirectAccess Feature Configure the DirectAccess Setup Wizard for Selected Server Access Design Your Intranet for Corporate Connectivity Detection Configure Corporate Connectivity Detection Settings
97
Task
Reference
If needed by your design plan, deploy and configure IPv6/IPv4 translator and IPv6/IPv4 DNS gateway devices.
Choose Solutions for IPv4only Intranet Resources See the IPv6/IPv4 translator and IPv6/IPv4 DNS gateway device documentation. Configure the NRPT for an IPv6/IPv4 DNS Gateway
If needed by your design plan, configure force tunneling. If needed by your design plan, configure a connection or routing to the Internet Protocol version 6 (IPv6) Internet. If needed by your design plan, configure client authentication and certificate mapping for Internet Protocol over Secure Hypertext Transfer Protocol (IPHTTPS) connections. If needed by your design plan, configure connection security rules to protect traffic sent between DirectAccess clients.
Task
Reference
Review important concepts and the example for the DirectAccess end-to-end access model. Configure the required infrastructure for DirectAccess. Prepare the DirectAccess server computer for the DirectAccess Setup Wizard. Install the DirectAccess feature on the DirectAccess server. Configure the DirectAccess server for the end-to-end access method with the DirectAccess Setup Wizard. Customize the connection security policies created by the DirectAccess Setup Wizard for end-to-end access. Configure the Corporate Website Probe URL Group Policy setting.
Checklist: Preparing Your Infrastructure for DirectAccess Checklist: Preparing Your DirectAccess Server Install the DirectAccess Feature Configure the DirectAccess Setup Wizard for End-to-End Access Configure Connection Security Rules for End-to-end Access Design Your Intranet for Corporate Connectivity Detection Configure Corporate Connectivity Detection Settings Configure Force Tunneling Connect to the IPv6 Internet
If needed by your design plan, configure force tunneling. If needed by your design plan, configure a connection or routing to the Internet Protocol version 6 (IPv6) Internet. If needed by your design plan, configure client authentication and certificate mapping for Internet Protocol over Secure Hypertext Transfer Protocol (IPHTTPS) connections. If needed by your design plan, configure connection security
Task
Reference
Review important concepts for using Hyper-V to provide redundancy for DirectAccess. As needed by your design plan, configure DirectAccess for the full intranet, selected server, or end-to-end access model.
Planning Redundancy for a DirectAccess Server 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-toEnd Access
Configure two Hyper-V hosts Planning Redundancy for a with failover clustering DirectAccess Server supporting a single shared DirectAccess server in a virtual machine and modify the Hyper-V configuration for DirectAccess.
100
Review important concepts for using NAP with DirectAccess. Deploy NAP with the Internet Protocol security (IPsec) enforcement method.
Planning DirectAccess with Network Access Protection (NAP) Implementing Your NAP Design Plan Checklist: Implementing an IPsec Enforcement Design Create an IPsec NAP Exemption Group 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-toEnd Access
Install an IPsec enforcement exemption certificate on the DirectAccess server. As needed by your design plan, configure DirectAccess for the full intranet, selected server, or end-to-end access model.
As needed by your design plan, modify the connection security rules for DirectAccess clients and servers.
101
102
To complete these procedures, you must be delegated permissions to configure IIS, file sharing permissions on a shared folder, and Active Directory Certificate Services (AD CS). In this procedure, you create and configure a Web site to contain the CRL files. To create a Web-based CRL distribution point 1. On the IIS server, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager. 2. In the console tree, open the server name, and then Sites. 3. Right-click Default Web Site, and then click Add virtual directory. 4. In Alias, type the name of the site containing the CRL distribution list (example: CRLD). 5. In Physical path, click the ellipsis (). 6. Click the appropriate drive, and then click Make New Folder. 7. Type the name of a folder that will contain the CRL distribution list files (example: CRLDist), press ENTER, and then click OK twice. 8. In the contents pane, double-click Directory Browsing. 9. In the Actions pane, click Enable. 10. In the console tree, click the new site name folder. 11. In the contents pane, double-click Configuration Editor. 12. In Section, open system.webServer\security\authentication\requestFiltering. 13. In the contents pane, double-click allowDoubleEscaping to change it from False to True. 14. In the Actions pane, click Apply. In this procedure, you configure the permissions on the CRL distribution file share so that the certification authority (CA) can write CRL files.
103
To configure permissions on the CRL distribution file shared folder 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. 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 browsers Back button to return to the checklist.
104
105
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. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
IPHTTPSPublicIPv4Address is the public IPv4 address that the DirectAccess server is listening on for incoming IP-HTTPS connections. You can obtain this address from the URL in the display of the netsh interface httpstunnel show interfaces command. IPHTTPSPublicIPv4Address is either the Internet Protocol version 4 (IPv4) address in the uniform resource locator (URL) or the IPv4 address to which the fully qualified domain name (FQDN) in the URL resolves on the Internet. IPHTTPSPublicIPv4Address can also be set to 0.0.0.0. HashofDA_IPHTTPSCert is the certificate hash from step 3, a 20-byte hexadecimal number, with the spaces removed. Note You can also use the GuidGEN.exe tool (http://go.microsoft.com/fwlink/?Linkid=121586) to generate the GUID for the appid parameter. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
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 browsers Back button to return to the checklist.
exemptipsecprotectedconnections=yes netsh advfirewall consec set rule name=DirectAccess Policy-ClientToDnsDc new exemptipsecprotectedconnections=yes netsh advfirewall consec set rule name=DirectAccess Policy-ClientToMgmt new exemptipsecprotectedconnections=yes netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{ab991ef0-6fa94bd9-bc42-3c397e8ad300} netsh advfirewall consec set rule name=DirectAccess Policy-DaServerToMgmt new exemptipsecprotectedconnections=yes netsh advfirewall consec set rule name=DirectAccess Policy-DaServerToCorp new exemptipsecprotectedconnections=yes netsh advfirewall consec set rule name=DirectAccess Policy-DaServerToDnsDc new exemptipsecprotectedconnections=yes netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{f7b77f47-7c334d8c-bb9a-a913c5675d8d} netsh advfirewall consec set rule name=DirectAccess PolicyappServerToIpHttpsClientPolicy new qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb netsh advfirewall consec set rule name=DirectAccess Policy-appServerToClient new qmsecmethods=ESP:SHA1-AES192+60min+100000kb,ESP:SHA1AES128+60min+100000kb In this procedure, you configure end-to-end access connection security rules to always require encryption. To configure end-to-end access connection security rules to always require encryption 1. On a domain controller, start a command prompt as an administrator. 2. From the Command Prompt window, run the following commands: netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{3491980e-ef3c4ed3-b176-a4420a810f12} netsh advfirewall consec set rule name=DirectAccess Policy-clientToAppServer new endpoint2=any qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb netsh advfirewall consec set rule name=DirectAccess Policy-ClientToCorp new exemptipsecprotectedconnections=yes netsh advfirewall consec set rule name=DirectAccess Policy-ClientToDnsDc new exemptipsecprotectedconnections=yes netsh advfirewall consec set rule name=DirectAccess Policy-ClientToMgmt new exemptipsecprotectedconnections=yes netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{ab991ef0-6fa9110
4bd9-bc42-3c397e8ad300} netsh advfirewall consec set rule name=DirectAccess Policy-DaServerToMgmt new exemptipsecprotectedconnections=yes netsh advfirewall consec set rule name=DirectAccess Policy-DaServerToCorp new exemptipsecprotectedconnections=yes netsh advfirewall consec set rule name=DirectAccess Policy-DaServerToDnsDc new exemptipsecprotectedconnections=yes netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{f7b77f47-7c334d8c-bb9a-a913c5675d8d} netsh advfirewall consec set rule name=DirectAccess PolicyappServerToIpHttpsClientPolicy new endpoint2=any qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb netsh advfirewall consec set rule name=DirectAccess Policy-appServerToClient new endpoint2=any qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
name=RuleName profile=public,private program=system action=allow security=authenc protocol=Protocol localport=Port command. For example, to create an inbound firewall rule for Remote Desktop traffic, use the netsh advfirewall firewall add rule name=RemoteDesktop profile=public,private program=system action=allow security=authenc protocol=tcp localport=3389 command. 5. To request protection of traffic between DirectAccess clients for all applications, at the command prompt, type the netsh advfirewall consec add rule name=RuleName endpoint1=any endpoint2=any action=requestinrequestout profile=public,private auth1=computercert auth1ca=CANameString command. 6. To require protection of traffic between DirectAccess clients for all applications, at the command prompt, type the netsh advfirewall consec add rule name=RuleName endpoint1=any endpoint2=any action=requireinrequestout profile=public,private auth1=computercert auth1ca=CANameString command. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
6. In Corporate Website Probe URL, type the uniform resource locator (URL) of a highly available intranet Web server that is available to any computer connected to the intranet, either through a local area network (LAN) connection (such as wired or wireless) or DirectAccess. Note This URL is different that the network location server URL, which is designed to be accessible only from a computer connected to the intranet through a LAN connection. 7. Click Apply, and then click OK. 8. Start a command prompt as an administrator. 9. From the Command Prompt window, run the netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} command. 10. From the Command Prompt window, run the netsh advfirewall consec show rule name=DirectAccess Policy-ClientToDnsDccommand. 11. From the display of the netsh advfirewall consec show rule command, note the IPv6 address expressed as a range for Endpoint2. 12. In the details pane of the Group Policy Management Editor, double-click Corporate Site Prefix List in the details pane. 13. In Corporate Site Prefix List, type a comma, and then the IPv6 address for Endpoint2 with /128. For example, for the Endpoint2 IPv6 address 2002:836b:2::836b:2, type 2002:836b:2::836b:2/128. 14. Click Apply, and then click OK. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. The following procedure modifies the connection security rules for the infrastructure tunnel to allow DirectAccess clients access to the HRAs and remediation servers on the intranet. To modify the connection security rules for the infrastructure tunnel 1. On a domain controller, start a command prompt as an administrator. 2. From the Command Prompt window, run the following commands: netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{3491980e-ef3c4ed3-b176-a4420a810f12} netsh advfirewall consec show rule name=DirectAccess Policy-ClientToDnsDc 3. From the display of the netsh advfirewall consec show rule command, note the IPv6 address for Endpoint2. This is the IPv6 address of the intranet Domain Name System (DNS) server. 4. From the Command Prompt window, run the following commands: netsh advfirewall consec set rule DirectAccess Policy-ClientToDnsDc new endpoint2=IntranetDNSServerIPv6Address,ListOfHRAIPv6Addresses,ListOfRemediatio nServerIPv6Addresses netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{ab991ef0-6fa94bd9-bc42-3c397e8ad300}" netsh advfirewall consec show rule name=DirectAccess PolicyDaServerToDnsDc 5. From the display of the netsh advfirewall consec show rule command, note the IPv6 address for Endpoint1. This is the IPv6 address of the intranet DNS server. 6. From the Command Prompt window, run the netsh advfirewall consec set rule DirectAccess Policy-ClientToDnsDc new endpoint1=IntranetDNSServerIPv6Address,ListOfHRAIPv6Addresses,ListOfRemediatio nServerIPv6Addresses command. The following procedure modifies the connection security rules for the intranet tunnel to require the use of health certificates by DirectAccess clients to access intranet resources. Perform this procedure only when you are using NAP full enforcement for DirectAccess connections To modify the connection security rules for the intranet tunnel 1. On a domain controller, start a command prompt as an administrator. 2. From the Command Prompt window, run the following commands: netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{ab991ef0-6fa94bd9-bc42-3c397e8ad300} netsh advfirewall consec show rule name=DirectAccess Policy-DaServerToCorp 3. From the display of the netsh advfirewall consec show rule command, note the
114
certification authority (CA) name string for Auth1CAName. 4. From the Command Prompt window, run the following commands: netsh advfirewall consec set rule DirectAccess Policy-DaServerToDnsDC new auth1=computercert auth1ca=CANameString auth1healthcert=yes netsh advfirewall consec set rule DirectAccess Policy-DaServerToMgmt new auth1=computercert auth1ca=CANameString auth1healthcert=yes netsh advfirewall consec set rule DirectAccess Policy-DaServerToCorp new auth1=computercert auth1ca=CANameString auth1healthcert=yes applyauthz=yes If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
9. In DNS servers (optional), click Add. In DNS server, type the IPv6 address of your dual protocol (IPv4 and IPv6) proxy server or your IPv6/IPv4 translator and IPv6/IPv4 DNS gateway devices that are in front of your IPv4-based proxy server. Repeat this step if you have multiple IPv6 addresses. 10. Click Create, and then click Apply. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
116
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. Note If you are using an alias name, you cannot use an IIS server that is also being used for Secure Hypertext Transfer Protocol (HTTPS)-based connections. The certificate configured for HTTPS bindings is for the alias name and HTTPS connections using other FQDNs will not validate. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
types, select Echo Request, and then click OK. Click Next. On the Scope page, click Next. On the Action page, click Next. On the Profile page, click Next. On the Name page, for Name, type Inbound ICMPv4 Echo Requests, and then click Finish. 6. In the console tree, right-click Inbound Rules, and then click New Rule. 7. On the Rule Type page, click Custom, and then click Next. On the Program page, click Next. On the Protocols and Ports page, for Protocol type, click ICMPv6, and then click Customize. In the Customize ICMP Settings dialog box, click Specific ICMP types, select Echo Request, and then click OK. Click Next. On the Scope page, click Next. On the Action page, click Next. On the Profile page, click Next. On the Name page, for Name, type Inbound ICMPv6 Echo Requests, and then click Finish. 8. In the console tree, right-click Outbound Rules, and then click New Rule. 9. On the Rule Type page, click Custom, and then click Next. On the Program page, click Next. On the Protocols and Ports page, for Protocol type, click ICMPv4, and then click Customize. In the Customize ICMP Settings dialog box, click Specific ICMP types, select Echo Request, and then click OK. Click Next. On the Scope page, click Next. On the Action page, click Allow the connection, and then click Next. On the Profile page, click Next. On the Name page, for Name, type Outbound ICMPv4 Echo Requests, and then click Finish. 10. In the console tree, right-click Outbound Rules, and then click New Rule. 11. On the Rule Type page, click Custom, and then click Next. On the Program page, click Next. On the Protocols and Ports page, for Protocol type, click ICMPv6, and then click Customize. In the Customize ICMP Settings dialog box, click Specific ICMP types, select Echo Request, and then click OK. Click Next. On the Scope page, click Next. On the Action page, click Allow the connection, and then click Next. On the Profile page, click Next. On the Name page, for Name, type Outbound ICMPv6 Echo Requests, and then click Finish. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
118
For existing or duplicated inbound rules for management traffic to DirectAccess clients, you can enable edge traversal in the following ways: With the Windows Firewall with Advanced Security snap-in With commands in the netsh advfirewall firewall set rule context
To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to change Group Policy settings. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. To enable edge traversal for an inbound rule with the Windows Firewall with Advanced 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. To enable edge traversal for an inbound rule with the Netsh.exe command-line tool 1. On a domain controller, start a command prompt as an administrator 2. From the Command Prompt window, type the netsh advfirewall set store gpo=DomainName\GPOName command. For example, the name of the DirectAccess client GPO for the corp.contoso.com domain is DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}. Therefore, the command is netsh advfirewall set store gpo=corp.contoso.com\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}". 3. From the Command Prompt window, type the netsh advfirewall firewall show rule name=all command. 4. From the display of this command, copy or write down the names of the inbound rules for management traffic to DirectAccess clients. 5. From the Command Prompt window, run the netsh advfirewall firewall name=RuleName edge=yes command for each rule noted in step 4.
119
If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
netsh advfirewall consec add rule name=Exempt ICMPv6 from Tunnel endpoint profile=private,public action=noauthentication mode=tunnel endpoint1=IPv6AddressesOfTheRemoteTunnelEndpoints endpoint2=any protocol=icmpv6 5. Click Start, type gpmc.msc, and then press ENTER. 6. In the console tree, open Forest/Domains/YourDomain, right-click the DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} GPO, and then click Edit. 7. In the console tree of the Group Policy Management Editor, open Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security. 8. Right-click Windows Firewall with Advanced Security, and then click Properties. 9. Click the IPsec Settings tab. In IPsec exemptions, in Exempt ICMP from IPsec, click No, and then click OK. 10. Close the Group Policy Management Editor. 11. In the console tree of the Group Policy Management console, open Forest/Domains/YourDomain, right-click the DirectAccess Policy-{ab991ef0-6fa94bd9-bc42-3c397e8ad300} GPO, and then click Edit. 12. In the console tree of the Group Policy Management Editor, open Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security. 13. Right-click Windows Firewall with Advanced Security, and then click Properties. 14. Click the IPsec Settings tab. In IPsec exemptions, in Exempt ICMP from IPsec, click No, and then click OK. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. To configure strong certificate revocation checking for IPsec authentication 1. On a domain controller, start a command prompt as an administrator. 2. In the Command Prompt window, run the following commands: netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{ab991ef0-6fa94bd9-bc42-3c397e8ad300} netsh advfirewall set global ipsec strongcrlcheck 2 3. To update the DirectAccess server with this Group Policy change immediately, type the gpupdate /target:computer command. Notes If you enable strong CRL checking and the DirectAccess server cannot reach the CRL distribution point, certificate-based IPsec authentication for all DirectAccess connections will fail. If you are using Network Access Protection (NAP) with DirectAccess and you enable strong CRL checking, certificate-based IPsec authentication for all DirectAccess connections will fail. Health certificates do not contain CRL distribution points because their lifetime is on the order of hours, instead of years for computer certificates. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
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 browsers Back button to return to the checklist.
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, rightclick 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 browsers Back button to return to the checklist.
125
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, rightclick 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 browsers Back button to return to the checklist.
127
4. On the DirectAccess Client Setup page, click Add. 5. In the Select Group dialog box, specify the names of your security groups that contain DirectAccess client computers, click OK, and then click Finish. 6. Click Configure for step 2. 7. On the Connectivity page, for Interface connected to the Internet, select the network connection that is attached to the Internet. For Interface connected to the internal network, select the network connection that is attached to your intranet. If you are using smart card authorization, select Require smart card login for remote users, and enforce this policy on the DirectAccess server. Click Next. 8. If you have an existing Internet Protocol version 6 (IPv6) infrastructure, a Prefix Configuration page displays. In The IPv6 prefix that is used in your internal network, type the 48-bit address prefix used by your organization. In The IPv6 prefix that is used to assign IPv6 addresses to remote client computers, type the 64-bit address prefix that you have designated for Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS)-based IPv6 DirectAccess clients. 9. On the Certificate Components page, for Select the root certificate to which remote client certificates must chain, click Browse. In the list of certificates, click the root certificate for your public key infrastructure (PKI) that issues computer certificates to your DirectAccess clients and servers, and then click OK. 10. For Select the certificate that will be used to secure remote client connectivity over HTTPS, click Browse. In the list of certificates, click the certificate installed on the DirectAccess server computer for IP-HTTPS connections, and then click OK. Click Finish. 11. Click Configure for step 3. 12. On the Location page: If you are using a separate network location server, click Network Location server is run on a highly available server, type the Secure Hypertext Transfer Protocol (HTTPS)-based uniform resource locator (URL) for network location without a trailing / (such as https://nls.corp.contoso.com), click Validate, and then click Next. If you are using the DirectAccess server as the network location server, click Network Location server is run on the DirectAccess server, click Browse, click the certificate for network location, click OK, and then click Next. 13. On the DNS and Domain Controller page, add the appropriate rules for the Name Resolution Policy Table (NRPT) as needed by your design. To add an NRPT rule, rightclick 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.
128
16. On the DirectAccess Application Server Setup page: a. Click Require end-to-end authentication and traffic protection for the specified servers. b. Click Add. In the Select Group dialog box, specify the names of the security groups that contain the selected servers. c. If you want to confine the access of DirectAccess clients to only the selected servers, select Allow access to only those servers in the selected security groups. d. If you want to use authentication with null encapsulation, select Configure the IPsec connection security rules on these servers to perform authentication without traffic protection. 17. Click Finish. 18. Click Save, and then click Finish. 19. In the DirectAccess Review dialog box, click Apply. In the DirectAccess Policy Configuration message box, click OK. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
a4420a810f12} Group Policy object, and then click Edit. 5. In the console tree of the Group Policy Management Editor, open Computer Configuration\Policies\Windows Settings, and then click Name Resolution Policy. 6. In the details pane, click the DNS Settings for Direct Access tab, select Enable DNS setting for DirectAccess in this rule, specify the intranet namespace as a suffix rule, click Add, type the IPv6 address of your IPv6/IPv4 DNS gateway, and then click Create. 7. Repeat step 6 for additional namespaces as needed. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
130
If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
134
Note Steps 14 and 15 are optional, but make it easier for you to select the certificate for Secure Hypertext Transfer Protocol (HTTPS) connections in Step 2 of the DirectAccess Setup Wizard. If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
12. Click OK, click Enroll, and then click Finish. 13. In the details pane of the Certificates snap-in, verify that a new certificate with the FQDN was enrolled with Intended Purposes of Server Authentication. In this procedure, you configure the HTTPS security binding on the network location server to use the new SSL certificate. To configure the HTTPS security binding 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 browsers Back button to return to the checklist.
136
If you arrived at this page by clicking a link in a checklist, use your browsers Back button to return to the checklist.
Teredo server
Configure Teredo with the name or IPv4 address of the Teredo server. Configure the IPv6 interfaces for the correct forwarding and advertising behavior.
IPv6 interfaces
1. Run the following command for the 6to4 and Teredo interfaces: netsh interface ipv6 set interface InterfaceIndex forwarding=enabled 2. If a LAN interface is present with a native IPv6 address, run the following command: netsh interface ipv6 set interface InterfaceIndex forwarding=enabled 3. For the IP-HTTPS interface, run the following command: netsh interface ipv6 set interface IPHTTPSInterface forwarding=enabled advertise=enabled
netsh interface 6to4 set state enabled 1. Install the SSL certificate using manual enrollment. 2. Use the netsh http add sslcert command to configure the certificate binding.
IP-HTTPS Interface
netsh interface httpstunnel add interface server https://PublicIPv4AddressOrFQDN:443/iphttps enabled certificates netsh interface ipv6 add route IPHTTPSPrefix::/64 IPHTTPSInterface publish=yes IP-HTTPSPrefix is one of the following: 6to4-basedPrefix:2 if you are using a 6to4-based prefix based on the first public IPv4 address assigned to Internet interface of the DirectAccess server.
138
IP-HTTPS Routing
Component
Purpose
Command
NativePrefix:5555 if you are using a 48bit native IPv6 prefix. 5555 is the Subnet ID value chosen by the DirectAccess Setup Wizard.
Enable ISATAP. Configure the ISATAP router address. Configure ISATAP routing.
netsh interface isatap set state enabled netsh interface isatap set router DirectAccessServerIntranetIPv4Address netsh interface ipv6 add route IntranetPrefix:1::/64 ISATAPInterfaceIndex publish=yes IntranetPrefix is one of the following: The 48-bit 6to4-based prefix based on the first public IPv4 address assigned to Internet interface of the DirectAccess server. Your 48-bit native IPv6 prefix.
ISATAP
Configure intranet interface forwarding and advertising on the ISATAP interface. If you have native IPv6, configure intranet interface forwarding and advertising on the LAN interface. Publish the ISATAP name in DNS on the DNS server.
netsh interface ipv6 set interface ISATAPInterfaceIndex forwarding=enabled advertise=enabled netsh interface ipv6 set interface LANInterfaceIndex forwarding=enabled advertise=enabled
Network Interface
DNS
Purpose
Command
Enable IPsec Denial of Service Protection (DoSP) on the Internet interface. Enable IPsec DoSP on the intranet interface.
netsh ipsecdosp add interface InternetInterfaceName public netsh ipsecdosp add interface intranetInterfaceName internal
Connection security rule for traffic to the intranet DNS server and domain controller (the infrastructure tunnel). Connection security rule for traffic to management servers.
netsh advfirewall consec add rule name="DirectAccess Policy ClientToDNSDC" mode=tunnel profile=public,private Endpoint1=DNSDCIPv6Address Endpoint2=Any LocalTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface RemoteTunnelEndpoint=Any Action=RequireInRequireOut Auth1=ComputerCert Auth1CA=CANameString Auth2=UserNTLM qmsecmethods=ESP:SHA1-AES192+60min+100000kb,ESP:SHA1AES128+60min+100000kb netsh advfirewall consec add rule name="DirectAccess Policy ClientToMgMt" mode=tunnel profile=public,private Endpoint1=ManagementServerIPv6 Addresses Endpoint2=Any LocalTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface RemoteTunnelEndpoint=Any Action=RequireInRequireOut Auth1=ComputerCert Auth1CA=CANameString Auth2=UserNTLM qmsecmethods=ESP:SHA1-AES192+60min+100000kb,ESP:SHA1AES128+60min+100000kb netsh advfirewall consec add rule name="DirectAccess Policy ClientToCorp" mode=tunnel profile=public,private Endpoint1=IntranetIPv6Prefix Endpoint2=Any LocalTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface RemoteTunnelEndpoint=Any Action=RequireInRequireOut Auth1=ComputerCert Auth1CA= Auth1CA=CANameString Auth2=UserKerb qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb
Connection security rule for traffic to the intranet (the intranet tunnel).
140
Connection security rules for client configuration (full intranet access model)
Purpose Command
Connection security rule for traffic to the intranet DNS server and domain controller (the infrastructure tunnel). Connection security rule for traffic to management servers.
netsh advfirewall consec add rule name="DirectAccess Policy ClientToDNSDC" mode=tunnel profile=public,private Endpoint1=Any Endpoint2=DNS-DCIPv6Address LocalTunnelEndpoint=Any RemoteTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface Action=RequireInRequireOut Auth1=ComputerCert Auth1CA=CANameString Auth2=UserNTLM qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb
netsh advfirewall consec add rule name="DirectAccess Policy ClientToCorp" mode=tunnel profile=public,private Endpoint1=Any Endpoint2=IntranetIPv6Prefix LocalTunnelEndpoint=Any RemoteTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface Action=RequireInRequireOut Auth1=ComputerCert Auth1CA= Auth1CA=CANameString Auth2=UserKerb qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb netsh advfirewall consec add rule name="DirectAccess Policy ClientToMgmt" mode=tunnel profile=public,private Endpoint1=Any Endpoint2=ManagementServerIPv6 Addresses LocalTunnelEndpoint=Any RemoteTunnelEndpoint=IPv6AddressOfDirectAccessServerInternetInterface Action=RequireInRequireOut Auth1=ComputerCert Auth1CA=CANameString Auth2=UserNTLM qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1-AES128+60min+100000kb netsh advfirewall consec add rule name=DirectAccess Policy clientToNlaExempt mode=tunnel profile=public,private endpoint1=IntranetIPv6Prefix endpoint2=NetworkLocationServerIPv6Address action=noauthentication protocol=tcp port2=443
Connection security rule for traffic to the intranet (the intranet tunnel).
Connection security rule to exempt IPsec protection to the network location server.
Configure the Teredo client as an enterprise client and configure the Internet Protocol version 4 (IPv4) address of the Teredo server (the DirectAcce ss server). Configure the public IPv4 address of the 6to4 relay (the DirectAcce ss server).
Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies\Teredo State=Enterprise Client and Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\Ipv6 transition Technologies\Teredo Server Name=FirstPublicIPv4AddressOfDirectAcce ssServer
Enable the netsh interface httpstunnel add IP-HTTPS interface client https://SubjectOfIPclient and HPPTSCertificate/IPHTTPS configure the IPHTTPS Uniform Resource Locator (URL).
Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\Ipv6 transition Technologies\IP-HTTPS State set to Enabled and the IP-HTTPS URL of https://SubjectOfIPHPPTSCertificate:443/IPHTTPS
142
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.
CorpPrefix can be accessed by a script using the format $xmldata.root.ServerData.CorpPrefix. Three helper functions provide the ability to do the following:
143
Expand variables Construct commands Run commands and log output Executing PowerShell commands Executing Netsh.exe commands
These functions are extensible and more commands can be added as needed. The functions are: pscmdexec(string command, string description) netshcmdexec(string command, string description) Executing Internet Protocol security (IPsec) or Windows Firewall-related Netsh.exe commands netshipseccmdexec(string setstorecommand, string ipseccommand, string description)
Script 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>]
The first option <serveronly|gpsettingonly|all> is the following: Serveronly Configures only the DirectAccess server. Required settings and policies are not created for Group Policy. GPSettingOnly Creates and configures Group Policy. It does not configure the DirectAccess server. All Configures both the DirectAccess server and the Group Policies. This mode is equivalent to clicking Apply in the DirectAccess Management Console. The data and log options are optional. If they are not present, the script uses %WINDIR %\DirectAccess\DirectAccessConfig.xml and generates the log file in the current directory with the name DirectAccessLog.txt.
Log 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
144
Appendix D - DirectAccessConfig.xsd
The DirectAccessConfig.xml file contains DirectAccess configuration data of the DirectAccess Setup Wizard. The following is the Extended Markup Language (XML) schema definition (XSD) file for DirectAccessConfig.xml. To create a DirectAccessConfig.xsd file, copy the contents to Notepad, and then save the file as DirectAccessConfig.xsd.
<?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="http://www.microsoft.com/networking/DirectAccess/v1" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.microsoft.com/networking/DirectAccess/v1" attributeFormDefault="unqualified" elementFormDefault="qualified"> <xs:element name="root"> <xs:complexType> <xs:all> <xs:element name="ServerData"> <xs:complexType> <xs:all> <xs:element name="CorpPrefix" type="ipv6Prefix" /> <xs:element name="InternetInterface" type="interface" /> <xs:element name="InternalNetworkInterface" type="interface" /> <xs:element name="TransitionTechnologies"> <xs:complexType> <xs:all> <xs:element name="ISATAP" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en-us"> This MUST be specified if there is no pre-existing IPv6 or ISATAP 145
deployment on the internal network. </xs:documentation> </xs:annotation> <xs:complexType> <xs:all> <xs:element name="IsatapRouterName" type="domainName" /> <xs:element name="IsatapInterfaceName" type="domainName" /> <xs:element name="CorpV4Address" type="ipv4Address" /> </xs:all> </xs:complexType> </xs:element> <xs:element name="Teredo"> <xs:complexType> <xs:all> <xs:element name="FirstInternetGlobalAddress" type="ipv4Address" /> </xs:all> </xs:complexType> </xs:element> </xs:all> </xs:complexType> </xs:element> <xs:element name="IPHttps"> <xs:complexType> <xs:all> <xs:element name="IpHttpsPrefix" type="ipv6Prefix" /> <xs:element name="IpHttpsCertHash" type="xs:hexBinary" /> <xs:element name="IpHttpsServerURL" type="xs:anyURI" /> </xs:all> </xs:complexType> </xs:element> <xs:element name="DOSPConfig"> <xs:complexType> <xs:all>
146
<xs:element name="IPsecUnauthenticatedPerIPRate" default="10240" type="xs:unsignedInt" /> <xs:element name="IPsecAuthenticatedRate" default="0" type="xs:unsignedInt" /> <xs:element name="ICMPv6Rate" default="10240" type="xs:unsignedInt" /> </xs:all> </xs:complexType> </xs:element> <xs:element name="IsV6Deployed" type="xs:boolean" /> </xs:all> </xs:complexType> </xs:element> <xs:element name="IIS" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en-us"> This MUST be specified in case network location server is run on the DirectAccess server and certificate used for securing location identification is same as that used by remote client to secure connectivity over IPHTTPS. </xs:documentation> </xs:annotation> <xs:complexType> <xs:all> <xs:element name="IpHttpsAddresses"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" name="Address" type="ipAddress" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="InOutAddresses"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" name="Address" type="ipAddress" /> </xs:sequence> 147
</xs:complexType> </xs:element> </xs:all> </xs:complexType> </xs:element> <xs:element name="GPO"> <xs:complexType> <xs:all> <xs:element name="Common"> <xs:complexType> <xs:all> <xs:element name="AppServers" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en-us"> List of application server addresses that will enforce authorization. This must be specified in case the authorization option is other than NoAuthorization. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" name="Address" type="ipv6Address" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="DnsServers"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" name="Address" type="ipv6Address" /> </xs:sequence> </xs:complexType> </xs:element> 148
<xs:element name="MgmtServers" minOccurs="0"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" name="Address" type="ipv6PrefixOrAddress" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="CorpV6" type="ipv6Prefix" /> <xs:element name="NonCorpV6" type="xs:string" /> <xs:element name="TunnelEndpointDnsDcMgmt" type="ipv6Address" /> <xs:element name="TunnelEndpointCorp" type="ipv6Address" /> <xs:element name="RootCert" type="xs:string" /> <xs:element name="RootCertNetshFormatted" type="xs:string" /> <xs:element name="CertType"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="Root"/> <xs:enumeration value="Intermediate"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="SmartCard"> <xs:complexType> <xs:all> <xs:element name="Option"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="NoSmartCard"/> <xs:enumeration value="RemoteSmartCard"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="SDDLString" type="xs:string" minOccurs="0"> <xs:annotation> 149
<xs:documentation xml:lang="en-us"> This MUST be specified in case SmartCard option selected is RequireSmartCard. </xs:documentation> </xs:annotation> </xs:element> </xs:all> </xs:complexType> </xs:element> <xs:element name="DistinguishedDomainName" type="distinguishedDomainName" /> <xs:element name="DomainName" type="domainName" /> </xs:all> </xs:complexType> </xs:element> <xs:element name="ClientPolicies"> <xs:complexType> <xs:all> <xs:element name="SecurityGroups"> <xs:complexType> <xs:sequence> <xs:element name="SecurityGroup" type="sg" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="NRPT"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" name="entry"> <xs:complexType> <xs:all> <xs:element name="Name" type="xs:string" /> <xs:element name="DirectAccessDNSServers" type="xs:string"> 150
<xs:annotation> <xs:documentation> List of DNS server IPv6 addresses (, delimited) for the DNS suffix specified in Name element above. Can be empty if specifying NRPT exepmption. </xs:documentation> </xs:annotation> </xs:element> </xs:all> <xs:attribute name="PolicyName" type="xs:string" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:unique name="NRPTRuleName"> <xs:selector xpath="*" /> <xs:field xpath="@PolicyName" /> </xs:unique> </xs:element> <xs:element name="DnsFallBackOptions"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="DnsFallbackNameDoesNotExist"/> <xs:enumeration value="DnsAlwaysFallbackForAnyError"/> <xs:enumeration value="DnsAlwaysFallbackPrivateOnly"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="NCSI"> <xs:complexType> <xs:all> <xs:element name="NcsiUrl" type="xs:anyURI" /> <xs:element name="NcsiRrName" type="domainName" /> 151
<xs:element name="NcsiRrIp" type="ipv6Address" fixed="0:0:0:0:0:0:0:1" /> </xs:all> </xs:complexType> </xs:element> <xs:element name="NID"> <xs:complexType> <xs:all> <xs:element name="NidCertHash" type="xs:hexBinary" minOccurs="0"/> <xs:element name="NidUrl" type="xs:anyURI" /> <xs:element name="NidAddress" type="ipv6Address" /> </xs:all> </xs:complexType> </xs:element> <xs:element name="ClientToDnsPolicy" type="xs:string" default="DirectAccess Policy-ClientToDnsDc" /> <xs:element name="ClientToCorpPolicy" type="xs:string" default="DirectAccess Policy-ClientToCorp" /> <xs:element name="ClientToMgmtPolicy" type="xs:string" default="DirectAccess Policy-ClientToMgmt" minOccurs="0" /> <xs:element name="ClientToApplicationServerPolicy" type="xs:string" default="DirectAccess Policy-clientToAppServer" minOccurs="0" /> <xs:element name="ClientToApplicationServerExemptPolicy" type="xs:string" default="DirectAccess Policy-clientToAppServerExempt" minOccurs="0" /> <xs:element name="ClientToNlaExemptPolicy" type="xs:string" default="DirectAccess Policy-clientToNlaExempt" /> <xs:element name="IpHttpsOutRuleName" type="xs:string" default="Core Networking - IPHTTPS (TCP-Out)" /> </xs:all> <xs:attribute name="GPOName" type="xs:string" default="DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}" /> </xs:complexType> </xs:element> <xs:element name="ServerPolicies"> <xs:complexType> 152
<xs:all> <xs:element name="SecurityGroups"> <xs:complexType> <xs:sequence> <xs:element name="SecurityGroup" type="sg" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="ServerToDnsPolicy" type="xs:string" default="DirectAccess Policy-DaServerToDnsDc" /> <xs:element name="ServerToCorpPolicy" type="xs:string" default="DirectAccess Policy-DaServerToCorp" /> <xs:element name="ServerToMgmtPolicy" type="xs:string" default="DirectAccess Policy-DaServerToMgmt" minOccurs="0" /> <xs:element name="IpHttpsInRuleName" type="xs:string" default="Core Networking - IPHTTPS (TCP-In)" /> </xs:all> <xs:attribute name="GPOName" type="xs:string" default="DirectAccess Policy-{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300}" /> </xs:complexType> </xs:element> <xs:element name="AppServerPolicies"> <xs:complexType> <xs:all> <xs:element name="SecurityGroups" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en-us"> List of security groups containing servers that will enforce authorization. MUST be specified in case AuthorizationOption is other than NoAuthorization. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence>
153
<xs:element name="SecurityGroup" type="sg" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="AuthenticationOption"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="NoAuthentication"/> <xs:enumeration value="SelectedServerEndToEnd"/> <xs:enumeration value="EndToEndAuthentication"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="EndToEndIPsecCompatibilityMode" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en-us"> Whether IPsec connection security rules on application servers should allow null encryption. MUST be specified in case AuthorizationOption is other than NoAuthorization. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="ApplicationServerToClientPolicy" type="xs:string" default="DirectAccess Policy-appServerToClient" minOccurs="0" /> <xs:element name="ApplicationServerToIpHttpsClientPolicy" type="xs:string" default="DirectAccess Policy-appServerToIpHttpsClientPolicy" minOccurs="0" /> </xs:all> <xs:attribute name="GPOName" type="xs:string" default="DirectAccess Policy-{f7b77f47-7c33-4d8c-bb9a-a913c5675d8d}" /> </xs:complexType> </xs:element> </xs:all> 154
</xs:complexType> <xs:unique name="GPONames"> <xs:selector xpath="*" /> <xs:field xpath="@GPOName" /> </xs:unique> </xs:element> </xs:all> <xs:attribute name="State" type="xs:string" fixed="Complete" use="required" /> <xs:attribute name="Version" type="xs:decimal" default="1.0" /> </xs:complexType> </xs:element>
<xs:complexType name="sg"> <xs:annotation> <xs:documentation xml:lang="en"> Type representing a security group. </xs:documentation> </xs:annotation> <xs:all> <xs:element name="Name" type="xs:string" /> <xs:element name="Type"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="computer"/> <xs:enumeration value="group"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:all> </xs:complexType>
155
<xs:complexType name="interface"> <xs:annotation> <xs:documentation xml:lang="en"> Type representing an network interface. Holds interface properties. </xs:documentation> </xs:annotation> <xs:all> <xs:element name="Name" type ="xs:string" /> <xs:element name="Id" type="guid" /> </xs:all> </xs:complexType>
<xs:simpleType name="ipv4Address"> <xs:annotation> <xs:documentation xml:lang="en"> The representation of an IPv4 address </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="((0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9] [0-9]?))\.){3}(0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))" /> </xs:restriction> </xs:simpleType>
<xs:simpleType name="ipv6Address"> <xs:annotation> <xs:documentation xml:lang="en"> The representation of an IPv6 address </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4}))|((([0-9a-fA-F] {1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})))|((([0-9a-fA-F]{1,4}:)*([0156
<xs:simpleType name="ipv6Prefix"> <xs:annotation> <xs:documentation xml:lang="en"> The representation of an IPv6 prefix </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})/\d+)|((([0-9a-fA-F] {1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\d+)|((([0-9a-fA-F] {1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*/\d+)|((([0-9afA-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"> The representation of an IPv6 prefix or address </xs:documentation> </xs:annotation> <xs:union memberTypes="ipv6Prefix ipv6Address" /> </xs:simpleType>
157
<xs:documentation xml:lang="en"> The representation of an IP address. This can be IPv4 or IPv6. </xs:documentation> </xs:annotation> <xs:union memberTypes="ipv4Address ipv6Address" /> </xs:simpleType>
<xs:simpleType name="guid"> <xs:annotation> <xs:documentation xml:lang="en"> The representation of a GUID, generally the id of an element. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="\{[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}[a-fA-F0-9]{12}\}"/> </xs:restriction> </xs:simpleType>
<xs:simpleType name="domainName"> <xs:annotation> <xs:documentation> The domainName type represents a DNS domain name. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="([a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*[a-zA-Z][a-zA-Z0-9\-]*[azA-Z0-9]" /> </xs:restriction> </xs:simpleType>
<xs:annotation> <xs:documentation> This type represents a domain name in distinguished name format. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="(DC=[a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9],)*DC=[a-zA-Z][a-zA-Z09\-]*[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
159
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
Use Windows Network Diagnostics as your first troubleshooting tool on the DirectAccess client.
LinkId=157376), which provides much more efficient way to analyze and troubleshoot network problems. To capture a network trace for a DirectAccess client 1. Open an administrator-level command prompt. 2. In the command prompt window, type the netsh trace start scenario=directaccess capture=yes report=yes command. 3. Reproduce the problem that you are having with DirectAccess. 4. In the command prompt window, type the netsh trace stop command. Netsh.exe writes tracing information to the NetTrace.etl file in the %TEMP%\NetTraces folder. To see the contents of this file, open it with Network Monitor 3.3. Netsh.exe also writes additional environment and troubleshooting information to the NetTrace.cab file in the %TEMP%\NetTraces folder.
The Ping.exe Command Line Tool The Nslookup.exe Command Line Tool The Ipconfig.exe Command Line Tool The Certutil.exe Command Line Tool The Nltest.exe Command Line Tool
Certification authority C1-CA DNSSEC (Validation) IPsec settings DirectAccess (DNS Servers) DirectAccess (Proxy Settings)
Settings for .corp.contoso.com ---------------------------------------------------------------------Certification authority C1-CA DNSSEC (Validation) IPsec settings DirectAccess (DNS Servers) DirectAccess (Proxy Settings) : disabled : disabled : 2002:836b:2:1:0:5efe:10.0.0.1 : Bypass proxy : DC=com, DC=contoso, DC=corp, CN=corp-D
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. Note 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.
165
In this example, the DirectAccess client has been configured with the 6to4 relay IPv4 address of 131.107.0.2 through Group Policy. You use the netsh interface 6to4 show relay command to determine where the DirectAccess client is sending its default route IPv6 traffic when it has been configured with a public IPv4 address and using 6to4 to tunnel IPv6 traffic across the Internet.
Client Refresh Interval : 30 seconds Client Port State Error : unspecified : offline : client is in a managed network
In this example, the DirectAccess client has been configured with the Teredo server IPv4 address of 131.107.0.2 through Group Policy and is in an offline state. The following is an example of output from the netsh interface teredo show state command on a DirectAccess server.
Teredo Parameters --------------------------------------------Type : server 166
Virtual Server Ip
: 0.0.0.0
Server Packets Received : 0 Success Failure : 0 (Bubble 0, Echo 0, RS1 0 RS2 0) : 0 (Hdr 0, Src 0, Dest 0, Auth 0)
Packets Received in the last 30 seconds: Bubble 0, Echo 0, RS1 0, RS2 0 6to4 source address 0, native IPv6 source address 0 6to4 destination address 0, native IPv6 destination address 0
Estimated Bandwidth consumed in the last 30 seconds (in BPS): Bubble 0, Echo 0, Primary 0, Secondary 0 6to4 source address 0, native IPv6 source address 0 6to4 destination address 0, native IPv6 destination address 0
In this example, the DirectAccess server is acting as a Teredo server and a Teredo relay and is in an online state. You use the netsh interface teredo show state command on a DirectAccess client to determine the Teredo server of a DirectAccess client and its current state. You use the netsh interface teredo show state command on a DirectAccess server to determine whether it is acting as a Teredo server and its current state.
client, the IP-HTTPS client configuration is set by default through Group Policy. The uniform resource locator (URL) of the IP-HTTPS server is based on the Subject field in the certificate chosen for IP-HTTPS connections in Step 2 of the DirectAccess Setup Wizard. The following is an example of output from the netsh interface httpstunnel show interfaces command on a DirectAccess client.
Interface IPHTTPSInterface (Group Policy) Parameters
-----------------------------------------------------------Role URL Last Error Code Interface Status : client : https://da1.contoso.com:443/IPHTTPS : 0x0 : 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 URL : server : https://da1.contoso.com:443/IPHTTPS
Client authentication mode : certificates Last Error Code Interface Status : 0x0 : IPHTTPS interface active
In this example, the DirectAccess server has been configured as an IP-HTTPS server with the URL https://da1.contoso.com:443/IPHTTPS and uses certificates for authentication. You use the netsh interface httpstunnel show interfaces command on a DirectAccess client to determine the URL of the IP-HTTPS server and the current state of the IP-HTTPS client component. You use the netsh interface httpstunnel show interfaces command on a DirectAccess server to determine URL of the IP-HTTPS server and to verify that it is acting as an IP-HTTPS server and the authentication method. The URL for the netsh interface httpstunnel show interfaces command on both the DirectAccess client and server should be the same.
netsh interface istatap show state and netsh interface istatap show router
These commands show the state and configuration of the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) component on the ISATAP router (the DirectAccess server) or an ISATAP host. Unlike 6to4, Teredo, and IP-HTTPS transition technologies, the DirectAccess Setup Wizard does not configure a name or IPv4 address for an ISATAP router in Group Policy. Instead, it attempts to register the name ISATAP and an assigned intranet IPv4 address with its DNS server. ISATAP
168
hosts on the intranet use the name ISATAP to resolve the IPv4 address of the ISATAP router (the DirectAccess server). The following is an example of output from the netsh interface istatap show state command on a DirectAccess server.
ISATAP State : enabled
In this example, the DirectAccess server has the ISATAP component enabled. The following is an example of output from the netsh interface istatap show router command on the DirectAccess server.
Router Name Use Relay Resolution Interval : isatap.corp.contoso.com : default : 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.
169
Main Mode SA at 09/11/2009 10:43:59 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Auth1: Auth2: MM Offer: Cookie Pair: Health Cert: 2002:836b:65::836b:65 2002:836b:2::836b:2 ComputerCert UserNTLM None-AES128-SHA256 9e355ec21d66e39b:d748c6e2ddd09424 No
Main Mode SA at 09/11/2009 10:43:59 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Auth2 Local ID: Auth2 Remote ID: Auth1: Auth2: MM Offer: Cookie Pair: Health Cert: 2002:836b:65::836b:65 2002:836b:2:1:0:5efe:10.0.0.3 CORP\User1 host/APP1.corp.contoso.com ComputerCert UserKerb None-AES128-SHA256 912ff504e979e831:4eb6fb986fa84eb9 No
Main Mode SA at 09/11/2009 10:43:59 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Auth2 Local ID: Auth2 Remote ID: Auth1: Auth2: MM Offer: Cookie Pair: Health Cert: 2002:836b:65::836b:65 2002:836b:3::836b:3 host/CLIENT2.corp.contoso.com CORP\DA1$ ComputerCert UserKerb None-AES128-SHA256 96d2b451be5756e9:0d2515c811c26034 No
170
Main Mode SA at 09/11/2009 10:43:59 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Auth2 Local ID: Auth2 Remote ID: Auth1: Auth2: MM Offer: Cookie Pair: Health Cert: 2002:836b:65::836b:65 2002:836b:3::836b:3 NT AUTHORITY\SYSTEM host/da1.corp.contoso.com ComputerCert UserKerb None-AES128-SHA256 2ba50b46a6820026:24b64b78e8f7ac0d No
Main Mode SA at 09/11/2009 10:43:59 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Auth2 Local ID: Auth2 Remote ID: Auth1: Auth2: MM Offer: Cookie Pair: Health Cert: Ok. 2002:836b:65::836b:65 2002:836b:3::836b:3 CORP\User1 host/da1.corp.contoso.com ComputerCert UserKerb None-AES128-SHA256 4775f7dd32e268b2:b0ad96d598518fa7 No
The following is an example of output from the netsh advfirewall monitor show mmsa command on the DirectAccess server of the DirectAccess client.
Main Mode SA at 09/11/2009 10:44:03 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Auth1: Auth2: MM Offer: Cookie Pair: Health Cert: 2002:836b:2::836b:2 2002:836b:65::836b:65 ComputerCert UserNTLM None-AES128-SHA256 a075a1437682ad8e:0afed90d0f2a8cac No 171
Main Mode SA at 09/11/2009 10:44:03 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Auth1: Auth2: MM Offer: Cookie Pair: Health Cert: 2002:836b:2::836b:2 2002:836b:65::836b:65 ComputerCert UserNTLM None-AES128-SHA256 9e355ec21d66e39b:d748c6e2ddd09424 No
Main Mode SA at 09/11/2009 10:44:03 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Auth2 Local ID: Auth2 Remote ID: Auth1: Auth2: MM Offer: Cookie Pair: Health Cert: 2002:836b:3::836b:3 2002:836b:65::836b:65 NT AUTHORITY\SYSTEM host/CLIENT2.corp.contoso.com ComputerCert UserKerb None-AES128-SHA256 96d2b451be5756e9:0d2515c811c26034 No
Main Mode SA at 09/11/2009 10:44:03 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Auth2 Local ID: Auth2 Remote ID: Auth1: Auth2: MM Offer: Cookie Pair: Health Cert: 2002:836b:3::836b:3 2002:836b:65::836b:65 host/da1.corp.contoso.com CORP\CLIENT2$ ComputerCert UserKerb None-AES128-SHA256 2ba50b46a6820026:24b64b78e8f7ac0d No
172
Main Mode SA at 09/11/2009 10:44:03 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Auth2 Local ID: Auth2 Remote ID: Auth1: Auth2: MM Offer: Cookie Pair: Health Cert: Ok. 2002:836b:3::836b:3 2002:836b:65::836b:65 host/da1.corp.contoso.com CORP\User1 ComputerCert UserKerb None-AES128-SHA256 4775f7dd32e268b2:b0ad96d598518fa7 No
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.
Quick Mode SA at 09/11/2009 10:56:38 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Local Port: Remote Port: Protocol: Direction: QM Offer: PFS: 2002:836b:65::836b:65 2002:836b:3::836b:3 Any Any Any Both ESP:SHA1-AES192+60min+100000kb None
Quick Mode SA at 09/11/2009 10:56:38 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Local Port: Remote Port: Protocol: Direction: QM Offer: PFS: 2002:836b:65::836b:65 2002:836b:2:1:0:5efe:10.0.0.3 Any Any Any Both ESP:SHA256-None+60min+100000kb None
Quick Mode SA at 09/11/2009 10:56:38 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Local Port: Remote Port: Protocol: Direction: QM Offer: PFS: Ok. 2002:836b:65::836b:65 2002:836b:3::836b:3 Any Any Any Both ESP:SHA1-AES192+60min+100000kb None
174
The following is an example of output from the netsh advfirewall monitor show qmsa command on the DirectAccess server of the DirectAccess client.
Quick Mode SA at 09/11/2009 10:56:47 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Local Port: Remote Port: Protocol: Direction: QM Offer: PFS: 2002:836b:2::836b:2 2002:836b:65::836b:65 Any Any Any Both ESP:SHA1-AES192+60min+100000kb None
Quick Mode SA at 09/11/2009 10:56:47 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Local Port: Remote Port: Protocol: Direction: QM Offer: PFS: 2002:836b:3::836b:3 2002:836b:65::836b:65 Any Any Any Both ESP:SHA1-AES192+60min+100000kb None
Quick Mode SA at 09/11/2009 10:56:47 ---------------------------------------------------------------------Local IP Address: Remote IP Address: Local Port: Remote Port: Protocol: Direction: QM Offer: PFS: Ok. 175 2002:836b:3::836b:3 2002:836b:65::836b:65 Any Any Any Both ESP:SHA1-AES192+60min+100000kb None
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.
Rule Name:
DirectAccess Policy-clientToNlaExempt
---------------------------------------------------------------------Enabled: Profiles: Type: Mode: LocalTunnelEndpoint: RemoteTunnelEndpoint: Endpoint1: Endpoint2: 1:0:5efe:10.0.0.3 Port1: Port2: Protocol: Action: ExemptIPsecProtectedConnections: ApplyAuthorization: Any 443 TCP NoAuthentication No No Yes Private,Public Dynamic Tunnel Any Any 2002:836b:2:1::/64 2002:836b:2:1:0:5efe:10.0.0.3-2002:836b:2:
Rule Name:
DirectAccess Policy-clientToAppServer
---------------------------------------------------------------------176
Enabled: Profiles: Type: Mode: Endpoint1: Endpoint2: 1:0:5efe:10.0.0.3 Protocol: Action: Auth1: Auth1CAName: A Auth1CertMapping: Auth1ExcludeCAName: Auth1CertType: Auth1HealthCert: Auth2: MainModeSecMethods: 1,DHGroup2-3DES-SHA1 QuickModeSecMethods:
ESP:SHA256-None+60min+100000kb,AH:SHA256+6
0min+100000kb,AuthNoEncap:SHA256+60min+100000kb
Rule Name:
DirectAccess Policy-ClientToMgmt
---------------------------------------------------------------------Enabled: Profiles: Type: Mode: LocalTunnelEndpoint: RemoteTunnelEndpoint: Endpoint1: Endpoint2: 6b:2:1:200:5efe:157.60.79.2 Protocol: Any Yes Private,Public Dynamic Tunnel Any 2002:836b:2::836b:2 Any 2002:836b:2:1:200:5efe:157.60.79.2-2002:83
177
Action: Auth1: Auth1CAName: A Auth1CertMapping: Auth1ExcludeCAName: Auth1CertType: Auth1HealthCert: Auth2: MainModeSecMethods: 1,DHGroup2-3DES-SHA1 QuickModeSecMethods: S128+60min+100000kb ExemptIPsecProtectedConnections: ApplyAuthorization:
ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-AE
No No
Rule Name:
DirectAccess Policy-ClientToCorp
---------------------------------------------------------------------Enabled: Profiles: Type: Mode: LocalTunnelEndpoint: RemoteTunnelEndpoint: Endpoint1: Endpoint2: Protocol: Action: Auth1: Auth1CAName: A Auth1CertMapping: Auth1ExcludeCAName: Auth1CertType: No No Root Yes Private,Public Dynamic Tunnel Any 2002:836b:3::836b:3 Any 2002:836b:2:1::/64 Any RequireInRequireOut ComputerCert DC=com, DC=contoso, DC=corp, CN=corp-DC1-C
178
No UserKerb DHGroup2-AES128-SHA256,DHGroup2-AES128-SHA
ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-AE
No No
Rule Name:
DirectAccess Policy-ClientToDnsDc
---------------------------------------------------------------------Enabled: Profiles: Type: Mode: LocalTunnelEndpoint: RemoteTunnelEndpoint: Endpoint1: Endpoint2: 1:0:5efe:10.0.0.1 Protocol: Action: Auth1: Auth1CAName: A Auth1CertMapping: Auth1ExcludeCAName: Auth1CertType: Auth1HealthCert: Auth2: MainModeSecMethods: 1,DHGroup2-3DES-SHA1 QuickModeSecMethods: S128+60min+100000kb ESP:SHA1-AES192+60min+100000kb,ESP:SHA1-AE No No Root No UserNTLM DHGroup2-AES128-SHA256,DHGroup2-AES128-SHA Any RequireInRequireOut ComputerCert DC=com, DC=contoso, DC=corp, CN=corp-DC1-C Yes Private,Public Dynamic Tunnel Any 2002:836b:2::836b:2 Any 2002:836b:2:1:0:5efe:10.0.0.1-2002:836b:2:
179
ExemptIPsecProtectedConnections: ApplyAuthorization:
No 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.
In this example, the DirectAccess server is attached to two networks (corp.contoso.com and Unidentified network). The corp.contoso.com network is assigned the domain profile and the Unidentified network is assigned the public profile. You use the netsh advfirewall monitor show currentprofile command to determine the profiles that are assigned to DirectAccess clients when troubleshooting intranet detection and the profiles assigned to a DirectAccess server when troubleshooting DirectAccess Setup Wizard problems.
11 15 16 17 12
20 25 50 50 20
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).
Weak Host Sends Weak Host Receives Use Automatic Metric Ignore Default Routes Advertised Router Lifetime Advertise Default Route Current Hop Limit Force ARPND Wake up patterns Directed MAC Wake up patterns
Interface isatap.corp.contoso.com Parameters ---------------------------------------------IfLuid IfIndex State Metric Link MTU Reachable Time Base Reachable Time Retransmission Interval DAD Transmits Site Prefix Length Site Id Forwarding Advertising Neighbor Discovery Neighbor Unreachability Detection Router Discovery Managed Address Configuration Other Stateful Configuration Weak Host Sends Weak Host Receives Use Automatic Metric Ignore Default Routes : tunnel_4 : 13 : connected : 25 : 1280 bytes : 16500 ms : 30000 ms : 1000 ms : 0 : 64 : 1 : enabled : enabled : enabled : disabled : enabled : disabled : disabled : enabled : disabled : enabled : disabled
182
Advertised Router Lifetime Advertise Default Route Current Hop Limit Force ARPND Wake up patterns Directed MAC Wake up patterns
Interface isatap.isp.example.com Parameters ---------------------------------------------IfLuid IfIndex State Metric Link MTU Reachable Time Base Reachable Time Retransmission Interval DAD Transmits Site Prefix Length Site Id Forwarding Advertising Neighbor Discovery Neighbor Unreachability Detection Router Discovery Managed Address Configuration Other Stateful Configuration Weak Host Sends Weak Host Receives Use Automatic Metric Ignore Default Routes Advertised Router Lifetime Advertise Default Route Current Hop Limit Force ARPND Wake up patterns : tunnel_5 : 14 : connected : 25 : 1280 bytes : 36000 ms : 30000 ms : 1000 ms : 0 : 64 : 1 : disabled : disabled : enabled : disabled : enabled : disabled : disabled : enabled : disabled : enabled : disabled : 1800 seconds : disabled : 0 : disabled
183
: disabled
Interface Corpnet Parameters ---------------------------------------------IfLuid IfIndex State Metric Link MTU Reachable Time Base Reachable Time Retransmission Interval DAD Transmits Site Prefix Length Site Id Forwarding Advertising Neighbor Discovery Neighbor Unreachability Detection Router Discovery Managed Address Configuration Other Stateful Configuration Weak Host Sends Weak Host Receives Use Automatic Metric Ignore Default Routes Advertised Router Lifetime Advertise Default Route Current Hop Limit Force ARPND Wake up patterns Directed MAC Wake up patterns : ethernet_6 : 11 : connected : 20 : 1500 bytes : 19500 ms : 30000 ms : 1000 ms : 1 : 64 : 1 : enabled : disabled : enabled : enabled : enabled : enabled : enabled : enabled : disabled : enabled : disabled : 1800 seconds : disabled : 0 : disabled : disabled
184
IfLuid IfIndex State Metric Link MTU Reachable Time Base Reachable Time Retransmission Interval DAD Transmits Site Prefix Length Site Id Forwarding Advertising Neighbor Discovery Neighbor Unreachability Detection Router Discovery Managed Address Configuration Other Stateful Configuration Weak Host Sends Weak Host Receives Use Automatic Metric Ignore Default Routes Advertised Router Lifetime Advertise Default Route Current Hop Limit Force ARPND Wake up patterns Directed MAC Wake up patterns
: tunnel_6 : 15 : connected : 25 : 1280 bytes : 37000 ms : 30000 ms : 1000 ms : 0 : 64 : 1 : enabled : disabled : disabled : disabled : enabled : disabled : disabled : enabled : disabled : enabled : disabled : 1800 seconds : disabled : 0 : disabled : disabled
Interface Teredo Tunneling Pseudo-Interface Parameters ---------------------------------------------IfLuid IfIndex State Metric : tunnel_7 : 16 : connected : 50
185
Link MTU Reachable Time Base Reachable Time Retransmission Interval DAD Transmits Site Prefix Length Site Id Forwarding Advertising Neighbor Discovery Neighbor Unreachability Detection Router Discovery Managed Address Configuration Other Stateful Configuration Weak Host Sends Weak Host Receives Use Automatic Metric Ignore Default Routes Advertised Router Lifetime Advertise Default Route Current Hop Limit Force ARPND Wake up patterns Directed MAC Wake up patterns
: 1280 bytes : 13500 ms : 15000 ms : 2000 ms : 0 : 64 : 1 : enabled : disabled : enabled : enabled : enabled : disabled : disabled : enabled : disabled : enabled : disabled : 1800 seconds : disabled : 0 : disabled : disabled
Interface IPHTTPSInterface Parameters ---------------------------------------------IfLuid IfIndex State Metric Link MTU Reachable Time Base Reachable Time Retransmission Interval : tunnel_8 : 17 : connected : 50 : 1280 bytes : 35000 ms : 30000 ms : 1000 ms
186
DAD Transmits Site Prefix Length Site Id Forwarding Advertising Neighbor Discovery Neighbor Unreachability Detection Router Discovery Managed Address Configuration Other Stateful Configuration Weak Host Sends Weak Host Receives Use Automatic Metric Ignore Default Routes Advertised Router Lifetime Advertise Default Route Current Hop Limit Force ARPND Wake up patterns Directed MAC Wake up patterns
: 1 : 64 : 1 : enabled : enabled : enabled : enabled : enabled : disabled : disabled : enabled : disabled : enabled : disabled : 1800 seconds : disabled : 0 : disabled : disabled
Interface Internet Parameters ---------------------------------------------IfLuid IfIndex State Metric Link MTU Reachable Time Base Reachable Time Retransmission Interval DAD Transmits Site Prefix Length Site Id Forwarding : ethernet_9 : 12 : connected : 20 : 1500 bytes : 37000 ms : 30000 ms : 1000 ms : 1 : 64 : 1 : enabled
187
Advertising Neighbor Discovery Neighbor Unreachability Detection Router Discovery Managed Address Configuration Other Stateful Configuration Weak Host Sends Weak Host Receives Use Automatic Metric Ignore Default Routes Advertised Router Lifetime Advertise Default Route Current Hop Limit Force ARPND Wake up patterns Directed MAC Wake up patterns
: disabled : enabled : enabled : enabled : enabled : enabled : enabled : disabled : enabled : disabled : 1800 seconds : disabled : 0 : disabled : disabled
You use the netsh interface ipv6 show interfaces level=verbose command on a DirectAccess server to verify that forwarding has been enabled on the 6to4, Teredo, IP-HTTPS, ISATAP, and local area network (LAN) interfaces and that advertising has been enabled on the IP-HTTPS and ISATAP interfaces.
2002:836b:2:1:0:5efe:10.0.0.2/128
188
2002:836b:2:2::/64 2002:836b:2:2::/128
17 17
2002:836b:2:2:6d5c:17f7:69e8:dd2b/128
15 11 12 16
fe80::/64 fe80::5efe:10.0.0.2/128
17 13
fe80::200:5efe:131.107.0.2/128
Manual
256
fe80::200:5efe:131.107.0.3/128
14
isatap.isp.example.
11 17 16
udo-Interface No No 1 No No nterface No No Manual Manual 256 256 ff00::/8 ff00::/8 11 12 Corpnet Internet Manual Manual 256 256 ff00::/8 ff00::/8 17 16 IPHTTPSInterface Teredo Tunneling Pseudo-I Manual Manual 256 256 fe80::c862:7866:fd45:2ccf/128 ff00::/8 1 12 Internet
Loopback Pseudo-Interface
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 IPHTTPS clients, which is the 64-bit route that begins with 2 or 3 and has the Gateway/Interface Name of IPHTTPSInterface.
189
190
Important Nslookup.exe does not use the Name Resolution Policy Table (NRPT). If you do not specify the IPv6 address of the intranet DNS server, Nslookup.exe will send its queries to interface-configured DNS servers.
. :
Link-local IPv6 Address . . . . . : fe80::b52f:36dc:be07:9d6d%15 IPv4 Address. . . . . . . . . . . : 131.107.0.101 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . :
191
. :
In this example, the DirectAccess client is using 6to4 to reach the DirectAccess server (the interface named Tunnel adapter 6TO4 Adapter has a 6to4-based IPv6 address and default gateway). The following is an example of the output from the ipconfig command on a DirectAccess server.
Windows IP Configuration
. : isp.example.com
Link-local IPv6 Address . . . . . : fe80::c862:7866:fd45:2ccf%12 IPv4 Address. . . . . . . . . . . : 131.107.0.2 Subnet Mask . . . . . . . . . . . : 255.255.255.0 IPv4 Address. . . . . . . . . . . : 131.107.0.3 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . :
192
. : corp.contoso.com
Link-local IPv6 Address . . . . . : fe80::45d1:e335:2f5e:865c%11 IPv4 Address. . . . . . . . . . . : 10.0.0.2 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . :
. : corp.contoso.com
. : isp.example.com
Link-local IPv6 Address . . . . . : fe80::200:5efe:131.107.0.2%14 Link-local IPv6 Address . . . . . : fe80::200:5efe:131.107.0.3%14 Default Gateway . . . . . . . . . :
. : isp.example.com
. :
193
. :
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. Note 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.
194
Simple container name: le-Machine-e4918f29-7e62-48c3-a958-445f367d773d Provider = Microsoft RSA SChannel Cryptographic Provider Private key is NOT exportable Encryption test passed CertUtil: -store command completed successfully.
You use the Certutil.exe command line tool for DirectAccess troubleshooting to determine the subject, enhanced key usage (EKU), and certificate revocation list (CRL) distribution points fields of installed certificates. Use the certutil -v store my > cert.txt command and then view the contents of the Cert.txt file.
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
195
DirectAccess Management
With the Monitoring node of the DirectAccess Management snap-in, you can monitor the overall status and obtain performance counters for DirectAccess server components. To view the status of the DirectAccess server with DirectAccess monitoring 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.
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.
Allows you to specify a 6to4 relay name for a 6to4 host. A 6to4 relay is used as a default gateway for IPv6 network traffic sent by the 6to4 host. Allows you to specify the interval at which the 6to4 relay name is resolved. Allows you to configure the state of the 6to4 client. Allows you to configure the state of the IP-HTTPS client. Allows you to specify a router name or IPv4 address for an ISATAP router. Allows you to configure the
The first consecutive Internet Protocol version 4 (IPv4) address of the DirectAccess servers Internet interface. N/A (not configured)
N/A The IP-HTTPS uniform resource locator (URL) and the interface in a default state. N/A
ISATAP State
N/A
197
Setting name
Description
state of the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) host. Teredo Client Port Allows you to specify the User Datagram Protocol (UDP) port the Teredo client will use to send packets. N/A
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. Allows you to configure the rate at which Teredo clients refresh the Network Address Translator (NAT) translation table. Allows you to specify the name of the Teredo server. Allows you to specify the state of the Teredo service. N/A
The first consecutive IPv4 address of the DirectAccess servers Internet interface. N/A
Teredo State
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.
Setting name
Description
::1
198
Setting name
Description
Probe Host Name. Corporate DNS Probe Host Name A fully qualified domain name (FQDN) to query to determine corporate connectivity. The list of IPv6 addresses and prefixes that define the address space of the corporate network. A URL to request to determine corporate connectivity. The Secure Hypertext Transfer Protocol (HTTPS)based URL of the network location server. directaccesscorpConnectivityHost. ComputerDNSSuffix The IPv6 prefix of the intranet.
The URL specified during the DirectAccess Setup Wizard or obtained from the Subject field of the certificate on the DirectAccess server that was selected for network location.
Use the Group Policy Management Editor snap-in to verify the configuration of these corporate connectivity settingsmost importantly for DirectAccess, the Domain Location Determination URL settingand modify them as needed.
199
Event Viewer
Use the Event Viewer snap-in on a DirectAccess client to examine Windows events for operational Internet Protocol security (IPsec) and Windows Firewall events, intranet detection events, and IPsec negotiation events. To start the Event Viewer snap-in 1. Click Start, type eventvwr.msc, and then press ENTER. 2. In the console tree of Event Viewer, navigate to the appropriate location. 3. In the contents pane, double-click a Windows event to view its details. For troubleshooting DirectAccess problems, view the events in the following locations: Applications and Service Logs\Microsoft\Windows\Windows Firewall with Advanced Security Use this event log to view Windows Firewall and connection security (IPsec) operational events, such as changes to network profiles or firewall settings. Applications and Services Logs\Microsoft\Windows\NCSI\Operational
200
Use this event log to view intranet detection, also known as Inside/Outside detection, and its results. Windows Logs\Security IPsec events in the Windows Logs\Security event log are configured through audit settings, which are not enabled by default. To enable audit settings and view IPsec audit events for IPsec security negotiations, use Auditpol.exe, a command line tool that modifies audit polices of the local computer to enable or disable the various categories and subcategories of events and then view the events in the Event Viewer snap-in. To enable audit policies for IPsec security negotiation, run the auditpol /set /subcategory:IPsec Main Mode,IPsec Extended Mode /success:enable /failure:enable command at an elevated command prompt. Then, view events 4653, 4654 and 4984 in the Windows Logs\Security event log.
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. To view certificates in the computer store with the Certificates snap-in 1. Click Start, type mmc, and then press ENTER. 2. Click File, and then click Add/Remove Snap-in. 3. Click Certificates, click Add, select Computer account, click Next, select Local computer, click Finish, and then click OK. 4. In the console tree of the Certificates snap-in, open Certificates (Local Computer)\Personal\Certificates. 5. To view the properties of a certificate, double-click the certificate in the details pane. You use the Certificates snap-in for DirectAccess troubleshooting to verify the subject, enhanced key usage (EKU), and certificate revocation list (CRL) distribution points on the Details tab for the properties of installed certificates.
4. Negotiation of protection of DirectAccess traffic with the intranet server (for the selected server and end-to-end access models). You can use the following process as a general methodology for incrementally stepping through the DirectAccess connection requirements for a DirectAccess client on the Internet to successfully access an intranet resource: 1. The DirectAccess client computer must be running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows Server 2008 R2. 2. The DirectAccess client computer must be a member of an Active Directory Domain Services (AD DS) domain and its computer account must be a member of one of the security groups configured in step 1 of the DirectAccess Setup Wizard. 3. The DirectAccess client computer must have received computer configuration Group Policy settings for DirectAccess. To verify, use the Resultant Set of Policy snap-in to ensure that DirectAccess Policy{3491980e-ef3c-4ed3-b176-a4420a810f12} is listed for the computer configuration Group Policy objects associated with the DirectAccess client computer. 4. The DirectAccess server computer must have received computer configuration Group Policy settings for DirectAccess. To verify, use the Resultant Set of Policy snap-in to ensure that DirectAccess Policy{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300} is listed for the computer configuration Group Policy objects associated with the DirectAccess server computer. 5. The DirectAccess client must have a global IPv6 address. Use the ipconfig command to display the Transmission Control Protocol/Internet Protocol (TCP/IP) configuration. Is there an IPv6 address assigned to an interface that begins with 2 or 3? If so, go to step 6. If not, use the netsh interface 6to4 show relay, netsh interface teredo show state, and netsh interface httpstunnel show interfaces commands on the DirectAccess client and server to verify the configuration of 6to4, Teredo, and Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS). Tips 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
202
address that starts with 2002. The Tunnel adapter iphttpsinterface should also be assigned a default gateway. For more information and additional troubleshooting steps, see Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server over the Internet. 6. The DirectAccess client must be able to reach the IPv6 addresses of the DirectAccess server. Use the ipconfig command on the DirectAccess server to display the TCP/IP configuration. Note the global IPv6 addresses of the DirectAccess server (those starting with 2 or 3). From the DirectAccess client, ping any of the global IPv6 addresses of the DirectAccess server, starting with the IPv6 addresses that begin with 2002. If successful, go to step 7. If not successful, troubleshoot the IPv6 reachability between the DirectAccess client and server. For more information and additional troubleshooting steps, see Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server over the Internet. 7. The intranet servers have a global IPv6 address. Use the ipconfig command on the intranet server to display the TCP/IP configuration. Is there an IPv6 address assigned to an interface that begins with 2 or 3? If so, go to step 8. If not, troubleshoot the IPv6 infrastructure on your intranet. For Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), ensure that your Domain Name System (DNS) servers running Windows Server 2008 or later have the name ISATAP removed from their global query block lists. Additionally, verify that the DirectAccess server has registered an ISATAP A record in the intranet DNS. For additional information and troubleshooting steps, see DirectAccess Client Cannot Access Intranet Resources. Note If you are using an IPv6/IPv4 translator such as NAT64 or Network Address Translation-Protocol Translation (NAT-PT) to reach the intranet server, it will not have a global IPv6 address. In this case, ensure that the NAT64 or NAT-PT has a global IPv6 address. 8. The DirectAccess client on the Internet must correctly determine that it is not on the intranet. Use the netsh namespace show effectivepolicy command to display the Name Resolution Policy Table (NRPT). There should be NRPT rules for the intranet namespace and an exemption rule for the fully qualified domain name (FQDN) of the network location server. If you have the appropriate rules in your NRPT, go to step 9. If not, determine the network location uniform resource locator (URL) from the reg query HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\Corpo rateConnectivity /v DomainLocationDeterminationUrl command. Ensure that the FQDN from this URL either does not match the DNS suffix for your intranet namespace in the NRPT or matches an exemption rule.
203
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. 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. Note The use of the Ping.exe tool assumes the default global Internet Protocol security (IPsec) settings that exempt Internet Control Message Protocol (ICMP) traffic from IPsec protection. 11. The DirectAccess client must be able to use intranet DNS servers to resolve intranet FQDNs. Use the nslookup q=aaaa IntranetFQDN IntranetDNSServerIPv6Address command to resolve the names of intranet servers (example: nslookup q=aaaa dc1.corp.contoso.com 2002:836b:2:1::5efe:10.0.0.1). The Nslookup.exe tool should display the IPv6 addresses of the specified intranet server. If the Nslookup.exe tool performs successful name resolution, go to step 12. If there is no response from the intranet DNS server, go to step 14. If the name was not found, determine why the corresponding AAAA record is not in your intranet DNS. For additional information and troubleshooting steps, see DirectAccess Client Cannot Resolve Names with Intranet DNS Servers. 12. The DirectAccess client must have reachability to the intranet servers. Use the Ping.exe tool to ping the IPv6 addresses of intranet servers. If successful, go to step 13.
204
If not successful, troubleshoot the IPv6 reachability between the DirectAccess client and the intranet servers. Note 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 IPv6capable. If not, you cannot use it for DirectAccess. If not successful, go to step 14. 14. For the end-to-edge or selected server access models, the DirectAccess client must be able to successfully negotiate main mode and quick mode IPsec security associations (SAs) with the DirectAccess server for the infrastructure tunnel. On the DirectAccess client, use the Windows Firewall with Advanced Security snap-in or the netsh advfirewall monitor show mmsa and netsh advfirewall monitor show qmsa commands to determine if there are main mode and quick mode SAs to the IPv6 address 2002:WWXX:YYZZ::WWXX:YYZZ. WWXX:YYZZ is the colon-hexadecimal representation of the first consecutive IPv4 address assigned to the Internet interface of the DirectAccess 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
205
2002:RRSS:TTUU::RRSS:TTUU. RRSS:TTUU is the colon-hexadecimal representation of the second consecutive IPv4 address assigned to the Internet interface of the DirectAccess server. If the SAs exist and you are using an IPv6/IPv4 translator such as NAT64 or NAT-PT to reach the intranet server, verify that the IPv6/IPv4 translator supports translating the application protocol. Some protocols embed IP address information in the packet payload and cannot be used across some IPv6/IPv4 translators. If successful, go to step 16. If not successful, use the nltest /dsgetdc: /force command on the DirectAccess server to ensure that it has access to a domain controller. If there are no domain controllers listed, troubleshoot the lack of discoverability and connectivity between the DirectAccess server and Active Directory. Use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it has access to a domain controller. If there are no domain controllers listed, ensure that the IPv6capable 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 IPv6capable domain controllers that are being used by DirectAccess clients are using site-less locator records in DNS. Ensure that the DirectAccess client and intranet or selected server have the proper certificates for IPsec peer authentication.
206
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.
Fixing Problems Encountered when Applying the Settings of the DirectAccess Setup Wizard
Fixing problems that Prevent You from Running the DirectAccess Setup Wizard
If the DirectAccess server does not meet the configuration requirements, when you run the DirectAccess Management snap-in and click Setup in the console tree, the DirectAccess Management snap-in displays a series of messages indicating the error conditions that exist. The following table lists the most common error messages, a description of the error condition, and the steps to correct it.
207
Error message
The current security context is not associated or accessible to Active Directory Domain Services (AD DS).
The DirectAccess server cannot reach a domain controller of the domain in which it is a member. Verify the connection to your intranet and name resolution and reachability to an intranet domain controller. The DirectAccess server cannot be a standalone server. Join it to the appropriate AD DS domain. The DirectAccess server cannot reach a domain controller of the domain in which it is a member. Verify the connection to your intranet and name resolution and reachability to an intranet domain controller. The DirectAccess server requires two physical network adapters corresponding to two local area network (LAN) or wireless LAN (WLAN) network adapters that are installed in the DirectAccess server computer. The network connections corresponding to the network adapters for the DirectAccess servers connection to the Internet and intranet must be configured with static Internet Protocol version 4 (IPv4) addresses. They cannot use the Dynamic Host Configuration Protocol (DHCP) to obtain an IPv4 address configuration. At least one of the network connections corresponding to the network adapters installed in the DirectAccess server must have two, consecutive public IPv4 addresses statically assigned. These two consecutive addresses are needed by the DirectAccess server to act as a Teredo server. Obtain two consecutive addresses and assign them to a network adapter on the DirectAccess server. Note The DirectAccess Management console sorts the public IPv4 addresses alphabetically. Therefore, the DirectAccess Management console
208
The DirectAccess server must be joined to an Active Directory domain. Please join this server to a domain and then try again. The Active Directory domain is unreachable. Unable to get domain information.
The DirectAccess server must have two or more physical network interfaces. Verify that you have two or more interfaces and then try again. At least two network interfaces must be configured with static IP addresses. Please contact the network administrator to obtain and assign static IP addresses to this server.
The DirectAccess server must have two consecutive public IPv4 addresses configured on the same physical interface. Configure IPv4 addresses and try again.
Error message
does not consider the following sets of addresses as consecutive: w.x.y.9 and w.x.y.10, which is sorted as w.x.y.10, w.x.y.9; w.x.y.99 and w.x.y.100, which is sorted as w.x.y.100, w.x.y.99; w.x.y.1, w.x.y.2, and w.x.y.10, which is sorted as w.x.y.1, w.x.y.10, w.x.y.2. Use a different set of consecutive addresses. For additional information about events and errors encountered by the DirectAccess Management snap-in, see the %SystemRoot%\Tracing\DASetup.log file. For more information about the configuration requirements of the DirectAccess server, see Appendix A: DirectAccess Requirements and Checklist: Preparing Your DirectAccess Server.
Fixing Problems Encountered during the Steps of the DirectAccess Setup Wizard
The following sections describe problems that you might encounter on the pages of the DirectAccess Setup Wizard in the DirectAccess Management snap-in and how to correct them. For additional information about events and errors encountered by the DirectAccess Setup Wizard, see the %SystemRoot%\Tracing\DASetup.log file.
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.
Error message Error condition and the steps to correct
Error message
consecutive global Internet Protocol version 4 (IPv4) addresses configured. Select an interface with two consecutive global IPv4 addresses.
consecutive public IPv4 addresses statically assigned. These two consecutive addresses are needed by the DirectAccess server to act as a Teredo server. Note The DirectAccess Management console sorts the public IPv4 addresses alphabetically. Therefore, the DirectAccess Management console does not consider the following sets of addresses as consecutive: w.x.y.9 and w.x.y.10, which is sorted as w.x.y.10, w.x.y.9; w.x.y.99 and w.x.y.100, which is sorted as w.x.y.100, w.x.y.99; w.x.y.1, w.x.y.2, and w.x.y.10, which is sorted as w.x.y.1, w.x.y.10, w.x.y.2. Use a different set of consecutive addresses.
The interface that you have specified for the Internet is connected to a network that contains a domain controller (the network has been assigned the domain firewall profile). The Internet interface must be connected to a network that has been assigned the Public or Private profiles. Select a different interface or add outbound packet filters to the selected interface that block connectivity to the IP addresses of the domain controllers. For more information, see Configure Packet Filters to Block Access to Domain Controllers. You can use the netsh advfirewall monitor show currentprofile command to display the networks to which your computer is attached and their assigned profiles. Then, use the Network Connections window to determine the networks to which the interfaces are connected.
The interface that you have specified for the intranet (internal network) is connected to a network that has been assigned the Private or Public firewall profile. The intranet interface must be connected to a network that has been assigned the Domain profile, which contains a
210
Error message
domain controller. Select a different interface. You can use the netsh advfirewall monitor show currentprofile command to display the networks to which your computer is attached and their assigned profiles. Then, use the Network Connections window to determine the networks to which the interfaces are connected. The internal network interface does not have Domain Name System (DNS) server settings configured. Select an interface with DNS server settings configured. The intranet (internal network) interface must be manually configured with the IPv4 or IPv6 addresses of at least one intranet DNS server. Select another interface or manually configure the appropriate interface with the IPv4 or Internet Protocol version 6 (IPv6) addresses of at least one intranet DNS server. The intranet (internal network) interface must be manually configured with a connection-specific DNS suffix that represents your intranet DNS namespace (for example, corp.contoso.com). Select another interface or manually configure the appropriate interface with a connectionspecific DNS suffix. Your Internet interface has a native IPv6 address assigned. The DirectAccess Setup Wizard will configure IPv6 for the intranet without regard to the IPv6 configuration of the Internet interface. However, you will need to configure packet filters on the Internet interface to prevent the Internet interface from being assigned the Domain firewall profile. For more information, see Configure Packet Filters to Block Access to Domain Controllers.
The internal network interface does not have a connection-specific DNS suffix. Select an interface with a connection-specific DNS suffix.
IPv6 was detected on your Internet interface. DirectAccess setup will apply settings without considering the IPv6 settings on the Internet interface.
211
The following table lists the error messages you might see when specifying the organization or IP-HTTPS prefixes.
Error message Error condition and the steps to correct
The IPv6 prefix you provided for the internal network is not valid. Provide a valid IPv6 prefix. The IPv6 prefix you provided to assign to the IPv6 addresses of remote client computers is not valid. Provide a valid IPv6 prefix.
You have not specified a valid global or unique local address prefix for your organization. You have not specified a valid 64-bit global or unique local address prefix for your IP-HTTPSbased 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 required to configure DirectAccess clients with or an HTTPS-based URL of the IP-HTTPS server The selected certificate does not contain a (the DirectAccess server). subject name.
212
Error message
The selected certificate does not have Server Authentication Enhanced Key Usage enabled.
The certificate that you selected does not have the Server Authentication object identifier (OID) in the Enhanced Key Usage (EKU) field. The Server Authentication OID is required by the DirectAccess server to perform HTTPS-based authentications as the IP-HTTPS server. Select a certificate with a Server Authentication OID or obtain a new certificate with a Server Authentication OID. To see the value of the EKU field, use the Certificates snap-in for the local computer store, obtain properties of the certificate, and then click the Details tab. The DirectAccess Setup Wizard cannot resolve the fully qualified domain name (FQDN) in the Subject field of the selected certificate. Select a certificate with a resolvable FQDN in the Subject field or obtain a new certificate with a resolvable FQDN.
Unable to resolve the subject name of the certificate to a valid Internet Protocol (IP) address.
The following topics describe the most typical problems encountered on the Location and DNS and Domain Controller pages.
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.
213
If you are using an IP address in the FQDN portion of the URL, it must be an IPv6 address and it must be reachable by the DirectAccess server over IPv6. If you have selected the DirectAccess server as the network location server, you might see the message The IP and Domain Restrictions role service of the Web Server (IIS) role must be installed for network location to work properly on the DirectAccess server. Install this role service and try again. The IP and Domain Restrictions role service prevents DirectAccess clients on the Internet from reaching the network location URL on the DirectAccess server. Additionally, you cannot select the certificate that you are using for IP-HTTPS as the network location server certificate. Select another certificate or obtain an additional certificate with the Server Authentication OID. For more information about the network location certificate requirements, see Design Your PKI for DirectAccess.
214
Fixing Problems Encountered when Applying the Settings of the DirectAccess Setup Wizard
When you click Apply from the DirectAccess Review dialog box, the DirectAccess Server Setup Wizard configures the DirectAccess server and a set of Group Policy objects and their settings. The following table lists the most common types of error messages that you might encounter during this step.
Error message Error condition and the steps to correct
Registration of Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) in Domain Name System (DNS) failed.
The DirectAccess server computer does not have the privileges to use DNS dynamic update to create an Address (A) record in its DNS server for the name ISATAP. This most commonly occurs when using a DNS server that is not running Windows. Configure the appropriate privileges or permissions so that the DirectAccess server computer can create this A record. You must log on to the DirectAccess server computer with a user account that has local administrator privileges. The IP-HTTPS interface is not active. Use the netsh interface httpstunnel show interfaces command to display the state of the IP-HTTPS interface. The 6to4 service is not active. Use the netsh interface 6to4 show state command to display the state of the 6to4 service. If needed, start the 6to4 service with the netsh interface 6to4 set state enabled command.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this operation. DirectAccess server configuration failed because the IP-HTTPS interface cannot be configured. DirectAccess server configuration failed because the 6to4 interface is not operational.
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
215
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
Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server over the Internet
The typical problems with connectivity issues between the DirectAccess client and the DirectAccess server over the Internet are the following: Cannot Reach the DirectAccess Server from the IPv6 Internet Cannot Reach the DirectAccess Server with 6to4 Cannot Reach the DirectAccess Server with Teredo Cannot Reach the DirectAccess Server with IP-HTTPS DirectAccess Client Connection is Slow
If the DirectAccess server is also on the IPv6 Internet, the routing infrastructure of the IPv6 Internet forwards IPv6 traffic directly to the DirectAccess server (IPv6 reachability endto-end). If the DirectAccess server is on the Internet Protocol version 4 (IPv4) Internet and using 6to4, the routing infrastructure of the IPv6 Internet forwards the traffic to a 6to4 relay, which forwards the encapsulated IPv6 traffic across the IPv4 Internet to the DirectAccess server (IPv6 reachability from DirectAccess client to the 6to4 relay, IPv4-encapsulated IPv6 reachability from the 6to4 relay to the DirectAccess server). In either case, there must be a routing path between the DirectAccess client and server that allows the following types of IPv6 traffic: Internet Control Message Protocol for IPv6 (ICMPv6) (IPv6 Next Header value of 58) Internet Key Exchange (IKE)/Authenticating Internet Protocol (AuthIP) (User Datagram Protocol [UDP] port 500) Internet Protocol security (IPsec) Encapsulating Security Protocol (ESP) (IPv6 Next Header value of 50) To ensure that your DirectAccess server is on the IPv6 Internet, run the ipconfig command at a Command Prompt. There should be an IPv6 address assigned to your network adapter that starts with 2 or 3 but is not based on the 2002::/16 or 2001:0::/32 prefixes. To troubleshoot connectivity from a DirectAccess client on the IPv6 Internet to the DirectAccess server 1. On the DirectAccess client, start a command prompt as an administrator. 2. From the Command Prompt window, run the netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} command. 3. From the Command Prompt window, run the netsh advfirewall consec show rule name=DirectAccess Policy-ClientToDnsDc command. 4. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint. This is the IPv6 address of the DirectAccess server for the infrastructure tunnel. If you cannot reach this IPv6 address, use the tracert d IPv6Address command to trace the route to the destination. 5. From the Command Prompt window, run the netsh advfirewall consec show rule name=DirectAccess Policy-ClientToCorp command. 6. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint. This is the IPv6 address of the DirectAccess server for the intranet tunnel. If you cannot reach this IPv6 address, use the tracert d IPv6Address command to trace the route to the destination.
217
the DisabledComponents registry value is not present, the command displays ERROR: The system was unable to find the specified registry key or value. If DisabledComponents is present and it is not 0, convert it to a binary number. If the first or second bit from the right in the binary number is 1, DisabledComponents has disabled 6to4. You must change the first and second bit from the right to 0 to enable 6to4. 3. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition /v 6to4_RouterName command. This command should display the first consecutive public IPv4 address of the DirectAccess servers Internet interface. 4. From the Command Prompt window, run the netsh interface 6to4 show relay command. This command should display the first consecutive public IPv4 address of the DirectAccess servers Internet interface in Relay Name. 5. From the Command Prompt window, run the netsh interface 6to4 show state command. This command should display default or enabled in 6to4 Service State. The 6to4 service state should not show disabled. A value of disabled means that the DirectAccess client will never bring up a 6to4 interface. A value of default means that the DirectAccess client will bring up a 6to4 interface if it does not have a global IPv6 address assigned already and it has a public IPv4 address. A value of enabled means that the DirectAccess client will bring up a 6to4 interface whenever it has a public IPv4 address assigned. 6. From the Command Prompt window, run the netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} command. 7. From the Command Prompt window, run the netsh advfirewall consec show rule name=DirectAccess Policy-ClientToDnsDc command. 8. From the Command Prompt window, note the IPv6 address in RemoteTunnelEndpoint. 9. From the Command Prompt window, run the route print command. The IPv6 route table should have ::/0 route with the Gateway address set to the IPv6 address in step 8. The IPv6 route table should also have 2002::/16 route with the Gateway address set to On-link. To verify 6to4 functionality and configuration on the DirectAccess server 1. On the DirectAccess server, start a command prompt as an administrator. 2. From the Command Prompt window, run the ipconfig command. This command should display a interface named Tunnel adapter 6TO4 Adapter that has the Domain Name System (DNS) suffix configured on the Internet interface and with two
219
IPv6 addresses of the form 2002:WWXX:YYZZ::WWXX:YYZZ, corresponding to the two consecutive IPv4 addresses assigned to the Internet interface. 3. From the Command Prompt window, run the reg query HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command. If the DisabledComponents registry value is present, the command displays its value. If the DisabledComponents registry value is not present, the command displays ERROR: The system was unable to find the specified registry key or value. If DisabledComponents is present and it is not 0, convert it to a binary number. If the first or second bit from the right in the binary number is 1, DisabledComponents has disabled 6to4. You must change the first and second bit from the right to 0 to enable 6to4. 4. From the Command Prompt window, run the netsh interface 6to4 show state command. This command should display enabled in 6to4 Service State. The 6to4 service state should not show disabled. A value of disabled means that the DirectAccess server will never bring up a 6to4 interface. A value of default means that the DirectAccess server will bring up a 6to4 interface if it does not have a global IPv6 address assigned already and it has a public IPv4 address. A value of enabled means that the DirectAccess server will bring up a 6to4 interface whenever it has a public IPv4 address assigned. 5. From the Command Prompt window, run the route print command. The IPv6 route table should have 2002::/16 route with the interface index of the Microsoft 6to4 Adapter and the Gateway address set to On-link. To troubleshoot connectivity from a 6to4-based DirectAccess client on the IPv4 Internet to the DirectAccess server 1. On the DirectAccess client, start a command prompt as an administrator. 2. From the Command Prompt window, run the netsh interface 6to4 show relay command. This command should display the first consecutive public IPv4 address of the DirectAccess servers Internet interface in Relay Name. 3. From the Command Prompt window, ping the IPv4 address from step 2. This step ensures that the DirectAccess client can reach the first public IPv4 address of the DirectAccess server. 4. From the Command Prompt window, ping the next consecutive IPv4 address from step 2. This step ensures that the DirectAccess can reach the second public IPv4 address of the DirectAccess server. 5. From the Command Prompt window, run the netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} command.
220
6. From the Command Prompt window, run the netsh advfirewall consec show rule name=DirectAccess Policy-ClientToDnsDc command. 7. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint. This is the IPv6 address of the DirectAccess server for the infrastructure tunnel. If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the tracert d IPv6Address command to trace the route to the destination. 8. From the Command Prompt window, run the netsh advfirewall consec show rule name=DirectAccess Policy-ClientToCorp command. 9. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint. This is the IPv6 address of the DirectAccess server for the intranet tunnel. If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the tracert d IPv6Address command to trace the route to the destination.
Internet Protocol security (IPsec) Encapsulating Security Protocol (ESP) (IPv6 Next Header value of 50) To verify Teredo functionality and configuration on a DirectAccess client 1. On the DirectAccess client, start a command prompt as an administrator. 2. From the Command Prompt window, run the ipconfig command. You should see a Tunnel adapter Teredo Tunneling Pseudo-Interface with an IPv6 address that begins with 2001. 3. From the Command Prompt window, run the route print command. The IPv6 route table should have a ::/0 route with the interface index of the Microsoft Teredo Tunnel Adapter and the Gateway address set to On-link. 4. From the Command Prompt window, run the reg query HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command. If the DisabledComponents registry value is present, the command displays its value. If the DisabledComponents registry value is not present, the command displays ERROR: The system was unable to find the specified registry key or value. If DisabledComponents is present and it is not 0, convert it to a binary number. If the first 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 servers Internet interface. 6. From the Command Prompt window, run the netsh interface teredo show state command. This command should display enterpriseclient or client in Type and the first consecutive public IPv4 address of the DirectAccess servers Internet interface in Server Name. See the following table for information about the Teredo client state.
Teredo state Description
qualified
The Teredo tunnel interface has completed its negotiation with the Teredo server and has been used recently. The Teredo tunnel interface has completed its negotiation with the Teredo server but has not been used recently. The Teredo tunnel interface has completed its
222
dormant
probe
Teredo state
Description
negotiation with the Teredo server. offline An error or other condition has occurred and the Teredo interface is not active.
If the Teredo state is offline and the error state is Teredo server is unreachable over UDP, UDP port 3544 traffic may be blocked somewhere between the DirectAccess client and the DirectAccess server due to the following: A third-party host firewall that is running on the DirectAccess client. An intermediate router or network firewall between the DirectAccess client and the DirectAccess server. It is a common practice in organizations to block unexpected UDP traffic with their Internet firewalls. Another possibility is that the DirectAccess server is not available. If the Teredo state is offline and the error state is Client is in a managed network, the DirectAccess client has detected a local Active Directory domain. In this case, the Teredo client will not bring up the Teredo tunnel adapter unless the Teredo client has been configured as an enterprise client. You can view the Teredo client type from the netsh interface teredo show state command. If set to client, a reachable domain controller will prevent Teredo from becoming active. If it set to enterpriseclient, Teredo will be active even when a domain controller is reachable. You can change a Teredo client from client to enterpriseclient with the Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies\Teredo State setting of the Group Policy object for DirectAccess clients or for an individual DirectAccess client with the netsh interface teredo set state enterpriseclient command. To verify Teredo functionality and configuration on the DirectAccess server 1. On the DirectAccess server, start a command prompt as an administrator. 2. From the Command Prompt window, run the route print command. The IPv6 route table should have a 2001::/32 route with the interface index of the Teredo Tunneling Pseudo-Interface and the Gateway address set to On-link. 3. From the Command Prompt window, run the reg query HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command. If the DisabledComponents registry value is present, the command displays its value. If the DisabledComponents registry value is not present, the command displays ERROR: The system was unable to find the specified registry key or value. If DisabledComponents is present and it is not 0, convert it to a binary number. If the first or fourth bit from the right in the binary number is 1, DisabledComponents has disabled Teredo. You must change the first and fourth bit from the right to 0 to enable Teredo. 4. From the Command Prompt window, run the netsh interface teredo show state
223
command. This command should display server in Type and online in State. To troubleshoot connectivity from a Teredo-based DirectAccess client on the IPv4 Internet to the DirectAccess server 1. On the DirectAccess client, start a command prompt as an administrator. 2. From the Command Prompt window, run the netsh interface teredo show state command. This command should display the first consecutive public IPv4 address of the DirectAccess servers Internet interface in Server Name. 3. From the Command Prompt window, ping the IPv4 address from step 2. If there is a name in Server Name instead of an address, ping the name and ensure that it resolves to the first consecutive public IPv4 address of the DirectAccess servers Internet interface. This step ensures that the DirectAccess can reach the first public IPv4 address of the DirectAccess server. 4. From the Command Prompt window, ping the next consecutive IPv4 address from step 2. This step ensures that the DirectAccess can reach the second public IPv4 address of the DirectAccess server. 5. From the Command Prompt window, run the netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} command. 6. From the Command Prompt window, run the netsh advfirewall consec show rule name=DirectAccess Policy-ClientToDnsDc command. 7. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint. This is the IPv6 address of the DirectAccess server for the infrastructure tunnel. If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the tracert d IPv6Address command to trace the route to the destination. 8. From the Command Prompt window, run the netsh advfirewall consec show rule name=DirectAccess Policy-ClientToCorp command. 9. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint. This is the IPv6 address of the DirectAccess server for the intranet tunnel. If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the tracert d IPv6Address command to trace the route to the destination.
224
state=enabled command. 4. From the Command Prompt window, run the netsh interface httpstunnel show interfaces command. This command should display client in Role and the IP-HTTPS URL from step 3 in URL. To verify IP-HTTPS functionality and configuration on the DirectAccess server 1. On the DirectAccess server, start a command prompt as an administrator. 2. From the Command Prompt window, run the reg query HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command. If the DisabledComponents registry value is present, the command displays its value. If the DisabledComponents registry value is not present, the command displays ERROR: The system was unable to find the specified registry key or value. If DisabledComponents is present and it is not 0, convert it to a binary number. If the first bit from the right in the binary number is 1, DisabledComponents has disabled IP-HTTPS. You must change the first bit from the right to 0 to enable IP-HTTPS. 3. From the Command Prompt window, run the netsh interface httpstunnel show interfaces command. This command should display server in Role, the IP-HTTPS URL in URL, and IPHTTPS interface active in Interface Status. To troubleshoot connectivity from an IP-HTTPS-based DirectAccess client on the IPv4 Internet to the DirectAccess server 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 3. This ensures that the DirectAccess client can resolve the name of the IP-HTTPS server
226
in the URL and reach the resolved IPv4 address of the DirectAccess server. 6. Paste the URL from step 3 into your Internet browser and attempt to access it. Ensure that the IP-HTTPS web site is accessible and has no certificate errors. If there are certificate errors, see the To troubleshoot certificate problems for an IP-HTTPSbased connection to the DirectAccess server procedure in this topic. 7. From the Command Prompt window, run the netsh advfirewall set store gpo=DomainName\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} command. 8. From the Command Prompt window, run the netsh advfirewall consec show rule name=DirectAccess Policy-ClientToDnsDc command. 9. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint. This is the IPv6 address of the DirectAccess server for the infrastructure tunnel. If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the tracert d IPv6Address command to trace the route to the destination. 10. From the Command Prompt window, run the netsh advfirewall consec show rule name=DirectAccess Policy-ClientToCorp command. 11. From the Command Prompt window, ping the IPv6 address in RemoteTunnelEndpoint. This is the IPv6 address of the DirectAccess server for the intranet tunnel. If the IPv6 address is not a 6to4 address and you cannot reach this IPv6 address, use the tracert d IPv6Address command to trace the route to the destination. To troubleshoot certificate problems for an IP-HTTPS-based connection to the DirectAccess server 1. Ensure that the FQDN in the IP-HTTPS URL matches the Subject field of the IPHTTPS certificate on the DirectAccess server. If not, you need to either select the correct certificate on the DirectAccess server or install a certificate that can be used for IP-HTTPS connections. For information about IP-HTTPS certificate requirements, see Design Your PKI for DirectAccess. 2. Using the Certificates snap-in to view the properties of the IP-HTTPS certificate on the DirectAccess server, determine the Internet certificate revocation list (CRL) distribution point locations for the IP-HTTPS certificate (the URL without the file name). 3. From a Command Prompt window on the DirectAccess client, ping the FQDN from the CRL distribution point location in step 2. This step ensures that the DirectAccess client can resolve the name of the CRL distribution point server location and reach the resolved address. 4. Type the Internet CRL distribution point from step 2 into your Internet browser. You should see a series of files with the .crl extension. Ensure that you can open the .crl files. If you cannot reach the CRL distribution point and open the .crl files from the
227
DirectAccess client, you cannot use IP-HTTPS. 5. Perform certificate troubleshooting on the DirectAccess client and server to ensure that the DirectAccess client can successfully validate the IP-HTTPS certificate of the DirectAccess server and the DirectAccess server can successfully validate the IP-HTTPS certificate of the DirectAccess client.
The DirectAccess client needs to determine which of these two transition technologies to use. IPHTTPS 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.
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.
229
230
To verify whether the DirectAccess client can successfully create the infrastructure tunnel 1. On the DirectAccess client, start a command prompt as an administrator. 2. On the DirectAccess client, click Start, type wf.msc, and then press ENTER. 3. In the tree pane of the Windows Firewall with Advanced Security snap-in console, click Connection Security Rules. In the details pane, you should see connection security rules whose names begin with DirectAccess Policy. If not, this DirectAccess client has not received its connection security rules from computer configuration Group Policy. Verify that the DirectAccess client is running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows Server 2008 R2 and is a member of one of the security groups specified in step 1 of the DirectAccess Setup Wizard. 4. In the tree pane of the Windows Firewall with Advanced Security snap-in console, open Monitoring\Connection Security Rules. In the details pane, you should see a list of connection security rules that begin with DirectAccess Policy, including rules named DirectAccess Policy-ClientToDnsDc and DirectAccess Policy-ClientCorp. 5. If you do not see these rules, from the Command Prompt window, run the netsh advfirewall monitor show currentprofile command. This command displays the attached networks and their determined firewall profiles. None of your networks should be in the domain profile. If any of your networks has been assigned the domain profile, determine if you have an active remote access virtual private network (VPN) connection or a domain controller that is available on the Internet. 6. From the Command Prompt window, run the netsh advfirewall monitor show mmsa command. There should be a main mode SA with the Remote IP Address set to the IPv6 address 2002:WWXX:YYZZ::WWXX:YYZZ, in which WWXX:YYZZ is the colon hexadecimal representation of w.x.y.z, the first public Internet Protocol version 4 (IPv4) address assigned to the Internet interface of the DirectAccess server. For example, if the first public IPv4 address is 131.107.0.2, the corresponding 6to4 IPv6 address is 2002:836b:2::836b:2 (836b:2 is the colon-hexadecimal representation for 131.107.0.2). The main mode SA should also have ComputerCert for Auth1 and UserNTLM for Auth2. 7. From the Command Prompt window, run the netsh advfirewall monitor show qmsa command. There should be a quick mode SA with the Remote IP Address set to the IPv6 address 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
231
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 IPv6capable 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. To verify whether the DirectAccess client can successfully create the intranet tunnel 1. On the DirectAccess client, start a command prompt as an administrator. 2. From the Command Prompt window, run the net view \\IntranetFileServer command. Alternately, use your Internet Web browser to access an intranet uniform resource locator (URL) or another application to access an intranet resource. 3. From the Command Prompt window, run the netsh advfirewall monitor show mmsa command. There should be a main mode SA with the Remote IP Address set to the 6to4 IPv6 address corresponding to the second public IPv4 address assigned to the Internet interface of the DirectAccess server. For example, if the first public IPv4 address is 131.107.0.3, the corresponding 6to4 IPv6 address is 2002:836b:3::836b:3 (836b:3 is the colon-hexadecimal notation for 131.107.0.3). The main mode SA should also have ComputerCert for Auth1 and UserKerb for Auth2. 4. From the Command Prompt window, run the netsh advfirewall monitor show qmsa command. There should be a quick mode SA with the Remote IP Address set to the 6to4 IPv6 address corresponding to the second public IPv4 address assigned to the Internet interface of the DirectAccess server. If the DirectAccess client computer cannot establish the main and quick mode SAs for the intranet tunnel using the default connection security rules created by the DirectAccess Setup Wizard, the 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.
232
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 IPv6capable 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.
Event ID 4984: Extended Mode: Failed: An IPsec Extended Mode Negotiation Failed. The corresponding Main Mode Security Association has been deleted.
233
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.
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.
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. To troubleshoot why a DirectAccess client cannot connect to an intranet resource 1. On the DirectAccess client, start a command prompt as an administrator. 2. From the Command Prompt window, run the netsh namespace show effective command. This command displays the current effective rules, which are typically one or more namespace rules (with a leading period) for your intranet namespace and one or more exemption rules for names that should not be resolvable while on the Internet (fully qualified domain names [FQDNs] without a leading period for names such as your network location server). Verify that your entire intranet namespace is represented by DirectAccess-based namespace rules. In the rules for your intranet namespace, there should be at least one IPv6 address for DirectAccess (DNS Servers). If there are no rules, run the netsh namespace show policy command. If there are DirectAccess-based rules, the DirectAccess client has determined that it is on the intranet. If there are no rules, verify that the DirectAccess client is running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows Server 2008 R2, is a member of a security group specified in step 1 of the DirectAccess Setup Wizard, and has updated its computer configuration Group Policy. 3. From the Command Prompt window, ping the IPv6 addresses of your intranet DNS servers from step 2. This step ensures that the intranet DNS server is reachable across the DirectAccess connection. 4. Verify that the FQDN of the intranet resource matches a namespace rule in the NRPT and does not match an exemption rule. This step ensures that the DirectAccess client will send its queries to the intranet DNS servers, rather than an Internet DNS server. 5. From the Command Prompt window, use the nslookup q=aaaa IntranetFQDN IntranetDNSServerIPv6Address command to resolve the names of intranet servers to IPv6 addresses (example: nslookup q=aaaa dc1.corp.contoso.com 2002:836b:2:1::5efe:10.0.0.1). This command should display the IPv6 addresses of the specified intranet server. 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.
237
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 IPv6capable. 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. To determine the IPv6 addresses that an intranet resource registers in DNS 1. On the Windows-based intranet resource server, start a command prompt as an administrator. 2. From the Command Prompt window, run the ipconfig command. This command displays your current Transmission Control Protocol/Internet Protocol (TCP/IP) configuration, including both IPv4 and IPv6 addresses. Verify that an IPv6 global address (an address that begins with 2 or 3) or an IPv6 unique local address (begins with fd) is assigned to an interface on the computer. If all of the IPv6 addresses begin with fe80, the intranet resource has not been configured with an IPv6 address that is registerable in DNS and reachable by DirectAccess clients. For more information, see the To troubleshoot why an intranet ISATAP host does not configure an ISATAP address procedure in this topic. 3. If there is a global or unique local IPv6 address assigned to an interface, use the nslookup q=aaaa IntranetServerFQDN IntranetDNSServerIPAddress command to determine if the intranet resource has registered its IPv6 address. For example, for the 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
238
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. To troubleshoot why an intranet ISATAP host does not configure an ISATAP address 1. On the Windows-based intranet resource, start a command prompt as an administrator. 2. From the Command Prompt window, run the reg query HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command. If the DisabledComponents registry value is present, the command displays its value. If the DisabledComponents registry value is not present, the command displays ERROR: The system was unable to find the specified registry key or value. If DisabledComponents is present and it is not 0, convert it to a binary number. If the first or third bit from the right in the binary number is 1, DisabledComponents has disabled ISATAP. You must change the first and third bit from the right to 0 to enable ISATAP. 3. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition /v ISATAP_RouterName command. This command should display ERROR: The system was unable to find the specified registry key or value. If it does not, note the value. 4. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition /v ISATAP_State command. This command should display ERROR: The system was unable to find the specified registry key or value. If it does not, ensure that the value is set to enabled. If it is set to disabled, change the Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies\ISATAP State setting in the Group Policy object for this intranet resource to either Enabled or Not Configured and update computer configuration Group Policy. 5. From the Command Prompt window, run the netsh interface isatap show state command. This command should display enabled in ISATAP State. 6. From the Command Prompt window, run the netsh interface isatap show router command.
239
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. To troubleshoot an ISATAP router 1. On the DirectAccess server acting as the ISATAP router, start a command prompt as an administrator. 2. From the Command Prompt window, run the reg query HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters /v DisabledComponents command. If the DisabledComponents registry value is present, the command displays its value. If the DisabledComponents registry value is not present, the command displays ERROR: The system was unable to find the specified registry key or value. If DisabledComponents is present and it is not 0, convert it to a binary number. If the first or third bit from the right in the binary number is 1, DisabledComponents has disabled ISATAP. You must change the first and third bit from the right to 0 to enable ISATAP. 3. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition /v ISATAP_RouterName command. This command should display ERROR: The system was unable to find the specified registry key or value. If it does not, note the value. 4. From the Command Prompt window, run the reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition /v ISATAP_State command. This command should display ERROR: The system was unable to find the specified registry key or value. If it does not, ensure that the value is set to enabled. 5. From the Command Prompt window, run the netsh interface isatap show state command. This command should display enabled in ISATAP State. 6. From the Command Prompt window, run the netsh interface isatap show router command.
240
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 servers 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.
241
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 computers 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. To verify whether the management server can successfully create the management tunnel 1. On the DirectAccess client, start a command prompt as an administrator. 2. On the DirectAccess client, click Start, type wf.msc, and then press ENTER. 3. In the tree pane of the Windows Firewall with Advanced Security snap-in console, click Connection Security Rules. In the details pane, you should see connection security rules whose names begin with DirectAccess Policy. If not, this DirectAccess client has not received its connection security rules from computer configuration Group Policy. Verify that the DirectAccess client is running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows Server 2008 R2 and is a member of one of the security groups specified in step 1 of the DirectAccess Setup Wizard. 4. In the tree pane of the Windows Firewall with Advanced Security snap-in console, open Monitoring\Connection Security Rules. In the details pane, you should see a list of connection security rules that begin with DirectAccess Policy, including a rule named DirectAccess Policy-ClientToMgmt. 5. If you do not see these rules, from the Command Prompt window, run the netsh advfirewall monitor show currentprofile command. This command displays the attached networks and their determined firewall profiles. None of your networks should be in the domain profile. If any of your networks has been assigned the domain profile, determine if you have an active remote access virtual private network (VPN) connection or a domain controller that is available on the Internet. 6. Double-click the DirectAccess Policy-ClientToMgmt rule and then click the Computers tab. Verify that the IPv6 address of the management server is listed in
242
Endpoint 2. This list of IPv6 addresses was configured in step 3 of the DirectAccess Setup Wizard. 7. From the intranet, use the management server to initiate communication with the DirectAccess client. For example, use the management server to establish a remote desktop connection to the DirectAccess client. 8. On the DirectAccess client, from the Command Prompt window, run the netsh advfirewall monitor show mmsa command. There should be a main mode SA with the Remote IP Address set to the IPv6 address 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 IPv6capable domain controllers that are being used by DirectAccess clients are using site-less locator records in DNS. To perform detailed IPsec negotiation analysis, use IPsec audit events in the Windows Logs\Security event log and network tracing for DirectAccess. For more information, see Event Viewer and Network Diagnostics and Tracing. If you have configured DirectAccess for the end-to-end access model, verify that the management server has been configured with compatible connection security rules to use transport mode IPsec when initiating communication with DirectAccess clients.
243
Computers tab. Verify that the Internet Protocol version 6 (IPv6) addresses of the selected servers are listed in Endpoint 2. This list of IPv6 addresses was configured based on the selected server security groups specified in step 4 of the DirectAccess Setup Wizard. 7. Initiate communication with the selected server. For example, use the appropriate application or the net view \\SelectedServerName command. 8. From the Command Prompt window, run the netsh advfirewall monitor show mmsa command. There should be a main mode SA with the Remote IP Address set to the IPv6 address of the selected server. The main mode SA should also have ComputerCert or ComputerKerb for Auth1 and UserKerb for Auth2. 9. From the Command Prompt window, run the netsh advfirewall monitor show qmsa command. There should be a quick mode SA with the Remote IP Address set to the IPv6 address of the selected server. If the DirectAccess client computer cannot establish the main and quick mode SAs to the selected server using the default connection security rules created by the DirectAccess Setup Wizard, the most likely problem is the lack of corresponding connection security rules on the selected server. Verify that a rule named DirectAccess Policy-appServerToClient appears in the Connection Security Rules and Monitoring\Connection Security Rules nodes in the console tree of the Windows Firewall with Advanced Security snap-in on the selected server.
client is running Windows 7 Ultimate Edition or Windows 7 Enterprise Edition and is a member of one of the security groups specified in step 1 of the DirectAccess Setup Wizard. 4. In the tree pane of the Windows Firewall with Advanced Security snap-in console, open Monitoring\Connection Security Rules. In the details pane, you should see a list of connection security rules that begin with DirectAccess Policy, including a rule named DirectAccess Policy-clientToAppServer. 5. If you do not see this rule, from the Command Prompt window, run the netsh advfirewall monitor show currentprofile command. This command displays the attached networks and their determined firewall profiles. None of your networks should be in the domain profile. If any of your networks has been assigned the domain profile, determine if you have an active remote access virtual private network (VPN) connection or a domain controller that is available on the Internet. 6. Initiate communication with an intranet server. For example, use an appropriate client application or the net view \\IntranetServer command. 7. From the Command Prompt window, run the netsh advfirewall monitor show mmsa command. There should be a main mode SA with the Remote IP Address set to the IPv6 address of the intranet server. The main mode SA should also have ComputerCert or ComputerKerb for Auth1 and UserKerb for Auth2. 8. From the Command Prompt window, run the netsh advfirewall monitor show qmsa command. There should be a quick mode SA with the Remote IP Address set to the IPv6 address of the intranet server. If the DirectAccess client computer cannot establish the main and quick mode SAs to intranet server using the modified connection security rules, the most likely problem is the lack of corresponding connection security rules on intranet servers. Verify that a rule named DirectAccess Policy-appServerToClient appears in the Connection Security Rules and Monitoring\Connection Security Rules nodes in the console tree of the Windows Firewall with Advanced Security snap-in on your intranet servers.
246
Indicator\Domain Location Determination URL setting of the Group Policy object for DirectAccess clients. After a network state change and before intranet detection is complete, the DirectAccess client has the DirectAccess-based rules in its effective Name Resolution Policy Table (NRPT). If intranet detection determines that the DirectAccess client is on the intranet, the DirectAccess-based rules in the effective NRPT are removed. If intranet detection determines that the DirectAccess client is on the Internet, the DirectAccess-based rules in the NRPT are not removed. The most common issues that can occur with intranet detection are the following: DirectAccess Client Determines that it is on the Intranet When on the Internet DirectAccess Client Determines that it is on the Internet When on the Intranet
The network location URL is designed to be accessible only from the intranet. You should not be able to access the FQDN of the network location URL or the HTTPS-based URL from an Internet-connected computer. To test this, connect a computer that is not a DirectAccess client to the Internet and attempt to ping the FQDN of the network location URL and use an Internet browser to access the network location URL. If you can resolve the name and access the URL, remove the Internet DNS records for the FQDN or remove the network location server from the Internet. If the DirectAccess server is acting as the network location server, ensure that the IP and Domain Restrictions role service is installed for the Web server (IIS) role to prevent DirectAccess clients on the Internet from reaching the network location URL on the DirectAccess server.
name (FQDN). Because the DNS domain suffix is the same as the suffix for the intranet namespace rule in the effective NRPT, the FQDN for the ISATAP router name matches the intranet namespace rule in the NRPT. Therefore, the DirectAccess client attempts to send a DNS name query to the ISATAP-based address of the intranet DNS server, which it cannot reach because it does not yet have an ISATAP address. The result is that the DirectAccess client cannot reach the IPv6 addresses of its intranet DNS servers and cannot resolve intranet DNS names. To determine the results of intranet detection on a DirectAccess client 1. On the DirectAccess client, start a command prompt as an administrator. 2. From the Command Prompt window, run the netsh namespace show policy command. There should be set of NRPT rules. If not, this DirectAccess client has not received its NRPT rules from computer configuration Group Policy. Verify that this computer is running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows Server 2008 R2 and is a member of one of the security groups specified in step 1 of the DirectAccess Setup Wizard. 3. From the Command Prompt window, run the netsh namespace show effective command. If you have the same set of DirectAccess-based rules as in step 2, the DirectAccess client has determined that it is on the Internet. If the set of DirectAccess-based rules in step 2 are not listed, the DirectAccess client has determined that it is on the intranet. 4. Click Start, type eventvwr.msc, and then press ENTER. 5. In the console tree, open Application and Services Logs\Microsoft\Windows\NCSI\Operational. 6. Double-click the most recent Information events with the event ID 4010. The text on the General tab displays the result of the latest intranet detections (also known as Inside/Outside detections) as either INSIDE or OUTSIDE. INSIDE means the intranet has been detected. OUTSIDE means that the intranet has not been detected. Look at the events for the interfaces with interface numbers that begin with 0x47 (WLAN) and 0x60 (LAN). If any of the LAN or WLAN interfaces are INSIDE, the DirectAccess client is on the intranet. If all of the LAN and WLAN interfaces are OUTSIDE, the DirectAccess client is not on the intranet. Note You can also use the wevtutil qe Microsoft-Windows-NCSI/Operational /rd:true /f:text >> filename.log command to export the events to a text file.
249
To troubleshoot why a DirectAccess client on the intranet cannot successfully access the network location URL 1. On the DirectAccess client, start a command prompt as an administrator. 2. From the Command Prompt window, run the reg query HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\C orporateConnectivity /v DomainLocationDeterminationUrl command. This displays the network location URL. If there is no value, the DirectAccess client has not been properly configured with computer configuration Group Policy. Verify that this computer is running Windows 7 Ultimate Edition or Windows 7 Enterprise Edition and is a member of one of the security groups specified in step 1 of the DirectAccess Setup Wizard. 3. From the Command Prompt window, run the netsh namespace show policy command. 4. Compare the FQDN in the network location URL to the NRPT rules from step 3. Either the FQDN should not match the DirectAccess-based intranet namespace rules or it should match an exemption rule for the FQDN. In either case, the DirectAccess client will use interface-configured DNS server to resolve the FQDN in the network location URL. 5. From the Command Prompt window, ping the FQDN in the network location URL. This step ensures that the DirectAccess client can resolve the name and reach the network location server. 6. Attempt to access the network location URL with your Internet browser. You should see the Web page without any certificate errors. Note that the contents of the Web page do not matter, only the ability to successfully access it. If you see a certificate error, verify the following for the certificate on the network location server that is being used for HTTPS (SSL)-based connections: The DirectAccess client can validate and trust the network location certificate. The Subject field is the FQDN from the network location URL. The Enhanced Key Usage field contains the Server Authentication object identifier (OID).
The certificate revocation list (CRL) Distribution Points field contains at least one CRL distribution point that the DirectAccess client can successfully access. 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 pointsthe Hypertext Transfer Protocol (HTTP) URL without the file name or the universal naming convention (UNC) path without the file namefrom 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.
250
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.
251