How to Configure Direct Access in Windows Server

In this article, we’ll step by step describe how to deploy the Direct Access (DA) remote connection service on Microsoft Windows Server. Before we get started, let’s take a quick look at what the Direct Access service is. The Direct Access component was first introduced by Microsoft in Windows Server 2008 R2 and was designed to provide transparent access for remote computers to internal company network resources. When connecting through a DA, the user can take full advantage of the enterprise and domain services, and the IT support staff can manage and keep the computers up to date in terms of security. At its core, Direct Access is a lot like a traditional VPN connection to the corporate network. You can also call it “always on VPN”.

Difference Between Direct Access and VPN

Let’s look at the basic difference between Direct Access and VPN:

• In order to establish the Direct Access connection, the user does not need to start the VPN client – the connection is made automatically when there is Internet access.
• To establish a connection between the DA client and the server, you need to open port 443.
• The user’s computer must be in an Active Directory domain.
• The communication channel between the remote PC and the corporate gateway is encrypted with robust algorithms using IPsec.
• It is possible to organize two-factor authentication using a one-time password system.

Difference Between the First Version of Direct Access and Latest

What are the major differences between the new Windows Server versions of Direct Access and the first version on Windows 2008 R2? The main difference is the reduced requirements for the related infrastructure. For example, here are some differences:

• The Direct Access server no longer needs to be an edge server, it can now be behind NAT.
• If you’re using Windows 8 Enterprise and later as the remote client, you don’t need to deploy an internal PKI infrastructure (client authentication will be handled by the Kerberos proxy located on the DA server).
• Having IPv6 on the internal network of the organization is not necessary.
• New Direct Access supports OTP (One Time Password) and NAP (Network Access Protection) without requiring Unified Access Gateway (UAG) deployment.

Direct Access Installation Requirements

Here are infrastructure requirements to deploy Direct Access based on Windows Server:

• Active Directory domain and domain administrator rights.
• A dedicated (recommended) DA server running Windows Server 2012 R2 and later, included in a Windows domain. The server has 2 network cards: one is on the internal corporate network and the other is on the DMZ network.
• Dedicated DMZ subnet.
• The external DNS name or IP address available from the Internet that Direct Access clients will connect to.
• Traffic redirection configuration from TCP port 443 to DA server address.
• Deployed PKI infrastructure for certificate issuance. The certificate authority must publish the Web Server certificate template and allow it to be auto-enrolled (Not needed for Windows 8 and above).
• Clients must run Windows Professional / Enterprise edition.
• AD Group that will consist of computers that are allowed to connect to the network via Direct Access.

Installing Remote Access Server Role

First we need to start the Server Manager console and use the Add Roles and Features wizard to install the Remote Access role.

As part of the Remote Access role, you must install the Direct Access and VPN (RAS) service.

Leave all other settings by default and restart the server after installation.

Configuring the Direct Access Service in Windows Server

Once the Remote Access service has been installed, open the Tools ⇒ Remote Access Management snap-in.

The remote access console will start. Click on DirectAccess and VPN ⇒ Run the Remote Access Setup Wizard. Now we only need to install Deploy DirectAccess only role.

This should open a window in the right half of which you can see the four steps (Step 1 – 4) of the DA service configuration graphically.

Step One: Remote Clients

Let’s say that we’re deploying full DirectAccess for client access and remote management.

Now you need to specify the AD security group that will contain the computer accounts that are allowed to connect to the corporate network via Direct Access (in this example, we will use alwayonvpn group).

Enable DirectAccess for mobile only option – allows you to limit connection via DA only for mobile devices (laptops, tablets). This feature is implemented by polling clients via WMI.

The Force Tunneling option – means that remote clients when accessing any remote resources (including regular websites) always use DA servers (all external client traffic goes through the corporate gateway).

On the next step we need to specify a list of internal network names or URLs from which the client can check (Ping or HTTP request) that he is connected to the corporate network. You can also specify the help desk email address and the name of the DirectAccess connection (so that it will appear on the client’s network connections).

If necessary, you can enable the Allow DirectAccess clients to use local name resolution option, which allows the client to use the company’s internal DNS servers (DNS server addresses can be obtained by DHCP).

Step Two: Remote Access Server

The next step is to configure the Remote Access server. In our example we will have an edge server (firewall) with two network cards, so we need to select – Behind an edge device (with two network adapters), one of which is on the corporate network and the other is connected directly to the Internet or DMZ subnet. You also need to provide the external DNS name or IP address on the Internet (which is where port 443 is pinged to the external interface of the DirectAccess server) that the DA clients should connect to.

Then you must specify which NIC will be considered Internal (LAN) and which External (DMZ).

Now we need to generate a DA server certificate. To do this, create a new mmc snap-in, and add the Certificates console that manages local computer certificates.

In the Certificate Management Console, request a new personal certificate by clicking on Certificates (Local Computer) ⇒ Personal ⇒ Certificates and selecting All Tasks ⇒ Request New Certificate…

Request a certificate through the Active Directory Enrollment Policy. We are interested in a certificate based on the Web Servers template.

In the new certificate request settings on the Subject tab, let’s fill out the fields that identify our company and on the Private Key tab, let’s specify that the certificate private key can be exported (Make private key exportable).

Save the changes and request a new certificate from CA. Request and generate a new certificate.

Return to the DirectAccess server settings window and click the Browse button to select the generated certificate. Specify our certificate.

In the next step of the wizard, we’ll select a method for authenticating Direct Access clients. Specify that authentication with Active Directory credentials (username/password) is used. Select the checkbox of Use computer certificates and Use an intermediate certificate. Click the Browse button to specify the certificate authority that will be responsible for issuing client certificates.

Step Three – Infrastructure Servers

The third stage contains configuration of infrastructure servers. We need to specify the address of the Network Location Server, which is located inside the corporate network. Network Location Server (NLS) – is a server through which the client can determine that it is on the internal network of the organization, i.e. you do not need to use DA to connect. NLS server can be any internal web server (even with a default IIS page), the main requirement is that the NLS server must not be accessible from outside the corporate network.

Now let’s specify a list of DNS servers for name resolution by clients. It is recommended to leave the option Use local name resolution if the name does not exist in DNS or DNS servers are unreachable when the client computer is on a private network (recommended).

Then specify the DNS suffixes of internal domains in order of priority of their use.

Management settings window we will keep default.

Step Four – Application Servers

In this step we will configure application servers. This phase allows you to configure additional authentication and traffic encryption between the back-end application servers and DA clients. In this example we do not need this, so let’s leave the option Do not extend authentication to application servers.

This completes the Remote Access role configuration wizard, so we just need to save the changes.

After you finish, the wizard will create two new group policies – DirectAccess Client Settings and DirectAccess Server Settings that are attached to the root of the domain. You can either leave them as they are, or link them to the desired OU.

Test Direct Access on the Windows Client

To test how Direct Access works from the client side, let’s add a computer with Windows Enterprise OS to our direct access group (alwaysonvpn) and update Group Policy via gpupdate /force on it.

Disconnect the laptop from the corporate network and connect to the Internet via public Wi-Fi. The system automatically connects to the corporate network via DirectAccess. The connection name will be displayed in Network & Internet Settings.

You can verify if there is a DirectAccess established using the PowerShell command:

Get- DAConnectionStatus

If it returns ConnectedRemotely, then the DA is connected to the corporate network