If you zipped through the default settings when configuring DirectAccess, or worse, used the Getting Started Wizard, chances are that your Network Location Server (NLS) is running right on the DirectAccess server itself. This is not the recommended method for using NLS; it really should be running on a separate web server. In fact, if you want to do something more advanced later, such as setting up load-balanced DirectAccess servers, you're going to have to move NLS onto a different server anyway, so you might as well do it right the first time.
NLS is a very simple requirement, but a critical one. It is just a website, it doesn't matter what content the site has, and it only has to run inside your network. Nothing has to be externally available. In fact, nothing should be externally available, because you only want this site accessed internally. This NLS website is a large part of the mechanism by which DirectAccess client computers figure out when they are inside the office and when they are outside. If they can see the NLS website, they know they are inside the network and will disable DirectAccess name resolution, effectively turning off DA. If they do not see the NLS website, they will assume they are outside the corporate network and enable DirectAccess name resolution.
There are two gotchas with setting up an NLS website:
- The first is that it must be HTTPS, so it does need a valid SSL certificate. Since this website is only running inside the network and being accessed from domain-joined computers, this SSL certificate can easily be one that has been issued from your internal CA server. So there's no cost associated there.
- The second catch that I have encountered a number of times is that for some reason the default IIS splash screen page doesn't make for a very good NLS website. If you set up a standard IIS web server and use the default site as NLS, sometimes it works to validate the connections and sometimes it doesn't. Given that, I always set up a specific site that I create myself, just to be on the safe side.
So let's work together to follow the exact process I always take when setting up NLS websites in a new DirectAccess environment.
Our NLS website will be hosted on an IIS server that runs Server 2016. Most of the work will be accomplished from this web server, but we will also be creating a DNS record and will utilize a Domain Controller for that task.
Let's work together to set up our new Network Location Server website:
- First, decide on an internal DNS name to use for this website and set it up in DNS of your domain. I am going to use
nls.mydomain.localand am creating a regular Host (A) record, which pointsnls.mydomain.localto the IP address of my web server. - Now log in to that web server and let's create some simple content for this new website. Create a new folder called
C:NLS. - Inside your new folder, create a new
Default.htmfile. - Edit this file and throw some simple text in there. I usually say something like
This is the NLS website used by DirectAccess. Please do not delete or modify me!.
- Remember, this needs to be an HTTPS website, so before we try setting up the actual website, we should acquire the SSL certificate that we need to use with this site. Since this certificate is coming from my internal CA server, I'm going to open up MMC on my web server to accomplish this task.
- Once MMC is opened, snap in the Certificates module. Make sure to choose Computer account and then Local computer when it prompts you for which certificate store you want to open.
- Navigate to Certificates (Local Computer) | Personal | Certificates.
- Right-click on this Certificates folder and choose All Tasks | Request New Certificate....
- Click Next twice and you should see your list of certificate templates that are available on your internal CA server. If you do not see one that looks appropriate for requesting a website certificate, you may need to check over the settings on your CA server to make sure the correct templates are configured for issuance.
- My template is called Custom Web Server. Since this is a web server certificate, there is some additional information that I need to provide in my request in order to successfully issue a certificate. So I go ahead and click on the link that says More information is required to enroll for this certificate. Click here to configure settings.
- Drop down the Subject name | Type menu and choose the Common name option.
- Enter a common name for our website into the Value field, which in my case is
nls.mydomain.local. - Click the Add button, and your CN should move over to the right side of the screen like this:
- Click on OK then click on the Enroll button. You should now have an SSL certificate sitting in your certificates store that can be used to authenticate traffic moving to our
nls.mydomain.local name. - Open up Internet Information Services (IIS) Manager and browse to the Sites folder. Go ahead and remove the default website that IIS had automatically set up so that we can create our own NLS website without any fear of conflict.
- Click on the Add Website… button.
- Populate the information as shown in the following screenshot. Make sure to choose your own IP address and SSL certificate from the lists, of course:
- Click the OK button, and you now have an NLS website running successfully in your network. You should be able to open up a browser on a client computer sitting inside the network and successfully browse to
https://nls.mydomain.local.
In this recipe, we configured a basic Network Location Server website for use with our DirectAccess environment. This site will do exactly what we need it to when our DA client computers try to validate whether they are inside or outside the corporate network. While this recipe meets our requirements for NLS, and in fact puts us into the good practice of installing with NLS being hosted on its own web server, there is yet another step you could take to make it even better. Currently, this web server is a single point of failure for NLS. If this web server goes down or has a problem, we will have DirectAccess client computers inside the office thinking they are outside, and they will have some major name resolution problems until we sort out the NLS problem. Given that, it is a great idea to make NLS redundant. You could cluster servers together, use Microsoft Network Load Balancing (NLB), or even use some kind of hardware load balancer if you have one available in your network. This way you could run the same NLS website on multiple web servers and know that your clients will still work properly in the event of a web server failure.