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:\Windows\Tracing 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.