Many IT professionals mistakenly believe that DirectAccess is just another VPN solution. While there are some similarities between these technologies, both in terms of the underlying technology and function, there are some significant differences between the two. If you’re comparing DirectAccess to VPN, here are some essential points to consider.
VPN
Virtual Private Networking (VPN) has been around for ages. VPN is a mature, well understood technology that has been widely deployed, and today remains the de facto standard for providing secure remote access. VPN has broad client support, on both traditional computing platforms and mobile operating systems. VPNs today include support for modern protocols and integrate with numerous multifactor authentication platforms.
VPN Challenges
There are some serious drawbacks to implementing traditional client-based VPN. VPN connections are user initiated and therefore optional. It is up to the user to decide if and when they connect to the corporate network. Many VPNs require additional software to work, which must be deployed and maintained. Establishing connections is potentially problematic too, as some VPN protocols aren’t firewall friendly and don’t work in many locations.
From a security perspective, because anyone can attempt a connection to the VPN from any client, strong authentication becomes an essential requirement. Integrating multifactor authentication makes the implementation more complex and difficult to support. It often requires additional hardware, licensing, and support costs.
VPNs can be costly to implement and support. They typically require expensive proprietary hardware and dedicated management skill sets. Many VPN solutions also have additional licensing costs associated with them. Scaling a VPN solution requires additional investments in hardware devices, adding to the overall cost of the solution.
DirectAccess
DirectAccess is a relative newcomer to the world of secure remote access. First introduced with Windows Server 2008 R2, DirectAccess differs fundamentally from VPN by virtue of its seamless and transparent, always-on connection. DirectAccess connections are established by the machine, not the user. They are secure and authenticated, and are established automatically whenever the DirectAccess client has an active Internet connection. DirectAccess connections are also bidirectional, which is an important distinction. The ability to “manage out” to remote connected DirectAccess clients enables compelling new uses cases for IT administrators.
Addressing VPN Pain Points with DirectAccess
DirectAccess connections are inherently more secure than VPN. Unlike VPN, DirectAccess clients must be joined to the domain and, in most configurations, they must also have a certificate issued by the organization’s private, internal Public Key Infrastructure (PKI). This essentially serves as a type of multifactor authentication for the connecting device, resulting in a much higher level of assurance for remote connections. DirectAccess can also support integration with many existing multifactor authentication providers to provide strong authentication for the user, if desired.
DirectAccess is very firewall friendly and works anywhere the user has an active Internet connection. It requires no additional software to be installed, and the seamless and transparent nature of DirectAccess makes it much easier to use than VPN. All of this improves end user productivity and reduces associated management overhead for the solution.
DirectAccess is a more cost-effective alternative to VPN. DirectAccess can be deployed on existing infrastructure (physical or virtual) and does not require proprietary hardware. This makes it much easier and far less expensive to add additional capacity, if required. DirectAccess can also be managed using existing systems management tools and Windows administration skills and does not have any per-user licensing requirements, which results in additional cost savings over VPN.
DirectAccess Limitations and Drawbacks
DirectAccess is not a comprehensive remote access solution. It is designed for managed (domain-joined) Windows clients only. In addition, DirectAccess clients must be provisioned with the Enterprise edition SKU. Also, there are a few cases in which applications may not be compatible with DirectAccess. In addition, there is no support for DirectAccess on non-managed Windows machines, non-Enterprise SKUs, or any devices using non-Windows operating systems, so a VPN might still be required.
DirectAccess or VPN?
You might be asking yourself, “DirectAccess or VPN?” Why not both? After all, DirectAccess and VPN aren’t mutually exclusive. They are, in fact, quite complimentary. DirectAccess can be used to provide secure remote access and enhanced management for Windows laptops managed by IT, while VPN can be deployed for non-managed devices. While you may not be able to entirely eliminate VPN with DirectAccess, it will certainly allow you to decrease the number of existing VPN licenses and reduce your investment in proprietary hardware, management tools, and dedicated administrators, all of which translates in to reduced capital investment and operational costs.
Always On VPN
To extend DirectAccess-like functionality to non-managed Windows 10 clients, Microsoft recently introduced Always On VPN. Always On VPN provides the same seamless and transparent remote access that DirectAccess does, although under the hood it uses traditional client-based VPN protocols such as IKEv2 and SSTP. You can learn more about Windows 10 Always On VPN here.
Note: Windows 10 Always On VPN training classes now forming. Details here.
Summary
DirectAccess is not simply another VPN solution. While it does provide secure remote corporate network connectivity, it does so more securely and more cost effectively than traditional VPN does. DirectAccess is unrivaled in its security and ease of use, dramatically improving end user productivity and reducing associated infrastructure and support costs. DirectAccess can be deployed on current physical and virtual infrastructure, and can be managed using existing Windows systems management tools and skill sets.
Additional Information
If you’d like to learn more about how DirectAccess and Windows 10 Always On VPN can benefit your organization, or you would like some assistance with a DirectAccess or Always On VPN proof of concept implementation, consider a consulting services engagement today. I’m here to help plan, design, implement, and support DirectAccess and Always On VPN and ensure the best chance of success for your deployment.
Have a question about DirectAccess or Always On VPN? Fill out the form below and I’ll get in touch with you.
Philip B.
/ February 12, 2016Hi Richard, your blogs have been incredibly helpful in getting DirectAccess up and running for us. I understand that it is much more secure than VPN in many ways, but I think it really needs another level of user authentication like you mention with multifactor. My problem is that I’ve been having a difficult time finding a good multifactor authentication provider that has small upfront costs and works with DirectAccess. We recently started using Duo as a multifactor authentication provider for our Cisco AnyConnect users, and that works great, but they don’t support DirectAccess. Can you possibly recommend some multifactor authentication providers that work well with DirectAccess?
Thanks
Richard M. Hicks
/ February 12, 2016I don’t necessarily agree that additional user authentication is essential. Strong user authentication is critically important with traditional client-based VPN because a VPN connection can be made from any device. DirectAccess clients actually serve as a type of two-factor authentication. Because the device is trusted (has a certificate and AD computer account) it essentially serves as the “something you have” part of the multifactor authentication, making the additional strong user authentication requirement much less important.
That said, there’s certainly nothing wrong with requiring additional user authentication. However, it does break the seamless and transparent nature of DirectAccess, which are key advantages over traditional client-based VPN.
As for multifactor authentication providers that work with DirectAccess, both the Entrust and Gemalto solutions are popular and work well. Any OTP solution that serves as a RADIUS server should work though, really. The only limiting factor is that DirectAccess does not support challenge/response authentication solutions like Azure Mulitfactor Authentication.
mfekry86
/ February 25, 2016Hi Richard i need your help to answer my Q , i have DA server implemented in DMZ network with one Single adapter and he need to publish the DA server on Microsoft WAP
is that supported to publish on WAP
Richard M. Hicks
/ February 25, 2016I don’t know if it is formally supported, but it should work as long as you don’t require preauthentication.
Dave
/ March 9, 2016Requiring Enterprise SKU kills this for 75% of your customers. Unfortunate.
Richard M. Hicks
/ March 11, 2016Agreed. Microsoft has done a great job of making DirectAccess more accessible by creating the simplified deployment model, but by not supporting Windows 8 or Windows 10 Professional it really doesn’t help. :/
Bjoern Voss
/ April 21, 2016Only problem I see with Direct Access (DA) vs. VPN is that sometime after clients have been Windows Patched they loses their Direct Access Icon. (Restart does not help)
Most customers also have VPN and just connect and get their Group policies updated.
But some users only have DA as primary remote connection. If DA does not work, then they will have to bring their PC to corporate network to get their GPO settings refreshed.
I have not seen any fixes/workaround on this. (Script or other)
Richard M. Hicks
/ April 23, 2016That’s definitely unusual, and not something I’ve ever seen so I suspect there’s some other underlying issue that is causing this. DirectAccess is great, but for many organizations some form of client-based VPN will still be required. When DirectAccess doesn’t want to cooperate, it can sure come in handy. 🙂
Sundeep Kesavadas
/ May 11, 2016What factors are critical for making applications compatible with DirectAccess?
Richard M. Hicks
/ May 13, 2016Any application will work as long as it doesn’t make calls directly to IP addresses. As long as the application uses hostnames, single label or fully-qualified, it should work fine. Also, the application should not use protocols that embed IPv4 addresses in them, such as FTP and SIP.
Lesego Fortune
/ June 9, 2016Hi Richard
What do you have to consider when you want to do a transition from VPN to DirectAccess??
Richard M. Hicks
/ June 11, 2016Nothing, really. They aren’t mutually exclusive. You can deploy both without issue. 🙂
skymeat1
/ September 18, 2016I like the idea of DA and a traditional VPN working side by side. Trouble is DA seems to hijack all DNS requests while it’s trying to connect, so the traditional VPN fails.
Richard M. Hicks
/ September 19, 2016That can happen if the DirectAccess connection is trying, but failing, to connect. You can resolve this conflict by adding the public name of your VPN server to the NRPT as an exclusion. Let me know if you need assistance doing that. Happy to help. 🙂
Prasanna
/ October 29, 2016I can connect my corporate servers only through FQDN, not through IP address, How to make it work with IP address
Richard M. Hicks
/ November 2, 2016DirectAccess doesn’t work that way. You must use names (or IPv6 addresses) to connect to corporate resources.
Prasanna
/ October 29, 2016How to prevent DA automatically getting connected? I want to be connected only when i’m required like traditional VPN
Richard M. Hicks
/ November 2, 2016DirectAccess doesn’t work that way. If you need VPN-like connectivity, it is best to use VPN in that case. 🙂
John
/ December 21, 2016Does DirectAccess behave like split VPN or will all of the traffic (including web browsing and video) from branch offices have to funnel through the main office’s internet connection?
Richard M. Hicks
/ December 22, 2016In its default configuration, DirectAccess uses split tunneling. Only traffic destined for the internal corporate network will be sent over the DirectAccess connection. All other traffic (for example web browsing Internet traffic) will be sent directly to the Internet. You can, however, enable force tunneling. It isn’t generally recommended because the user experience is so poor, but it is supported. 🙂
Bellari Raja Returns
/ December 21, 2016Sir, you say that the client machine must be a member of our domain. but i can acess a shared folder from the domain remotely while the client machine is unmembered to the domain, even though i can acess if the client machine is also a member of the domain. what is the reason for that. please answer me.
Richard M. Hicks
/ December 22, 2016To establish a DirectAccess connection a client must be joined to the domain, yes. If the DirectAccess client’s computer account is disabled or deleted in Active Directory, it should not be able to connect. However, if it was connected before this change was made, it is possible that the underlying IPsec connections are still established. Forcibly terminating the IPsec connections would then be required, as outlined here: https://directaccess.richardhicks.com/2013/06/11/disconnecting-directaccess-clients-on-windows-server-2012/.
Paul
/ February 9, 2017Hi Richard, I am looking at implementing DirectAccess but have a concern about how it works from a networking point of view.
I have part of my network that I only allow certain users to access. This is controlled by a firewall ACL’s with the IP address of the users device.
It is my understanding that when users connect over DirectAccess all users source address will be the same from the firewalls view (i.e. the IP of the DA server) as DA doesn’t provide them with unique internal IPs.
Is this correct? Is there a way use DHCP to provide them with an individual internal address?
Richard M. Hicks
/ February 13, 2017That’s correct, assuming you are using IPv4 exclusively on your internal network. In this scenario, all traffic from remote connected DirectAccess clients will appear to come from the internal IPv4 address of the DirectAccess server. Any ACLs enforced between the DirectAccess server and the internal network will apply to all connected users. DirectAccess uses IPv6 and SLAAC. It is not possible to use IPv4 or IPv6 with DHCP.
kalaivanan
/ October 9, 2017Hello Richard,
May i know the workflow of RAS and why its faster than the Direct access server.While pinging from RAS server, its result are faster that the DA server.
Richard M. Hicks
/ October 16, 2017The connection overhead for RAS is much lower than it is for DirectAccess. The addition of IPv6 in IPv4 encapsulation required for DirectAccess is the culprit. All things being equal, VPN performance will always be better than DirectAccess.
kalaivanan
/ October 12, 2017Hi Richard,
While accessing particular application Through RAS, its accessing fast than the DA connection, may i know what is the major difference between RAS and DA?Why the connection for DA is slower than RAS?
Richard M. Hicks
/ October 16, 2017See my earlier reply. It has to do with protocol overhead for the connection. 🙂
Tajinder singh
/ November 16, 2018How does direct access be used to improve management of remote workers and its used by organisations to provide technical support to remote systems?
Richard M. Hicks
/ November 17, 2018It enables this by providing always-on corporate network connectivity. With persistent access, the client computers are continuously updated using group policy, WSUS, SCCM, or other management platforms. The DirectAccess connection is bi-directional, which allows administrators to initiate connections outbound to remote clients. This enables important management scenarios such as Windows Remote Assistance or Remote Desktop, SCCM remote control, PowerShell remoting, and many others.