The Windows Server 2012 Simplified DirectAccess Wizard Overview (Part 1)

by [Published on 10 April 2013 / Last Updated on 10 April 2013]

In this article, we'll discuss some of the changes in the DirectAccess wizard that have been included in Windows Server 2012.

If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real-Time Article Update newsletter.

Introduction

When it comes to remote access security solutions, it’s hard to find a better solution than Microsoft DirectAccess. DirectAccess solves the most important problems we’ve faced in the past when it comes to providing a secure, transparent and reliable connection for external users to access internal network resources. However, getting there has been something of a challenge.

If your first taste of DirectAccess was with Windows Server 2008 R2, you might have felt like a kid who went to the circus to see the “naked lady.” You saw the paintings outside the circus tent and you were anxious to finally see her in person – until you actually got into the tent and discovered things aren’t always what they’ve been hyped up to be. That is how you might have felt after you tried to get the DA feature in Windows Server 2008 R2 to work. It sounded great, but there were so many limitations and so many complex manual requirements that you came away from the experience feeling as if you’d been the victim of a “bait and switch” game.

Maybe you started your DirectAccess path with the UAG DirectAccess solution. If that was the case, you might have been more optimistic about the DirectAccess solution. The UAG DirectAccess wizard simplified the DirectAccess deployment and did much of the hard work that was required to get DirectAccess working. However, there were still many background services that you needed to stand up, and there were some limitations and “gotcha’s” that took some of the bang out of the DirectAccess buck and reduced what you considered a positive ROI. Not to mention the fact that UAG took a big bite out of your budget.

Direct Access Deployment Problems

There have been several obstacles to deploying a DirectAccess solution prior to Windows Server 2012. Let’s look at some of those now.

Public IPs

One of the most problematic requirements for DA prior to Windows Server 2012 was the fact that you needed to use two consecutive public IP addresses on the external interface of the DirectAccess server. Given that public IP addresses (or at least public IPv4 IP addresses) are getting to be in short supply these days, this could be an onerous requirement, especially for smaller businesses. For larger organizations, the problem wasn’t access to the public addresses, but instead the fact that the network security guys didn’t want the DirectAccess server to have those public addresses for security reasons.

The PKI problem

Another problem for both small and large organizations was the fact that you needed to deploy your own PKI in order to deploy DirectAccess. It might seem funny to think of establishing a PKI as a problem in this day and age for a business of any size, but the fact is that PKIs need to be designed carefully and require a lot of administrative overhead. In spite of over a decade of strong advice from “the experts” that a PKI is going to be an essential part of network security in the future, organizations of all sizes continue to drag their feet.

Microsoft, in spite of its strong support for PKI in an overall security solution, has conceded to the reality that PKIs aren’t going to be universal and that those who haven’t established one now are unlikely to establish one in the near future, and that there needs to be a way to accommodate these customers. That’s why you are seeing an increasing number of Microsoft solutions that enable “PKI-less” deployments. Windows Server 2012 DirectAccess is one of those.

Off to see the Wizard

That brings us to the subject of this article, which is the simplified DirectAccess wizard. This new wizard is aimed primarily at those organizations that are happy with a simplified deployment that introduces a few (but important to consider) limitations. The simplified DirectAccess wizard is characterized by the following benefits and limitations:

  • There are no requirements for a PKI. The DirectAccess wizard will create a self-signed certificate that DirectAccess clients will trust when establishing a DirectAccess connection.
  • There is support for a single NIC configuration. In the past, you had to have at least two NICs in the DirectAccess server. With the new simplified DirectAccess wizard, you can configure the DirectAccess server with a single NIC on the internal network.
  • Public IP addresses are not required. In contrast to the “full blown” version of DirectAccess, the simplified DirectAccess configuration allows you to use private addresses on the DirectAccess server. This makes it possible to deploy the DirectAccess server behind a NAT device.
  • The performance of IP-HTTPS connections is improved. One of the problems with the IP-HTTPS protocol in the past was the issue of double encryption and the processing overhead that is incurred because of this. With Windows Server 2012, the IP-HTTPS protocol uses SSL with NULL encryption. This allows for server authentication without having to deal with the overhead of TLS encryption. Credentials are secured inside an IPsec tunnel, so that there are no security risks due to open exchange of credentials.
  • You have a Network Location Server right on the box. In a full blown deployment of DirectAccess, you need to deploy a network location server on some other server on the corporate network. The Network Location Server is used by DirectAccess clients to determine whether or not they are currently located on the corporate network. When you run the simplified DirectAccess wizard, the wizard will configure the DirectAccess server itself as a Network Location Server. Clients will connect to the Network Location Server over a custom TCP port number, TCP port 62000.
  • NAT64/DNS64 support is built in. The Windows Server 2008 R2 DirectAccess server did not include a NAT64/DNS64 solution, so you had to configure the internal network to provide some kind of native IPv6 support. That support could include the introduction of an ISATAP server, but ISATAP really wasn’t designed to be a long term solution. The UAG DirectAccess solution included built-in support for ISATAP, but it also included a NAT64/DNS64 solution, so that you didn’t need IPv6 support on the corporate network. The simplified DirectAccess solution doesn’t set up an ISATAP server on the DirectAccess server. Instead it relies on NAT64/DNS64 to enable DirectAccess client access to IPv4 only resources.
  • It provides support for IP-HTTPS only. In order to use alternate IPv6 transition protocols, you need at least two addresses on the DirectAccess server so that the client can determine what type of NAT device it is behind. With the simplified DirectAccess server, you can use a single IP address on the NIC that accepts the incoming DirectAccess client connection requests, but because of this, only the IP-HTTPS IPv6 transition protocol is supported.
  • There is no support for DirectAccess server arrays. For high availability, you typically want to set up a DirectAccess server array, where you configure a members of the array through a central policy that is applied to all array members. This is how it was done with the UAG DirectAccess solution, but the Simplified Wizard doesn’t support this.

As you can see, the simplified setup is quite a bit different from the full blow deployment of DirectAccess. For larger organizations, the major drawback is the lack of high availability built into the solution. Of course there are workarounds to this, such as the same ones you had to use with the Windows Server 2008 R2 solution, whereby you could have the DirectAccess servers configured as virtual machines and back-up DirectAccess servers could sit as cold stand-by servers. It’s not an elegant solution but it does work – even though it doesn’t provide transparent failover.

Preparing the Simplified DirectAccess Server Test Lab

In our family, we’re big fans of the Test Lab Guides. Tom Shinder and Joe Davies came up with the idea of Test Lab Guides a few years ago and now Microsoft produces Test Lab Guides for a large number of their products and technologies. Test Lab Guides are great for learning about new technologies because they’re all based on a common “Base Configuration” that you can snapshot and reuse; this speeds up your testing process because you don’t have to create custom labs every time you want to test a new product or technology.

Microsoft has prepared a number of Test Lab Guides for Windows Server 2012 and you can find a list of them here. There is even a Test Lab Guide listed on that page that shows you how to configure the simplified DirectAccess solution. However, there are some significant problems with that guide, which make it a worthwhile effort for me to write this article (and for you to read in before venturing forth), as the simplified DirectAccess wizard Test Lab Guide doesn’t really highlight the primary values of the simplified configuration.

Let me explain what I mean by that . I believe that the simplified DirectAccess wizard provides two major value propositions for small and mid-sized businesses (and to some degree, to larger organizations, too). Those are:

  • The ability to deploy the solution behind a NAT device
  • The ability to deploy the solution with a single network interface card

The problem with the Microsoft simplified DirectAccess Test Lab Guide is that it is based on the Base Configuration without making the changes that would be required to make it a more realistic demonstration of these values of the simplified DirectAccess Wizard. The figure below shows the network configuration on which the Microsoft simplified DirectAccess configuration is based.

Image
Figure 1

As you can see, the network topology in the Test Lab Guide is designed primarily to support the full blown DirectAccess server deployment. You can see that there are two network interfaces on the DirectAccess server (EDGE1) and the external interface of EDGE1 has two public IP addresses. This seems to me to completely overlook the spirit and philosophy of the simplified DirectAccess configuration.

Instead, in order to demonstrate the benefit of the simplified configuration, there should be a NAT device of some kind in front of the DirectAccess server and the DirectAccess server (EDGE1) should be reconfigured to have a single network interface card. The network topology of that configuration would look like what you see in the figure below.

Image
Figure 2

As you can see in the second figure, there is an “edge” device that is a NAT device (EDGE4). For this article, I used a Windows Server 2008 R2 computer as an RRAS NAT server that performs reverse NAT. The server was configured to forward all TCP 443 connections to the server to the IP address of EDGE1. For details on how to configure Windows Server 2008 R2 as a reverse NAT server, please see my article on how to do that.

Another change that you need to make to the base configuration in order to make this work is to configure the default gateway address in DHCP and on the individual servers to be the IP address on the internal interface of the RRAS NAT server (EDGE4). The reason for this is that EDGE4 is now the gateway address to the Internet, and even EDGE1, which is the simplified, single NIC DirectAccess server, is configured to use EDGE4 as its default gateway. It might sound wrong, but I guarantee that this will work – as I’ll demonstrate in Part 2 of this article series.

With these minor changes to the Base Configuration, you’ll be able to get a full feel and realistic representation of the value and the operations of the simplified DirectAccess configuration, and that’s where we’ll pick up next time.

Summary

In this article, we discussed some of the changes in the DirectAccess wizard that have been included in Windows Server 2012. We then discussed some of the specific characteristics – both benefits and limitations – of the new Simplified DirectAccess Wizard and how you can use it to support a streamlined version of DirectAccess. We finished off by describing the changes you need to make in the Base Configuration if you want to get the most out of your testing of the simplified DirectAccess wizard. These changes in the Base Configuration will enable you to carry out the steps that I’ll described in subsequent articles in this series. See you then! –Deb.

If you would like to be notified of when Deb Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real-Time Article Update newsletter.

Advertisement

Featured Links