Updated: September 17, 2010
Applies To: Windows Server 2008 R2
DirectAccess overcomes the limitations of VPNs by automatically establishing a bi-directional connection from client computers to the corporate network. DirectAccess is built on a foundation of proven, standards-based technologies: Internet Protocol security (IPsec) and Internet Protocol version 6 (IPv6).
DirectAccess uses IPsec to authenticate both the computer and user, allowing IT to manage the computer before the user logs on. Optionally, you can require a smart card for user access to the intranet.
DirectAccess also leverages IPsec to provide encryption for communications across the Internet. You can use IPsec encryption methods such as Advanced Encryption Standard (AES) and Triple Data Encryption Standard (3DES).
Clients establish an IPsec tunnel for the IPv6 traffic to the DirectAccess server, which acts as a gateway to the intranet. Figure 1 shows a DirectAccess client connecting to a DirectAccess server across the public IPv4 Internet. Clients can connect even if they are behind a firewall.
Figure 1 DirectAccess clients access the intranet using IPv6 and IPsec
The DirectAccess client establishes two IPsec tunnels using IPsec tunnel mode and Encapsulating Security Payload (ESP):
An infrastructure tunnel using both a computer certificate and computer account credentials. This tunnel provides access to an intranet Domain Name System (DNS) server and domain controller, allowing the computer to download Group Policy objects and to request authentication on the user’s behalf.
An intranet tunnel using both a computer certificate and user account credentials. This tunnel authenticates the user and provides access to intranet resources and application servers. For example, this tunnel would need to be established before Microsoft Outlook could download e-mail from the intranet Microsoft Exchange Server.
After the tunnels to the DirectAccess server are established, the client can send traffic to the intranet through the tunnels. You can configure the DirectAccess server to control which applications remote users can run and which intranet resources they can access.
DirectAccess clients can connect to intranet resources by using two types of IPsec protection: end-to-end and end-to-edge.
With end-to-end protection, as shown in Figure 2, DirectAccess clients establish an IPsec session (shown in green) through the DirectAccess server to each application server to which they connect. This provides the highest level of security because you can configure access control on the DirectAccess server. However, this architecture requires that application servers run Windows Server 2008 or Windows Server 2008 R2 and use both IPv6 and IPsec.
Figure 2 End-to-end protection
For end-to-edge protection, as shown in Figure 3, DirectAccess clients establish an IPsec session to an IPsec gateway server (which by default is the same computer as the DirectAccess server). The IPsec gateway server then forwards unprotected traffic, shown in red, to application servers on the intranet. This architecture does not require IPsec on the intranet and works with any IPv6-capable application servers.
For information about connecting to IPv4-only application servers, read Using IPv6 later in this document.
Figure 3 End-to-edge protection
For the highest level of security, deploy IPv6 and IPsec throughout your organization, upgrade application servers to Windows Server 2008 or Windows Server 2008 R2, and use end-to-end protection. This allows authentication and, optionally, encryption from the DirectAccess client to the intranet resources. Alternatively, use end-to-edge protection when you want to avoid deploying both IPv6 and IPsec throughout your enterprise network. End-to-edge protection closely resembles VPNs and, as such, can be more straightforward to deploy.
|For either of these architectures, you can deploy multiple DirectAccess servers with a load balancer to meet your redundancy and scalability requirements.|