Mobility is no longer a challenge to traditional IT environments, it’s the standard.  Users work from home to save office space, need to be connected during sales trips and are consistently not in the corporate office connected to the local area network (LAN).  Combine this demand for a mobile workforce with the ever increasing security requirements put forth such as HIPPA and PCI-DSS etc make this a significant hurdle for IT departments.  Microsoft Direct Access may be a solution that eases this hardship.

In the past, if you wanted to work remotely a Virtual Private Network (VPN) was probably used to connect to the office.  The VPN would create an encrypted tunnel to secure and allow access to machines outside the network.  This worked well but required the software to be installed, and the user needed to initiate a connection.  Microsoft Direct Access allows users to access a corporate network through an encrypted connection and it’s always on!

Direct Access Requirements

DIrect Access was released with Server 2008 R2 so you’ll need a server running this OS version or later.  My examples below run Server 2012.

You’ll also need to be running one of the following flavors of Windows 7 or later:

• Windows 7 Enterprise
• Windows 7 Ultimate
• Windows 8 Enterprise

All Clients MUST be members of the domain that they are connecting to in order to work successfully.  This can be a pain for administrators who may be setting up remote access for a user that will never come into the office, but it is possible to use the Offline Domain Join along with Direct Access.  THIS IS AWESOME!

Additional Remote Access Requirements are listed on Technet.

Installing Microsoft Direct Access

The install of Direct Access was surprisingly simple.  

• Install the Remote Access Module from Server Manager
• Configure and deploy the Client and Server Group Policies from a wizard
• Allow port 443 to your Direct Access Server

Install and Configure Walkthrough

Open the Add Roles and Features through Server Manager.  Choose the Remote Access Role and accept the additional features that will be installed.

This can also be done via an elevated powershell command:

Install-WindowsFeatures RemoteAccess -IncludeManagementTools

When the installer is finished, Server Manager will notify you that additional Post-deployment configurations are available.  This configuration wizard can be started right from Server manager, or you could open the Remote Access Utility which will be installed on the server.

Choose your deployment option.  Note that the VPN is available so that older clients can still connect to the network.  For instance if you have Windows XP machines that need remote access this same server can be utilized for both purposes.  In my case I’ve only chosen to configure the second option “Deploy DirectAccess only.”

The best part about this for me is that you can install with a single network adapter behind a Network Address Translation (NAT).  In the past you might have needed to have two network adapters (outside and inside) to turn the server into a router.  In my lab I used a single adapter behind my firewall.  Be sure that your routerfirewall is also allowing port 443 (HTTPS) traffic as well.  This is the only required port that needs to be open on the incoming direction.

One important configuration option is to enter the public DNS name of the Direct Access server.  This DNS entry needs to be available on the Internet so be sure to add your ‘A records’ to the publicly accessible DNS Server.  The setup wizard will also create a self-signed certificate used to encrypt the connections.  This can be modified to use a public certificate if you wish.  I recommend this if using for anything other than a lab.

You are then given the option to modify the settings before they are applied.  For this example, click finish.

You’ll notice some settings being configured and many of these will be configured as Group Policy Objects in Active Directory.

When the configuration is finished, you can view the settings from the GPO Management tool in Active Directory.  Two GPOs will be created “DirectAccess Client Settings” and DirectAccess Server Settings”.

NOTE:  During the configuration only mobile computers will be enabled.  You can change this setting in Remote Access or modify the WMI Filter on the GPO itself.

Open the Remote Access Management Utility and the operational status should look like the one below.  If it doesn’t, don’t panic.  Remember that these settings were applied via Group Policy which may take up to 15 minutes in some cases.  You can speed this up by running GPupdate /force from a command line on the server and refreshing this page.

Below is an example of the gpupate /force command.  This might also be useful on the clients that you’re testing with.  They will also be configured via Group Policy.

 Verify Functionality

Once the GPOs have been successfully deployed, the next step is to verify that the machines can use Direct Access correctly.  There are two parts to the connectivity that should be checked.  The first is what happens when the client is connected to the local LAN and the other is when the client is outside the network.

Running the powershell command:

get-daconnectionstatus

should show either “ConnectedLocally” or “ConnectedRemotely” depending on the location of the client.

You will also be able to see the Direct Access Connection in your network Connections (seen below).

When clients are connected remotely, you can via them from the Direct Access Server as well.

Troubleshooting

If you are looking for some troubleshooting information, a great command to run on clients is the

netsh interface httpstunnel show interface

This will give additional information on any errors that might be encountered when connecting to the Direct Access Server.

An additional Thank you to Richard Hicks for some very useful assistance in writing this post.  He has some great information on Direct Access on his website that is worth taking a look at.