DirectAccess NLS Deployment Considerations for Large Enterprises

Introduction

For a DirectAccess deployment, the Network Location Server (NLS) is an infrastructure component that allows DirectAccess clients to determine if they are inside or outside of the corporate network. If the DirectAccess client can successfully connect to the NLS, it is on the internal network and DirectAccess is not used. If the NLS cannot be contacted, the client is outside of the network and will attempt to establish remote corporate network connectivity using DirectAccess.

High Availability

It is recommended that the NLS be made highly available by deploying at least two servers in a load balanced configuration to avoid potential service disruptions for DirectAccess clients inside the corporate network. While this approach is sufficient for networks that are contained in a single physical location, it does present some challenges for large organizations with internal networks that span multiple physical locations.

NLS Challenges

For DirectAccess, only a single NLS URL can be configured per DirectAccess deployment, as shown here.

DirectAccess NLS Deployment Considerations for Large Enterprises

If a WAN outage occurs on an internal network that spans multiple physical locations, internal DirectAccess clients in locations other than where the NLS resides will mistakenly believe they are outside of the corporate network. This can lead to degraded performance and potential loss of connectivity. NLS reliability can still be improved when the internal network spans multiple physical locations by deploying NLS at each physical location and configuring clients to use a local NLS. This will keep traffic off of the WAN and prevent service disruptions in the event of a WAN outage.

Redundant NLS

There are several strategies that can be used to configure internal DirectAccess clients to use a local NLS, including DNS round robin, a network load balancer, or Active Directory Group Policy. Using DNS or a load balancer requires only a single NLS URL. Using Active Directory Group Policy requires a unique NLS URL per physical location.

DNS

The simplest way to enable DirectAccess clients to use a local NLS is to use DNS round robin and take advantage of subnet prioritization. To do this, create an “A” resource record in DNS that resolves to the IPv4 address for each NLS. On the DNS server, open the DNS Manager, right-click the DNS server and choose Properties. Click the Advanced tab and select the options to Enable round robin and Enable netmask ordering.

DirectAccess NLS Deployment Considerations for Large Enterprises

This will ensure that name resolution requests for the NLS FQDN will be returned with the nearest NLS. More information about DNS netmask ordering can be found here.

Load Balancer

A Global Server Load Balancing (GSLB) solution can also be employed to route requests to a local NLS. Examples include F5 Global Traffic Manager (GTM) and Kemp Technologies LoadMaster GEO. Prescriptive guidance for configuring the Kemp LoadMaster for this scenario can be found here.

Group Policy

This method involves creating unique NLS URLs per site and overriding the default DirectAccess client configuration using Active Directory Group Policy. Separate Group Policy Objects (GPOs) are created and linked to Active Directory Sites to assign a local NLS to internal DirectAccess clients. To accomplish this, create a new GPO for each location where NLS will reside. Edit the GPO and navigate to Computer Configuration/Policies/Administrative Templates/Network/Network Connectivity Status Indicator. Double-click Specify domain location determination URL, choose Enabled, and then enter the URL that corresponds to the NLS for that location.

DirectAccess NLS Deployment Considerations for Large Enterprises

In the Remote Access Management Console, edit the Infrastructure Server Setup (Step 3) and add the FQDN for each NLS. Do not specify a DNS server. This effectively creates a Name Resolution Policy Table (NRPT) exemption so the NLS cannot be reached when the DirectAccess client is connected remotely.

DirectAccess NLS Deployment Considerations for Large Enterprises

In the Group Policy Management Console right-click on Sites and choose Show Sites.

DirectAccess NLS Deployment Considerations for Large Enterprises

Select each Active Directory site where NLS will reside.

DirectAccess NLS Deployment Considerations for Large Enterprises

Link the GPOs for each NLS to the corresponding site, then right-click the linked GPO and choose Enforced.

DirectAccess NLS Deployment Considerations for Large Enterprises

Note: Do not install the NLS on a domain controller! By design, the NLS is not reachable remotely by DirectAccess clients. This can lead to potential authentication issues and may prevent DirectAccess clients from connecting successfully.

Client Testing

To confirm that a client computer has been configured to use a local NLS, verify the currently associated Active Directory site by issuing the following command on the DirectAccess client computer:

nltest /dsgetsite

Next, confirm the setting of the NLS by issuing the following command:

Get-NCSIPolicyConfiguration

As a reference, here are examples from two DirectAccess clients in two different internal physical locations:

DirectAccess NLS Deployment Considerations for Large Enterprises

DirectAccess NLS Deployment Considerations for Large Enterprises

Summary

The limitation of a single Network Location Server (NLS) URL for a DirectAccess deployment presents some challenges for DirectAccess architects seeking to eliminate single points of failure in their design. Using the techniques described in this article, administrators can ensure that DirectAccess clients will always connect to a local NLS, eliminating potential failure points and improving the overall reliability of the solution.

Additional Resources

DirectAccess Network Location Server (NLS) Guidance

Configure KEMP LoadMaster Load Balancer for DirectAccess Network Location Server (NLS)

Configure Citrix NetScaler for DirectAccess Network Location Server (NLS)

Configure F5 BIG-IP for DirectAccess Network Location Server (NLS) 

Leave a comment

23 Comments

  1. xcomiii

     /  April 7, 2015

    Thanks! Never tought of the site GPO trick before.

    Reply
  2. Thomas Forsmark Soerensen

     /  April 9, 2015

    Hi Richard,
    Great article. I never thought about using policies for setting the NLS URL, instead of using local DNS zones on the local DNS servers on the sites.
    However, I think you still miss to inform that the CRL list for the NLS certificate should be accessible for the clients, when they check access to the NLS site. If the CRL is not available then the NLS certificate will be seen as invalid and the NLS check will fail.
    Please Correct me if I am wrong 😀

    Reply
    • Hi Thomas,

      You are correct. The CRL is indeed critical. However, this article assumes that you’ve configured the NLS correctly in the first place, which includes CRL reachability too. Thanks for pointing that out though! 🙂

      Reply
  3. ben petz

     /  June 27, 2015

    Interesting Article many thanks for that. From my experience dns netmask ordering doesnt always work well, if the sites have different network structures. i would go with a single GPO within this you configure the NLS for each Site as GPP registry collection and map this via item Level targeting to each AD site. this one gpo will then always detect the current AD site and configure the right NLS on the client and prevents client connections to a different NLS if a user is working sometimes at site A and sometimes at another site.

    Reply
    • To be honest, I’m not a big fan of relying on netmask ordering myself either. It is included in this article for completeness. Using some of the other alternatives will be much more reliable, for sure. 🙂

      Reply
  4. Craig

     /  August 19, 2015

    Richard,
    I’ve read over the Kemp scenario from your link above, looking at the config for the DirectAccess Server Virtual Service it mentions only 443/IPHTTPS. Am I to assume their product will not work with Teredo or 6to4?

    Also, the section on GPOs assumes a one-to-one relationship between an AD Site and a NLS. We have over 60 AD Sites and configuring 60 NLSs would be an admin nightmare. I assume I can instead create, say 5, NLSs with associated GPOs and map multiple Sites to each of the GPOs?

    Cheers
    Craig

    Reply
    • Hi Craig,

      Regarding your first question, it may be possible to configure a load balancer for use with 6to4 and Teredo, but it’s not something I have ever tried. IP-HTTPS is easy to configure and works well, so that is how I’ve always configured load balancing in these scenarios.

      As for your second question, yes, clearly creating a unique NLS for each site in your scenario would be unwieldy. You can take the concept of the post and apply it as you see fit in your particular deployment. I’ve also had other readers suggest that using Group Policy Preferences might be a good idea too. I’ve not tried that myself, but it might be worth investigating. 🙂

      Reply
  5. Gerald

     /  January 29, 2016

    Hello Richard,

    In this “old” post by Tom Shinder (http://blogs.technet.com/b/tomshinder/archive/2010/07/19/what-defines-a-functional-connection-to-a-network-location-server.aspx) I can read that if the NLS is down a DA client won’t try to build the DA tunnels if it can contact a domain controller. Is this (still) true ? Unfortunately for the moment I don’t have a lab environment available to give it a test… Thanks ! Gerald

    Reply
    • Not true. If the NLS does not respond, the NRPT will be enabled without fail. It’s possible you may be conflating this with Teredo behavior. The Teredo protocol will not be used if *any* domain controller can be contacted. Changing Teredo to Enterprise Client type resolves that. 🙂

      Reply
  6. Craig

     /  March 7, 2016

    Richard,

    For the Group Policy solution would it be prudent to also put a security filter on the GPO so only DirectAccess clients apply it?

    Reply
    • Probably wouldn’t be a bad idea, although it wouldn’t negatively affect other non-DirectAccess clients if they got the policy.

      Reply
      • Craig

         /  March 8, 2016

        Unless you make a typo with your NLS certificate name like I did 🙂 which then caused all the firewalls on the machines targeted by the policy (including servers) to change to the Public profile. Ouch!

  7. Bob

     /  June 27, 2016

    Hi Richard,

    First off, thank you so much for this blog. It’s incredibly invaluable. Now for the question.

    Do you have any guidance for changing the NLS URL in production without affecting DA clients on the internal network? Our current deployment utilized the server’s computer certificate and made the NLS match the server name. We want to decouple the URL from the server name so we can deploy additional instances at our other sites.

    I’ve generated a new certificate for the URL we want to utilize and was considering adding IIS bindings for the old URL with the old certificate after the change is implemented. Does that seem like it would allow us to change the URL and maintain connectivity for clients that haven’t updated group policy yet?

    Reply
    • There are a variety of different ways to address this. I’ve had success in the past creating a new NLS and then creating a separate temporary GPO that overrides the default DirectAccess client policy settings. After you’ve transitioned to the new URL you can safely remove the temporary GPO.

      Reply
  8. Thomas

     /  August 2, 2016

    Hi Richard, thanks for a great post. We are looking into the option of assigning NLS name using GPO (we have about 80 sites). One possible challenge that came to mind though was this. Will a computer be able to receive the GPO (containing the address of the NLS) from the Domain Controller before the DirectAccess Client actually know where to Connect. Regards.

    Reply
    • The DirectAccess client attempts to contact the NLS once immediately after a network interface status change. It would already have gotten the policy at least once before this occurs, so I don’t expect you’d have any issues. However, I would at least make sure that the default NLS FQDN (the one defined in the DirectAccess configuration) is reachable to avoid any potential conflicts.

      Reply
  9. Thorsten Frohberg

     /  February 8, 2017

    Hello Richard, is it normal that after the DA Clients have etablish the DA Connection, they can reach the NLS ?

    Reply
    • No. The NLS should not be reachable over the DirectAccess connection. If it is, there’s definitely a problem with the configuration. It’s also possible that the DirectAccess client has some other network access, either directly or via client-based VPN.

      Reply
  1. Configure Kemp LoadMaster for DirectAccess NLS | Richard Hicks' DirectAccess Blog
  2. Uninstalling and Removing DirectAccess | Richard M. Hicks Consulting, Inc.
  3. DirectAccess Network Location Server Guidance | Richard M. Hicks Consulting, Inc.
  4. Deployment Considerations for DirectAccess on Amazon Web Services (AWS) | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: