Windows 7 Direct Access Review – VPN for the 21st Century?
It’s billed as a seamless connection to the corporate network from anywhere – but those not running Windows 7 Enterprise and Windows Server 2008 should stick with traditional VPs
Making It Work
I tested DirectAccess on a VMWare VSphere 4-based virtual network, virtualising 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 virtualised 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 Microsoft 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 set up: 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 log-set-up-in screen.
As part of the client set-up process, I needed to create firewall exception policies via Group Policy to permit inbound and outbound ICMPv4 and ICMPv6 Echo traffic. Organisations 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.
Conclusion
Windows 7 DirectAccess is being billed by Microsoft as the “great extender”, a next-generation access technology designed to connect remote clients in the age of the vanishing network perimeter. One of the first tangible products to be borne of Microsoft’s “better together” development strategy, which takes advantage of the simultaneous release of the new Windows 7 client OS and the new Windows 2008 Server R2 server OS, DirectAccess worked well in eWEEK Labs’ tests. However, current system and security requirements may make DirectAccess just a pipe dream for many organisations right now.
Andrew Garcia is senior analyst at eWeek
