UAG DirectAccess: Network Location Server (NLS)

UPDATE: My guide for Configuring DirectAccess with UAG Service Pack 1 has been released! Read it here.

DirectAccess enabled clients use a pretty rudimentary assessment to determine if it should use the virtual interfaces to connect to “corporate resources”.  The primary test is to see if the Network Location Server (NLS) can be found.  This is an incredibly basic web service that needs only to respond to a HTTPS request.  And by “respond” I mean any kind of good response from the web service like a blank HTML file.  As long as the HTTPS request is responded to, then the client decides it is INSIDE the corporate network and will NOT enable the DirectAccess virtual adapters. While the NLS service itself is very basic, it plays a pretty vital role to any DirectAccess deployment in order for DA clients to behave properly.  If the NLS cannot be found when they are inside the corpnet then they might tunnel all traffic through the UAG server instead of just go directly to the local resource.  Conversely, if the client is able to find the NLS while outside of the corpnet then they will not send traffic through the UAG server and will never reach those resources at all.  So it’s pretty important to have the NLS configured correctly and ensure that it is available only when INSIDE the corpnet.  In fact, Microsoft recommends that you make the NLS Highly Available, be it NLB or Failover Clustering. While it may not be the recommended way, in this guide we’ll be using a single IIS server to act as the NLS.  If you have an existing HA IIS farm then you should definitely put the NLS on that farm.  If you have an intranet web server, then you may want to put the NLS on there.  If you currently have no internal IIS servers, then you could build one (especially if you are running virtual servers) or you could install the IIS role on an existing server.  I have put the NLS on the Enterprise Certificate server and that seems to work well for a few reasons:

1. The Certificate server typically has a pretty low utilization anyway, and the NLS has very little overhead.  Standing up a full Windows server just to run the NLS IIS site could incur additional licensing costs that may be hard to justify, unless your DirectAccess deployment is particularly large.
2. There are a couple other simple IIS sites that DirectAccess clients use (CRL and DCA for example) and I find it easier to place them all on one host.  Also, because these sites have some interdependency’s (if one is down they may as well all be down) it minimizes administration overhead of the host OS’s.
3. The NLS requires an SSL certificate which must be checked against the Certificate Revocation List (CRL).  If the CRL is hosted by the Certificate server and the CRL is unavailable, then the certificate for the NLS cannot be verified and the connection check to the NLS will fail anyway.  So there is a pretty tight co-dependency between the NLS and the CRL.  Rather than make two servers that you need to independently maintain and keep available, I put them on the same host.  I figure if one is down then effectively so is the other one anyway, so may as well keep them together if you’re not making a Highly Available environment.
4. If your needs or scenario changes then following the steps I outline below will allow you relocate the NLS to another server pretty easily.  Just make sure that you give it it’s own IP and hostname.

So let’s stand up a Network Location Server on an existing Windows Server 2008 R2 server, presumably your Certificate server.

Bind a Secondary IP Address

In order to isolate the NLS and make it easy to move from one server to another (or perhaps to a cluster someday) I recommend assigning an IP address to represent your Network Location Server.  Pick something in your private network; This will not be available externally, so do not reuse an IP or hostname that DirectAccess clients should be able to reach from outside. In addition, if your server is a virtual server, I find it useful to actually add a second virtual network adapter to be used for the IIS sites.  As I mentioned earlier, I eventaully will tie three sites and IP’s to this nic.  This will isolate Web traffic from the Host traffic, gives you the ability to place it on a different network if you needed to and it makes DNS management a bit easier IMO.  Plus it also serves as a pretty obvious reminder to administrators that this host does more than just run certificates when they see an adapter named “IIS Sites” and might cause them to think twice before rebooting or shutting down the server in the middle of the day. 

 Open the properties of your NIC then the Properties of TCP/IPv4.  Select “Use the following IP address” but leave the fields blank.  Instead, click the Advanced button.  This is where you can add several IP addresses that will operate over this NIC. 

 Click Add, fill in the IP Address and Subnet that you want to use for NLS and click Add.  Now click the Add button to enter the Gateway.  Leave Automatic metric checked. Before clicking OK, select the DNS tab.  Here you should set the DNS suffix to your internal domain name and UNcheck the “Register this connection’s addresses in DNS”.  This prevents the server from registering these IP addresses with the server’s hostname instead of the IIS site name like we want. 

 Now you can click OK and close the control panel.

Create a DNS Record

In order to allow clients to find this website we need to manually create an A Record so that “NLS.domain.com” will resolve to the IP address you just set.  Open the DNS MMC and connect to one of your DNS servers or Domain Controllers.  Navigate to the Forward Lookup Zone for your domain, right click it to select New Host. 

 Enter the hostname you want to use (I recommend “nls”) and the IP address that you assigned in the previous step.  Also, check the box to create the PTR record.  This will generate the “reverse dns” record so clients can lookup the IP address and find the hostname. 

 Click Add Host and you’re done here.  You can close the DNS MMC. NOTE: You must NOT have this hostname available outside of your corpnet!  If this hostname resolves to any working HTTPS web server on the Internet then your DirectAccess clients will always think they are “inside”.  They will never bring up the DirectAccess virtual adpaters and will not be able to access the corproate resources they are supposed to.  So you should never create an External DNS Record for this hostname.  You want external requests for this hostname to fail so that they know they are “outside” and need to use DirectAccess.  Later we’ll go over how DirectAccess clients are prevented from reaching the internal NLS over DirectAccess through Exclusions on the UAG server.

Configure the IIS Site

As I mentioned earlier, the NLS is a very simple HTTPS site.  It doesn’t even need any content, it just need to exist and repond to requests.  So all that needs to be done is install IIS if it isn’t there already, then create a new site, bind it to the IP address you configured earlier and select the certificate. If you haven’t installed IIS yet, you can use this guide as a how-to.  For the most part you should just need to open the Server Manager and Add the Web Server Role. Before creating the site, you’ll want to import the SSL Certificate that the NLS will be using.  Here is a nice guide on how to create the certificate request and import it into IIS 7.  I like to use a friendly name like “NLS IIS Cert” but make sure the “common name” is actually the FQDN of the NLS site.  For example, “nls.domain.com“. Once IIS has been installed and you have installed the SSL Cert, you can create the directory that the site will look in for content.  Again, the NLS itself doesn’t NEED to deliver any content, but the IIS site needs to know where it should pull content from if it had any.  I like to create a new folder on the root of the server’s C: called “nlsroot” for this.  One thing you could do, just to make things pretty is to create a new text file named “default.htm” in the root of this folder and put something in there like “You are on the inside” so that when you load the web site, instead of seeing nothing you at least get a message and you know it is pulling up the correct site. To create the IIS site, open the IIS MMC and drill down to the Sites list.  Right click it and select Add Web Site. 

 Now you can name the site (I recommend “Network Location Server”), set the Path to the folder that will have the content for this site (it can be an empty directory), select HTTPS as the binding type, select the IP address that you created the DNS record for the NLS and then select the SSL cert that you already imported. 

 Now you can “Test Settings” and if all goes well, click OK and the NLS site should now exist.

Test Connectivity

To make sure the NLS site is working correctly just open up a web browser and try to load https://nls.domain.com/ and you should get a web site.  Make sure you do this test from inside your corpnet and from a domain member computer.  If the web site does not load then you will need to double check the DNS record and IIS setting as well as permissions on the folder that IIS is looking at.  Also make sure that you are not getting any sort of warnings about the certificate being invalid.  If you are testing from a non-domain machine then your test computer will not trust the certificate.  As long as the FQDN is being used and you specified that FQDN as the common name in your certificate then you should good to go.

Next Step:

Index 1. IP Addressing the UAG Server 2. Unified Access Gateway Installation & Updates 3. Firewall and DNS Considerations 4. Certificates, Groups and Client Requirements 5. Configure other Prerequisites for UAG 6. Configuration Wizard: Clients 7. Configuration Wizard: DirectAccess Server 8. Network Location Server (NLS IIS site) 9. Configuration Wizard: Infrastructure Servers 10. Configuration Wizard: Application Servers 11. Generate and Activate Policies 12. DirectAccess Connectivity Assistant 13. What won’t work over DirectAccess