Direct Access feature was introduced with Windows Server 2008 R2 and Windows 7 Client computers. Direct Access overcomes the limitations of VPNs by automatically establishing a bi-directional connection from client computers to the corporate network so users never have to think about connecting to the enterprise network and IT administrators can manage remote computers outside the office, even when the computers are not connected to the VPN.
In this blog post series I’ll cover Direct Access Feature in Windows Server 2012 and design a complex Windows Server 2012 lab to implement Direct Access feature. In my next post I will outline the lab requirements and design considerations. With 3rd post we will be able to install direct access feature and then cover details and troubleshooting steps.
In this first post, let’s look at the Direct Access feature on Windows 7 /2008 R2 and compare with Windows Server 2012.
Direct Access feature in Windows Server 2008 R2 had following goals for organizations;
- Direct Access enhances the productivity of mobile workers by connecting their computers automatically and seamlessly to their intranet any time Internet access is available
- With Direct Access, IT staff can manage mobile computers by updating Group Policy settings and distributing software updates any time the mobile computer has Internet connectivity
- Direct Access separates intranet from Internet traffic.
- When an application on a Direct Access client attempts to resolve a name, it first compares the name with the rules in the NRPT (Name Resolution Policy Table )
If there are no matches, the Direct Access client uses Internet DNS servers to resolve the name
From connectivity perspective;
Direct Access clients create two tunnels to the Direct Access server. The first tunnel, the infrastructure tunnel, provides access to intranet Domain Name System (DNS) servers, Active Directory Domain Services (AD DS) domain controllers, and other infrastructure and management servers. The second tunnel, the intranet tunnel, provides access to intranet resources such as Web sites, file shares, and other application servers.
Direct Access feature relies on IPv6 network infrastructure. For those who have not a native IPv6 network infrastructure, ISATAP can be used to make intranet servers and applications reachable by tunneling IPv6 traffic over your IPv4-only intranet. Computers running Windows 7 or Windows Server 2008 R2 support ISATAP host functionality.
To configure ISATAP you have to put ISATAP host ( A ) record in your DNS and all machines can then resolve this name to configure their ISATAP adapters.
By default, Windows 2003 SP2 and above DNS servers do not answer queries for the names WPAD and ISATAP. That means you will need to enable queries for the ISATAP name on these servers.
Here is a simple diagram that shows how direct access feature works on Windows Server 2008 R2;
Notice that the Direct Access client establishes two IPsec tunnels:
IPsec Encapsulating Security Payload (ESP) tunnel with IP-TLS (Transport Layer Security) encryption using the machine certificate. This tunnel provides access to the DNS server and domain controller, allowing the computer to download Group Policy objects and to request authentication on the user’s behalf.
IPsec ESP tunnel with IP-TLS encryption using both the machine certificate and user credentials. This tunnel authenticates the user and provides access to internal resources and application servers. For example, this tunnel would need to be established before Microsoft Outlook could download e-mail from the internal Microsoft Exchange Server.
Also Direct Access servers running Windows Server 2008 R2 requires two network adapters, one that is connected directly to the Internet and one that is connected to the intranet. Also this server should have two consecutive and public IPv4 addresses.
One another major challenges for IT administrators to deploy Direct Access in Windows Server 2008 R2 was the need of a PKI environment to issue computer certificates.
And if you have not Forefront UAG, an optional NAT64 device is a requirement to provide access to IPv4-only resources for Direct Access clients.
As you noticed with above complex requirements, implementing Direct Access feature was not a easy task for IT Departments.
Direct Access feature has been designed again with Windows Server 2012 and now addresses better connectivity with better manageability.
In brief, Windows Server 2012 includes following improvements over Windows Server 2008 Direct Access and RRAS features;
- Direct Access and RRAS coexistence
In Windows Server 2008 R2, combining RRAS and Direct Access might cause some conflicts for the remote client connectivity. Since Direct Access relies on IPv6 and RRAS implements IKEv2 IPSEC, this results in Direct Access traffic being blocked if RRAS is installed and VPN access is deployed with IKEv2. Now in Window Server 2012, Direct Access and RRAS are combined within a new unified server role.
- Simplified Direct Access management for small and medium organization administrators
One of the most important simplicity in Windows Server 2012 is removal of the need for a full PKI deployment. As you know that one major deployment blocker for Windows 7 Direct Access is the requirement of a Public Key Infrastructure (PKI) for server and client certificate-based authentication. Now in Windows Server 2012, client authentication requests are sent to a Kerberos proxy service running on the DA server. Then Kerberos proxy sends requests to domain controllers on behalf of the client.
And also new getting started wizard which will be covered on next posts allows for an automated setup in a few simple steps.
- Built-in NAT64 and DNS64 support for accessing IPv4-only resources
In Windows Server 2008 R2, UAG might be used for NAT64 and DNS64 translations;
Now Windows Server 2012 Direct Access server includes native support for NAT64 and DNS64 translations that convert IPv6 communication from the client to IPv4 internal resources.
- Support for Direct Access server behind a NAT device
The Teredo IPv6 transition technology is used typically when the client system is assigned a private IP address (and for modern Windows clients, will be used when the client is assigned a public IP address and 6to4 isn’t available). A Windows Server 2008 R2 Direct Access server requires two network interfaces with two consecutive public IPv4 addresses assigned to the external interface. This is required so that it can act as a Teredo server.
Now in Windows Server 2012 direct access server can be deployed behind a NAT device with support for only one single network interface and removes the public IPv4 address prerequisite.
One of the most important enhancement is the chance to design a fully high available direct access solution. Now in Windows Server 2012, Direct Access has built-in Windows Network Load Balancing support to achieve high availability and scalability. And this configuration can be configured within new deployment wizard interface with a couple of clicks.
- Support for multiple domains
Now you can configure Direct access server to allow remote clients located in different domains.
- Support for OTP (token based authentication)
For organizations that needs a security level with OTP vendor solutions such as RSA SecurID, Windows Server 2012 supports two factor authentication with smart cards or OTP token based solutions.
- Automated support for force tunneling
http://blogs.technet.com/b/tomshinder/archive/2011/04/19/url-and-antivirus-filtering-for-directaccess-clients.aspx
By default only specific network traffic (defined by DNS records) will go through direct access tunnel. But if you want to route all traffic from client computer to the intranet resources over Direct Access tunnel, you can configure it with Force Tunneling.
Force tunneling is a feature in Windows Server 2008 R2 that forces all network traffic to be routed over Direct Access IPSEC tunnel. But it requires manual steps to enable via group policy. In Windows Server 2012, direct access has integrated force tunneling with the setup wizard.
Now in Windows Server 2012, you can configure multiple Direct Access entry points across remote locations. This makes sure the client locates the closest IP-HTTPS server, Teredo Server, DNS Server etc. regardless of their physical location.
- Windows PowerShell support
Direct Access in Windows Server 2008 R2 lacks a complete scripting and command line interface for configuration options. Windows Server 2012 provides full Windows PowerShell support for the setup, configuration, management, monitoring and troubleshooting of the Remote Access Server Role.
- User and server health monitoring
The Monitoring Dashboard shows a summary of remote client connectivity status for the following items. The information is generated from the relevant Performance Monitor counters and accounting data.
- Total number of active remote clients connected – includes both Direct Access and VPN remote clients
- Total number of active Direct Access clients connected – only the total number of clients connected using Direct Access
- Total number of active VPN clients connected – only the total number of clients connected using VPN
- Total unique users connected – includes both Direct Access and VPN users, based on the active connections
- Total number of cumulative sessions – the total number of connections serviced by the Remote Access Server since the last server restart
- Maximum number of remote clients connected – the maximum concurrent remote users connected to the Remote Access Server since the last server restart
- Total data transferred – the total inbound and outbound traffic from the Remote Access Server for both Direct Access and VPN since the last server restart
With the above enhancements, it’s now much easier to implement this great remote access feature in your organization.
In second blog post of this series, I will discuss to design a Windows Server 2012 Direct Access lab that will guide us for next posts.
![Mohamed Marzouk [MSFT]}](http://i1.social.s-msft.com/profile/u/avatar.jpg?displayname=mohamed+marzouk+%5bmsft%5d&size=large){kind=avatar}
