Windows Server 2012: What's New in Security (Part 1) - DirectAccess Improvements

by [Published on 4 July 2012 / Last Updated on 4 July 2012]

In this multi-part series, we'll take a look at what's new (and what's not) in security for 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

It's official: The next version of Windows Server has a name and that name indicates it will be released sometime before the end of the year. Whether and when to deploy a new server OS is always a big decision, and most enterprises won't be rolling it out immediately. But part of that decision-making process involves evaluating the relative benefits, and better security is always high on the list of factors that can make all the hassles involved in an upgrade worthwhile. So in this multi-part series, we'll take a look at what's new (and what's not) in security for Windows Server 2012.

First, we’re going to look at the big improvements that have come to DirectAccess. Server 2008 R2 included DirectAccess – but it wasn’t very functional. DirectAccess is a great technology that allows users to connect a remote computer to a work network without the hassle of setting up and using VPN software; the connection is automatic and easy. From the admin side, it allows you to update the remote computer’s software and Group Policy settings even if the user isn’t logged in.

DirectAccess is an important security feature because it gives you much more control over the remote machines that connect to your corporate network. It authenticates the remote computers, encrypts communications via IPsec and lets you configure access controls to specify what resources each user can access. I’ve written a lot about implementing DirectAccess via Forefront UAG over on the ISAServer.org site.

The reason I focused on using the UAG version of DirectAccess rather than the Server 2008 R2 version is that the former was a lot more flexible and feature-rich. Server 2012 has brought the UAG DA functionality into Windows Server, so that you don’t have to buy another (expensive) server software package. Microsoft has also added some new capabilities that UAG didn’t have.

Where does this leave UAG?

Some folks have been asking what this inclusion of full DirectAccess capabilities in Server 2012 might portend for the future of UAG. Since the more full featured DirectAccess was one of the big benefits of UAG, will it now fade away since you can get that capability free in Windows Server 2012? Or will it just go back to being an advanced reverse proxy and SSL VPN gateway, similar to IAG?

In fact, it seems clear that Microsoft intends for Server 2012 to be the platform for DirectAccess, moving forward. Back in February, over on the TechNet site they published documentation to assist customers in migrating from Forefront UAG SP1 to Windows 8 Beta DirectAccess.

The documentation references two migration scenarios: a side-by-side migration, whereby you would keep the UAG server running while you deploy DirectAccess in Windows Server, and an offline migration, in which you copy the DirectAccess configuration from the UAG server to the Windows Server that has the Remote Access role installed. The Windows Server 8 (2012) remote access server must be a domain member, and can be deployed either at the edge of the local network or behind an edge device such as a firewall.

Considerations for Windows Server 2012 DirectAccess

Microsoft recommends that you use NAT64 as your IPv6 to IPv4 technology, rather than ISATAP. If you migrate from a UAG server that is using ISATAP, you should disable it and enable NAT64. Of course, native IPv6 will give you the most flexibility.

Enabling and deploying DirectAccess in Server 2012

Now let’s take a closer look at DirectAccess in Server 2012. DirectAccess is enabled as a server role (Remote Access), which you can add through the Server Manager dashboard, as shown in Figure 1 below.


Figure 1

To add the Remote Access role, you run the Add Roles and Features Wizard that helps you install roles, services and features. After selecting the installation type (in this case, role-based or feature-based installation) and selecting the server on which you want to install the role, check the Remote Access box on the “Select Server Roles” page of the wizard. This will bring up a list of role services and features that must be installed before you can install DirectAccess. To do so, click Add Features, as shown in Figure 2.


Figure 2

You might look for DirectAcess on the Features page of the wizard, shown in Figure 3, but you won’t find it in the list. Don’t worry; we’ll get to it in a moment. For now, just accept the default features and click Next.


Figure 3

Go through the next few pages and then you’ll find the option to select the DirectAccess and VPN role services when you get to that page of the wizard, as shown in Figure 4. In fact, it is selected by default, so just click Next.


Figure 4

On the last page of the wizard, look over your installation selections and be sure “DirectAccess and VPN (RAS)” is shown under the Remote Access section. You’ll need to check the box to restart the destination server automatically if required, and then you can click Next.

The installation process, shown in Figure 5, can take a while.


Figure 5

Once you’ve enabled the Remote Access role, it’s time to configure DirectAccess on the server. You can deploy DirectAccess only, or deploy both DirectAccess and VPN so that remote client computers that don’t support DirectAccess (pre-Windows 7) can connect to the server over a VPN connection.

The Remote Access configuration wizard will first check to make sure you have all the prerequisites in place. Then you select the network topology of your server (whether it’s on the edge of the network, behind an edge device with two network adapters, or behind an edge device with a single network adapter). You also will need to enter the public name or public IPv4 address that will be used by the remote client computer to connect to the network.

The wizard will do most of the heavy lifting for you, including configuring Kerberos proxy so that you don’t have to set up an internal Public Key Infrastructure – thus saving a ton of time and effort. The wizard provisions self-signed certificates for IP-HTTPS and the Network Location Server. In addition, the wizard will enable NAT64 and DNS64 if you have an IPv4 environment. Note that you can only use the self-signed IP-HTTPS certificate in a single server configuration. If you have multiple servers/multi-site scenario, you’ll need a public IP-HTTPS certificate.

Managing DirectAccess in Server 2012

If you used DirectAccess in Server 2008 R2, you’ll notice that the DirectAccess Management console has gone missing in Server 2012. Instead, you manage DirectAccess by using the Remote Access Management console, which you can access from the Server Manager’s dashboard, as shown in Figure 6.


Figure 6

The Remote Access Management console itself looks very similar to the DirectAccess Management console in Server 2008 R2, but with some added features such as the ability to manage DirectAccess and VPN remotely.

Deploying DirectAccess on the client computers

The next step that you need to take in order to get DirectAccess on Server 2012 up and running is to enable DirectAccess for the managed client computers. In the DirectAccess Client Setup, you will choose between two deployment scenarios: You can either select Full DirectAccess (which enables the clients to connect to the internal network) or Manage Out (for using DirectAccess only to manage client computers remotely). This is shown in Figure 7.


Figure 7

The Manage Out option wasn’t available in Server 2008 R2; you had to have UAG to get that (it was called “Remote Management”). The way this works is that instead of having two IPsec tunnels as you do in the normal client connection scenario, you have only the infrastructure tunnel.

You select one or more security groups of client computers to enable for DirectAccess. You’ll also select how to authenticate your DirectAccess users: through Active Directory credentials or two-factor authentication (smart cards or One Time Passwords), as shown in Figure 8.

You can use an intermediate certification authority to issue the computer certificates, or you can browse for a CA. You can also select whether to enable Windows 7 client computers to connect via DirectAcess and whether to enforce corporate compliance for DirectAccess clients with Network Access Protection (NAP).


Figure 8

You’ll also have to configure the infrastructure servers that DirectAccess clients will access before they can connect to resources on the internal network. A highly available Network Location server is required for DirectAccess, and Microsoft recommends that this server be deployed with a server infrastructure such as domain controllers. You can also run the Network Location server on the DirectAccess server (in which case, the DirectAccess server needs to be highly available). DirectAccess connectivity can be disrupted if the Network Location server becomes unavailable.

Further steps include:

  1. Configuring DNS (setting up a list of DNS suffixes to be used by client computers to determine which DNS queries should be directed to the internal DNS servers).
  2. Configure use of management servers (HRA and SCCM).
  3. Application server setup (select whether to require end-to-end authentication and if you do, select the security groups of the servers that require authentication).

At this point, DirectAccess should be ready to roll. In later articles, we’ll look at how to configure different scenarios and how to troubleshoot problems with DirectAccess 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.

Featured Links