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.
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)
Robson Carvalho
/ February 9, 2015Rick,
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!
Richard Hicks
/ February 10, 2015The 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. 🙂
Steve
/ March 11, 2015How 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.
Richard Hicks
/ March 12, 2015Good 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. 🙂
Thomas Forsmark Soerensen
/ March 12, 2015Yes 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.
Steve
/ March 12, 2015Thanks 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.
Richard Hicks
/ March 16, 2015There 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, 2015I 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
Richard Hicks
/ March 17, 2015You’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, 2015Yes. Always use a seperate DNS name for the NLS site no matter which server the NLS sites is placed on. 😀
Thomas Forsmark Soerensen
/ March 12, 2015An 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.
Richard Hicks
/ March 12, 2015Excellent point. Thanks Thomas!
AM
/ June 11, 2015Hi 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 ?
Richard Hicks
/ June 22, 2015That’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.
Matthew Morris
/ September 27, 2015Hi 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?
Richard M. Hicks
/ October 1, 2015At some point yes, but I don’t think you’ll have to worry about it for the foreseeable future.
mfekry86
/ May 30, 2016Hi 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
Richard M. Hicks
/ May 30, 2016Absolutely. 🙂
TJ
/ October 28, 2016This 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?
Richard M. Hicks
/ November 2, 2016Yes, 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. 🙂
Magali Sourbes
/ December 15, 2016My 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.?
Richard M. Hicks
/ December 15, 2016Moving 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!
Mac
/ June 28, 2020Hello Richard,
Many thanks for this blog, do you have published an article about this scenario ? Move a NLS from DA to a external NLS with keep the same NLS URL (or not disruptiive scenario if I change my NLS form DA to another server) ?
Richard M. Hicks
/ June 29, 2020I don’t believe I’ve written anything about that specifically.
Stephen Roper
/ June 15, 2017Great 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?
Richard M. Hicks
/ June 19, 2017Unusual. Assuming when you browse the NLS server it returns a web page of some sort? Either the default IIS start page or something else?
Simon Andree
/ November 24, 2017Hi 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
Richard M. Hicks
/ November 24, 2017Assuming 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. 🙂
Andy OBrien
/ January 26, 2018Hi this may be a very silly question but, Should the NLS only resolve internally?
Richard M. Hicks
/ January 27, 2018Correct! The NLS is used by DirectAccess clients to detect if they are inside or outside your defined internal network. If it were resolvable outside clients would never connect. They’d think they were “inside” even outside your network. 🙂
Craig
/ March 6, 2018Hi Richard,
My company needs to re-IP address all our environment due to a takeover. As a result I need to change the IP address of my NLS (and of course all the internal IPs of my 4 DA endpoints and domain controllers)
Is this something that can done without disruption to my users?
I was thinking that if I reduce the TTL on the DNS record for the NLS a few days in advance and then change the IP over a weekend it would be OK. I can see a reference to the NLS IPv4 address in the DirectAccess Policy-ClientToNlaExempt group policy setting so after the IP change I would run through the DA setup wizard and validate the NLS location to which would hopefully picking up the new IP address and then I’d commit that change and push out the updated Group Policies. The internal clients will be then be able to connect on the Monday morning when they refresh group policy. I’m expecting this change not to effect externally connected clients.
For the DA server internal addresses I would change the IPv4 address and DNS servers (because I’m re-addressing the domain controllers too) on the NIC then in the RA Mgmnt Console go to each server under Enterprise Direct Access -> Entry Point -> Servers and click on “Configure Server Settings” and hopefully see the new IPv4 address and and DNS servers. I’d then commit those changes and push out the updated Group Policies.
Does this sound correct or am I over-simplifying it?
Richard M. Hicks
/ March 10, 2018Hi Craig – Changing the IP address of the NLS is easy enough. Yes, it is a good idea to reduce the TTL on the NLS DNS record to minimize disruption when making the change. However, changing the IP addresses of the DirectAccess servers themselves is likely going to be problematic. In my experience, changing the internal IP address of DirectAccess servers after it is configured often produces poor results. I’ve seen times when it works fine, but other times DirectAccess quits working entirely. If you are looking for a way to do this without interruption, I would recommended deploying new DirectAccess servers with in the new IP subnets and migrating clients to those.
Craig
/ March 10, 2018Ouch. That sounds a bit painful. We are under some very tight timelines so don’t really have time to build new servers.
If you change the internal address and it breaks can you just go back to the original address to fix it or does the change break DA permanently?
Richard M. Hicks
/ March 10, 2018I’ve seen cases where restoring original IP addresses worked, others where it hasn’t. :/ I can only suggest that you have full backups of the servers and GPOs before trying to change IP addresses. If it doesn’t work, restoring is going to be your best bet. Hopefully you’ll be one of those cases where there’s no impact, but best to have a fallback plan just in case. 🙂
Craig
/ March 11, 2018And if it doesn’t work I guess my only option is to remove the server/entry point via the DA wizard, re-IP the server and then re-add it again with the DA wizard?
With the NLS can I just change the IP and update DNS or should I run through the DA wizard and verify the NLS after making the change?
Richard M. Hicks
/ March 12, 2018Correct. As for the NLS, you should be just fine with changing the IP address and updating DNS. Shouldn’t need to re-verify in the Remote Access Management console, although it certainly won’t hurt anything to do that. 🙂
Craig
/ March 12, 2018Thanks Richard, much appreciated. Wish me luck!
Chris Wakefield
/ May 21, 2018Hi Richard!. Thanks so much for all your guides they are a god send!. I have an issue i was wondering if you could point me in the right direction as im scratching my head. We already have an existing DA server setup and I am building a new one along side seperate so we dont disrupt existing testing.
That one is using the Default NLS self signed cert and DNS, and needed to have a different DNS entry for this new environment so…
I created a certificate by our internal CA, the subject name etc matches, there is a DNS entry which matches the subject name and can be pinged. However applying the configuration I get the error
“The subject name of the network location server certificate does not resolve correctly. Ensure that the name resolves to the IP address of the internal network adapter of the server.
I only got a single NIC on here which has both IPV6 and IPV4 address. I have checked, i can ping, the subject name is correct, DNS entry Host A Record is present too and it has the IP address of my DA server. What could i be missing?!
Richard M. Hicks
/ May 21, 2018Not sure, but it could be related to using the collocated NLS on your new DirectAccess deployment. I try to avoid this configuration at all costs, as it is often problematic for a variety of reasons. However, here if you are trying to use a PKI issued certificate for the DirectAccess server hosted NLS, it’s possible that DirectAccess is objecting because it expects a self-signed certificate. Not sure, just conjecture on my part. I might suggest that you use the existing NLS in your environment though, as it won’t negatively affect your new test deployment. Also, you know it works correctly. 🙂
Chris Wakefield
/ May 21, 2018Thanks Richard, i found out what this was and something i left out of my scenario that this is a child domain and the parent domain CA issued the Cert and it didnt like that despite the cert having the matching common and subject name!.
Is there any way of changing the “directaccess-corpConnectivityHost”. When i apply my new config despite changing the GPO names and NLS DNS name, and web probehost, it stops the existing from working?! Could that be to do with the fact that there are multiple “directaccess-corpConnectivityHost” entries with different IPs?
Richard M. Hicks
/ May 21, 2018If you are using IP-HTTPS only you can safely disregard the directaccess-corpConnectivityHost DNS entry. That’s only used for 6to4 and Teredo. It has no impact on DirectAccess operation for IP-HTTPS only deployments. The directaccess-WebProbeHost record is crucial however. It should resolve to a web server listening on TCP port 80. It can be an internal web server or any of the DirectAccess servers too. Your choice.
Mark Robinson
/ February 25, 2021This guide is really well put together – thanks. I seem to have a unique problem that I can’t find any help on. Microsoft have looked at this and not found a solution. I have inherited a DA infrastructure in the job I am in. And it was worked reliable and happily for many years. However we found that whenever we upgrade out WIN10 clients beyond 18.09, Direct Access stops working.
It is quite a unique issue in that on bootup DA is connecting correctly, but once connected the NLS server becomes visible for just a few seconds. This causes the DA client to incorrectly believe it is inside the network. It seems something is secretly slipping my client a IPV6 number for the NLS and it must be returning a ping. Once the client has decided I am inside the network, when I am actually outside then nothing will work.
If I look at my DA client in the GUI it just constantly says “connecting”
Any ideas anyone has would be most welcome
Googling will find a few people talking about DA stopping working after 1809, but no definitive answers are out there that I can find
Richard M. Hicks
/ February 27, 2021This could be caused by any number of things, but I’ve heard more than a few reports of clients reverting from Enterprise Edition to Professional after a version upgrade. Make sure your clients are still reporting as Enterprise Edition, otherwise DirectAccess won’t work.
Mark Robinson
/ March 1, 2021Sadly no, they haven’t reverted to professional. However I have found that I do have full DA connectivity by forcing the reg key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\EnableDAForAllNetworks to 1. This forces DA on for all connections. In this configuration I can clearly see that my NLS is returning pings using IPv6. I am assuming if I could find out why I am getting pings returned I could stop them and it would be ok
Richard M. Hicks
/ March 1, 2021If your NLS is resolving over the DirectAccess connection it is configured correctly. The NLS should be excluded in the NRPT. Have a close look at that and make sure the NLS FQDN is in the NRPT as an exclusion (no DNS server defined). Once you can’t resolve it to an IPv6 address when connected via DirectAccess it should work as expected.
Mark Robinson
/ March 2, 2021Richard – thanks you you have solved an 18 month puzzle!!. Every google search I ever did bought me back to your pages and I have poured through trying to apply the information to my problem. But your last post has pointed the way for me. We had the host name of the NLS only in our NRPT. I changed it to the FQDN and it is working perfectly.
I don’t know how it manged to work for year with incorrect configuration. But I have got it soak testing with 1803 and 1909 and 20H2 machines and it all seems well.
A million times thank you.
If I can ask one more question. Should I be able to route traffic out of my network to DA connected machines. IE can a machine inside my LAN get to see \\NAME\C$ on a DA connected client?
Richard M. Hicks
/ March 2, 2021Yes. How you do it depends on how DirectAccess is set up. How many DirectAccess servers do you have? If you have more than one, is it configured in a load-balanced cluster? Is multisite enabled?
Mark Robinson
/ March 3, 2021I have 2 DA servers in a load balanced cluster
Richard M. Hicks
/ March 3, 2021NLB or external load balancer?
Mark Robinson
/ March 4, 2021Network Load Balanced >
Thanks for taking the time!!!!
Richard M. Hicks
/ March 4, 2021Easy. Documented here: https://directaccess.richardhicks.com/2017/12/14/directaccess-manage-out-with-isatap-and-nlb-clustering/.
Enjoy!
Mani
/ November 18, 2021We had a weird issue where all the external DA clients were stopped working. We noticed that from DA servers the DNS query to DNS server for NLS URL was blocked by IPS filter. After disabled the filter, all the clients are able to connect. My question here is, how the external users got affected when the NLS query was failing on DA server which is used for internal users only. Ideally external users shouldn’t have got affected.
Richard M. Hicks
/ November 18, 2021That’s quite odd. NLS reachability should have no effect on DirectAccess clients outside the network. In fact, that’s what the NLS is for. If it isn’t reachable, for whatever reason, then DirectAccess connects. 🙂 I can’t imagine why in this scenario the NLS being unreachable from your clients in the field would break. I suspect it must be something else though.