Network Location Server

Network Location Server (NLS) is a server, which will be used by URA clients to detect when they are inside your corporate network. This is a very important function, because unlike traditional VPN, the user can't simply turn their URA connection on or off. When the computer is connected to the corporate network, it should behave like any regular client, and we would want the connection to be off so that the computer can communicate with the corpnet resources directly. This is not only to avoid wasting resources by going out-and-around, but also in case something is wrong with the connection and we want to apply new settings to it via Group Policy.

The URA clients have a component referred to as Network Location Awareness (NLA), which detects their location by trying to contact the location server routinely. If they fail in getting a response or are unable to resolve the name of the NLS, they deduce that they are on the public Internet and turn on the URA connection. If they succeed, the URA connection stays off.

The communication process is a simple HTTPS connection. The location server runs a secure website to which the client connects. If the connection succeeds (the HTTP connection succeeds and gets a 200 OK response code), the client determines that it's inside the network and acts accordingly. With a basic URA scenario, the web service role is automatically configured by the URA wizard and the URA server serves as the location server, so the NLS doesn't require additional manual configuration.

One thing that is important to understand with regards to the location server is that it's more than a key component to URA. Since its very existence is what allows the clients to know they are inside the network, any malfunction in that functionality is a major negative impact on your network. If the URA server is offline, your clients won't be able to connect from home, but if the server is completely down (taking with it the location service), your mobile clients will think they are outside the corporate network even when they are inside. This would cause them to attempt to start the URA connection, which would fail, of course, and none of these clients will be able to connect to any resource on the internal network. This is a grim situation to say the least. For this reason, you might want to consider separating this role from the URA server even if your deployment is relatively small and configure at least two servers in a redundant setup.

URA certificates

Another piece of the setup is certificates. Certificates are used for two purposes with URA:

These two certificates can be generated by the URA server itself (a self-signed certificate), and that's usually the easiest option. You can also elect to use your own certificates. If you use your own location server, you will need to generate the certificate for it on your own. We will discuss this later in this chapter.

An important part of the basic setup of URA in general is the authentication. The standard authentication scheme for Windows Domains is Kerberos. Kerberos authentication is not simple, but in a situation where the connecting client (a URA client in our situation) is coming from the Internet, it makes things a little more complicated than the way it works when authentication is done from inside the network. To make things as easy as possible, URA installs a service called Kerberos Proxy (and sometimes also referred to as KerbProxy or KDC Proxy). This service allows the connecting client to perform Kerberos authentication against the domain seamlessly and without the cumbersome PKI (Public Key Infrastructure). Before this service came along, every organization that wanted to use DirectAccess had no choice but to configure a complex setup of a certificate authority and certificate distribution, and it was the most common cause of problems with the DirectAccess deployments.

Technically, the URA client creates a secure connection, using TLS, to the Kerberos Proxy service running on the URA server. The service sends the request to the domain's domain controller (which is a Kerberos Key Distribution Center or KDC for short), fetches a Kerberos ticket for the client, and forwards it to the client. Once a ticket has been obtained, it can be used for subsequent connections to domain resources.

Basic scenario considerations

The things you need to consider and decide upon for this scenario include the following:

Having made these decisions, you are almost ready to start the installation procedure for Unified Remote Access, which we will discuss in Chapter 4, Installing and Configuring the Unified Remote Access Role. However, if you are planning to use some of the more advanced scenarios, such as offering support for Windows 7 clients or multisite, you should read on and get a better understanding of some of the additional concepts.