With a trend toward flexible working arrangements and the requirement for simple but secure access to corporate resources from any location, DirectAccess — new in Windows Server 2008 R2 and Windows 7 — improves on traditional dial-up and virtual private network (VPN) remote access solutions. Providing mobile workers with a clientless, always-on connection to the corporate intranet, DirectAccess also gives sysadmins remote access to notebooks, even when users aren’t logged in, and supports integration with Active Directory and Network Access Policy servers.
Conventional VPN protocols such as Layer Two Tunneling Protocol (L2TP) and Point-to-Point Tunneling Protocol (PPTP) don’t always work well with network address translation (NAT) routers and cannot traverse firewalls if outbound traffic is restricted to HTTP. Clientless Secure Sockets Layer (SSL) VPNs solve some of these problems, but access to the corporate network via a web browser brings its own security concerns. Neither L2TP, PPTP or Microsoft’s Secure Socket Tunneling Protocol (SSTP) for client-based SSL VPNs offer end-to-end authentication and encryption.
DirectAccess is based on the principle that all Internet-connected machines can have a globally unique IPv6 address and therefore communicate with each other without the need for intermediary devices such as NAT routers. Secure connections between devices are managed using IPsec and digital certificates. (If you need a primer on IPv6 or the related transition technologies, see the article “What You Need to Know About IPv6”.)
The use of native TCP/IP technologies IPv6 and IPsec allows DirectAccess to provide notebooks with an always-on connection to the corporate intranet whenever an Internet connection is present. Not only does this alleviate the need for remote users to manually dial up to the intranet, but it gives sysadmins greater access to remote devices so that they can be easily managed and updated.
DirectAccess clients take advantage of various IPv6 transition technologies to connect to the intranet if the remote user’s ISP doesn’t support IPv6 addresses. For home users behind a NAT router, DirectAccess defaults to the Teredo tunneling protocol for IPv6 connectivity. If a user connects to the Internet using their mobile phone, the DirectAccess client uses 6to4, a transition mechanism that lets IPv6 packets run over an IPv4 network.
Failing that, DirectAccess clients always use IP over HTTPS (IP-HTTPS) — a new protocol developed by Microsoft specifically for DirectAccess. Though less efficient than the other transition technologies, IP-HTTPS guarantees a globally routable IPv6 address can be assigned to the client even when a remote user’s outbound Internet access is restricted to HTTP.
If your network routers and switches don’t support IPv6, DirectAccess uses the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) to provide IPv6 connectivity on IPv4 intranets.
DirectAccess clients route intranet traffic via the DirectAccess server and all other outbound packets directly to the Internet without the need for a split tunnel. Windows Firewall can also be configured to route all outbound traffic via the DirectAccess server if required.
Clients use a Name Resolution Policy Table (NRPT), which contains a list of fully qualified domain names (FQDNs) for intranet servers. When a DNS lookup using a FQDN is made on a DirectAccess client, the NRPT is checked, and if the server’s name is on the list, the query is forwarded to a DNS server on the intranet.
A Full Access topology connects DirectAccess clients to a server at the network edge, where two IPsec tunnels (infrastructure and intranet) are terminated. The infrastructure tunnel connects DirectAccess clients to Active Directory, DNS and other infrastructure servers. The intranet tunnel connects clients to all resources that support IPv6. Once the IPsec tunnels are terminated at the DirectAccess server, traffic on the intranet flows without any network-layer protection.
The Selected Server model restricts DirectAccess clients to accessing specific application servers on the intranet. The infrastructure and intranet tunnels are terminated by the server at the network edge, but in this topology, traffic flowing from the DirectAccess server to the selected application servers on the intranet is protected by IPsec, using computer credentials for authentication and Encapsulating Security Payload (ESP-NULL) for data integrity.
Using the End-to-End topology, IPsec traffic passes through the DirectAccess server directly to infrastructure and application servers (endpoints). Intranet traffic is protected by IPsec, using computer credentials for authentication and ESP for encryption and data integrity. This is the only model that provides full end-to-end encryption. If all servers are running Windows Server 2008 (or later) with IPv6 enabled, this is the recommended topology.
DirectAccess servers must be running Windows Server 2008 R2 (Standard or Enterprise) and have two network interface cards (NICs): one connected to the Internet and the other to the corporate intranet. The Internet-connected NIC must be assigned two consecutive public IPv4 addresses.
Before you can deploy DirectAccess on your network, you need to have the following infrastructure in place:
DirectAccess clients determine whether they are connected to the intranet by locating an NLS, which is a web server that allows incoming connections over SSL. If a DirectAccess client is able to communicate with an NLS, it understands that it’s located on the corporate intranet, and DirectAccess is disabled. If an NLS is unavailable, or the DirectAccess client is unable to check the Certificate Revocation List (CRL) for the Certification Authority (CA) that issued the NLS website certificate, DirectAccess is enabled. Network location servers must be highly available to ensure a reliable experience for end users.
IP-HTTPS is the default IPv6 transition technology developed by Microsoft for DirectAccess that clients fall back on if Teredo or 6to4 don’t work. IP-HTTPS is hosted on a web server and requires a website certificate. DirectAccess clients must be able to check the Certificate Revocation List (CRL) of the Certification Authority (CA) that issued the IP-HTTPS website certificate. Smaller enterprises may find it more convenient to use a public CA for the IP-HTTPS website certificate to ensure high availability for CRL access.