Microsoft advertises Windows 7’s DirectAccess as the great extender–a next-generation access technology designed to connect remote clients in the age of the vanishing network perimeter.
DirectAccess is designed to replace the trusty VPN with a secure, always-on connection that requires little or no user interaction. Indeed, DirectAccess represents one of the primary deliverables borne of Microsoft’s “better together” development strategy, which leverages the simultaneous release of the new Windows 7 client OS and the new Windows 2008 Server R2 server OS to add more features and deliver more value to customers who adopt both at the same time.
Microsoft’s New Efficiency cost-savings campaign (which was unveiled in September at an event in San Francisco) touts DirectAccess as one of the pillars of the better-together promise. While virtualization delivered with 2008 Server R2 via Hyper-V aims to deliver cost savings and operational efficiencies in the data center, DirectAccess’ pervasive connectivity purports to deliver efficiencies to the workstation–through easier access to data and applications for remote end users and easier ongoing management and troubleshooting for IT departments.
In eWEEK Labs’ tests on a brand-new domain running the latest and greatest version of Windows on both the server (Windows 2008 Enterprise Server R2) and the client (Windows 7 Enterprise/Ultimate), DirectAccess worked like a dream, providing instant-on, two-way connectivity. But questions about scalability, performance and management abound–and most of the answers rest upon another Microsoft gateway technology that is still beta, called Forefront Unified Access Gateway (UAG). Although based upon numerous industry standards, DirectAccess also needs a thorough vetting from the security industry before customers can be confident of privacy afforded by the solution.
For many, though, DirectAccess may be viewed as an unattainable pipe dream for at least the near to mid-range future: those whose network infrastructure servers haven’t yet progressed beyond Windows Server 2003; those who must slowly stage their endpoint migration to Windows 7 due to limited budget or IT resources and must therefore keep current access technologies active; those yet unfamiliar with the ins and outs of IPv6 networking; and those unwilling or unable to replace certain security implementations with Microsoft’s solutions to provide scale or backward compatibility.
Indeed, DirectAccess’ reach is limited: Workstations must be running Windows 7 Enterprise or Ultimate, while application servers must be running either Windows Server 2008 R2 or Windows Server 2008 SP2 (unless those additional gateway elements are added to the network).
DirectAccess leverages IPSec and IPv6 to provide the always-on connectivity. When connected to a network, the Windows 7 client performs a quick check to determine whether it connected to a protected network or elsewhere.
To see a slide show of Windows 7 DirectAccess, click here.
If the client determines it is connected remotely, the next time a DNS name query occurs, the client will check its NRPT (Name Resolution Policy Table)–a new feature of Windows 7 that helps map a protected network’s namespace to an internal DNS server, to determine whether the lookup request needs to be sent to the protected network’s internal DNS server. Non-matching requests are sent to DNS servers configured to the network adapter, keeping Internet-related traffic off the DirectAccess infrastructure.
Requests intended for the protected network are routed via IPv6 over the Internet to a DirectAccess server that bridges the Internet and the protected Intranet. As many networks on the Internet do not yet support IPv6, DirectAccess will automatically employ transition technologies such as 6to4 or Teredo to traverse IPv4 and NAT networks. For clients behind a Web proxy or a firewall with a restrictive outbound policy, DirectAccess can also fall back to IP-HTTPS Tunneling, cramming the already encrypted IPSec traffic inside another HTTPS-encrypted transmission.
For those, like me, whose protected network was also not entirely IPv6-ready, DirectAccess also utilizes ISATAP to provide connectivity on an IPv4 intranet.
With DirectAccess, IPSec encryption is enforced automatically from the endpoint to the DirectAccess server at the network edge. Administrators can, under some circumstances, also extend encryption all the way from the endpoint to the application server.
By default, authentication is performed on a machine basis, as administrators need to create security groups to identify the PCs eligible to use DirectAccess. As with encryption, authentication can terminate at the network edge or extend all the way to the application server. For more granular authentication, DirectAccess supports Smart Cards, although I did not test this configuration.
Network Up to Spec
For many administrators still reliant on Windows Server 2003, supporting DirectAccess connectivity will require some significant upgrades to core domain infrastructure elements.
To get started with DirectAccess, a network requires a single system running Windows Server 2008 R2 (on the DirectAccess server that serves to bridge traffic between the Intranet and the Internet). However, a domain controller/DNS server must be running either Windows Server 2008 with Service Pack 2 or Windows Server 2008 R2 because the DNS service needs to support AAAA records for IPv6 nodes.
Administrators also need to have a certificate server for the domain, as Windows 7-based clients assigned to a security group with permission to use DirectAccess must have the right certificate installed in their Certificate store. Administrators must also create a highly available network location server (an encrypted Web server) on the protected network; this server is used by clients to determine whether they are connected inside or outside the firewall.
How internally hosted application servers work with DirectAccess depends on what operating system they are running, as well. Application servers running Windows Server 2008 R2 or Windows Server 2008 support IPv6 with a dual IP layer architecture and will be easy to access via DirectAccess. But servers with a dual stack architecture, such as with Windows Server 2003, or ones that don’t support IPv6 at6 all cannot be accessed directly by remote DirectAccess clients.
To support legacy application servers, administrators will need to deploy at the network perimeter another device that supports NAT-PT to bridge the communications between IPv6 DirectAccess clients and IPv4 application servers. The next version of Microsoft’s gateway solution, now called Microsoft Forefront UAG 2010, will provide NAT-PT functionality. Forefront UAG 2010 is currently in beta, and Microsoft has not yet announced an availability date.
Microsoft officials informed me that some third-party networking partners plan to ship their own NAT-PT solutions. While Microsoft specifically mentioned F5 as one of those partners, F5 officials declined to comment for this story.
Network administrators will also find that they will need Forefront UAG 2010 if they intend to scale their DirectAccess implementations beyond a single DirectAccess server on the network perimeter. As currently designed, each DirectAccess server is an independent entity– to be configured and managed on its own. Forefront UAG must be added to the network to provide array management and load balancing in a DirectAccess scenario.
Unfortunately, Microsoft currently does not yet offer much guidance when it comes to right-sizing a DirectAccess implementation. According to Microsoft officials, the company is still gathering telemetry from early beta adopters to better understand show many DirectAccess servers are needed given a certain amount of load. However, they do anticipate there will be a wide variation according to how the network is used, as the number of remote clients connected at one time, the amount of data transmitted back and forth, and the traversal method used by clients at any given time will all combine to determine performance. Microsoft officials told me that on a DirectAccess server, processor utilization is more likely than memory to present a bottleneck.
As for the clients, DirectAccess is available only to endpoints running Windows 7 Enterprise or Ultimate. Further, machines must be joined to the domain because certificate services and Group Policy play important roles in establishing a remote connection.
DirectAccess will not work on Windows 7 Professional, even though that SKU has Domain Join capabilities, nor is it available for any other consumer editions of Windows 7.
DirectAccess also will not work with Windows Vista- or Windows XP-based systems, nor with systems running Windows versions older than XP. Administrators will need to continue to maintain existing remote access solutions to support these down-level clients or replace those technologies with identical services offered via Forefront UAG 2010. Microsoft officials leave the door open for DirectAccess support on other client operating systems down the road, although I’d guess that support would not extend beyond Vista.
Administrators also should not expect virtualized clients on a DirectAccess-capable Windows 7 machine (via XP Mode or other hypervisor) to be able to leverage DirectAccess connectivity–even if using NAT between the host and the VM. This is not a big deal when it comes to files or shares, as the Windows 7 host can copy files locally for consumption in an XP Mode application. But for anyone using XP Mode to access legacy Web applications that require an IE 6 browser on the protected network, DirectAccess will not provide the needed connectivity. A separate VPN solution for the virtualized instance itself may be required.
Making It Work
I tested DirectAccess on a VMWare VSphere 4-based virtual network, virtualizing four Windows Server 2008 R2 Enterprise-based servers and one Windows 7 Ultimate 32-bit client on a single Intel “Nehalem”-based server (an HP DL380 G6 outfitted with 12GB of RAM).Each virtual machine instance was provisioned with 2 GB of RAM. I also added a second client to the test bed running 32-bit Windows 7 Enterprise on a Dell XPS M1330 laptop. The latter system was configured to access the test domain over the Internet and through a NAT firewall.
The first virtualized server provided essential domain services, acting as domain controller, DHCP server, DNS server and certificate server. Server two was my application and network location server, running IIS 7.0. Server three was earmarked for DirectAccess, acting as a bridge between the Internet and my protected network. I configured the fourth server as an Internet-borne DNS server. The DNS server was not a required element, but it simplified testing on the live Internet.
DirectAccess policy is created directly on the DirectAccess server using the DAMgmt wizard. There is no administrator pack or toolkit to install on a workstation to manage DirectAccess, so administrators will need to log into the server directly or via Remote Desktop to update DirectAccess configuration policy or to view the management console.
The wizard first runs diagnostics to determine whether the server qualifies to run DirectAccess, checking if the system has at least two network interfaces–one on the intranet and the other to the Internet. If the system passes these checks, administrators walk through four distinct steps to complete setup: assigning security groups composed of computers eligible to use DirectAccess; assigning DirectAccess network interfaces and certificates on the DirectAccess server; identifying the network location server and DNS suffixes found on the protected network; and determining whether encryption and authentication can be terminated at the network edge (the DirectAccess server) or at the application server. With those steps complete, I could then save my DirectAccess configuration and apply it.
I experienced one hiccup during DirectAccess configuration. I had mistakenly applied the same DNS suffix to both network adapters on the DirectAccess server. This error would cause problems with ISATAP connections, making it impossible to complete some behind-the-scenes consistency checks that happen on the DirectAccess server when applying policy. Due to this error, I was unable to successfully apply policy. Unfortunately, the wizard warned only of an “unexplained error,” so I had to find the specific problem by looking though the log found in the c:WindowsTracing folder on the DirectAccess server.
Applying DirectAccess policy automatically creates Group Policy Objects in Active Directory with the necessary Computer Configuration settings. These settings are then applied to the Default Domain Policy with a security filter targeting the security groups allowed in step one of the wizard. As soon as those clients refresh their Group Policy (either at the regular interval or manually with a GPUpdate command), DirectAccess will be ready to go.
With DirectAccess enabled, I found that my two clients–one connected to the IPv4 live Internet and the other connected behind a NAT firewall–were both able to remotely access Websites and file shares located on the protected network without any user interaction required to initiate the connection. I was also able to successfully push out to the remote clients Group Policy preferences (a mapped drive) and a policy that removed the last logged-in user from the login screen.
As part of the client setup process, I needed to create firewall exception policies via Group Policy to permit inbound and outbound ICMPv4 and ICMPv6 Echo traffic. Organizations using third-party endpoint firewall solutions should take care to similarly permit such traffic on those firewall products while evaluating DirectAccess.
From the same DAMgmt snap-in, administrators can monitor their DirectAccess implementation. The snap-in displays real-time status and activity for all of the relevant DirectAccess components–Teredo, 6to4,IPHTTPS, ISATAP, DNS and IPSec–with links to tailored Performance Monitors for each.
Senior Analyst Andrew Garcia can be reached at agarcia@eweek.com.