Microsoft DirectAccess: The ugly truth
The seamless secure remote access built into Windows 7 and Windows Server 2008 R2 is fantastic, if you don't mind a forklift upgrade or complexity and work-arounds
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.