Microsoft DirectAccess: The ugly truth
- 12 January, 2010 22:29
DirectAccess, Microsoft's pairing of Windows 7 and Windows Server 2008 R2 for connect-anywhere access, is possibly the best thing Redmond has produced in a long time. Unfortunately for many, it just may be about five years too early.
For those just getting up to speed on some of Windows 7's new features, DirectAccess is a way for Windows 7 clients to securely connect to the corporate network from any location without any type of traditional VPN. It provides an encrypted bidirectional connection between the enterprise domain and the client device prior to the user logging on to the system, allowing admins to manage the remote machine via Group Policy and the like, just as if it were physically connected to the network. The connection is always on, so users don't have to remember to manually launch a VPN client, and their applications, such as Microsoft Outlook and instant messaging, are always in communication with the corporate network.
[ Windows 7 is an InfoWorld 2010 Technology of the Year Award winner. Take a quick tour of all 21 winners | Don't miss InfoWorld's top 10 Windows tools for IT pros and the best free open source software for Windows. ]
From this standpoint, DirectAccess is fantastic. As the network admin, I love that I always have access to the remote device to make sure virus definitions and Windows updates are in place, and that my managed systems are always governed by my domain Group Policy. I also love that I don't have to maintain a bunch of VPN policies, and yet my users can still access e-mail and intranet sites without additional applications. Always on equals no user intervention.
Greater functionality means greater hardware and software requirements. The following list of DirectAccess requirements comes directly from Microsoft TechNet:
- One or more DirectAccess servers running Windows Server 2008 R2 with two network adapters: one connected directly to the Internet, and a second connected to the intranet.
- On the DirectAccess server, at least two consecutive, public IPv4 addresses assigned to the network adapter that's connected to the Internet.
- DirectAccess clients running Windows 7.
- At least one domain controller and DNS server running Windows Server 2008 SP2 or Windows Server 2008 R2.
- A public key infrastructure (PKI) to issue computer certificates, smart card certificates, and for NAP, health certificates.
- IPsec policies to specify protection for traffic.
- IPv6 transition technologies available for use on the DirectAccess server: ISATAP, Teredo, and 6to4.
- Optionally, a third-party NAT-PT device to provide access to IPv4-only resources for DirectAccess clients.
That is no small list of requirements. What it means is that to implement DirectAccess, I have to change, replace, or upgrade just about everything at my network edge. In addition to maintaining a public-facing firewall for Internet access, I have to add another direct-to-Internet server to act as the DirectAccess termination point. As servers are replaced and updated, I can see the enterprise eventually getting to the point where all of these things are already in place. But for most of us, this set of conditions can be a showstopper.
From a deployment standpoint, there are a couple of problems. First, DirectAccess runs over IPv6 and only connects to Windows Server 2008 R2 or Windows Server 2008 with SP2. The Internet at large is still IPv4. In order for DirectAccess to communicate over the Internet, bridging protocols such as 6to4 or Teredo have to be used to encapsulate IPv6 packets over any IPv4 medium or network device. These technologies have been around for years, so they in themselves are not scary. But when we thought we were simplifying our remote access by eliminating VPN management, we are now adding more protocol support to the mix.
[ DirectAccess is one of several "better together" features in Microsoft's new client and server. See "Windows 7 and Windows Server 2008 R2: Joined at the hip." ]
Also, because other releases of Windows server operating systems don't support dual-layer IP, DirectAccess can't natively talk to them. If your enterprise has a bank of Windows Server 2003 or older machines that won't be upgraded anytime soon, that data is in a silo that DirectAccess can't directly access.
There are ways to provide access to these "legacy" servers using a NAT-PT (Network Address translation/Protocol Translation) appliance, such as Microsoft's Forefront Unified Access Gateway. Using a NAT-PT gateway will allow DirectAccess clients to connect to IPv4-based servers and resources -- a good thing. But now we have added another system to the network in order to make it work.
DirectAccess is one of the new "better together" features of Windows 7 and Windows Server 2008 that I was most excited about. I still believe it is the future of secure, managed remote access for Windows users, but unfortunately, I don't see many small or medium-size networks doing a forklift upgrade just to enable this new feature. It's too hard to justify the expense and the effort when VPN and other remote access options are already paid for and installed.
Read more InfoWorld Test Center reviews of Microsoft technologies:
- InfoWorld preview: Visual Studio 2010 Beta 2 impresses
- First look: Microsoft SharePoint 2010 beta spreads the wealth
- Ten things you need to know about SharePoint Server 2010
- PC vs. Mac deathmatch: Snow Leopard beats Windows 7
- Windows 7 on multicore: How much faster?
- Office suites in the cloud: Microsoft Office Web Apps versus Google Docs and Zoho
- Microsoft's Hyper-V R2 is hot on VMware's heels
- First glimpse: Microsoft Office Web Apps
- Windows 7 RTM: The revenge of Windows Vista
- Office 2010 looks solid and smooth
- Windows XP Mode: The new DOS box
- First look: Exchange 2010 beta shines
This story, "Microsoft DirectAccess: The ugly truth," was originally published at InfoWorld.com. Follow the latest developments in Windows, mobile computing, and security at InfoWorld.com.