Appendix B: Reviewing Key DirectAccess Concepts

Applies To: Windows 7, Windows Server 2008 R2

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

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.

IPv6 connectivity across the IPv4 Internet

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

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 (https://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 (https://go.microsoft.com/fwlink/?Linkid=157322).

IP-HTTPS

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

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

IPv6 connectivity across an IPv4-only intranet

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 (https://go.microsoft.com/fwlink/?Linkid=117205).

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 (https://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.

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.

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

Separation of DNS traffic

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 https://internal, will typically have configured DNS search suffixes appended to the name before they are checked against the NRPT. If no DNS search suffixes are configured and the single-label name does not match any other single-label name rules in the NRPT, the request will be sent to the DNS servers specified in the client’s TCP/IP settings.

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

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

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

NRPT exemptions

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

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

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

• Network location servers

• Intranet certificate revocation list (CRL) distribution points

• System health remediation servers

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

Network location detection

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

The network location server

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.

How network location detection works

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.

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.