I’ve been working previously with DirectAccess when it first appeared in Windows Server 2008 and although it was a bit difficult to install and configure, I managed to get the grasps of this technology. I haven’t been able to work on a real production environment and I still haven’t seen large DirectAccess implementations. One reason for this may be the fact that it’s a relatively new technology and most enterprises prefer the use of good old VPN technologies. Also, I haven’t seen a scenario or an article with very large implementations of DirectAccess and I don’t know how reliable it is in such scenario. This technology has changed a bit with Windows Server 2012 and now it’s much easier to implement. In this article we will cover the basics on DirectAccess and try to understand how it all fits together, what are the requirements for it and what are the features supported with this technology. Note that I’m still in the learning phase with this Windows Server 2012 feature so I may not cover all aspects of it.
So what is DirectAccess and how does it work? Simply put, it’s an always-on remote access technology that uses IPv6 for client-server communication. Clients with DirectAccess are seamlessly connected to the company’s network as soon as the host receives Internet connection. Note that once you’ve activated this technology on a client computer, user intervention is no longer needed. You may already been acquainted with VPN technologies so let’s make a simple comparison between VPN and DirectAccess:
Always-on connection
With VPN technologies, a computer would have to use a VPN client software that would be used to connect to the network. With DirectAccess, a user does not have to worry about this aspect since the connection is made before the user logs on the machine.
DirectAccess works with all firewalls because of its communication protocols
Although it uses IPv6, it does support multiple IP transition technologies and can be used with IP-HTTPS protocol which is normally allowed through any firewall. We will talk later about the transition technologies available with DirectAccess.
It offers increased manageability over remote computers security
With DirectAccess, clients have access to network resources, but they can also be accessed from within the enterprise. This bi-directional connectivity offers a huge advantage over VPN connections because hosts can be accessed just as if they were connected from within the network. Imagine that Group Policy Objects and Software/Windows Updates can be downloaded to DirectAccess clients directly. For System Administrators, manageability over remote computers results in a much easier way to control network devices.
Seamless connection
Connection to the DirectAccess server is made completely transparent to the user so it may not even feel any difference between local or remote connections. With a fast Internet connection, a DirectAccess client would have the same user experience as if connected from within the enterprise network.
Supports end-to-end authentication and encryption with IPSec
This is a secure protocol that is used to provide both authentication and encryption. I’ve talked previously about IPsec NAP enforcement
, Authentication methods, IPSecPolicies and IPSec Connection Security Rules so you can check out those articles if you need more information about IPsec.
I’ve mentioned earlier that DirectAccess uses IPv6 to establish communications between the client and the server. The server acts like a “gateway” between DirectAccess clients and network resources. The client-server communication includes two phases, one in which the client uses IPv6 to establish a connection with the DirectAccess server and the second one in which the server connects with the requested network resources. If the remote client uses an IPv6 address, the connection is made directly with the server. As you may already know, IPv6 is not largely implemented over the public Internet so, in order to surpass this connectivity issue, IPv6 to IPv4 transition technologies are used with DirectAccess. Within the local network, IPv4 can be used if the DirectAccess server is acts as a NAT64/DNS64 device which translates IPv6 to IPv4 and vice-versa. I’ve described below the transition technologies that can be used with DirectAccess:
6to4 – this transition technology is used when the connection to the server does not support IPv6 by default. When this technology is used, the IPv6 packet is encapsulated within an IPv4 header to be able to traverse the path to the DirectAccess server. The payload portion of the IPv4 packet is set to protocol type 41. The underlying routers between the two communication points must support this transition mechanism and also allow the needed protocol type for the packets to traverse them.
Teredo – this mechanism uses IPv6 over IPv4 encapsulation in scenarios where DirectAccess server is behind a NAT device. It encapsulates IPv6 datagrams within IPv4. Routers must be able to support this protocol and allow the 3544 UDP port for the datagrams to flow.
IP-HTTPS – If none of the above methods are available when a client tries to establish a DirectAccess connection, the IP-HTTPS method is used. In Windows Server 2008 and Windows 7, IP-HTTPS uses SSL encryption that sits on top of the IPSec encryption, thus the overall DirectAccess speed is badly degraded. In Windows Server 2012, IP-HTTPS uses only encryption provided by IPSecc so the speed is close to Teredo connections.
DirectAccess communication process can be divided into several steps:
• The client will try to establish whether it’s located inside or outside the enterprise network. To achieve this result, the client will try to access the network location server which is located within the company’s network. If this server is available then the client will not try to establish a DirectAccess connection since it will consider it’s located within the network. The network location server is an internal web server that was configured for DirectAccess clients.
• By default, the client will try to access the server by using IPv6. If no such connection can be created, the tunnel over the IPv4 network will be created using the tunneling methods discussed earlier (6to4, Terdo or IP-HTTPS)
• The client and the server are authenticated using IPSec with Kerberos or Computer Certificates.
• The DirectAccess server will verify if the computer and the user are allowed to connect using DirectAccess by checking their group membership within Active Directory.
• DirectAccess clients will be verified for system health if a NAP (Network Access Protection) server is configured within the enterprise. If the client does not pass the health requirements, the NAP server will refuse the connection. Once the client finishes all the health checks successfully, it will be allowed to access network resources.
• Once the connection has been established successfully, the DirectAccess server will pass information between remote clients and network resources.
DirectAccess can be deployed in several ways depending on your network requirements and configuration. If the DirectAccess server is placed at the network edge and no other devices are in front of it, the server will act as a NAT64/DNS64 device which will basically translate between the IPv6-to-IPv4 traffic. The server will need to have a public IP configured on its frontend interface and a private IP address on the backend interface. It will also need to accept and forward Kerberos traffic for the DirectAccess clients to the Active Directory Domain Services. Only Windows Server 8 computers support Kerberos authentication so you are not able to use it in older editions.
If the DirectAccess server is hosted behind a NAT device, the machine will only require one internal IP configured on its interface since no connection is made directly to outside clients. With a NAT device placed in front of the DirectAccess server, the connection is made using IP-HTTPS. Note that DirectAccess behind NAT scenarios are supported only by Windows Server 2012 machines.
DirectAccess can now be deployed within a NLB (Network Load Balancing) cluster to provide increased redundancy for remote communications.
What’s new about Windows Server 2012 is that you can deploy DirectAccess on multiple locations. Windows 8 clients will receive a list with the available DirectAccess servers and will ping each of them determine the lowest latency. Once the proper server is selected, the client will try to establish a connection with the server. On Windows 7 you would configure only one address to point to the DirectAccess server so the clients will always try to connect to that particular machine. One requirement for such scenario is the fact that you need to implement a PKI infrastructure within the enterprise network to allow computers to authenticate using computer certificates.
The complexity of the DirectAccess deployment increases with the requirements of the network. Either if you need to deploy a NLB cluster for DirectAccess, configure a PKI infrastructure, configure NAP or other servers and services, the overall complexity of the infrastructure changes.
I hope I managed to cover the new features introduced with Windows Server 2012 and you’ve understood the principles behind DirectAccess. I want to write an article on how to install and configure DirectAccess on Windows Server 2012 so you can further enhance your knowledge in this technology. If you have enjoyed this article don’t forget to comment and share and stay tuned for the following posts.
