[Tutorial] Configuring Direct Access on Server 2012 R2

This tutorial will cover deployment of Windows Server 2012 R2's latest version of DirectAccess.  While there are multiple ways to configure Direct Access, I tried to pull together what I believe are the best/recommended practices and what I believe would be a common deployment between organizations.  If you have any thoughts/feedback on how to improve this deployment, please leave a comment below.

Before beginning, if you are curious what DirectAccess is, here is a brief overview of what it is and what it will allow us to accomplish.

DirectAccess, also known as Unified Remote Access, is a VPN-like technology that provides intranet connectivity to client computers when they are connected to the Internet. Unlike many traditional VPN connections, which must be initiated and terminated by explicit user action, DirectAccess connections are designed to connect automatically as soon as the computer connects to the Internet. DirectAccess was introduced in Windows Server 2008 R2, providing this service to Windows 7 and Windows 8 "Enterprise" edition clients.
http://en.wikipedia.org/wiki/DirectAccess

Prerequisites

  • Domain Admin rights to complete the tutorial below
  • Windows Server 2012 R2 machine
    • Two network cards - One in your internal network, the other in your DMZ
    • Joined to your domain
    • Latest Windows Updates
      (seriously, apply these, there are updates released specifically for DirectAccess)
  • DMZ
  • PKI Setup (Public Key Infrastructure to issue self-signed certificates)
    • Custom template setup for issuing servers with an intended purpose of Server Authentication
    • Certificate auto-enrollment has been configured
  • Active Directory Security Group designated with Computer Objects allowed to use DirectAccess
  1. Login to your Server 2012 R2 server we will be using for installing the Direct Access
  2. Ensure all windows updates have been applied.
    Latest Windows Updates
  3. Open up Server Manager
    Server 2012 R2 - Server Manager
  4. Select Manage -> Add Roles and Features
    Server 2012 - Manage - Add Roles and Features
  5. Click Next > on the Before you Begin step
    Add Roles and Features Wizard - Before you begin
  6. Ensure Role-based or feature-based installation is checked and click Next >
    Add Roles and Features Wizard - Select installation type
  7. Select Next > on the Select destination server step
    Add Roles and Features Wizard - Select destination server
  8. Check Remote Access and click Next >Add Roles and Features Wizard - Server Roles - Remote Access
  9. Click Next > on the Select Features step
    Add Roles and Features Wizard - Server Roles - Features
  10. Click Next > on the Remote Access step
    Add Roles and Features Wizard - Remote Access
  11. Check DirectAccess and VPN (RAS)
    Add Roles and Features Wizard - Remote Access
  12. Click the Add Features button on the dialog box that prompts
    Add Roles and Features Wizard - Remote Access - Add Features
  13. Check DirectAccess and VPN (RAS) and then click Next >
    Add Roles and Features Wizard - Remote Access - Select role services
  14. Click Next > on the Web Server Role (IIS) page
    Add Roles and Features Wizard - Web Server Roll IIS
  15. Click Next > on the Role Services page
    Add Roles and Features Wizard - Web Server Roll IIS - Roll Services
  16. Check the Restart the destination server automatically if required checkbox and click Yes on the dialog box.
    Add Roles and Features Wizard - Confirm installation selections
    Add Roles and Features Wizard - Restart is required dialog
  17. Click Install
    Add Roles and Features Wizard - Confirm installation selections - Restart the destination server automatically if required
  18. Click Close when the install has completed
    Add Roles and Features Wizard - Results
  19. Back in Server Manager, click on Tools -> Remote Access Management (You can ignore the warning icon, the Open the Getting Started Wizard will only do a quick setup of DirectAccess.  We want to do a full deployment).
    Server Manager - Tools - Remote Access Management
    Here is what the quick deployment looks like.  Don't click on this. Server Manager - Post-Deployment Configuration - DirectAccess
  20. On the Remote Access Management Console, click on DirectAccess and VPN on the top left and then click on the Run the Remote Access Setup Wizard.
    Remote Access Management Console - DirectAccess and VPN
  21. On the Configure Remote Access window, select Deploy DirectAccess only
    Configure Remote Access - Deploy DirectAccess Only
  22. Click on the Configure... button for Step 1: Remote Clients
    Remote Access Management Console - DirectAccess and VPN - Step 1 Remote Clients
  23. Select Deploy full DirectAccess for client access and remote management and click Next >
  24. Remote Access Setup - Deploy full DirectAccess for client access and remote managment
  25. Click on the Add... button
  26. Remote Access Setup - Select one or more security grups containing client computers that will be enabled for DirectAccess
  27. Select the security group inside of Active Directory that will contain computer objects allowed to use DirectAccess and click OK
    Remote-Access-Setup-Select-Groups
  28. Optionally, uncheck or check Enable DirectAccess for mobile computers only as well as Use force tunneling and click Next >
    1. If Enable DirectAccess for mobile computers is checked, WMI will query the machine to determine if it is a laptop/tablet.  If WMI determines the machine is not a "mobile device", the group policy object will not be applied to those machines in the security group.  In short, if checked, DirectAccess will not be applied to computers that are desktops or VMs placed inside the security group.
    2. If Use force tunneling is checked, computers will always use the direct access server when remote.  For example, if the user surfs the web to a public website like jackstromberg.com, the traffic will go through the DirectAccess tunnel and back to the machine, rather than directly to the ISP.  Generally, this is used for strict compliance environments that want all network traffic to flow through a central gateway.
    3. Remote Access Setup - Select Groups - Next
  29. Double click on the Resource | Type row
    1. What this step is trying to do is find a resource on the internal network that the client can "ping" to ensure the DirectAccess client has successfully connected to the internal network.
      Remote Access Setup - Network Connectivity Assistant - Resource Type
  30. Select whether you want the client to verify it has connected to the internal network via a HTTP response or network ping, optionally click the validate button to test the connection, and then click Add
    1. You may want to add a couple resources for failover testing purposes, however it isn't recommended to list every resource on your internal network.
      Remote Access Setup - Network Connectivity Assistant - Configure Corporate Resources for NCA
  31. Enter in your Helpdesk email address and DirectAccess connection name (this name will show up as the name of the connection a user would use), and check Allow DirectAccess clients to use local name resolution and click Finish.
    1. Based on what I could find, checking Allow DirectAccess clients to use local name resolution will allow the DirectAccess client to use the DNS server published by DHCP on the physical network they are connected to.  In the event the Network Location server is unavailable, the client would then use the local DNS server for name resolution; allowing the client to at least access some things via DNS.
      Remote Access Setup - Network Connectivity Assistant - Helpdesk email address - DirectAccess connection name
  32. Click on Configure... next to Step 2: Remote Access Server
    Remote Access Management Console - DirectAccess and VPN - Step 2 Remote Access Server
  33. On the Remote Access Server Setup page, select Behind an edge device (with two network adapters) and ensure you specify a public facing DNS record that DirectAccess will use to connect back to your environment, and then click Next >
    1. NOTE: By default, your domain's FQDN will be used, so if you have a .local domain, you will want to switch this to your actual .com, .net, .org, .whatever.
    2. As an additional side note, hereis some information from the following KB article on what the differences are between each of the topologies.  From what I gather, using the dual NIC configuration is Microsoft's best practice from a security standpoint.
      • Two adapters—With two network adapters, Remote Access can be configured with one network adapter connected directly to the Internet, and the other is connected to the internal network. Or alternatively the server is installed behind an edge device such as a firewall or a router. In this configuration one network adapter is connected to the perimeter network, the other is connected to the internal network.
      • Single network adapter—In this configuration the Remote Access server is installed behind an edge device such as a firewall or a router. The network adapter is connected to the internal network.

    Remote Access Server Setup - Network Topology

  34. On the Network Adapters step, select your External (DMZ) and Internal (LAN) adapters.Remote Access Server Setup - Network Adapters - External Internal
  35. Leave the Remote Access Setup screen open and right click on Start button and select Run
    Server 2012 - Run
  36.  Type mmc and select OK
    Server 2012 - Run - mmc
  37. Click File -> Add/Remove Snap-in...
    mmc - File - Add-Remove Snap-in
  38. Select Certificates and click Add >
    Add or Remote Snap-ins - Certificates
  39. Select Computer account and click Next >
    Certificates snap-in - Computer Account
  40. Ensure Local Computer is selected and click Finish
    Certificates snap-in - Select Computer
  41. Click OK on the Add or Remove Snap-ins machine
    Add or Remove Snap-ins - Certificates - Local Computer
  42. Expand Certificates (Local Computer) -> Personal -> Certificates, right click on Certificates and select Request New Certificate...
    Certificates - All Tasks - Request new certificate
  43. Click Next on the Before You Begin screen
    Certificate Enrollment - Before You Begin
  44. Click Next on the Select Certificate Enrollment Policy
    Certificate Enrollment - Select Certificate Enrollment Policy
  45. Select your template that will support server authentication and click More information is required to enroll for this certificate.  Click here to configure settings.
    Certificate Enrollment - Request Certificates

    1. Note: The WebServers enrollment policy is not something out of the box configured by Microsoft.  You will need to manually login to your certificate authority, duplicate the Web Servers template with the settings you wish, ensure your usergroup can Enroll for a certificate, and then publish it to AD.
  46. On the Subject tab, enter the following values (substituting in your company's information):
    Common name: da.mydomain.com
    Country: US
    Locality: Honolulu
    Organization: My Company
    Organization Unit: Information Technology
    State: Hawaii
    Certificate Enrollment - Certificate Properties - Subject Tab
  47. On the Private Key tab, expand Key options and check Make private key exportable.  Click Apply when done.
    Certificate Enrollment - Certificate Properties - Private Key Tab
  48. Click Enroll.
    Certificate Enrollment - Request Certificates - Enroll
  49. Click Finish.
    Certificate Enrollment - Certificate Installation Results
  50. Go back to the Remote Access Setup screen and click Browse...
    Remote Access Server Setup - Network Adapters - External Internal
  51. Select your da.mydomain.com certificate we just created and click OK.
    Remote Access Setup - Select a certificate
  52. Click Next >
    Remote Access Setup - Network Adapters - External Internal Certificate
  53. Check Use computer certificates and check Use an intermediate certificate and then click Browse...
    Remote Access Setup - Authentication - Active Directory Credentials
  54. Select the certificate authority that will be issuing the client certificates and click click OK
    Remote Access Setup - Authentication - Select a certificate
  55. Optionally, you may enable Enable Windows 7 client computers to connect via DirectAccess as well as Enforce corporate compliance for DirectAccess clients with NAP.  Note: Configuring these two options are not covered in the scope of this tutorial.  Click Finish when done.
    Remote Access Setup - Authentication - Finish
  56. Click on Configure... next to Step 3: Infrastructure Servers
    Remote Access Management Console - DirectAccess and VPN - Step 3 Infrastructure Servers
  57. On the Remote Access Setup screen, check The network location server is deployed on a remote web server (recommended), type in the website address to the Network Location Server, and click Next >
    1. So for whatever reason, there aren't many articles explaining what exactly the network location server is and how to set it up.  From what I gather, the Network Location Server is merely a server with a website running on it that the client can contact to ensure it has reached the internal network.  The webpage can be the default IIS webpage; just ensure the website is NOT accessible externally.
      Remote Access Setup - Network Location Server
  58. Specify any additional DNS servers you wish to use for name resolution, ensure 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) is checked and click Next >
    Remote Access Setup - Infrastructure Server Setup - DNS
  59. Check Configure DirectAccess clients with DNS client suffix search list, ensure your local domain's suffix has been added, and click Next >
    Remote Access Setup - DNS Suffix Search List
  60. Click Finish on the Management page.
    Remote Access Setup - Management
  61. Click the Configure.... button on Step 4: Application Servers
    Remote Access Management Console - Step 4 Application Servers
  62. Check Do not extend authentication to application servers and click Finish
    Remote Access Setup - Do not extend authentication to application servers
  63. Click Finish... on the Remote Access Management Console page
    Remote Access Management Console - Finish
  64. Click Apply on the Remote Access Review page
    Remote Access Review - Summary of Remote Access configuration settings
  65. Click Close once direct access has successfully finished deploying
    Apply Remote Access Setup Wizard Settings - The configuration was applied successfully
  66. Login to one of your Windows 8.X Enterprise machines that is inside of your DirectAccess Compuers security group and run a gpupdate from command line to pull down the latest group policy.
  67. At this point, you should now be able to login to your network via DirectAccess!

NOTES:

Here is a pretty good resource from Microsoft on helping plan your DirectAccess deployment.  Once you click on the link, in the bottom left corner, you will find two steps to some good KB articles: http://technet.microsoft.com/en-us/library/jj134262.aspx

Here is another article from Microsoft with a more indepth explanation about where to place the Network Location Server: http://technet.microsoft.com/en-us/library/ee382275(v=ws.10).aspx

17 thoughts on “[Tutorial] Configuring Direct Access on Server 2012 R2

  1. Rene Wieldraaijer

    Nice tutorial. One comment on point 28. You write "If Use force tunneling is enabled, mobile computers will always connect to the DirectAccess server regardless if the client is directly attached to local network or is remote.".

    It should be. "When force tunneling is enabled mobile computers will always use the direct access server when remote. So they will not use local breakout for Web surfing and stuff like that. Some say that this improves security because the client cannot be used as a 'remote bridge' between the Internet and the corporate network. Anyway. When force tunneling is enabled computers will still not use the DA server when on the local network.

    Reply
  2. Mahmoud

    Thanks Jack,

    I am on a task of setting up Direct Access on 2012 R2 but with OTP (One Time Password), I am going through this guide and hopefully OTP will work fine 🙂

    Reply
  3. Markus Kugler

    Thanks, nice article.
    I'm playing around in my lab environment and I'm running into a annoying wizard issue. The wizard tells me that the active directory security group cannot be found althou it exists. Found one guy having this issue solved with solving a frs-error, but everything looks great here.
    I tried the one-nic and the two-nic scenario behind a edge device.
    can anybody give me a hint?
    Thanks, Markus

    Reply
    1. Jack Post author

      Hi Markus,

      The only thing that I can think of that would cause this is if you were running the installer as a local user account on the machine rather than domain admin, your active directory account you are running does not have access to browse the security group, or the security group is in a different domain/child domain and you have not browsed to it properly.

      Hope this helps!
      Jack

      Reply
  4. Katherine Moss

    Thanks for that! Very helpful; I've not tried it yet, though I plan to shortly. My question is, why uncheck the "extend authentication to application servers" checkbox? Because wouldn't that imply that you would need a standard VPN in order to authenticate because DA isn't being extended to applications?

    Reply
    1. Jack Post author

      Hi Katherine,

      This option isn't really extending access to an application, but providing the authentication process directly with the requested server, rather than the DA server. In the case where you have a highly locked down environment, I would recommend you check the extend authentication to application servers checkbox and then specify the security groups containing the specific servers that users can access over the DirectAccess connection.

      Hope this helps,
      Jack

      Reply
  5. Patrick van Kampen

    This article gives some great must knows before you start implementing direct access: http://www.ironnetworks.com/blog/common-directaccess-implementation-mistakes#.Vfml3Tl1HqA

    Reading that article it says a internal PKI infra is only needed if you want to connect w7 ent/ult machines.. So as of my understanding public ssls should be enough when implementing DA for w8 and up.

    I will start testing DA soon on a 1 NIC setup using only W8 and without PKI.

    Thanks for thuis great article its verry usefull!!

    Reply
    1. Jason Nelson

      There is one caveat to your statement: when you require the 'force tunnel' option, it only works with pki.

      Reply
  6. George

    Hi all.

    I want to share something I encountered while following this great tutorial, whichcan be of help to someone.

    I had a problem at step 57. The wizard does not accept my setting https://nls.xxx.local. The error was "name cannot be resolved to valid IP address". However I was able to ping nls.xxx.local normally. It turned out that the wizard does not like that nls.xxx.local was a CNAME record pointing to the actual fqdn of the server. When I changed it to be an "A" record, the wizard accepted it and finished successfully.

    regards
    George

    Reply
  7. Pingback: Direct Access / VPN Server Topology

Leave a Reply

Your email address will not be published. Required fields are marked *