How does it work?
If you haven't used DirectAccess before, the entire thing may seem mysterious. How does it compare to more traditional VPN solutions? What does it do under the hood? How the heck does it work without any additional software?
The concept of Virtual Private Networking is built around the idea of sending your confidential data over an open medium (the public Internet) and protecting it with encryption. Over the years, various encryption protocols and methods have been in use, such as PPTP, L2TP, and SSL. VPN connections work with some kind of client software which does all the work. The client software establishes a connection to the target VPN server, and authenticates the user to the server. Then, the software creates a virtual network card, which makes the whole thing transparent to the user and his applications. When an application sends out data, the virtual NIC intercepts it, encrypts it, and sends it out to the VPN server. The VPN server decrypts it, and sends it out onto the corporate network.
Unified Remote Access is no exception to that concept. The security piece (encryption) is done using IPsec, which is a very advanced security protocol that was designed for the twenty-first century. As in the previous versions of DirectAccess (with Windows Server 2008 R2 and Unified Access Gateway 2010), the advanced setup of Unified Remote Access 2012 uses the two IPsec tunnels mechanism. This mechanism uses two stages that complement each other. The first tunnel is an intermediate step, because all it can do is provide the means for the client to perform the next step of the authentication. Then, the second tunnel is established, with the first tunnel providing the path to perform the authentication for it.
In the first tunnel, the Windows Firewall uses two levels of authentication. The first authentication uses computer certificates (this is why the Certificate infrastructure was required to distribute the machine certificates to all client machines and the DirectAccess server). The second authentication in the first tunnel uses the NTLM credentials of the computer account in the domain (this is why DirectAccess requires that all clients be domain members). The two levels of authentication make it highly secure. Because the computer account is used in the first tunnel authentication, the tunnel can be established even before the user logs on to the machine. This allows the domain administrator to connect to the client securely for the purpose of remote-management, even before the user is logged on to the machine. For this reason, this first tunnel is also called the machine tunnel or the management tunnel.
The second tunnel also uses two levels of authentication, but this time, the computer uses certificates for the first authentication and Kerberos for the second. Since it uses the user's Kerberos tickets for the IPsec encryption, it is also called the user tunnel. This tunnel is used to reach the entire corporate network (as opposed to just the domain controllers, which the first tunnel allowed the client to reach). You might be wondering why we need all this trouble and don't just use Kerberos authentication for the first tunnel to begin with. Well, to perform Kerberos authentication, the client has to talk directly to the domain controller. At the stage where the client starts connecting to DirectAccess, it can only connect to the DirectAccess server and cannot connect to the domain controllers (because they are inside the network). However, NTLM authentication does not require the client to talk to the domain controllers directly, and the DirectAccess server verifies the credentials against the domain controller for the client. Once the credentials have been verified, the tunnel is established and the client can now talk to the domain controllers directly, paving the way for the Kerberos authentication to go through.
Tip
You can think of this like going into an apartment building; you need the front-door key to get into the building, and then your apartment key to get into your apartment. Your front-door key only lets you see the apartment doors and not into the apartments themselves, and by gaining access into the building, you have the means to approach and unlock the apartment itself.
The first tunnel can actually have a scope that's a bit wider. The administrator can define it to allow access to other servers, such as a WSUS, NAP, and SCCM servers, if he chooses to. If so, the tunnel can also allow the client to check for security updates or perform other secondary security checks before proceeding with setting up the second tunnel. We will talk about how to set up the health policies to control access in the later chapters.
Before URA with Windows Server 2012, many customers faced challenges with deploying computer certificates, which made deploying DirectAccess difficult. In Unified Remote Access 2012, Microsoft addressed this by adding an option for a simpler setup. This setup allows the Kerberos authentication to take place via the first tunnel (the machine tunnel) using a special service on the URA server. This service, known as Kerberos Proxy or Kerbproxy, removes the obstacle by being the middle-man, and proxying the Kerberos authentication process.
One limitation of the Kerberos Proxy is that it requires all client machines to be Windows 8 Clients. The Kerberos Proxy option makes everything very secure, but also easy to set up without having to redesign your network.
As opposed to most VPN solutions, you do not have to install any software on your client for URA. It's not that such software is not needed... it is, but it comes built-in to the operating system. The magical seamless connection is conjured up by the Windows Firewall. The original purpose of the Windows Firewall is to block malicious traffic, but the Windows Filtering Platform (WFP) also has the ability to create, manage, and establish the virtual network that we need.
The configuration for the firewall is provided to the client using Group Policy, which is the key to the easy manageability of the solution. Instead of providing users with complex instructions on setting up the connection, or spending hours on the phone walking through wizards, the administrator uses the Unified Remote Access console or PowerShell scripts to create the Windows Firewall connection security rules. Then, when the client applies the Group Policy updates, the client computer is automatically configured with these settings.
With almost all other VPN solutions, the user needs to launch the connection to the VPN server, but with URA, this is done automatically, and here's how. The DirectAccess configuration becomes effective depending on whether the machine is inside the corpnet or outside the corpnet. The key pieces of the URA architecture are the name resolution and location awareness that helps the client to decide whether to apply the URA connection or not; that is, when the user turns on his computer, or resumes it from being suspended, the operating system detects whether it is able to establish corporate connectivity. The location detection happens through its ability to connect to a specific server, which we refer to as the Network Location Server (NLS). This server is installed within your internal network as part of the URA setup, and it stands there like a virtual lighthouse. The URA client attempts to make a secure connection to the URL of the NLS server whenever it becomes aware of a new network connection. The URL of the NLS server is defined as part of the URA server setup, and stored as part of the client GPO. This way the client automatically knows which server it has to connect to in order to determine whether the client is on the corporate network or not.
If the client gets an HTTP response code 200, that means the client can resolve the name of the NLS server and make a secure HTTP connection to it. This confirms that the client is physically inside the corporate network, and therefore, there is no need to establish the URA connection. If, however, the NLS does not respond (and we have to make sure the NLS won't respond to clients on the outside... we will talk more about that later), the client deduces that it's outside the corporate network, and the Windows Firewall springs into action, and starts establishing the IPSec tunnel for the connection. This happens almost instantly, and once the tunnel is up, the user's experience is identical to being physically connected to the corporate network. We will talk more about the NLS server configuration in the planning chapter later. The users can access any internal server, using any port and protocol, and even if there's some kind of network interruption, the client will automatically re-establish the tunnel seamlessly as soon as the network is back. All the connection security rules are already configured in the client GPO and when the client GPO applies to the machine there is no further manual configuration needed by anyone. That is why URA clients don't need to have additional software installed or any additional user action.
From an administrator's perspective, the deployment consists of installing a Windows 2012 server and configuring the various settings for the Unified Remote Access role. Once the server is ready, the settings are deployed to clients using Group Policy, so there's little to do. You define to which computers and groups the policy will apply, and once users who have been defined in that scope leave the office and connect to the public Internet, their computers will automatically establish the connection. You also have the option of joining clients to the domain and applying the Unified Remote Access policies to them remotely, so even if your users are spread across the country, you can still provision them to connect easily.