Architecting, Deploying and Operating Direct Access (Part 1)

by [Published on 24 May 2011 / Last Updated on 24 May 2011]

This article covers the pre-requisites to plan, prepare and scope the environment of your new Direct Access deployment.

If you would like to read the other parts in this article series please go to:

Introduction

In the previous article in this column, you read about Direct Access from Microsoft and how it’s driving IPv6 planning and adoption in some enterprises. While certainly Direct Access is one of the more dynamic and game changing technologies to be integrated into Windows in recent memory, it is also a complex project that requires planning, design, architecture and some rigor in deployment and operations as well. In the next few articles, we’ll walk through the essentials on DA and tips and tricks to keep in mind while you plan for your future network state. In this article, we’ll cover the prerequisite’s to plan, prepare, plan and scope the environment of your new DA deployment.

Planning: Measure twice, cut once

The first step in the process is to sit down with your network, security and other IT operational teams (including business unit representatives that liaise with IT) to consider whether ‘to use DA or not to use DA’. Common questions to ask in the enterprise include:

  • Direct Access will provide seamless access to intranet resources for your users regardless of network location; is this something that’s acceptable to your organization from a risk vs. reward perspective? IT Security will want to weigh in.
  • How about from a systems management perspective? Being able to manage and remotely ‘touch’ devices regardless of network location is very tempting from an IT operations perspective, but what does the networking team have to say about that ingress and egress traffic on your perimeter network? A general best practice is to crawl before you walk before you run – that is, perhaps your first approach here is to redefine what remote access means to your enterprise and which ‘tools’ fit into the tool chest to accomplish that.
  • Is your current VPN solution meeting your user’s needs? Is a Direct Access migration going to increase user satisfaction, reduce help desk cases, increase security or whatever other goal you’re trying to accomplish? Quantifiable metrics like this will help you make the business case to management for Direct Access and the resources required to use it. Perhaps the first 6-12 months of the plan involve modernizing your current VPN solution (crawling) and implementing something like Internet Based Client Management in System Center Configuration Manager (walking) to control and manage IT assets off the corporate network before deploying Direct Access (running).

Pre-requisites for Direct Access

OK, you’ve done the pre-work and you’ve assembled a working team of representatives from different parts of the organization – what are the pre-requisites for Direct Access and what do you need to get started? Let’s start with the client-side; a big selling point for Direct Access is that the client is fully integrated into the Windows operating system – no more third party clients to manage or deploy, and no more worrying about 64-bit vs. 32-bit dependencies. However, Direct Access is included in a list of ‘premium’ features such as Bitlocker Drive Encryption and Applocker, both of these require Windows 7 Enterprise. Be sure you have the right version of Windows 7 to deploy Direct Access. Also be sure to check with your desktop imaging team to verify that they are deploying Windows 7 Enterprise. Since Direct Access requires clients to have IPv6 enabled; check to make sure that no build processes or configuration tools are disabling or removing the IPv6 stack from your gold image.

From a server side, Direct Access is considered a ‘role’ in a Windows Server 2008 R2 Enterprise deployment. You may need one server or you may need several (more on that later during capacity planning), but each Direct Access server role is required to be domain-joined to your corporate Active Directory environment. The servers must have:

  • At least two physical network adapters installed
  • They cannot be behind a Network Address Translation (NAT) device (e.g.: a router or firewall performing NAT)
  • They must have consecutively addressed static IP addresses.

http://www.computerworld.com/common/images/site/features/2009/032009/DirectAccess.gif
Figure 1

Please note, this Windows Server configuration assumes that you will be deploying Direct Access in a ‘native’ IPv6 mode; if you are extending Direct Access to servers or other resources that are not addressed with IPv6 or accessed via Teredo (IPv6 encapsulation), you may require or want to deploy Forefront Unified Access Gateway (UAG) in your environment. We will cover UAG in a future article, but most large organization (1,000 devices+) are deploying or planning to deploy Direct Access with UAG.

Other infrastructure requirements or pre-requisites include:

  • A healthy Active Directory with Group Policy working smoothly (this is necessary for components like IPSec policy management)
  • A Microsoft DNS environment,
  • A properly tuned Public Key Infrastructure (necessary to issue computer certificates for the mutual authentication process in Direct Access),
  • Most importantly, IPv6 enabled on your servers and clients that will participate in DA.

What’s the Scope?

Next, plan your deployment and the scope of the environment. Initially, you will want to do a pilot for DA. A good rule of thumb is to seek out more advanced users in both IT and the business units of your organization to participate in a ‘pilot program’. This pilot allows you to start small and then enabling users a few at a time as they migrate to Windows 7. This has been a much more successful approach to deploying the DA. Obviously, mobile devices are primarily in scope, but organizations that have deployed desktops to telecommuting workers may be in scope as well. Have a solid understanding of all your assets and your Windows 7 planning prior to scoping the architecture on the server side.

Understanding the different Access Models

Planning for the access model that best fits your environment is critical to sizing the environment. There are three access models for Direct Access: full intranet access, selected server access and end-to-end access.

Full intranet access is the closest semblance to a traditional “client-based VPN” solution that many organizations have deployed today. While this model does not require that the servers being accessed run Windows Server 2008 or Windows Server 2008 R2, it does put all the Direct Access termination load on the Direct Access servers themselves; this could require scaling up or scaling out the server farm for the deployment.

Selected Server Access pushes the IP Sec encryption and authentication down to the servers being accessed themselves; peer authentication in some configurations may require Windows Server 2008 R2 or later, though.

The end-to-end access model allows mutual authentication between both clients and servers and encrypts that traffic as well, but does not allow access to IPv4-only resources on your corporate network.  If you have a lot of client to client activity in your environment, consider this model. 

Summary

As you can see, each model has advantages and drawbacks. It’s prudent to consult the Direct Access design guide on TechNet to fully understand each of the models and decide what works best in your environment.

Now that we’ve covered the pre-requisites for Direct Access, scoping, organizational alignment and the access models, we’ll get into sizing and design of the infrastructure in the next article.

If you would like to read the other parts in this article series please go to:

Featured Links