Export (0) Print
Expand All

Appendix B: Reviewing Key DirectAccess Concepts

Updated: May 12, 2011

Applies To: Windows 7, Windows Server 2008 R2

ImportantImportant
This topic describes design considerations for DirectAccess in Windows Server 2008 R2. For the design considerations of DirectAccess in Microsoft Forefront Unified Access Gateway (UAG), see the Forefront UAG DirectAccess Design Guide (http://go.microsoft.com/fwlink/?LinkId=179988).

The DirectAccess solution uses a combination of Internet Protocol version 6 (IPv6) end-to-end connectivity, Internet Protocol security (IPsec) protection of intranet traffic, separation of Domain Name System (DNS) traffic with the Name Resolution Policy Table (NRPT), and network location detection that DirectAccess clients use to determine when they are on the intranet. The following sections describe the role that these technologies have in providing DirectAccess clients with transparent access to intranet resources.

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.

To send IPv6 packets across the IPv4 Internet, a DirectAccess client can use 6to4, Teredo, or IP-HTTPS. If the DirectAccess client has been assigned a public IPv4 address, it will use 6to4. If assigned a private IPv4 address, it will use Teredo. If the DirectAccess client cannot connect to the DirectAccess server with either 6to4 or Teredo, it will use IP-HTTPS.

6to4, 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, 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 is a new protocol for Windows 7 and Windows Server 2008 R2 that allows hosts behind a Web proxy server or firewall to establish connectivity by tunneling IPv6 packets inside an IPv4-based HTTPS session. HTTPS is used instead of HTTP so that Web proxy servers will not attempt to examine the data stream and terminate the connection. IP-HTTPS is typically used only if the client is unable to connect to the DirectAccess server using the other IPv6 connectivity methods or if force tunneling has been configured.

For the details of IP-HTTPS, see the IP over HTTPS (IP-HTTPS) Tunneling Protocol Specification (http://go.microsoft.com/fwlink/?Linkid=157309).

noteNote
The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) demonstrates DirectAccess connectivity across a simulated Internet subnet using 6to4, Teredo, and IP-HTTPS.

ISATAP, defined in RFC 4214, is an IPv6 transition technology that provides IPv6 connectivity between IPv6/IPv4 hosts across an IPv4-only intranet. ISATAP can be used for DirectAccess to provide IPv6 connectivity to ISATAP hosts across your intranet.

For more information, see IPv6 Transition Technologies (http://go.microsoft.com/fwlink/?Linkid=117205).

noteNote
ISATAP can also be used to provide IPv6 connectivity when the client is at a remote location. ISATAP deployments can either connect to the IPv6 Internet or use 6to4 to transfer IPv6 traffic across the IPv4 Internet.

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

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.

noteNote
Windows Server 2003 and earlier versions of Windows Server do not fully support the use of IPsec with IPv6. IPv6-capable resources on servers running Windows Server 2003 will only be available to DirectAccess clients if you use the full intranet access model. IPv4-only resources on servers running Windows Server 2003, including most built-in applications and system services, require an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway to be available to DirectAccess clients.

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

noteNote
When sensitive data is being transmitted, IPsec with only data integrity should only be used when some other form of encryption is also implemented. It is possible to have end-to-end data integrity using transport mode rules while using end-to-edge encryption for the tunnel mode rules, which is how the selected server access model works.

DirectAccess accomplishes data integrity through the use of transport and tunnel mode IPsec settings. These settings can be applied to DirectAccess clients, DirectAccess servers, or application servers and provide data integrity by requiring ESP-NULL (recommended) or Authentication Header (AH) for IPsec-protected communications. Some network infrastructure devices or traffic monitoring and inspection solutions might not be able to parse packets with an IPsec ESP or AH header. In this case, you can use authentication with null encapsulation to perform IPsec peer authentication, but no per-packet data integrity.

To separate Internet traffic from intranet traffic for DirectAccess, Windows 7 and Windows Server 2008 R2 include the NRPT, a new feature that allows DNS servers to be defined per DNS namespace, rather than per interface. The NRPT stores a list of rules. Each rule defines a DNS namespace and configuration settings that define the DNS client’s behavior for that namespace. When a DirectAccess client is on the Internet, each name query request is compared against the namespace rules stored in the NRPT. If a match is found, the request is processed according to the settings in the NRPT rule. The settings determine which DNS servers to which the request will be sent.

If a name query request does not match a namespace listed in the NRPT, it is sent to the DNS servers configured in the TCP/IP settings for the specified network interface. For a remote client, this will typically be the Internet DNS servers as configured through the Internet service provider (ISP). For a DirectAccess client on the intranet, this will typically be the intranet DNS servers as configured through the Dynamic Host Configuration Protocol (DHCP).

Single-label names, such as http://internal, will typically have configured DNS search suffixes appended to the name before they are checked against the NRPT. If no DNS search suffixes are configured and the single-label name does not match any other single-label name rules in the NRPT, the request will be sent to the DNS servers specified in the client’s TCP/IP settings.

Namespaces, such as .internal.contoso.com, are added to the NRPT followed by the IPv6 addresses of the DNS servers to which requests matching that namespace should be directed. If an IP address is entered for the DNS server, then all DNS requests will be sent directly to the DNS server over the DirectAccess connection. There is no need to specify any additional security for this configuration.

However, if a name is specified for the DNS server (such as dns.contoso.com) in the NRPT, then that name must be publicly resolvable when the client queries the DNS servers specified in its TCP/IP settings. To prevent an attacker from hijacking this external name query request and injecting a malicious reply, enabling IPsec protection for the DNS message exchanges is strongly recommended in this configuration.

The NRPT allows DirectAccess clients to use intranet DNS servers for name resolution (dedicated DNS servers are not required). DirectAccess is designed to prevent the exposure of your intranet namespace to the Internet.

There are some names that need to be treated differently from all others with regards to name resolution; these names must not be resolved using intranet DNS servers. To ensure that these names are resolved with interface-configured DNS servers, you must add them as NRPT exemptions.

If no DNS server addresses are specified in the NRPT rule, the rule is an exemption. If a DNS name matches a rule in the NRPT that does not contain addresses of DNS servers or does not match a rule in the NRPT, the DirectAccess client sends the name query to interface-configured DNS servers.

If any of the following servers have a name suffix that matches an NRPT rule for the intranet namespace, that server name must be an NRPT exemption:

  • Network location servers

  • Intranet certificate revocation list (CRL) distribution points

  • System health remediation servers

These servers must always be resolved with interface-configured DNS servers.

noteNote
The DirectAccess Setup Wizard in the DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) creates two rules in the NRPT: a namespace rule for corp.contoso.com with the IPv6 address of the intranet DNS server and an exemption rule for nls.corp.contoso.com. You can view the NRPT rules configured with Group Policy from CLIENT1 by running the netsh namespace show policy command at a command prompt. You can view the active NRPT rules with the netsh namespace show effectivepolicy command.

DirectAccess clients use network location detection to determine if they are on the intranet by attempting to access a network location server. If the DirectAccess client can successfully access a Secure Hypertext Transfer Protocol (HTTPS)-based uniform resource locator (URL) on the network location server, it determines that it is on the intranet and removes the DirectAccess rules from the NRPT.

A network location server is an intranet Web server that hosts an HTTPS-based URL. The DirectAccess server can be the network location server but a separate, highly-available Web server is highly recommended. The Web server does not have to be dedicated as a network location server.

Because the behavior of the DirectAccess client depends on the response from the network location server, it is critical to ensure that this Web site is highly available and available from each remote branch site. Branch locations may need a separate dedicated network location Web site at each branch location to ensure that the Web site remains accessible even in the event of a link failure.

When a DirectAccess client starts up or experiences a network change event (such as change in link status or a new IP address), it adds the DirectAccess rules to the NRPT. The DirectAccess client then attempts to resolve the fully qualified domain name (FQDN) in the URL for the network location server, which is stored in the Computer Configuration/Policies/Administrative Templates/Network/Network Connectivity Status Indicator/Domain Location Determination URL Group Policy setting. Because the NRPT has active DirectAccess rules, this FQDN should either match an exemption rule or no rules in the NRPT so that the DirectAccess client can use normal name resolution and interface-configured DNS servers.

After resolving the FQDN, the DirectAccess client attempts to connect to the HTTPS-based URL of the network location server, which includes a Secure Sockets Layer (SSL)-based authentication and verification of the server certificate offered by the network location server. For authenticating the DirectAccess client’s access to the URL, use anonymous authentication. The network location server should not require any type of user credentials for authentication or authorization. Certificate verification includes validating the certificate and verifying that it has not been revoked by accessing the CRL location defined in the network location server’s SSL certificate. When the DirectAccess client successfully accesses the HTTPS-based URL of the network location server, it determines that it is on the intranet. The DirectAccess client then removes the DirectAccess NRPT rules from the active table and the DirectAccess client uses interface-configured DNS servers to resolve all names.

For more information, see Network Location Detection.

noteNote
Just like the URL for the network location server, the FQDN in the URL or the universal naming convention (UNC) path for the CRL distribution point should either match an exemption rule or no rules in the NRPT so that the DirectAccess client can use normal name resolution and interface-configured intranet DNS servers to resolve the name. If the DirectAccess client cannot resolve the FQDN for the CRL distribution point, intranet location detection fails.

The DirectAccess test lab (http://go.microsoft.com/fwlink/?Linkid=150613) uses APP1, a separate application server, as the network location server and the network location URL https://nls.corp.contoso.com. The SSL certificate on APP1 has the CRL distribution point http://crl.contoso.com/crld/corp-DC1-CA.crl, which for ease of configuration is hosted on EDGE1, the DirectAccess server. To demonstrate network location detection, do the following:

  1. Connect CLIENT1 to the Internet subnet.

  2. Open a Command Prompt.

  3. From the Command Prompt window, run the netsh dnsclient show state command.

    Notice that the Machine Location field states Outside corporate network.

  4. Run the netsh namespace show effectivepolicy command.

    Notice that there are two active NRPT rules: A namespace rule for corp.contoso.com and an exemption rule for nls.corp.contoso.com.

  5. Disconnect CLIENT1 from the Internet subnet and connect it to the Corpnet subnet.

  6. From the Command Prompt window, run the netsh dnsclient show state command.

    Notice that the Machine Location field states Inside corporate network.

  7. Run the netsh namespace show effectivepolicy command.

    Notice that there are now no active NRPT rules.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft