[NOTE: This article originally appeared in "The Edge Man" blog at
(Discuss UAG DirectAccess issues on the TechNet Forums over at
In order for the DirectAccess (DA) client to determine whether to turn on it’s DirectAccess client configuration (which connects the DA client to the DA server), it must know if it is on the corporate network or not. If the DA client is
not on the corporate network, then the DA client components are turned
on, and if the DA client is on the corporate network, then the DA client components are
not turned on.
The DA client uses a Network Location Server (NLS) to find out if it is on the corporate network. The NLS is a web server that is accessible only when the client is on the corporate network. That means there must never be a DNS entry on the public Internet
that matches the name of your NLS server. For example, if the name of your NLS server is
nls.contoso.com, then that name must not be resolvable by any public DNS server. However, that name
must be resolvable by your internal NLS servers.
The URL used to connect to the NLS server is contained in the Registry of the DA client, and this setting is delivered over Group Policy. The Registry setting is stored at:
and is pictured in the figure below.
The DA client always assumes that it is on the outside. Whenever the DA client detects that there has been a network status change (such as when the network interface is unplugged and then plugged in again, or after waking from sleep), the DA client tries
to connect to the NLS server URL over an HTTPS connection. If the DA client receives a 200 HTTP success code, then it assumes that it on the corporate network and will then use Network Location Awareness to determine if it should switch the the domain profile.
NLA is part of the users decision making process when they select “which type of network are you on” when they change networks. When they choose the “work network” the Domain Profile (part of the Windows Firewall with Advanced Security) is enabled, which turns
off the DA client components.
NOTE: In order to successfully connect to the NLS server, the DA client must have access to the CRL location(s) listed on the web site certificate presented by the NLS server. If the CRL checks, then the connection will fail, and the DA client components
will remain enabled, even if the DA client is on the corporate network.
This is an important point to understand. The DA client configuration is driven by Group Policy settings and Windows Firewall for Advanced Security. The Windows Firewall with Advanced Security maintains three profiles:
public, private, and domain. When the client is on a public or private network, the DA client components are enabled via the WFAS configuration for those profiles. When the DA client is on the corpnet and the
domain profile is enabled, the DA client settings in WFAS are disabled.
When the DA client has disabled its DA client components, it resolves names based on the DNS server IP address settings on its NIC. However, when the DA client has enabled its DA client configuration, name resolution depends on the settings on the Name Resolution
Policy Table or NRPT.
The NRPT provides a form of “DNS server routing” based on the names configured on the NRPT. You configure the NRPT during the setup of the Windows DA server or the UAG DA server. The figure below shows the configuration interface for the NRPT using the UAG
DA wizard. Notice that there are two entries in this example:
NOTE: The UAG DA server DNS proxy is a component of the UAG DNS64 feature set. You can learn more about this feature at
If a name does not match any entry on the NRPT, then the name resolution request is sent to the DNS server configured on the DA client computer’s NIC. Since public DNS servers do not contain entries for your private network addresses, connection are made
to public servers over the local connection the client has to the Internet and
not over the DA link to the UAG DA server.
Let’s take a closer look at what happens when the NRPT name resolution policies are active (and remember that they are only active when the DA client components are turned on):
At this point things get a bit more tricky, because name resolution fallback depends on what type of name was queried for initially. This relates into the options seen on the bottom of the figure above and reproduced in the figure below. If the original
query to the UAG DA server was for a FQDN and the query fails, then that’s it and there’s no fall back. However, if the name query was for a single-label name (note that the user interface assumes that you know that
local name resolution is the same as “single-label name”), then there are three fall back options for name resolution.
Fall back for single label names will always happen if the client receives a “name not found” response from the UAG DA DNS proxy.
However, if the Fall back to local name resolution if the name does not exist in DNS or the DNS servers are unreachable when the client computer is on a private network (recommended)
option is selected, fall back will take place if the name doesn’t exist in DNS or if DNS server isn’t reachable
and the user selected the “Home” or “Work” option for the type of network their connected to. (that is to say, they didn’t select the “public” network option).
However, if the Fall back to local name resolution for any kind of DNS resolution error (least secure) option is selected, fall back will also take place for any kind of DNS query error and will take place if the user is located on a public
Network. As you can imagine, this can be a bit problematic if you’re concerned about your private names being broadcasted to the DA client’s local link. A determined attacker might be able to leverage this information in a focused attack on your network.
It’s worth repeating that fall back only takes place for single-label names and never takes place for FQDNs. Another thing to be aware of is that LLMNR only works on the local segment (similar to NetBIOS Name Query broadcasts) and that NetBIOS name resolution
only works on the local segment (actually subnet) unless a WINS server is configured, and it’s unlikely that the client is going to be assigned a WINS server that’s going to resolve the name of the server the client is actually interested in, and if there
is a name match in WINS, it’s almost impossible that this is going to be the correct computer, since the DA client computer is not located on the corpnet.
At this point you now should have a better understanding of the Network Location Server and how its used to determine whether the DA client is on or of the corpnet. You should also understand how DNS query behavior changes when the DA client components are
enabled – and that the NRPT determines what DNS server will be used to service a DNS query when the DA components are enabled on the client.
In the next blog post on network location awareness and detection, we’ll build on this understanding and looking into what happens when the DA client is unable to determine if it’s on the corpnet, and what happens to corpnet located clients when they are
not able to turn off their DA client configuration.