Microsoft’s DirectAccess, new to Windows Server 2008 R2, promises connectivity nirvana: an always-on application infrastructure for employees both inside and remote to the organization. But it comes with a very steep cost in terms of IT dollars and time to deploy.
Microsoft has not yet promised an availability date for R2, but a beta version was made available in early February and can be downloaded here.
In the meantime, it’s always a good idea to familiarize yourself with new concepts even before they’re available. And hHere’s the promise of DirectAccess.: Imagine yourself as a field sales representative. After a long flight, you arrive at your hotel at 10 PM and want to check your e-mail and log your timesheet hours before bed. Once checked in, you go to your room, plug in your laptop and connect to the hotel’s Internet facility. In a matter of seconds, not only does your e-mail update, but your intranet timesheet application opens up automatically — and you can update it — without messing with a VPN connection.
The next morning, at a client site, you connect to the client’s guest wireless network while in a meeting. Using standard Windows search tools, you search for a document that resides on a SharePoint server internal to your firm. Your computing experience is the same, no matter where you are.
On the flip side, imagine yourself as an IT worker in a large firm. (This one shouldn’t be too difficult to envision.) You have a large contingent of telecommuters spread across the world and previously have had no way to enforce that they either come into the office or connect to your VPN at any regular interval. As a result, you didn’t have any way to ensure that their machines were properly patched, that they weren’t infested with malware, or that they weren’t leaking confidential and proprietary company information via peer-to-peer networks or other means.
But now all of these remote users can be managed, secured, patched and trusted — all via a secure, authenticated connection — removing any obstacle to administering those machines as if they were hardwired to your internal networks.
DirectAccess is the technology that purports to offer this level of seamless connectivity. In this feature, I’ll take a look behind the scenes at the technology that drives it and then walk you through an overview of how to prepare for and deploy DirectAccess.
How does DirectAccess work?
DirectAccess relies heavily on IPv6. (I can hear the collective groaning throughout the audience.) The reasoning here is that IPv6 (Internet Protocol version 6) is one of the only transport protocols that supports the addressing needs required from the client through bridges to the corporate network. Of course, migrating to IPv6 is a costly and time-consuming proposition, and thus DirectAccess also supports a variety of transition technologies that make IPv6 work in a world that is still heavily based on IPv4.
These transition technologies essentially carry IPv6 packets across IPv4 tunnels, and sometimes through edge devices that might otherwise interrupt the flow of communications. The technologies in use are:
Teredo: Teredo helps IPv6 transmission pass through NAT (Network Address Translation) devices, which traditionally allow larger networks to assign private, non-routable addresses behind an edge device that shares one or more public IPv4 addresses. If a client is behind a NAT firewall, Teredo is the preferred DirectAccess connectivity method.
6to4: 6to4 is a way to translate IPv6 address into IPv4 addresses, and it works well in scenarios where IPv6 connectivity is needed across the public IPv4 Internet. If the remote clients have public IPv4 addresses, 6to4 is the preferred connectivity method.
IP-HTTPS: This is a new protocol to Windows 7, and also Windows Server 2008 R2, that tunnels IPv6 packets coming behind an edge device through an HTTPS session. While more accessible than Teredo and 6to4, this method has a significant performance penalty and is meant to be a “last resort” connectivity protocol when Teredo or 6to4 won’t connect.
Native IPv6: Of course, if you have deployed IPv6 and all clients and servers have globally routed IPv6 addresses, then you can work in the native IPv6 protocol without any transition technologies necessary.
Additionally, if your corporate network isn’t yet IPv6 ready, you will need some sort of translation device or technology. Your options are:
Configure your intranet routing infrastructure to support native IPv6. This is probably the least likely option.
Deploy ISATAP on your intranet. With ISATAP, intranet servers and applications are reachable by tunneling IPv6 traffic over your IPv4-only intranet. This option is based on configuring the operating system a certain way, as opposed to needing more hardware as with other possibilities.
Use a Network Address Translation-Protocol Translation (NAT-PT) device that sits in front of your server resources. This device translates traffic between your DirectAccess clients that are using IPv6 and servers and applications that can only use IPv4. This solution requires more hardware.
Once all of the appropriate transition technologies are in place, clients connect through the cloud to one interface on your publicly accessible DirectAccess server, which then performs all the necessary authentications and authorizations and creates a user-transparent link to the corporate network. During DirectAccess setup, you can determine which DNS servers, domain controllers and other line-of-business resources should be made available to remote DirectAccess clients.
Down sides: Complexity and resources
In short, installing DirectAccess involves thinking about three different sets of code, none of which should be altered without considerable planning:
- The interface between the wide-open Internet and your corporate network
- The protocols that bridge connections between or through two intranets, such as a customer site to your corporate intranet, or the DirectAccess server itself to other resources on your intranet
- The components that encompass the overall security of your corporate network and each DirectAccess client
Not only is that a lot to think about, but there are down sides to DirectAccess as it currently stands and that are likely to remain upon the release of Windows Server 2008 R2. Among the problems:
- Clients must be running Windows 7. This limits deployments severely, as you need to upgrade all potential remote DirectAccess clients to Windows 7.
- You must have some sort of connection to potential clients to propagate DirectAccess settings back to them. There is an initial setup, which means you must bring these clients online on your corporate campus, convince the users to connect via your VPN or send them a file they must run.
- You need Windows Server 2008 R2, at least for the DirectAccess server.
In other words, this is definitely a bleeding-edge solution right now.
Preparing your environment for DirectAccess
Here’s how the process works overall. It is complex, but most of the difficulty comes in configuring the environment properly, as you’ll see. You need to procure a correctly configured server, deploy some transition technologies, poke appropriate holes in firewalls and work somewhat in depth with addressing. You also will need to decide among a number of access and scalability models.
While some of this process can be scripted, I will walk you through a manual preparation and deployment of an end-to-edge solution (the broadest and most comprehensive of the available models) in this feature for the sake of clarity.
Let’s begin the preparations:
1) Choose a server with two Ethernet adapters and install Windows Server 2008 R2. Join this server to an Active Directory domain.
2) On this server, connect one network adapter to the Internet and the other network adapter to your intranet. Assign appropriately schemed IPv4 addresses to each respective adapter — native IPv6 is not required at this point, as other protocols can automatically assist in the transition.
3) Open ports on both the edge and DMZ firewalls. You can use the following table to determine which ports to open on your edge firewall based on which client connectivity protocols you plan to support.
This table lists ports for your DMZ firewall, connecting the DirectAccess server itself to the intranet.
4) Acquire two public static IPv4 addresses that are consecutive, and publish one of the addresses to your external DNS zone, assigning the name directaccess.company.com or da.company.com. Assign the two public addresses to one of the adapters on the DirectAccess server, which will from that point forward be the Internet-facing interface.
5) Designate the Internet-facing adapter as a “Public” or “Private” interface, and designate the other adapter as a “Domain” interface.
6) Enable IPv6 on clients and servers.
7) Create a security group in your Active Directory domain that contains the computer accounts of all clients that will participate in DirectAccess.
8) Install Web server software on the DirectAccess machine.
9) Install the DirectAccess Management Console feature by going to Server Manager, Initial Configuration Tasks, and then choosing Add features. In the resulting wizard, select DirectAccess Management Console and click Add Required Features in the pop-up window to add the Group Policy Management feature. Click Next, Install, and then Close to finish the installation.
Using the DirectAccess setup wizard
Once you have prepared your environment for DirectAccess, you can use a relatively simple wizard to put in place the tools necessary to deploy DirectAccess. In the wizard, you specify which clients can connect to your corporate network via DirectAccess; choose connectivity and security policies for controlling access to DirectAccess; identify the right DNS, domain controller, and management servers necessary to enable all DirectAccess features; and specify the application servers accessible to remote clients connected through DirectAccess.
To run the console, go to Start, Administrative Tools, and then click on DirectAccess Management. You’ll be greeted with the screen shown in the figure below.
Click the Setup branch in the left pane to start the process.
The first step is to choose the security group, or groups, you created earlier during preparations that contain the computer accounts that will be enabled for DirectAccess.
Next you set up the DirectAccess server itself. First, specify which interface connects to the Internet and which is connected to your internal corporate network. Next, choose the root certificate that will be used to verify certificates sent by DirectAccess clients while they authenticate via IPsec. You can also choose a certificate to use for IP-HTTPS connectivity. Next, determine whether clients will be required to use a smart card to log onto its DirectAccess-enabled computers.
The third phase of the DirectAccess configuration identifies and sets up communication with infrastructure servers, such as DNS and management servers and domain controllers. First, identify a URL that DirectAccess clients will use to get network location information — this is how clients can figure out if a resource is internal or external to the corporate network. Next, identify the DNS suffixes and IP addresses of internal DNS servers so that clients can send name and address queries to the correct machines. Finally, you can enter names or IP prefixes of DirectAccess management servers — this is optional.
The final phase of DirectAccess deployment is to select application servers that will be restricted using IPsec and set up authentication and authorization for access to them. You can allow a certain subset of servers (contained within a security group) that you select that must enforce authorization, and you can also restrict access only to servers in those groupings.
The last word
DirectAccess is a highly useful feature of Windows Server 2008 R2 and has the potential to make administration in large organizations remarkably easier by allowing administrators to touch all clients, even those previously considered unmanageable. The benefits, however, may be masked by the initial complexity and technological requirements needed to fully deploy DirectAccess.
From IPv6 to the transition technologies to the very requirement that Windows Server 2008 R2 be running within the enterprise (forcing you then to be an early adopter), I don’t think anyone is arguing this is easy. And it could be made easier, via better options during setup, a migration and preparation wizard a la Windows Essential Business Server, and other means. But eventually the benefits may well outweigh the costs: this is definitely a feature to watch.
