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;
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;
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.
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.
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.
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.
Now you can configure Direct access server to allow remote clients located in different domains.
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.
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.
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.
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.
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.
Very good information for me. Thanks for the post. And you all get more such kinds of info in this site.
Can you blog on how to setup Direct Access in 2012 that does not require an Edge server. or if there is documentation point me to it.
You can setup a single DA Server for different scenarios, for instance a server that have direct internet access and intranet access. Or a server that resides in DMZ (behind NAT). These scenarios are supported.
What do you mean exactly "DA Server that does not require an Edge Server"?
Can you discuss how to remove ISATAP on an existing UAG setup and move to DNS64 and NAT64. We are not ready to move to IPV6 and would like to move to Server 2012 when available but DA is vital to our business. Also, MS does not recommend ISATAP but can it still be used and what are the issues of using it with Server 2012 DA deployment?
Is Part 3 now posted somewhere?
So it appears that if you are already doing DA with UAG boxes you are not gaining much. You could if you want take the boxes off of the internet and NAT them. In doing so you lose the ablity to do 6to4 and teredo. Do you think it is worth the effort to move from a UAG deployment to a Server 2012?
My kind of licensing Windows Server 2012 is per processor. If I use DirectAccess to 100 users need to make additional payments ie acquire any license.
I appreciate your response
Sorry for the delay. Part 3 will be available in couple of days!
Does DirectAccess client in 2012 still create two tunnels to the DirectAccess server? One IPsec Encapsulating Security Payload (ESP) tunnel with IP-TLS (Transport Layer Security) encryption using the machine certificate and one IPsec ESP tunnel with IP-TLS encryption using both the machine certificate and user credentials. From the way I read your article, that is how it worked in Windows 2008 R2 however you haven't mentioned if there are any changes to the way this works in 2012.
Nice post Anil, thanks for sharing.
Take a look at my site over at http://heineborn.com
<quote>Part 3 will be available in couple of days!</quote> Is it available yet???
How is this called in UNIX derivatives ?
where part 2?please share