- Overview of DirectAccess
- The Engines That Drive DirectAccess
- Laying the Groundwork
The Engines That Drive DirectAccess
In order to establish secure connections to remote computers across the public, Internet DirectAccess relies on two things: IPsec and IPv6. Both IPsec and IPv6 are proven standards that provide a solid foundation for secure bi-directional connections between the network and remote systems.
Secure Connections with IPsec
IPsec is used by DirectAccess to authenticate both the user and the computer. It is the computer authentication via IPsec, which allows IT personnel to manage the computer even if the user is not logged on.
IPsec also provides the encryption to secure and protect communications between the computer and the DirectAccess server across the public Internet. The encryption method used can be configured to any method available in IPsec, including DES (Data Encryption Standard) and 3DES (Triple DES).
When DirectAccess makes a connection, there are actually two IPsec tunnels that are created. One uses the computer’s certificate to provide access to the DNS server and domain controller to enable the computer to authenticate and download Group Policy objects even when the user is not logged in. The second IPsec tunnel uses both the machine certificate and the user’s credentials to establish a secure connection for the user to access internal network resources and applications.
The DirectAccess server can be configured to control which internal servers and resources can be accessed on a per-user or per-group basis. IPsec enables IT admins to restrict access to the internal network and ensure that authorized access is done over an encrypted, secure connection.
Riding on IPv6
IPv6 is the backbone of DirectAccess. The globally routable IP addresses in IPv6 are required by DirectAccess to maintain the bi-directional connection between the DirectAccess server and the Windows 7 client.
Organizations that are already using IPv6 can implement DirectAccess without any additional overhead. DirectAccess will seamlessly extend the existing infrastructure to remote clients.
The good news is that you don’t have to fully implement IPv6 in order to use DirectAccess. I’m not saying there is anything wrong with IPv6[md]I would actually recommend moving toward IPv6 as time and budgets permit. However, fully implementing IPv6 is a fairly large undertaking, and such a requirement would prevent many organizations from even looking at DirectAccess.
Thankfully, Microsoft has considered that and provides workarounds for organizations that still rely on IPv4. You can use IPv6 translation technologies like 6to4 and Teredo to enable DirectAccess connectivity across the public Internet (which still uses IPv4 primarily). To provide access to intranet resources that don’t support IPv6 for DirectAccess clients, you can use a NAT-PT (Network Address Translation-Protocol Translation) device.