‘Real World’ Direct Access installation using Windows Server 2012

I've got three weeks of helping customers set up and administer Direct Access 2012 coming up so I wanted to make sure I was ready to handle a setup in a 'real world' type scenario. Although we had a massive readiness season for "Windows 2012 Networking" in Charlotte earlier this month I find that sometimes 'lab' environments are a little 'perfect'. For me, the problem with building DA in a lab scenario is there is no 'real' internet to deal with - no modems, on-ramps, intrusion detection, firewall, massive latency, change control -> none of the things that always complicate a 'real world' installation. Also, the labs I worked with didn't light up any non-Microsoft resources to DA clients, I would like to test this out as well.

(Before I go on, I should point out there is a good write up on configuring a test lab without the real connection to the internet here: http://blogs.technet.com/b/meamcs/archive/2012/05/14/windows-server-2012-direct-access-part-2-how-to-build-a-test-lab.aspx - this is definitely the best way to start to get comfortable with DA before you worry about the real world quirks that I was hoping to discover in this lab).

Lab Setup

The lab I've come up with is shown here. Limited budget, limited time and limited imagination is still keeping it simple but it should serve the purpose I am after.

The diagram above is the nice high level logical view, let me level with you and show you the Physical view of this setup...

Its not pretty, but it can get the job done. (I think).

The DA clients will start life connected to the physical network (hence the cables hanging out of them). Once they get their group policy and a few settings are tested I will move them to the internet using my phone as a 3G wireless access point.

The other thing I would like to do in this lab, is simulate a 'real world' scenario by setting up the Intranet servers with no 'managed' IPv6 stack and no native IPv6 routing infrastructure configured. That is, the internal servers that I want my Direct Access clients to connect to will only have IPv4 addresses that have been configured by an administrator. The IPv6 settings will come from NAT64/DNS64 running on the Direct Access server. I also want to avoid implementing ISATAP in the customer environment. (ISATAP has it's place for sure, but as a general rule it shouldn't be blanket 'enabled' by unblocking it on your DNS servers and adding a host record. If it is necessary, ISATAP should be a careful planned implementation and is probably a big enough topic to cover in a separate blog post.).

High Level Steps

I white-boarded the following list of high level steps required for this to work:

1. Build Machines: 2 physical laptops (1 x Windows 8, 1 x Windows 7), 1 x Physical Hyper-V Host (Windows Server 2012), 4 x Hyper-V Guests (DC1, DA1, APP1, CA1 - all Windows Server 2012)
2. Configure Non-DA related Infrastructure (in a very vanilla fashion) - Domain Controller including DNS, DHCP Server, Basic IIS role install on APP1, Basic Certificate Services role install on CA1.
3. Configure Dynamic DNS on DA1. Because I don't have a fixed IP address with the ISP I need a dynamic DNS client. I used www.dyn.com and paid $20 for 12 months.
4. Configure SMOOTHWALL firewall to forward port 443 to the Direct Access Server.
5. Configure Workstation Certificates for Authentication.
6. Run through the DA installation Wizard
7. Ensure Group Policy has been applied to workstations. (There is a cool new feature where all of this can be sent out as a djoin blob, but for now i'm assuming the client devices start life on the corporate network).  
8. Connect the remote clients to the 3G Network, outside of this lab.


For this details part I'm going to follow the path I used. I had the following concept in mind -> "getting it to work on Windows 2012 and Windows 8 is easy, start there". I figured, if I could get it to work the easy way in the slightly more complex lab environment, then I could introduce Windows 7 clients later and patch in the extra bits and pieces to make it work. (It wasn't a bad approach, the Windows 8 part didn't take more than an afternoon, the Windows 7 part took me a while longer but in hindsight should have been more obvious.)

To get the Windows 8 clients to work:

Create a group for Remote Access enabled Laptops:
1. On DC1, from the Start screen, click Active Directory Administrative Center or AD Users and Computers.  
2. In the console tree, click the arrow to expand your domain name, and locate an OU where you would like to keep your groups. 
3. In the Tasks pane, click New, and then click Group (Right click, new group also works).
4. In the Create Group dialog, type 'DirectAccessClients' for Group name. 
5. Scroll down to access the Members section of the Create Group dialog, and click Add.
6. Click Object Types, select Computers, and click OK.
7. Type CLIENT1 or whatever your first Windows 8 test laptop is, and then click OK.(It wont matter too much if you add your Windows 7 test machine now).
8. Click OK to close the Create Group dialog.
9. Exit the Active Directory Administrative Center.

Install the DA Role on your DA Server:
1. The most simple way is PowerShell, open a PowerShell console and type: "Install-WindowsFeature RemoteAccess -IncludeManagementTools"
2. Alternate is to use the GUI - just add the "Remote Access" Role.

Perform a very basic install of Direct Access:
1. From the Start screen, click "Remote Access Management". 
2. In the Remote Access Management console, click Run the Getting Started Wizard.
3. Choose Deploy DirectAccess only.
4. Verify that Edge is selected as the network topology. Type the public name of your Direct  Access server as the public name to which remote access clients will connect - in my  example the public name is "duffey.dyndns.org" even though the machine i am connecting to  is called "da1.contoso.com" - my firewall will recieve this traffic and forward it to the  correct host. Click Next.
5. On the final wizard page, click the link supplied to edit the wizard settings. 
6. In the Remote Access Review dialog, next to Remote Clients, click Change.
7. On the Select Groups screen, clear the Enable DirectAccess for mobile computers only  checkbox.
8. Click Domain Computers (CONTOSO\Domain Computers), and then click Remove.
9. Click Add, type DirectAccessClients, and then click OK.
10. Click Next, and then click Finish.
11. Click OK in the Remote Access Review screen, and then click Finish.
12. Since there is no PKI setup yet in this lab environment, the wizard will automatically   provision self-signed certificates for IP-HTTPS and the Network Location Server, and will   automatically enable Kerberos proxy. The wizard will also enable NAT64 and DNS64 for   protocol translation in the IPv4-only environment. After the wizard successfully completes   applying the configuration, click Close.
13. In the console tree of the Remote Access Management console, select Operations Status. Wait  until the status the status monitors display as "Working". From the Tasks pane under   Monitoring, click Refresh periodically to update the display.

Test a Win8 Client:
1. Before even connecting to the internet with the 3G device, there are some things we can check on the client. Using PowerShell do "Get-DaConnectionStatus" to check the assistant is working. And do "Get-DNSClientNrptPolicy" to check the NRPT table has been applied from the group policy the DA wizard built. (The DA wizard is essentially putting together some complex policies that are applied to your DA client and Servers, if there are problems the first thing to check is that the policies have applied). The result of the commands will look similar to this:

'Trap' Number 1: one of the first head scratching moments came from my initial setup. If you get a screen that looks more like this:

Where the text is: "Network Connectivity Assistant service is stopped or not responding."

If you inspect the service, it probably wont be running and it wont be possible to start it:

And when you inspect the event log you will get an event similar to this:

"The network connectivity assistant terminated with the following service specific error: the request is not supported"

Then you are probably running the Release Preview (RP) PRO version of Windows 8. The workaround is to test with the older version, Consumer Preview or to obtain Enterprise Edition of RP. The Windows 8 Consumer Preview (CP) works fine and Windows 8 RC Enterprise works fine - PRO is not supported. The assistant service seems the service has been hobbled in Pro Edition. I don't know where the specific reference is for this, but I found some notes on the TechNet forums indicating this was known - there probably is some official reference to this somewhere but I hadn't seen it, I hope this post saves someone some time.

You will know if you are on pro because the "msinfo32" dialog will look like this:

Win8 Enterprise will actually spell it out:


Once you are comfortable your Windows 8 client looks healthy, has the group policies and the NRPT updated you can connect it to the external network using your phone if it supports Internet Sharing. Once the DA client realises it isn't on the corporate network it should connect to the DA server.

Visually you should see a notification in your "Available Networks" pane which indicates you are connected.

You should also be able to use the PowerShell command "Get-DaConnectionStatus":

Once you are connected you should be able to browse Intranet resources as if you were in the office (This is my Linux based NAS):

All of your resource names should be resolving to IPv6 addresses. Direct Access is an IPv6-only technology. The magic is being performed by NAT64/DNS64 on the Direct Access server. 

On the Direct Access server side you should get visual confirmation and detail of client connections:


Detailed Client information is available per connection:


Getting Windows 7 to Work

So, Windows 8 works well in the lab. Windows 8 has a huge benefit over Windows 7 in terms of Direct Access in that it supports the new Kerberos Proxy. When the Windows 8 clients connect to the DA server both the Client computer and the user can be authenticated using Kerberos. The DA server proxies the request to a domain controller. In Windows 7/Windows 2008 R2 the initial authentication required certificates for the workstations. Windows 8 is more efficient than Windows 7 in its use of the IP-HTTPS protocol, the IP-HTTPS protocol has become the default and preferred method for a lot of the deployment scenarios. (In Windows 7 IP-HTTPS was seen as the option we took if other technologies couldn't be used - like Teredo). 

My initial set back for getting Windows 7 to work was I completely forgot about the need for workstation certificates, with that in mind it shouldn't take too long to add support to your lab for Windows 7 clients. The high level steps will be to configure a CA to hand out workstation certificates, ensure the clients have enrolled for the certificates and change the Direct Access server to enable this type of authentication.

To Get the client Certificates installed I enabled auto-enrolment in the Default Domain Policy (you might choose a more granular solution):

1. Open the Start menu, select Administrative Tools and then Group Policy Management.
2. On the Group Policy Management console, expand Forest: contoso.com, expand Domains and select contoso.com.
3. On the left panel right click on Default Domain Policy and select Edit.
4. On the Group Policy Management Editor console, on the left panel under Computer Configuration expand Policies, expand Windows Settings, expand Security Settings and then select Public Key Policies.
5. On the right panel, double click on Certificate Services Client – Auto-Enrolment.
6. In Configuration Model select Enabled, and then check both Renew expired certificates… and Update certificates that use certificate templates check boxes.
7. Click OK and close the Group Policy Management Editor console.
8. Close the Group Policy Management console.

Then in the Basic Certification Authority I set up with the Vanilla settings (literally -> next, next, next on the install) I create a template for Computers using Direct Access:

1. Open Certification Authority console.
2. On the left panel, expand Contoso-RootCA and right click on Certificate Templates. Select Manage.
3. On the Certificate Templates Console window, right click on Workstation Authentication and select Duplicate Template.
4. Click OK to confirm Windows 2003 Server, Enterprise Edition.
5. In the Template display name text box, type DirectAccess IPsec Client.
6. Go to the Security tab and click Add…
7. In the Enter the object names to select text box type Direct Access Clients (or whatever your group is called) and click OK.
8. Under Permissions for Direct Access Clients select Read, Enroll and the Autoenroll check boxes.
9. Click OK to create the template.

I create a template for the Direct Access Server using the new CA:

1. On the Certificate Templates Console window, right click on Workstation Authentication and select Duplicate Template.
2. Click OK to confirm Windows 2003 Server, Enterprise Edition.
3. In the Template display name text box, type DirectAccess IPsec Server.
4. Go to the Extensions tab. Select Application Policies and click on Edit…
5. On the Edit Application Policies Extension window, click Add… Select Server Authentication and click OK.
6. Click OK again to close the Edit Application Policies Extension window.
7. Go to the Subject Name tab.
8. Under Subject name format select Common name.
9. Go to the Security tab and click Add…
10. In the Enter the object names to select text box type Direct Access Servers (or whatever group you put your DA servers in) and click OK.
11. Under Permissions for DA Servers select Read, Enroll and the Autoenroll check boxes.
12. Click OK to create the template.

Then in the CA console I enable the certificate templates to be issued:

1. Right click on Certificate Templates, select New and then Certificate Template to Issue.
2. Select both DirectAccess IPsec Client and DirectAccess IPsec Server, and then click OK.
3. Close the Certification Authority console.

Now the clients and the server should get the new certificates. To speed up the process you can use:

1. Certutil -pulse

This will tell the clients to check what certificates they need to auto-enroll for now, rather than the polling interval.

If you would like to check if the certificates have been added to the client stores you can open an MMC console on the client, choose to add snap-in and add the certificates snap in. You should see the workstation certificate in the Personal store of the computer account.

Then, on the DA server we need to make a change to allow the Windows 7 clients to authenticate to the DA server using certificates:

Open the configuration screen, and we will modify a section inside step 2:

Click next to progress through the items we don't want to change until you arrive at the following screen:

 On the screen we need to make a couple of changes.

We need to "Use computer certificates", and we need to select the certificate from our CA.

And we need to tick "Enable Windows 7 client computers".

Select Finish. Then apply the policy changes.

At this point, it should be possible to connect the Windows 7 clients to the external network and connect in over the internet. You should see details in the DA connection monitor that is included in the console. You will notice that certificate authentication and NTLM is used rather than the Kerberos v5 that you will see with the Win8 IP-HTTPS clients.

One thing I forgot to mention earlier which is good for troubleshooting information if you hit issues is the wf.msc console. It will show you the IPSEC tunnels being established (if they are being established). This example is from a Windows 8 client and we see Kerberos as the authentication method. On Windows 7 you will see NTLM in its place. Its important to bring up here because if you made it this far you already had Windows 8 clients working - the big change for the Windows 7 clients is the certificate authentication for the infrastructure tunnel.

And that's about it for getting both Windows 7 and Windows 8 clients connecting to your DA infrastructure. The coolest part of this whole thing (I think) is that we no longer need the two external public IPv4 addresses we did in Windows 2008 R2 DA. This means it is a lot easier to test this stuff out in a lab, but more importantly a big deployment blocker has been removed for lots of companies who wanted to use this technology but didn't have the addresses available (It also works behind a NAT).

Before I wrap it up, there is one more trap to mention if you are testing this in a lab:

Second Trap:

Your clients using certificate authentication will be looking for a CRL (Certificate Revocation List) if you have a default install of your certificate services role. This is good for production, and should be set up. You would need to look into publishing your CRL externally so that your clients can check it. For your lab, if you would like to take shortcuts (I did) you can simply disable the CRL publishing points so that clients don't try this step:

1. In the Certification Authority console tree, right-click Contoso-CA, and then click Properties.
2. Click the Extensions tab. Select each listed CRL Distribution Point (CDP), and click Remove. Click Yes to confirm removal.
3. Click OK to close the Contoso-CA Properties dialog, and then click Yes to restart Active Directory Certificate Services.
4. Close the Certification Authority console.

That's it for this week, hope you have fun building your Direct Access lab. 

Comments (7)
  1. Pat DiPersia says:

    Chad – two items.

    One, you may want to mention that the Windows firewall is a REQUIREMENT!  We had it turned off, and couldn't get DA to work.  Figured that out the hardway.

    Two, on the CRL – all of our machines will start their DA life on the domain/network.  Once DA is setup for the machine and it can ALWAYS connect to the network, would we still need to publish an external CRL, technically?  If the clients are able to see the CRL internally (And via DA), wouldn't that suffice (Technically)?

  2. Chad Duffey says:

    Hey Pat – Windows Firewall does a lot more than just firewall – it shouldn't be 'turned off' anyway. If you need to disable components of the firewall service this article might help: technet.microsoft.com/…/cc766337(v=WS.10).aspx

    With the CRL; Its something that's in our DA infrastructure checklist. technet.microsoft.com/…/ee649276(v=ws.10)

  3. None of the above 5 Direct Access guide links work!

  4. Chad Duffey says:

    Thanks. Removed the links, content updates for 2012 maybe.

  5. LinuxAdmin says:

    I'm trying to set this up for a small company that is spread out over 2 offices and lots of client locations.  I have the luxury of starting from scratch and thought I had this planned well, until I actually got started working on it.  I thought I could put all necessary services (AD, DNS, DHCP, IIS, and DA) on the same server.  Is this possible?  I'm having troubles with the configuration and I'm not sure if it's because of my lack of understanding.  I am mainly a linux admin with rusty Windows server experience.  I may have fallen for the marketing that the admin no longer needs to know the full details of what happens behind the scenes.

  6. Chad Duffey says:

    Hi LinuxAdmin,

    Sorry for the delay.


    The DirectAccess server must be a domain member and cannot be a domain controller.



  7. Arun says:

    Hi Chad,

    I have a setup almost identical to the one you have described above. I wanted to know whether instead of forwarding port 443 to the DA server, another port such as 8433 could be used and forwarded to 443 (i.e. 8433 –> 443) . I have tried this by modifying the IPHTTPS URL in GPO to domain.com/IPHTTPS. This setup works if both ports 8433 and 443 are forwarded. If I close 443 while a session is still active, it does not disconnect. Furthermore, a terminated DA session can be reconnected with a short time after disconnection (15 minutes). I determined that the primary cause of the failure was the current security tunnels were not being established (visible in Main Mode SAs in Windows Firewall). From this post (social.technet.microsoft.com/…/3a2be182-0af5-4bb5-a951-3f0f948bfa17), I was suggested to try machine certificates instead of Kerberos. I followed the steps above and got the same result (actually it still prefers Kerberos). Could you please let me know if such a configuration is possible and where I would reroute the traffic on 443 (possibly from the client) to 8433.


Comments are closed.

Skip to main content