Windows Server 2019 – DirectAccess

Install PHP on CentOS 8

Throughout our discussion about Always On VPN, I mentioned Microsoft DirectAccess a couple of times. DirectAccess is another form of automatic VPN-like connectivity, but it takes a different approach than that of Always On VPN. Where AOVPN simply uses expected, well-known VPN protocols and does some crafty magic to automatically launch those otherwise traditional VPN tunnels, DirectAccess tunnels are quite proprietary. Tunnels are protected by IPsec, and are essentially impenetrable and also impersonable. I find that security teams love the protections and complexity surrounding DA tunnels because it is a connection platform that attackers have no idea how to tamper with, or how to replicate.

In my experience, at this point in the game, Microsoft DirectAccess is the most common reason that administrators deploy the Remote Access role on a Windows Server. As stated, the easiest way to think about DirectAccess is to think of it as an automatic VPN. Similar to VPN, its purpose is to connect users’ computers to the corporate network when they are outside the office. Different from VPN, however, is the method that employees use in order to make this connection possible. DirectAccess is not a software component, it is a series of components that are already baked into the Windows operating system, working in tandem to provide completely seamless access for the user. What do I mean by seamless? In the same way that AOVPN connects without user interaction, there is nothing the user needs to do in order to make DirectAccess connect. It does that all by itself. As soon as the mobile computer receives an internet connection, whether that connection is a home Wi-Fi, public internet at a coffee shop, or a cell phone hotspot connection, DirectAccess tunnels automatically build themselves using whatever internet connection is available, without any user input.

Whether using Always On VPN or DirectAccess, when your computer connects automatically it saves you time and money. Time is saved because the user no longer has to launch a VPN connection. Money is saved because time equals money, but also because having an always-on connection means that patching, security policies, and the management of those remote computers always happens, even when the user is working remotely. You no longer have to wait for users to get back into the office or for them to choose to launch their manual VPN connection in order to push new settings and policies down to their computers; it all happens wherever they are, as long as they have internet access. Clearly, with the advent of two different remote access technologies that are both focused on automatic connectivity for remote users, Microsoft is clearing the way for a more productive workforce. The terms user-friendly and VPN have never gone hand-in-hand before, but in the latest versions of the Windows operating systems, that is exactly the goal.

DirectAccess has actually been around since the release of Windows Server 2008 R2, and yet I regularly bump into people who have never heard of it. In the early days, it was quite difficult to deploy and came with a lot of awkward requirements, but much has changed over the past few years and DirectAccess is now easier than ever to deploy, and more beneficial than ever to have running in your environment.

The truth about DirectAccess and IPv6

One of the awkward requirements I mentioned used to be the need for IPv6 inside your network. With the first version of DirectAccess, this was an unfortunate requirement. I say unfortunate because, even today, in the year 2019, almost nobody is running IPv6 inside their corporate networks, let alone years ago when this technology was releaseda lot of admins didn’t even know what IPv6 was. Fortunately, the requirement for IPv6 inside your networks is no more. I repeat, just in case anybody wasn’t paying attention or is reading old, outdated TechNet documentsyou do not need IPv6 to use DirectAccess! I have seen too many cases where DirectAccess was considered by a company, but the project was tossed aside because reading on TechNet made them believe that IPv6 was a requirement, and they discarded DirectAccess as something that wouldn’t work. You absolutely do not have to be running IPv6 in your network to make DirectAccess function, but it is important to understand how DirectAccess uses IPv6, because you will start to encounter it once your deployment gets underway.

When I am sitting at home, working on my company laptop, DirectAccess connects me to the corporate network. My internal network at work has absolutely no IPv6 running inside of it; we are a completely IPv4 network at the moment. This is true for most companies today. However, when I open Command Prompt and ping one of my servers from my DirectAccess laptop, this is what I seeapologies for the sanitized output of the screenshot:

What in the world is that? Looks like IPv6 to me. This is where IPv6 comes into play with DirectAccess. All of the traffic that moves over the internet part of the connection, between my laptop and the DirectAccess server that is sitting in my data center, is IPv6 traffic. My internal network is IPv4, and my DirectAccess server only has IPv4 addresses on it, and yet my DirectAccess tunnel is carrying my traffic using IPv6. This is the core of how DirectAccess works, and cannot be changed. Your DA laptop sends IPsec-encrypted IPv6 packets over the internet to the DA server, and when the DA server receives those packets, it has the capability to spin them down into IPv4 in order to send them to the destination server inside the corporate network. For example, when I open my Outlook and it tries to connect to my Exchange server, my Outlook packets flow over the DirectAccess tunnel as IPv6. Once these packets hit my DirectAccess server, that DA server reaches out to internal DNS to figure out whether my Exchange server is IPv4 or IPv6. If you are actually running IPv6 inside the network and the Exchange server is available via IPv6, the DA server will simply send the IPv6 packets along to the Exchange server. Connection complete! If, on the other hand, you are running IPv4 inside your network, the DA server will only see a single host record in DNS, meaning that the Exchange server is IPv4only. The DirectAccess server will then manipulate the IPv6 packet, changing it down into IPv4, and then send it on its way to the Exchange server. The two technologies that handle this manipulation of packets are DNS64 and NAT64, which you have probably seen in some of the documentation if you have read anything about DirectAccess online. The purposes of these technologies is to change the incoming IPv6 packet stream into IPv4 for networks where it is required, which is pretty much every network at the moment, and spin the return traffic from IPv4 back up into IPv6 so that it can make its way back to the DirectAccess client computer over the IPv6-based IPsec tunnel that is connecting the DA client to the DA server over the internet.

It is important to understand that DirectAccess uses IPv6 in this capacity, because any security policies that you might have in place that squash IPv6 on the client computers by default will stop DirectAccess from working properly in your environment. You will have to reverse these policies in order to allow the clients to push out IPv6 packets and get their traffic across the internet. However, it is also very important to understand that you do not need any semblance of IPv6 running inside the corporate network to make this work, as the DirectAccess server can spin all of the traffic down into IPv4 before it hits that internal network, and most DA implementations that are active today run in exactly this fashion.

Prerequisites for DirectAccess

DirectAccess has a lot of moving parts, and there are many different ways in which you can set it up. However, not all of these ways are good ideas. So, in this section, we are going to discuss some of the big decisions that you will have to make when designing your own DirectAccess environment.


The first big requirement is that the systems involved with DirectAccess need to be domain-joined. Your DA server, or servers, all need to be joined to your domain, and all of the client computers that you want to be DA-connected need to be joined to a domain as well. Domain membership is required for authentication purposes, and also because the DirectAccess client settings that need to be applied to mobile computers come down to these computers via Group Policy. I always like to point out this requirement early in the planning process, because it means that users who purchase their own laptops at a retail location are typically not going to be able to utilize DirectAccessunless you are somehow okay with adding home computers to your domainand so DA is really a technology that is designed for managing and connecting your corporate assets that you can join to the domain. It is also important to understand this requirement from a security perspective, since your DirectAccess server or servers will typically be facing the edge of your network. It is common for the external NIC on a DA server to sit inside a DMZ, but they also have to be domain-joined, which may not be something you are used to doing with systems in a perimeter network.

Supported client operating systems

Not all Windows client operating systems contain the components that are necessary to make a DirectAccess connection work. Enterprise does, which covers the majority of larger businesses who own Microsoft operating systems, but that certainly does not include everyone. I still see many small businesses using professional or even home SKUs on their client machines, and these versions do not include DirectAccess components. The following is a list of the operating systems that do support DirectAccess. During your planning, you will need to make sure that your mobile computers are running one of these:

  • Windows 10 Enterprise
  • Windows 10 Education
  • Windows 8.0 or 8.1 Enterprise
  • Windows 7 Enterprise
  • Windows 7 Ultimate

DirectAccess servers get one or two NICs

One big question that needs to be answered even prior to installing the Remote Access role on your new server is: How many NICs are needed on this server? There are two supported methods for implementing DirectAccess.

Single NIC Mode

Your DirectAccess server can be installed with only a single NIC. In this case, you would typically plug that network connection directly into your internal network so that it had access to all of the internal resources that the client computers are going to need to contact during the user’s DA sessions. In order to get traffic from the internet to your DirectAccess server, you would need to establish a Network Address Translation (NAT) from a public IP address into whatever internal IP address you have assigned to the DA server. Many network security administrators do not like this method, because it means creating a NAT that brings traffic straight into the corporate network without flowing through any kind of DMZ.

I can also tell you from experience that the single NIC mode does not always work properly. It does a fine job of spinning up a quick test lab or proof of concept, but I have seen too many problems in the field with people trying to run production DirectAccess environments on a single NIC. The ability to use only a single network card is something that was added to DirectAccess in more recent versions, so it was not originally designed to run like this. Therefore, I strongly recommend that, for your production DA install, you do it the right way and go with…

Dual NICs

Here, we have two network cards in the DirectAccess server. The internal NIC typically gets plugged right into the corporate network, and the external NIC’s physical placement can vary depending on the organization. We will discuss the pros and cons of where to place the external NIC immediately after this section of the chapter. The edge mode with two NICs is the way that DirectAccess works best. As you may recall from earlier in the book, implementing a Windows Server with multiple NICs means that you will be multihoming this server, and you need to set up the network settings accordingly. With a Remote Access Server, your external NIC is always the one that receives the default gateway settings, so you need to make sure you follow this rule and do not configure a default gateway on the internal NIC. On the other hand, you do want to configure DNS server addresses into the internal NIC properties, but you do not want to configure DNS servers for the external NIC. Since this server is multihomed, you will likely need to create some route statements in order to add your corporate subnets into the Windows routing table of this server before it is able to successfully send and receive traffic. The only networks that would not need to accommodate adding static routes would be small networks, where all of your internal devices are on a single subnet. If this is the case, then you have no need to input static routes. But most corporate networks span multiple subnets, and in this case you should refer back to Chapter 5, Networking with Windows Server 2019, where we discussed multihoming and how to build out those route statements.

More than two NICs

Nope, don’t go there. If you are familiar with configuring routers or firewalls, you know that you have the potential to install many different NICs on a server and plug them all into different subnets. While there are many reasons why splitting up network access like this on a Remote Access Server might be beneficial, it won’t work how you want it to. The DirectAccess configuration itself is only capable of managing two different network interfaces.

As you can see in the following screenshot, in the course of the setup wizards, you will have to define one NIC as External, and the other as Internal. Any more NICs that exist in that server will not be used by DirectAccess, unfortunately. Maybe this is something that will change in future versions!

To NAT or not to NAT?

Now that you have decided to roll with two NICs in your DirectAccess server, where do we plug in the external NIC? There are two common places that this external network interface can be connected to, but depending on which you choose, the outcome of your DirectAccess environment can be vastly different. Before we talk about the actual placement of the NIC, I would like to define a couple of protocols that are important to understand, because they pertain very much to answering this question about NIC placement. When your DirectAccess laptop makes a connection to the DirectAccess server, it will do so using one of the three IPv6 transition tunneling protocols. These protocols are 6to4, Teredo, and IP-HTTPS. When the DA client connects its DA tunnels, it will automatically choose which of these protocols is best to use, depending on the users current internet connection. All three protocols perform the same function for a DirectAccess connection: their job is to take the IPv6 packet stream coming out of the laptop, and encapsulate it inside IPv4 so that the traffic can make its way successfully across the IPv4 internet. When the packets get to the DirectAccess server, they are decapped so that the DA server can process these IPv6 packets.


DA clients will only attempt to connect using 6to4 when a remote laptop has a true public internet IP address. This hardly ever happens these days, with the shortage of available internet IPv4 addresses, and so 6to4 is typically not used by any DirectAccess client computers. In fact, it can present its own set of challenges when users are connecting with cell phone cards in their laptops, and so it is common practice to disable the 6to4 adapter on client computers as a DirectAccess best-practice setting.


When DA clients are connected to the internet using a private IP address, such as behind a home router or a public Wi-Fi router, they will attempt to connect using the Teredo protocol. Teredo uses a UDP stream to encapsulate DA packets, and so, as long as the user’s internet connection allows outbound UDP 3544, Teredo will generally connect and is the transition protocol of choice for that DirectAccess connection.


If Teredo fails to connect, such as in the case where the user is sitting in a network that blocks outbound UDP, then the DirectAccess connection will fall back to using IP-HTTPS, pronounced IP over HTTPS. This protocol encapsulates the IPv6 packets inside IPv4 headers, but then wraps them up inside an HTTP header and encrypts them with TLS/SSL, before sending the packet out over the internet. This effectively makes the DirectAccess connection an SSL stream, just like when you browse an HTTPS website.

Installing on the true edge – on the internet

When you plug your DirectAccess server’s external NIC directly into the internet, you grant yourself the ability to put true public IP addresses on that NIC. In doing this, you enable all three of the preceding transition tunneling protocols, so that DirectAccess client computers can choose between them for the best form of connectivity. When installing via the true edge method, you would put not only one, but two public IP addresses on that external NIC. Make sure that the public IP addresses are concurrent as this is a requirement for Teredo. When your DirectAccess server has two concurrent, public IP addresses assigned to the external NIC, it will enable the Teredo protocol to be available for connections.

The NIC does not necessarily have to be plugged directly into the internet for this to work. Depending on your firewall capabilities, you might have the option to establish a Bridged DMZ where no NATing is taking place. You need to check with your firewall vendor to find out whether or not that is an option for your organization. In this scenario, you are still able to configure true public IP addresses on the external NIC, but the traffic flows through a firewall first, in order to protect and manage that traffic.
Installing behind a NAT

It is much more common for the networking team to want to place the external NIC of your DirectAccess server behind a firewall, inside a DMZ. This typically means creating a NAT in order to bring this traffic into the server. While this is entirely possible and better protects the DirectAccess server itself from the internet, it does come with a big downside. When you install a DA server behind a NAT, Teredo no longer works. In fact, the DirectAccess configuration wizards will recognize when you have a private IP address listed on the external NIC and will not even turn on Teredo.

When Teredo is not available, all of your DirectAccess clients will connect using IP-HTTPS. So why does it even matter if Teredo is unavailable? Because it is a more efficient protocol than IP-HTTPS. When Teredo tunnels packets, it simply encapsulates IPv6 inside IPv4. The DirectAccess traffic stream is already, and always, IPsec-encrypted, so there is no need for the Teredo tunnel to do any additional encryption. On the other hand, when IP-HTTPS tunnels packets, it takes the already-encrypted IPsec traffic stream and encrypts it a second time using SSL. This means all of the packets that come and go are subject to double encryption, which increases processing and CPU cycles, and  makes for a slower connection. It also creates additional hardware load on the DirectAccess server itself, because it is handling twice the amount of encryption processing.

This is a particularly apparent problem when you are running Windows 7 on client computers, as double encryption processing will cause a noticeably slower connection for users. DirectAccess still works fine, but if you sit a Teredo-connected laptop next to an IP-HTTPS-connected laptop, you will notice the speed difference between the two.

Thankfully, in Windows 8 and Windows 10, there have been some countermeasures added to help with this speed discrepancy. These newer client operating systems are now smart enough that they can negotiate the SSL part of the IP-HTTPS tunnel by using the NULL encryption algorithm, meaning that IP-HTTPS is not doing a second encryption and IP-HTTPS performance is now on a par with Teredo.

However, this only works for the newer client operating systems (Win7 will always double encrypt with IP-HTTPS), and it still doesn’t work in some cases. For example, when you enable your DirectAccess server to also provide VPN connectivity, or if you choose to employ a One-Time-Password (OTP) system alongside DirectAccess, then the NULL algorithm will be disabled because it is a security risk in these situations, and so even your Windows 8 and Windows 10 computers will perform double encryption when they connect via IP-HTTPS. You can see where it would be beneficial to have Teredo enabled and available so that any computers that can connect via Teredo will do so.

To summarize, you can certainly install your DirectAccess server’s external NIC behind a NAT, but be aware that all DA client computers will connect using the IP-HTTPS protocol, and it is important to understand the potential side-effect of implementing in this way.

Network Location Server

This major component in a DirectAccess infrastructure is something that does not even exist on the DA server itself, or at least it shouldn’t if you are setting things up properly. Network Location Server (NLS) is simply a website that runs inside the corporate network. This website does not need to be available for access over the internet; in fact, it should not be. NLS is used as part of the inside/outside detection mechanism on DirectAccess client computers, similar to the way that Trusted Network Detection works for Always On VPN. Every time a DA client gets a network connection, it starts looking for the NLS website. If it can see the site, then it knows that you are inside the corporate network, and DirectAccess is not required, so it turns itself off. However, if your NLS website cannot be contacted, it means you are outside the corporate network, and DirectAccess components will start turning themselves on.

This prerequisite is easily met; all you need to do is spin up a VM and install IIS on it to host this new website, or you can even add a new website to an existing web server in your network. There are only two things to watch out for when setting up your NLS website. The first is that it must be an HTTPS site, and so it requires an SSL certificate. We will discuss the certificates used in DA, including this one, in the next section of this chapter. In addition to making sure that the website is accessible via HTTPS, you must also make sure that the DNS name you are using in order to contact this website is unique. You want to do this because, whatever name you choose for the NLS website, that name will not be resolvable when client computers are outside the corporate network. This is by design, because you obviously don’t want your DA clients to be able to successfully contact the NLS website when they are working remotely, as that would then disable their DirectAccess connection.

The reason I bring up the unique DNS name is that I often see new DirectAccess admins utilizing an existing internal website as their NLS website. For example, if you have https://intranet running as a SharePoint site, you could simply use this in the DA config as the NLS server definition. However, once you set it up this way, you will quickly realize that nobody who is working remotely can access the https://intranet website. This is by design, because the DA environment now considers your intranet website to be the NLS server, and you cannot resolve it while you are mobile. The solution to this problem? Make sure that you choose a new DNS name to use for this NLS website. Something like https://nls.contoso.local is appropriate.

The most important part about the Network Location Server that I want to stress is that you should absolutely implement this website on a server in your network that is not the DirectAccess server itself. When you are running through the DA config wizards, you will see on the screen where we define NLS that it is recommended to deploy NLS on a remote web server, but it also gives you the option to self-host the NLS website right on the DirectAccess server itself. Don’t do it! There are many things that can go wrong when you co-host NLS on the DA server. Running NLS on your DA server also limits your DirectAccess potential in the future, because some of the advanced DA configurations require you to remove NLS from the DA server anyway, so you might as well do it correctly the first time you set it up. Changing your NLS website after you are running DA in production can be very tricky, and often goes sideways. I have helped numerous companies move their NLS website after realizing that they cannot co-host NLS on the DA server if and when they want to add a second DirectAccess server for growth or redundancy. The following a screenshot of the section in the DA config wizard where you choose the location of NLS. Make sure you stick with the top box!

Certificates used with DirectAccess

Aside from reading and misunderstanding about how DirectAccess uses IPv6, here is the next biggest turn off for administrators who are interested in giving DirectAccess a try. Once you start to read about how DA works, you will quickly come to realize that certificates are required in a few different places. While VPNs generally also require the use of certificates, it is admittedly difficult to distinguish which certificates need to go where when you are wading through Microsoft Docs, so this section clears up any confusion that exists about DirectAccess certificates. It really is not very complicated, once you know what does and does not need to be done.

The core prerequisite is that you have a Windows CA server somewhere in your network. The stature of your PKI implementation is not that important to DirectAccess. We simply need the ability to issue certificates to our DA server and clients. There are only three places that certificates are used in DirectAccess, and two of them are SSL certificates.

SSL certificate on the NLS web server

As mentioned previously, your NLS website needs to be running HTTPS. This means that you will require an SSL certificate to be installed on the server that is hosting your NLS website. Assuming that you have an internal CA server, this certificate can be easily acquired from that internal CA, so there are no costs associated with this certificate. You do not need to purchase one from a public CA, because this certificate is only going to be accessed and verified from your domain-joined machines, the DirectAccess clients. Since domain-joined computers automatically trust the CA servers in your network, this certificate can simply be issued from your internal CA, and it will do exactly what we need it to do for the purposes of DirectAccess.

SSL certificate on the DirectAccess server

An SSL certificate is also required to be installed on the DirectAccess server itself, but this one should be purchased from your public certification authority. This certificate will be used to validate IP-HTTPS traffic streams coming in from the client computers, because that is SSL traffic and so we need an SSL certificate to validate it. Since the IP-HTTPS listener is facing the public internet, it is definitely recommended that you use a certificate from a public CA, rather than trying to use a cert from your internal PKI.

If your company already has a wildcard SSL certificate, use it here to save costs!
Machine certificates on the DA server and all DA clients

The last and most complicated part of the DirectAccess certificate puzzle is machine certificates. Once you know what is required though, it’s really not hard at all. We simply require that a Computer or Machine certificate be installed on the DirectAccess server, as well as each of the DirectAccess client machines. This machine certificate is used as part of the authentication process for IPsec tunnels. It is a big part of the way in which DirectAccess verifies that you really are who you say you are when your computer makes that DA connection happen.

The best way to go about issuing these machine certificates is to log into your CA server and create a new certificate template that is duplicated from the built-in computer template. When setting up your new certificate template, just make sure that it meets the following criteria:

  • The Common Name (subject) of the certificate should match the FQDN of the computer
  • The Subject Alternative Name (SAN) of the certificate should equal the DNS Name of the computer
  • The certificate should serve the intended purposes (Enhanced Key Usage) of both Client Authentication and Server Authentication

I should note here, though I don’t really want to, that issuing these certificates is not absolutely necessary to make DirectAccess work. If you are running Windows 8 or higher on the client side, then it is possible to get DA working without machine certificates. Computers in the network can instead utilize something called Kerberos Proxy for their computer authentication when the IPsec tunnels are being built, but I highly recommend sticking with certificates. Using certificates as part of the authentication process makes the connection more stable and more secure. Additionally, as with the placement of NLS, if you want to perform any advanced functions with DirectAccess, such as load balancing or multisite, or even if you simply want to make some Windows 7 computers connect through DA, then you will be required to issue certificates anyway. So, just stick with the best-practice in the first place and issue these certificates before you even get started with testing DirectAccess.

Do not use the Getting Started Wizard (GSW)!

After making the necessary design decisions and implementing the prerequisites we have talked about so far, it is finally time to install the Remote Access role on your new DirectAccess server! After you have finished installing the role, similarly to many roles in Windows Server 2019, you will be shown a message informing you that additional configuration is required in order to use this role. In fact, if you follow the yellow exclamation mark inside Server Manager, the only option that you are presented with is Open the Getting Started Wizard. Ugh! This is not what you want to click on:

Your home for DirectAccess configurations is the Remote Access Management Console, which is available from inside the Tools menu of Server Manager now that our Remote Access role has been installed. Go ahead and launch that, and now we are presented with a choice:

Do not click on Run the Getting Started Wizard! The GSW is a shortcut method for implementing DirectAccess, designed only for getting DA up and running as quickly as possible, perhaps for a quick proof of concept. Under no circumstances should you trust the GSW for your production DA environment, because in an effort to make configuration quick and easy, many configuration decisions are made for you that are not best-practices.

You want to make sure and click on Run the Remote Access Setup Wizard instead when you are first prompted in the console; this will invoke the full set of DirectAccess configuration screens. DA setup consists of a series of four different steps, each containing a handful of screens that you will navigate through to choose your appropriate configuration options. There is a good amount of detail on these screens, as to what each one of them means and what your options are, so don’t be afraid to dive in and set this up in the proper way. If you have already configured DirectAccess and used the Getting Started Wizard, DA may be working for you but it will not be running as efficiently or securely as it could be. The following is a quick list of the reasons why the Getting Started Wizard is not in your best interests. These are the things that it does that go directly against a best-practice DirectAccess install, with accompanying peanut gallery commentary from yours truly:

  • GSW co-hosts the NLS website on the DA serverbad
  • GSW applies the DA client GPO settings to Domain Computersthis is a terrible idea
  • GSW utilizes self-signed certificatesa “Security 101 level” no-no
  • GSW automatically disables Teredoinefficient
  • GSW does not walk you through any of the advanced options for DirectAccess, probably because the way that it sets everything up invalidates your ability to even use the advanced functionslame

Comments are closed.