The Cable Guy - March 2010

Network Location Detection for DirectAccess

By The Cable Guy

Along with settings for Internet Protocol version 6 (IPv6) transition technologies, DirectAccess clients that are connected to the Internet rely on the following to perform transparent connectivity to intranet resources:

• Name Resolution Policy Table (NRPT) rules for DirectAccess. These rules specify that the DirectAccess client forward Domain Name System (DNS) queries for fully qualified domain names (FQDNs) that match the intranet namespace to the IPv6 addresses of intranet DNS servers. This separates intranet traffic from Internet traffic.

• Connection security rules for DirectAccess. These rules specify that the DirectAccess client create encrypted Internet Protocol security (IPsec) tunnels to access intranet resources. There is an infrastructure tunnel that allows the client to access intranet DNS servers and domain controllers and an intranet tunnel that allows access to the entire intranet. These tunnels require computer (infrastructure and intranet tunnels) and user (intranet tunnel) credentials. The connection security rules for DirectAccess tunnels are specified for the Private and Public firewall profiles.

When the DirectAccess client is connected to the intranet, the NRPT rules and connection security rules must be deactivated so that the DirectAccess client uses normal DNS name resolution methods and does not use IPsec tunnels to access intranet resources. Therefore, a DirectAccess client must be able to determine when it is connected to the intranet. This is known as network location detection. Before we can dive into the details of the network location detection process, we must first understand name resolution for DirectAccess clients.

Name Resolution for DirectAccess Clients

Some technologies require special handling of name queries for specific portions of the DNS namespace. If the FQDN matches specified portions of the namespace, apply the special handling. If the FQDN does not match the specified portions of the namespace, perform normal name resolution. To address this need, Windows 7 and Windows Server 2008 R2 include the NRPT. The NRPT contains rules for names or namespaces and the settings for the special handling. For additional details about the NRPT, see The Name Resolution Policy Table, the February 2010 The Cable Guy article.

When performing a DNS name resolution, the DNS Client service compares the requested name to each rule in the NRPT. Queries and responses that match an NRPT rule get the specified special handling applied. Queries and responses that do not match any NRPT rules are processed normally. For DirectAccess, FQDNs that match the intranet namespace are sent to the IPv6 addresses of intranet DNS servers.

The following is the name resolution process for DirectAccess clients that have active DirectAccess-based NRPT rules:

1. An application submits a name to be resolved, either a single-label name or an FQDN. Single-label names are also known as flat names.

2. If the name submitted is a single-label name, append a DNS suffix to form an FQDN.

3. Compare the FQDN against the rules in the NRPT.

4. If there is no match, perform normal name resolution; send queries to interface-configured DNS servers and, if the original name is a single-label name, use Link-Local Multicast Name Resolution (LLMNR) and Network Basic Input/Output System (NetBIOS) name resolution methods to resolve the name.

5. If there is a match and the rule is not configured with DNS server IPv6 addresses, this is an exemption rule. Perform normal name resolution.

6. If there is a match and the rule is configured with the IPv6 addresses of DNS servers, send the FQDN as a AAAA query (for IPv6 addresses only) to the IPv6 addresses of the matching rule.

7. If the original name is a single-label name and the DNS query sent to NRPT rule-configured DNS servers results in an error, use LLMNR and NetBIOS name resolution methods based on the configured fall back behavior.

The fall back behavior options are the following:

• When the DNS response error is Name Not Found.

  This provides the highest security because only names that do not match intranet server names are leaked to the local subnet through LLMNR multicasts or NetBIOS broadcasts. If the intranet DNS servers cannot be reached or if there are other types of DNS errors, the intranet server names will not be leaked to the subnet

• When the DNS response error is Name Not Found or if the intranet DNS servers do not respond and the attached network is assigned the Private firewall profile.

  This provides a medium level of security (the default). Intranet server names are only leaked when connected to a private network.

• When there is any type of DNS query error, including Name Not Found.

  This is the lowest level of security. Intranet server names can be leaked to the local subnet when connected to public networks.

Successful name resolution with LLMNR and NetBIOS, including Windows Internet Name Service (WINS), depend on whether the target resource is on the same subnet as the DirectAccess client or has its name stored in WINS.

You configure the fall back behavior on the DNS and Domain Controller page of step 3 of the DirectAccess Setup Wizard. See the following figure for an example.

The following figure shows the flowchart of the name resolution process for DirectAccess clients.

Network Location Detection Process

The Windows Network Location Awareness (NLA) service performs network location detection for every network state change, such as an Internet Protocol (IP) address change, and attempts to access a specific Secure Hypertext Transfer Protocol (HTTPS)-based uniform resource locator (URL). You configure the network location URL on the Location page of step 3 of the DirectAccess Setup Wizard. The following figure shows an example.

DirectAccess clients receive the configuration of the network location URL from the DirectAccess client Group Policy object (Computer Configuration\Policies\Administrative Templates\Network\Network Connectivity Status Indicator\Domain Location Determination URL) and store it in the Windows Registry at HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity\DomainLocationDeterminationUrl.

When the network state changes, the NLA service adds the DirectAccess rules to the NRPT. If the client can access the network location URL successfully over SSL and receive a valid HTTP response indicating a successful connection, the NLA service removes the DirectAccess NRPT rules. Otherwise, the rules remain in the NRPT.

The detailed process is the following:

1. Attempt to resolve the FQDN in the network location URL.

2. The FQDN matches an exemption rule in the NRPT, which is configured by default by the DirectAccess Setup Wizard. Because the FQDN matches an exemption rule, perform a normal name resolution, which includes using interface-configured DNS servers.

3. Using the IP address returned from name resolution, perform an HTTP GET of the network location URL (an HTTPS connection).

4. Establish a Transmission Control Protocol (TCP) connection with port 443 at the resolved IP address.

5. Perform Secure Sockets Layer (SSL) authentication for HTTPS and validate the SSL certificate from the network location server.

6. Perform a certificate revocation check for the SSL certificate by checking the certificate revocation list (CRL) files in the CRL Distribution Point field.

If the DirectAccess client can also locate and authenticate with a domain controller, it switches the network to the Domain profile. Because the DirectAccess connection security rules are specified only for the Private and Public profiles, they are deactivated.

With the combination of network location detection and computer domain logon, the DirectAccess client configures itself for normal intranet access.

Network Location Detection Failures and Their Consequences

There are many reasons why the HTTP GET of the network location URL could fail, including the following:

• Network location server is offline

• A link failure makes the network location server unreachable

• Cannot resolve FQDN of the network location URL

• Incorrect address for the FQDN of the network location URL

• Cannot establish the SSL session (TCP)

• Cannot validate the SSL certificate due to certificate expiration, incorrect object identifier (OID), incorrect Subject field

• Cannot resolve the FQDN of the CRL distribution point

• Cannot reach the CRL distribution point

• Cannot read the CRL files

The behavior of a DirectAccess client on the intranet when it cannot perform a successful network location detection depends on the name used by applications to access intranet resources, either FQDN or single-label, and whether the DirectAccess client can reach the Internet interface of the DirectAccess server.

If the DirectAccess client cannot reach the Internet interface of the DirectAccess server and tries to resolve an intranet FQDN, name resolution fails because there is no fall back behavior for FQDNs. Therefore, the DirectAccess client cannot reach the intranet resource.

If the DirectAccess client cannot reach the Internet interface of the DirectAccess server and tries to resolve a single-label name, fall back behavior can use LLMNR or NetBIOS methods, including WINS. Therefore, connectivity to the intranet resource can use IPv4, rather than IPv6.

A DirectAccess client on the intranet can use Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) and an intranet proxy server to reach the Internet interface of the DirectAccess server. In this case, all DirectAccess tunneled traffic is exchanged with the DirectAccess server over the IP-HTTPS session out to the Internet and back to the intranet via the DirectAccess server.

In this configuration, the DirectAccess client behaves in much the same way as if it were located on the Internet. However, intranet resources that are not available over DirectAccess are still unavailable, even though the DirectAccess client is connected to the intranet. Additionally, intranet access can have decreased performance because the traffic is routed through the IP-HTTPS session, out to the Internet, and back through the DirectAccess server.

Planning for Network Location Detection

The best way to prevent network location detection failures is to deploy highly-available, fault-tolerant network location servers and CRL distribution points with fault-tolerant link-layer connectivity. The following table lists network location failure points and mitigation strategies.

Failure point	Mitigation strategy
Network location server fails	Provide Web server redundancy using a failover cluster, Windows Network Load Balancing, or a network-based load balancer.
Link failures between DirectAccess clients and network location servers, such as a WAN failure	Place network location servers in multiple locations, especially key branch offices.
Network location server SSL certificate expires or becomes untrusted	Use certificate lifecycle management to ensure that the SSL certificate does not expire and the trust chain is maintained.
CRL for the network location server SSL certificate is unavailable	Deploy redundancy for CRL distribution points and ensure required updates of CRL files.
DNS name resolution issues with the FQDN of the network location server or CRL distribution point	Exercise security and change control over the network location and CRL distribution point FQDNs and deploy DNS server redundancy to ensure that these FQDNs are always resolvable.

An additional element of planning for network location detection is to ensure that DirectAccess clients can operate when failures occur through the following:

• Configure an appropriate fall back setting

  The fall back setting is a balance between confidentiality and availability. Setting fall back to happen more easily can result in name resolution queries being leaked to a public subnet. However, blocking fall back or relying on the user to choose the Private profile for the intranet network can result in loss of intranet connectivity.

• Deploy the DirectAccess Connectivity Assistant (DCA)

  The DCA is a Windows notification area status indicator for DirectAccess that allows you to enable local name resolution when network location detection fails. If the DCA indicates that there is a DirectAccess connectivity problem, right-click the DCA icon and click Prefer Local DNS Names. This removes the DirectAccess NRPT rules and the DirectAccess client performs normal name resolution. Because the intranet network is assigned the Public or Private profile, the DirectAccess client will attempt to send IPv6-based intranet communication through tunnels to the DirectAccess server. However, DirectAccess clients will be able to reach intranet resources with Internet Protocol version 4 (IPv4). The DCA will revert back to normal DirectAccess behavior when there is a network state change.

Summary

Successful network location detection is a crucial process for DirectAccess clients. Without it, DirectAccess clients might not be able to access intranet resources when they are connected to the intranet. To ensure successful network location detection, deploy high-availability and redundancy for network location servers and associated services. To provide mitigation for network location detection failures, use the DCA.

For a list of all The Cable Guy articles, click here.