11th August 2014

IMPLEMENT DIRECT

ACCESS WITH WINDOWS

SERVER 2012 IN FIVE

EASY STEPS

Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | Twitter: @gerryhampson

Introduction

Direct Access is a marvellous technology provided by Microsoft. It allows domain-joined devices to

access corporate resources seamlessly over the Internet. When an Internet connection is detected

Windows automatically connects to the Corporate Workplace without any intervention (like a hands

free VPN if you like). Direct Access provided by Windows Server 2012 is really easy to configure (5

easy steps). It has progressed a lot since the days of Windows Server 2008R2 when this was quite a

difficult configuration in conjunction with UAG.

Direct Access is an excellent alternative to traditional VPN technologies.

In Enterprise Client Management, a high percentage of helpdesk calls are logged regarding

issues with VPN clients. I have seen evidence of a reduction in helpdesk calls after the

deployment of Direct Access.

The performance overhead of the VPN client is eliminated.

Costs can be reduced with the reduction in VPN client licensing.

Note that Direct Access is a supplement to traditional VPNs rather than a replacement. Devices have

to be domain-joined to be able to use the feature. This is normally not permitted in the case of 3rd

party support companies or partners. They will continue to use traditional VPNs to connect to your

corporate resources.

This guide will demonstrate how to deliver Direct Access in 5 Easy Steps using Windows Server

2012. We will concentrate only on Windows 8 clients which pretty much can connect "out-of-the-box".

Windows 7 clients require a little more work and certificate configuration.

Step 1: Networking & Active Directory

Step 2: Certificates

Step 3: Add Remote Access Role

Step 4: Configure Remote Access Role

Step 5: Windows 8 client and troubleshooting

Note that there a few ways to deploy the solution - you have some choices along the way. We will

deploy a single server solution (with single NIC) incorporating a 3rd Party SSL Certificate.

Other options include:

deploying several servers for redundancy and load balancing

separate server for Network Location Server (NLS) - recommended

Network (NLB) or hardware (HLB) load balancing

Two-NIC implementation for deployment in DMZ

Certificates: Self-signed, CA, 3rd Party SSL

Advanced

Move NLB to remote web server

High Availability

Start by creating a Windows 2012 server, fully patched, and join to your domain. This will be our

Direct Access server (and our NLS in this case).

What is the Network Location Server (NLS)?

The NLS is a critical part of a Direct Access deployment. It is deployed as a means of verifying that

Direct Access clients can, in fact, access corporate resources - the Direct Access clients locate and

access a secure web page (or can be configured to locate by pinging). It is also used to detect

whether Direct Access clients are on the Internet or Intranet.

Step1 Networking & Active Directory

There are a number of Networking and Active Directory tasks to be carried out before we start the

installation and configuration of the Remote Access role.

1. External DNS A record

Use a Public IP address that you own that is currently not configured on your external firewall to use

port 443 (eg 82.72.142.22. I've made this up - my apologies if you own it).

Contact your domain hosting company (or log on to your domain portal if you have one) to create a

new DNS A record for your domain (eg da.contoso.com). Configure this record to use the

above Public IP address.

Verify that the record has been created by pinging it. It doesn't matter if the ping does not get a reply

(perhaps your firewall doesn't allow it). What matters is that the FQDN resolves to the IP address.

2. Firewall Rules

Create a rule that allows inbound traffic to 82.72.142.22 Port 443.

Create a NAT rule that directs this traffic to the IP address of your Direct Access server.

3. ISATP status

Check that ISATAP protocol is allowed in your Active Directory network (by default, it is not).

Execute this command on a DNS server (Windows 2008 upwards).

dnscmd /info /globalqueryblocklist

See that wpad and isatap protocols are currently "blocked".

Remove ISATAP from the Global Query Block List by executing the following command. This

configures the list to include wpad only.

dnscmd /config /globalqueryblocklist wpad

Query the list again to verify

dnscmd /info /globalqueryblocklist

Restart DNS

Verify the Global Query Block List in the registry (see the path below)

4. Verify that the Direct Access server has been configured to use IPv6 (it is by default).

5. Create an Active Directory Security Group.

You will enable domain devices for Direct Access by adding their computer accounts to this group.

Step2 Certificates

This section describes the certificates required for the process and their configuration.

IPHTTPS

IPHTTPS simply means IP over HTTPS. This protocol allows for an IP tunnel to be created through a

secure HTTPS connection. Direct Access uses IPHTTPS listeners which are available to respond to

client requests.

You have several options when choosing a certificate for the IPHTTPS listener

Self-signed certificate (I am not a fan of using external facing self-signed certificates)

PKI (you can use your own Certificate Authority to generate the required certificate)

3rd Party SSL (this is my preferred method - in this guide I will be using a Comodo SSL

Certificate)

When you use a 3rd Party certificate it must be configured to use the external FQDN that we

previously used for the external DNS record (eg da.contoso.com).

NLS

The NLS certificate should be configured to use the internal FQDN of the NLS server. It is quite

acceptable to use the self-signed certificate in this case.

Request Certificate

Open Internet Services Manager on your Direct Access Server.

Select the server name on the left pane and double-click the "Server Certificates" button in the

Security Section.

In the "Actions" menu on the right, click on "Create Certificate Request".

This will open the "Request Certificate Wizard"

Enter your details. Remember the Common Name should be the FQDN that we used for our DNS

record earlier (eg da.contoso.com).

Enter the required details in Cryptographic Service Provider Properties (Comodo recommend Bit

Length of 2048).

Save the Certificate Request.

Open the saved file.

When you make your online application, make sure you copy the CSR in its entirety into the

appropriate section of the enrolment form

----BEGIN CERTIFICATE REQUEST-----

to

-----END CERTIFICATE REQUEST-----

Install Certificate

Within a few hours the certificate will be available for download from the Comodo website.

Open Internet Services Manager.

Select the server name on the left pane and double-click the "Server Certificates" button in the

Security Section.

This time choose to "Complete the Certificate Request".

The SSL certificate will now be available when we are configuring the IPHTTPS listener.

Step3 Add Remote Access Role

Now that we have completed the pre-requisites we can get to work on the Direct Access server. We

now add the Remote Access Role. Note you must use a Domain Administrator account to configure

Remote Access. The process will makes some changes to Active Directory and Group Policy.

Click Manage in Server Manager and select "Add Roles and Features".

The "Add Roles and Features Wizard" is launched.

Click Next to continue.

Choose your server and click Next

Choose the "Remote Access" role and select "Add Features" to add the additional features required

by Remote Access.

Open "Role Administration Tools" and select “Remote Access Management Tools".

Click Next.

Select "DirectAccess and VPN".

Click to Install.

Installation has succeeded.

Open the new Remote Access Management console.

Run the Getting Started Wizard.

You can choose to "Deploy DirectAccess only". I chose to "Deploy both DirectAccess and VPN" for

this series.

Choose "Behind an edge device (with a single NIC)".

Enter your external FQDN. This is the name we previously configured in our DNS A record and SSL

certificate.

Click Finish to apply our initial configuration.

Certificates and Group Policy Objects have been created and the configurations have been applied.

The Remote Access Management Console is now available for further configuration. We will do this in

the next section.

Step4 Configure Remote Access

We have added the Remote Access Role and now we must carry out the final configuration.

Open the Remote Access Management Console.

Note that the Microsoft have simplified the configuration by grouping the tasks into steps. We will

configure each in turn.

1. Click Edit under Step 1 - Remote Clients

Choose to "Deploy Full Direct Access for client access and remote management".

The wizard has been pre-populated with Domain Computers. Remove this and add the Active

Directory Security Group you created earlier.

Uncheck the box "Enable Direct Access for mobile computers only".

2. Click Edit under Step 2 - Remote Access Server

Verify the details

Choose the SSL certificate that you configured earlier.

We are using Active Directory credentials.

Also, see the check box to enable Direct Access support for Windows 7 clients. We will not be

enabling this for now.

We will not configure any VPN settings at the moment.

3. Click Edit under Step 3 - Infrastructure Servers

Use a self-signed certificate for the NLS server.

Verify DNS server.

Verify DNS suffixes.

Verify management server.

4. Click Edit under Step 4 - Application Servers

We have nothing to configure here for now.

We are now presented with a Remote Access review. Review all settings before clicking Apply.

Click Apply to finalise your Remote Access configuration.

Remote Access status now looks good.

See the GPOs automatically created for Remote Access. Both policies are applied to the domain.

However the Direct Access server only has the permissions to apply the DirectAccess Server Settings

and your AD security group only has the permissions to apply the DirectAccess Client Settings.

Step5 Win8 client & troubleshooting

That's it. We have finished the configuration. Now we will verify the Direct Access connectivity using a

Windows 8 client.

We enable Direct Access for a client device by adding the computer account to the Active Directory

Security Group we previously created.

While connected to the Corporate LAN

Restart the test computer so that the computer account permissions can be updated and run

gpupdate/force to update Group Policy.

No further configuration is necessary. The rest of our work is verification and troubleshooting.

Verify Group Policy on the test computer. Open the Registry > HKEY_LOCAL_MACHINE

See the Network Connectivity Assistant Registry keys.

Disconnect from the Corporate LAN

At this point you will see the new Workplace Connectivity icon (click on the network icon in the system

tray).

The status of the Workplace Connection should say "Connected" (if you have an Internet connection).

If it is you can now browse corporate resources.

Type ipconfig/all in a command prompt. See that the iphttpsinterface is active.

Ping a resource using NetBIOS name only.

Troubleshooting

If the Workplace connection is not available but Group Policy has been updated.

Verify that the Network Connectivity Assistant Service is started

If you cannot start this service look in the Event log for errors. You may see an error that "This request

is not supported".

In that case run msinfo32 command to look at the computer properties. Verify that the OS version is

indeed Windows 8 Enterprise (not Windows 8 Pro).

If the Workplace connection is available but not connected (status Connecting) there are a couple

of troubleshooting steps to take.

1. DirectAccess log file

Right click the Workplace Connection and click "View Connection Properties".

See the DirectAccess Properties.

Click "Collect Logs" for advanced troubleshooting.

You can now "View logs" to open the file location (or email logs to a System Admin for assistance).

We configured this email address in Step 4.

Open the Log file.

The log file contains extensive configuration information.

2. DNS

Verify that the following A records have successfully been created in DNS

Remote Access creates a default web probe that is used by DirectAccess client computers to verify

connectivity to the internal network. During configuration of the single server the following names

should have been registered in DNS:

directaccess-WebProbeHost—should resolve to the internal IPv4 address of the Remote Access

server, or to the IPv6 address in an IPv6-only environment.

directaccess-CorpConnectivityHost—should resolve to a localhost (loopback) address (either ::1 or

127.0.0.1, depending on whether IPv6 is deployed in the corporate network).

3. Windows Firewall.

When a Windows 8 device cannot connect to Corporate Resources via Direct Access this is normally

the culprit.

The Windows Firewall MUST be enabled and it is configured by Group Policy to allow the

connections.

Windows Firewall MUST be enabled.

Verify the Connection Security rules. Note the DirectAccess Policy - ClientToCorp.

Open the policy and view the Authentication tab. Note that first authentication is computer certificate

and the second authentication is the user account (both Kerberos).

See the Main mode

and Quick Mode details of a successful Direct Access connection.

4. External Firewall.

In Step 1 we created a DNS record (eg da.contoso.com) and this was configured to direct https traffic

(port 443) to one of our Public IP addresses. Our firewall was configured to allow this traffic and a

NAT rule was configured to divert this traffic to the Direct Access sever.

Test this configuration by using telnet at a command prompt.

telnet da.contoso.com 443

If the firewall has been configured correctly a connection will be made (you will be presented with

a blinking cursor but a connection has been made). If you cannot make a connection then the firewall

is not configured correctly.

Move NLB to remote web server

Previously we implemented Direct Access in five easy steps using a single server. In production

additional configuration is required to implement a best practice solution.

The Network Location Server is a key component of DirectAccess. Its purpose is to detect whether

computers configured as DirectAccess clients are located in the corporate network. When clients are

in the corporate network, DirectAccess is not used to reach internal resources. Instead, clients

connect to internal resources directly.

The network location server is simply a Web site with an HTTPS server certificate. It should be

located on a remote web server (not the DirectAccess server - which has the Remote Access role). It

is also good practice to have multiple NLS servers in a Highly Available configuration.

This section demonstrates how to move the NLS configuration to a remote web server.

First you need a web server. Install IIS as normal.

Next you will need an SSL certificate. Note that you can use a self-signed certificate when the NLS is

co-located with the DirectAccess server. However you can't on a remote web server.

In my example I used my Internal CA and requested a certificate using the Web Server template

(using the Certificates Snap-In).

See that further information is required.

The Common Name is the FQDN of the web server (eg nlsweb.contoso.local).

Web Server certificate has been installed.

Add https to site binding and configure to use the new certificate.

Now, back at the DirectAccess server, open the Remote Access Management console.

Edit the Infrastructure Servers section (Step 3).

Enter the URL of the remote server (in the format https://nlsweb.contoso.local) and click to Validate.

You will not be able to continue if the URL is incorrect and you cannot validate.

Apply the new settings.

Close the wizard.

Now test your configuration. DirectAccess clients should still be able to connect as normal.

High Availability

DirectAccess has become a vital resource in many enterprise environments. We implement High

Availability for technologies like SQL and Exchange so why should DirectAccess be any different?

The good news is that it's easy to do so.

We've previously deployed a single server DirectAccess solution (let’s call this server RAS1). Then

we moved the NLS to a remote web server. Now we will implement HA for the solution. The following

are the basic steps.

Add NLB feature to RAS1

Build new Windows 2012R2 Server RAS2

Add Remote Access role and NLB feature to RAS2

Export IPHTTPS listener certificate from RAS1 and import to RAS2

Enable MAC spoofing on virtual NICs

Enable Load Balancing

Add second server to Load Balanced cluster

Add NLB feature to RAS1

Add Remote Access role and NLB feature to RAS2

Export IPHTTPS listener certificate from RAS1 and import to RAS2

Export certificate from RAS1

Import to RAS2

Virtual NICs

Enable MAC spoofing

Enable MAC spoofing on the virtual NICs of RAS1 and RAS2

Second NIC

You can implement this solution with a single NIC per server. However it is better practice to use two

NICs. The second NIC, for NLB communication, should be configured in a separate subnet with no

default gateway.

6. Enable Load Balancing

Launch the Remote Access Management console on RAS1. Open the configuration.

On the bottom right of the window select "Enable Load Balancing".

The "Enable Load Balancing" wizard is launched. Click Next.

Choose NLB as the cluster method (note that you can configure the solution to use an external load

balancer).

Enter an available IP address. The wizard is quite smart here. It knows that DirectAccess is already

working with a single server solution (RAS1). DNS records and firewall rules have been created and

we don't want to have to amend these. Therefore the wizard swaps the IP addresses.

The working dedicated IP address of RAS1 (DIP) becomes the Virtual IP address of the NLB cluster

(VIP). The new available IP address becomes the IP address of RAS1. Pretty clever.....

Verify the settings and "Commit".

Review progress.

Click Close to return to the wizard.

Verify success and close the wizard.

See what has happened. A load balanced cluster has been created with a single node (RAS1).

Note that the IP address of RAS1 has changed.

Add second server to cluster

Now, on the bottom right of the Remote Access Management configuration window, choose "Add or

Remove Servers".

Select "Add Server".

Browse to choose RAS2.

Ensure that the correct NIC is selected.

Verify the settings and click Add.

Close the wizard.

"Commit" the changes.

Verify progress.

Close the "Adding or Removing Servers" wizard.

See that the second node has been added to the load balanced cluster.

Verify that the nodes are operating correctly.

Issues Encountered

I encountered a couple of issues during this configuration.

Firstly the wizard did not seem to add both nodes to the NLB cluster. When I opened the Network

Load BaIancing Manager I noticed that only one node was present. I had to add the second node

manually.

Also, my DirectAccess solution failed after I introduced NLB. I found that this was due to the fact that

my customer had a series of firewalls with some kind of one-to-one NATing throughout. This played

havoc with the NLB traffic. This was solved by introducing Dynamic NAT rules.