Windows 7 and Windows 2008 R2 operating systems have a new feature named Direct Access that lets users access corporate network resources such as file shares and applications or the company intranet website without using Virtual Private Network (VPN).
There are some limitations using Virtual Private Networking. With VPNs, the user on the client computer must explicitly launch the connection to the server. The server then authenticates the user and authorizes access to the internal network resources. Depending on the server policies, this can take some time. If the client loses its Internet connection for any reason, the user must manually reestablish the VPN connection.
Direct Access, on the other hand uses connections that the client computer establishes automatically and that are always on. As soon as the client computer connects to the Internet, it begins the Direct Access connection process. It also benefits you as network administrator. Direct Access connections are bidirectional, and Windows 7 clients establish their computer connections before the user even logs on to the system. This means that administrators can get access to the client computer at any time so they can apply Group Policy settings, deploy patches, or perform other upgrade and maintenance tasks.
When a client connects to a Direct Access server, it creates two separate IPSec tunnels. The first connection uses a computer certificate and enables the client to access the Domain Name System (DNS) server and the Active Directory Domain Services (AD DS) domain controller on the intranet. With this access, the client can download Group Policy objects and initiate the user authentication process. The client then uses the second connection to authenticate the user account and access the intranet resources and application servers.
The access model you choose for your DirectAccess deployment specifies where on your
intranet the IPSec encryption will terminate and how the traffic to and from the client will
proceed once it passes through the DirectAccess server.
The access model you choose for your deployment also specifies how the DirectAccess server
will forward the client traffic to the resources on the intranet. Three access models are available.
End-to-end: Here DirectAccess clients establish transport mode ESP connections that go through the DirectAccess server and all the way to the individual
application servers on the intranet. This is the best solution if you are worried about the security, but it requires all of the application servers to support IPSec connections using IPv6.
This means that the application servers must all be running Windows Server 2008 or Windows Server 2008 R2 and be configured to use both IPv6 and IPSec.
End-to-edge: Here DirectAccess clients establish tunnel mode connections to an IPSec gateway server, typically the computer functioning as the Direct Access server. The IPSec gateway server then forwards the client traffic, now protected by IPSec, to the application servers on the intranet. This model keeps IPSec traffic off of the intranet and enables you to use application servers that run Windows Server 2003, or any other operating system that supports IPv6.
Modified end-to-edge: This model is identical to the end-to-edge model, except that it uses an additional IPSec tunnel that authenticates clients at the application server. Client traffic is therefore encrypted only as far as the IPSec gateway server, but it is authenticated all the way to the application server. The need for this additional authentication also makes it easier for administrators to limit client access to specific application servers. To use this model, application servers must be running Windows Server 2008 R2.
All these model descriptions assume that the intranet applications and resources are all capable of supporting IPv6 connections to the DirectAccess server. If not so the intranet needs some kind of IPv4-to-IPv6 transition mechanism, such as ISATAP or a NAT-PT device.
On the client:
Joined to an Active Directory domain
Running Windows 7 Ultimate or Enterprise edition or Windows Server 2008 R2.Clients not joined to an Active Directory domain or clients running Windows Vista or earlier or Windows Server 2008 or earlier are not supported.
On the server:
Joined to an Active Directory domain
Running Windows Server 2008 R2
Has at least two physical network adapters installed
Has at least two consecutive static, public IPv4 addresses that are externally resolvable through the Internet DNS
Cannot be behind a NAT.
There are also some requirements for the infrastructure:
Active Directory: At least one Active Directory domain must be deployed. Workgroups are not supported
Group Policy: Group policy is recommended for centralized administration and deployment of DirectAccess client settings. The DirectAccess Setup wizard creates a set of Group Policy objects and settings for DirectAccess clients, the DirectAccess server, and management servers.
DNS/domain controller: At least one domain controller and DNS server must be running Windows Server 2008 SP2 or later or Windows Server 2008 R2.
Public key infrastructure (PKI): Required to issue computer certificates for authentication, and optionally, health certificates when using Network Access Protection.(NAP)
The SSL certificate for IP-HTTPS installed on the DirectAccess server must have a CRL distribution point that is reachable from the Internet,and the Subject field must contain either a public IPv4 address assigned to the DirectAccess server or an FQDN,that can be resolved to a public IPv4 address assigned to the DirectAccess server using the Internet DNS.
The SSL certificate for the network location server must have a CRL distribution point that is reachable from the intranet,and the Subject field must contain either an intranet IPv4 address assigned to the network location server,or an FQDN that can be resolved to an intranet IPv4 address assigned to the network location server using the intranet DNS.
IPsec policies DirectAccess utilizes IPsec policies configured and administered as part of Windows Firewall with Advanced Security.
Allow ICMPv6 Echo Request traffic You must create separate inbound and outbound rules that allow ICMPv6 Echo Request messages. The inbound rule is required to allow ICMPv6 Echo Request messages and is scoped to all profiles. The outbound rule to allow ICMPv6 Echo Request messages, scoped to all profiles, is
recommended as a best practice and is only required if Outbound block is turned on. DirectAccess clients that use Teredo for IPv6 connectivity to the intranet use ICMPv6 message when establishing communication.
IPv6 and transition technologies IPv6 and the transition technologies ISATAP, Teredo, and 6to4 must be available for use on the DirectAccess server.
Direct Access uses IPSec to authenticate both users and computers. Clients establish an IPSec tunnel for the IPv6 traffic to the direct access server which then acts as gateway to the Intranet.
The direct access client running Windows 7 detects that it is connected to the network The client attempts to connect to an Intranet website that an administrator specifies during the configuration of direct access. If the website is available the client determines that it is already connected to the Intranet and if so the connection process stops.
If not the client connects to the direct access server using IPv6 and IPSec. If there is a firewall that prevents the client to connect using 6to4 or Teredo the client automatically attempts to use the IP-HTTPS Protocol. When the client and server are establishing the IPSec connection they authenticate each other using computer certificates for authentication. By validating AD group membership the direct access server verifies that the computer and user are authorized to connect using direct access. If NAP is enabled and configured for health validation the client obtains a health certificate from the health registration authority located on the Internet prior to the connection to the direct access server. The server begins forwarding traffic from the client to the intranet resources.