DirectAccess Network Location Server Guidance

Introduction

The Network Location Server (NLS) is a critical component in a DirectAccess deployment. The NLS is used by DirectAccess clients to determine if they are inside or outside of the corporate network. If a DirectAccess client can connect to the NLS, it must be inside the corporate network. If it cannot, it must be outside of the corporate network. It is for this reason that the NLS must not be reachable from the public Internet. A client configured for DirectAccess will probe the NLS when it first starts, and on subsequent network interface status changes.

What is the NLS?

The NLS itself is nothing more than a web server with an SSL certificate installed. Beginning with Windows Server 2012, the NLS can be collocated on the DirectAccess server itself. Although there may be scenarios in which this is acceptable, it is generally recommended that NLS be configured on a server dedicated to this role.

NLS Configuration

Any web server can be used, including IIS, Apache, Nginx, Lighttpd, and others. You can also use an Application Delivery Controller (ADC) like the F5 BIG-IP Local Traffic Manager (LTM), as described here. The web server must have a valid SSL certificate installed that includes a subject name that matches the NLS FQDN (e.g. nls.corp.example.com). The DNS record for the NLS must configured using an A host record. A CNAME DNS entry will not work. In addition, the NLS must also respond to ICMP echo requests.

DirectAccess Network Location Server Guidance

DirectAccess Network Location Server Guidance

The certificate can be issued by an internal PKI or a public third-party Certificate Authority (CA). A self-signed certificate can be used if the certificate is distributed to all DirectAccess clients and servers, but this is not advisable. To avoid possible service disruptions, the NLS should be made highly available by deploying at least two NLS in a load balanced configuration.

What Happens if the NLS is Offline?

If the NLS is offline for any reason, remote DirectAccess clients will be unaffected. However, DirectAccess clients on the internal network will mistakenly believe they are outside of the corporate network and attempt to establish a DirectAccess connection. If the DirectAccess server is not accessible from the internal network, the client will be unable to connect to any local network resources by name until the NLS is brought online or other actions are taken.

Collocation Issues

As mentioned previously, it is possible in some scenarios to collocate the NLS on the DirectAccess server. This is probably acceptable for proof-of-concept deployments, but any production deployment should have the NLS configured on a server dedicated to this role. If the NLS is located on the DirectAccess server and the server is offline for any reason, DirectAccess clients on the internal network will be unable to access local resources by name until the DirectAccess server is back online.

Don’t Use Existing Web Application Servers

Occasionally I will encounter a scenario in which an administrator who wants to avoid implementing additional infrastructure will use an existing internal web application server for the NLS, such as a SharePoint server. Although this will work, it quickly becomes an issue when remote DirectAccess clients need to access the server. Since the NLS is not resolvable or reachable externally, connectivity will fail, preventing DirectAccess clients from reaching the internal application.

Summary

The NLS is a vitally important piece of the DirectAccess architecture. DirectAccess clients use the NLS to determine their location, and if the service is unavailable for any reason (planned or unplanned) internal DirectAccess clients will be negatively affected. The NLS isn’t necessarily complicated, as it is nothing more than a web server with an SSL certificate installed. However, don’t overlook the importance of this service, and make sure it is highly available to avoid any potential network connectivity issues.

Additional Resources

DirectAccess Network Location Server (NLS) Deployment Considerations for Large Enterprises

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

32 Comments

  1. Rick,

    Great article but I have a note about the topic “Don’t use existing web application”

    if we use a exclusive name for reach nls and a different name for reach the web application, in this case dont have problem, because the advertise is ” Don’t publish the nls in the public dns and create a exception on DirectAccess for dns resolution of registry of nls”

    Hugs!

    Reply
    • The recommendation not to use an existing internal web application server also has to do with availability. If a developer publishes an application to a web server where the NLS is also hosted, it is possible that the NLS could be affected negatively. For example, if the web application server needs to be recycled after installation, NLS will be offline and internal DirectAccess clients will be impacted. But yes, it is possible to collocate the NLS on a web application server using different IP addresses or SNI. 🙂

      Reply
  2. Steve

     /  March 11, 2015

    How can deploy multiple Network Location Servers for a single Direct Access 2012 R2 solution? I cannot seem to find any tutorials on how to do this. Is it possible to do this? I don’t mean NLB but rather having more than one Network location server. Thanks.

    Reply
    • Good timing. I’m currently working on an article that addresses just this scenario. 🙂 The reality is that DirectAccess supports only a single NLS URL per deployment, but there are some alternatives available for you. If you have an ADC that provides Global Server Load Balancing (GSLB) services (e.g. F5 Global Traffic Manager or Kemp LoadMaster GEO) you can use that. I’m also testing some other options. Stay tuned for more details. 🙂

      Reply
    • Thomas Forsmark Soerensen

       /  March 12, 2015

      Yes it is possible. If you fx have several sites connected with unstable WAN connections it can be a good idea to have a NLS server at every site. You only need to make sure that the local NLS site is pointed to by the local DNS.

      Reply
      • Steve

         /  March 12, 2015

        Thanks for your reply gents. So what I gather is there is a “simple” way to do this as DirectAccess itself does not natively support this functionality but rather you have to use the DNS record to allow for multiple “hot standby”, if you will NLS servers.

        In the event that the primary NLS server goes down for some reason you would have to manually change the IP address of the NLS DNS record. Would it be simply enough for them to each have their own internal CA issued SSL certificate?

        If the CRL lists for the certificate is hosted on the internal CA, by default, should that be enough if it is available?

        Another thought I have is if there are DA clients at WAN satellite offices without an NLS server the WAN goes down that would cause problem.

      • There are a number of different ways in which NLS availability can be addressed, really. Using NLB is quick and simple, but doesn’t provide for geographic load balancing. This becomes an issue for clients in a remote location if the WAN link goes down. Depending on your DNS configuration, you could use round-robin DNS and netmask ordering should connect clients to a local NLS. And, as you mentioned, you can do this manually by updating DNS entries. If you choose that route, I’d suggest using a very short TTL on that DNS record. CRL availability shouldn’t be an issue with internally issued certificates.

      • Thomas Forsmark Soerensen

         /  March 16, 2015

        I have a solution for the WAN satellite sites. I am not sure if it is best practices but as I see it, it will work.
        DA clients in a WAN satellite need to be able to access two resources to be able to function normally (DirectAccess wise).
        1. They need to be able to access the CRL lists for the certificate used on the NLS site.
        2. They need to be able to access the NLS site
        In the case of a WAN link is down those resources must be accessible locally on the satellite site, otherwise the clients will not be able to access local resources.
        When issuing a certificate for the NLS site at the internally CA make sure that the CRL lists for the NLS certificate are published to the AD. That way the CRL lists will be replicated to a local DC on the satellite site.
        The next thing is to make sure that the NLS site is available even when the WAN link is down.
        This can be done by creating a local NLS site and then create a local zone for the nls.domain.local that points to the local NLS site. The zone MUST not be AD integrates because it is for this site only. (Se here how to create such a zone: (http://failsys.com/2011/12/08/redirecting-name-resolution-of-a-single-host-for-an-external-dns-zone/)
        The clients should then be configured to use the local DNS as primary DNS and a central DNS server as secondary DNS server.
        As long as the local DNS server is up and running the clients will then use the local NLS server. If DC is down then the central DNS will be used and therefore the central NLS site will be used.
        Now to the part that might not be best practices. We could place the local NLS site on the local DC. This means that the local NLS will be down when the local DNS is down and therefore the central NLS will be used (if the WAN link is not down as well).
        The above-mentioned solution might not be beautiful but I think it will work and ensure that local resources can be access from DirectAccess clients even when the WAN link is down.

        Thomas

      • You’re stealing a bit of thunder from one of my upcoming blog posts, but yes, this looks reasonable. 🙂 Just use caution when collocating the NLS on the DC. Best to keep them separate, but if you have limited resources (common in branch office scenarios) it might be necessary. If you do put the NLS on the DC, be sure to use a unique hostname along with an “A” resource record in DNS. Recall that the NLS is not available to clients outside of the corporate network. If the NLS uses the same name as the DC, then the DC can’t be contacted and remote DirectAccess clients can’t authenticate or connect. 🙂

      • Thomas Forsmark Soerensen

         /  March 17, 2015

        Yes. Always use a seperate DNS name for the NLS site no matter which server the NLS sites is placed on. 😀

  3. Thomas Forsmark Soerensen

     /  March 12, 2015

    An important thing to notice is that the CRL lists for the NLS certificate should also be available otherwise the NLS certificate will be seen as invalid and the NLS will not work.

    Reply
  4. AM

     /  June 11, 2015

    Hi Richard,
    Do you believe it wise to join servers of two different network zones (difference is in trustlevels granted to each zone) using Direct Access to our internal AD Domain.
    I don’t read that Direct Access is build for this purposes. What do you believe the risks are ?

    Reply
    • That’s certainly an interesting use case for DirectAccess, and one I’m sure is not common. DirectAccess is designed as a client remote access solution, but I don’t see any reason why it wouldn’t work though. Windows Server 2008R2 and 2012/R2 are both supported clients after all. However, it might be simpler to use IPsec as opposed to implement a DirectAccess solution for this.

      Reply
  5. Matthew Morris

     /  September 27, 2015

    Hi Richard,

    Quick question, with the pending depreciation of SHA1 certificates do you know if the nls certificate will be impacted? Does it need to be upgraded to SHA256 signatures?

    Reply
  6. Hi Richard
    Hope you are doing well , can i share the NLS servers within multiple DA deployment instead of building dedicated NLS server for each DA deployment , please note that all DA server & NLS in same domain , but i need to share NLS across the deployments

    Reply
  7. TJ

     /  October 28, 2016

    This article is great! I have inherited a network that uses DA, and this answers a big question about the load-balanced IIS server that doesn’t appear to actually do anything. 🙂

    One question though, the person that configured our DA deployment put the nls url in the DNS suffix name list without a DNS server specified. Essentially, DA clients are unable to reach the NLS server after they have connected. Is this a normal configuration?

    Reply
    • Yes, that’s expected. The NLS is designed to allow the client to detect if it is inside or outside of your network. If it can reach the NLS, it is inside. If it can’t, it is outside. If the NLS were reachable over the DirectAccess connection, it wouldn’t be able to serve its purpose. 🙂

      Reply
  8. Magali Sourbes

     /  December 15, 2016

    My NLS is currently collocated on the DA server but I’d like to move it. Is this going to affect my internal users when I make the change, or will they just pick up the change automatically.?

    Reply
    • Moving the NLS from the DirectAccess server to another dedicated server can be potentially disruptive, yes. When you update the DirectAccess configuration to reflect the new NLS location, the NLS running on the DirectAccess server is removed immediately. If a client comes online before receiving the new configuration via group policy, it will be unable to connect to local resources. To avoid any outages it is recommended to keep the NLS URL the same. This can be challenging if the NLS URL is the name of the server though. I’m actually working on a blog post that talks about this very scenario. Hopefully I can get it published soon. Stay tuned!

      Reply
  9. Great article and usually never have an issue with the NLS config. But this time my customer NLS fails on the operations Status. When running the PS cmd “Get-DANetworkLocationServer -Checkreachability” the Reachability comes up false. It provides no reason. I can ping /resolve the NLS URL in my user context. The Web server firewall is off.
    If I run the PS cmd “Set-DANetworkLocationServer -url https://nls.mycompany.com -Checkreachability” it reports the following error “Specified URL cannot be Resolved”

    I found and applied KB3047280 with no effect. Clients fail too if they get the DA GPO’s when the DA host is configured with the external NLS. If I configure the DA NLS to point to its self it all works.

    You have any advice how to troubleshoot this issue?

    Reply
    • Unusual. Assuming when you browse the NLS server it returns a web page of some sort? Either the default IIS start page or something else?

      Reply
  10. Simon Andree

     /  November 24, 2017

    Hi Richard,
    We are having an issue at the moment with our Direct Access deployment. We have setup two Direct Access Servers, one setup as Edge whilst the other is setup as behind an Edge device. Reason for this is because we wanted to get Teledo working, although that never seems to connect. Always goes to IP-HTTPS. We have setup one of these Direct Access servers as the NLS, and the other DA server points to this. I can ping the NLS URL internally. Problem is the DA clients are connecting to DA whilst on the corporate LAN when they should not be. Surely they should be disconnecting? Any ideas what this could be?

    Many thanks
    Simon

    Reply
    • Assuming this is two separate DirectAccess deployments implemented in parallel, then this is to be expected. The reason is most likely because the NLS is collocated on the DirectAccess server and using a self-signed certificate. Only clients from that deployment would trust it. Clients from the other deployment would not, which would mean they’d try to connect using DirectAccess. Best advice is to move the NLS off-box for both deployments and use a certificate issue by your internal PKI. Shouldn’t have any issues after that. 🙂

      Reply
  1. Configure F5 BIG-IP for DirectAccess NLS | Richard Hicks' DirectAccess Blog
  2. Configure Kemp LoadMaster for DirectAccess NLS | Richard Hicks' DirectAccess Blog
  3. Direct Access issues
  4. Uninstalling and Removing DirectAccess | Richard M. Hicks Consulting, Inc.
  5. DirectAccess NLS Deployment Considerations for Large Enterprises | Richard M. Hicks Consulting, Inc.
  6. 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: