Common DirectAccess Implementation Mistakes

Here at Iron Networks we deploy Microsoft DirectAccess on a near daily basis for companies all over the world. We’ve gained a tremendous amount of experience doing this, and much of what we’ve learned over the years is baked in to our DirectAccess hardware appliance platform. Although you may be deploying DirectAccess for the first time, leveraging Iron Networks' solutions and services can ensure that you don’t make mistakes that others are prone to. Although our appliance platform is pre-configured to include configuration and implementation best practices, and is pre-hardened to provide the smallest attack surface and highest availability and reliability, there are a number of infrastructure requirements for supporting DirectAccess where we see common issues. They are:

Incorrect Client Operating System – DirectAccess requires Windows 8/8.1 Enterprise or Windows 7 Enterprise/Ultimate. No other operating system SKUs are supported. If you are using Windows 8 Professional, Windows 7 Home Premium, Windows Vista, or Windows XP, you’re out of luck. Only the Enterprise or Ultimate versions of Windows 7/8 are supported as DirectAccess clients.

Certificate Issues – DirectAccess leverages digital certificates for a variety of different purposes. First, machine certificates are required for IPsec authentication and encryption and need to be deployed to the DirectAccess server and clients. Windows Server 2012 can use self-signed certificates, but this is not recommended. If you are planning to support Windows 7 clients, then a working Public Key Infrastructure (PKI) is required to issue and manage certificates for DirectAccess servers and clients. A common issue we see here is using the incorrect certificate template to issue these certificates. The computer certificate template on a Microsoft Certificate Authority (CA) should be used as a template for DirectAccess certificates. Additionally an SSL certificate is required to be installed on the DirectAccess server for IP-HTTPS communication. IP-HTTPS is an IPv6 transition protocol used to transport IPv6 packets over the public IPv4 Internet. DirectAccess traffic is encapsulated in HTTP and authenticated/encrypted using SSL/TLS. Common issues here are incorrect subject name and missing Certificate Revocation List (CRL). Issuing this certificate can be done using your internal PKI as long as the CRL is publicly available. Best practices dictate that a public CA be used to issue this certificate. Finally, an SSL certificate is required to be installed on the Network Location Server (NLS). The NLS is used by DirectAccess clients to determine their network location, either internal or external. The NLS must have an SSL certificate installed and the subject name must match. This certificate can be issued by your internal PKI. For all certificates, they must of course be trusted. Be sure to verify certificate trust before implementation and update any root certificates as required.

Network Interface Configuration – The most common (and recommended) network configuration for DirectAccess is dual-homed, either edge facing (connected directly to the public Internet) or behind a border router or edge firewall performing Network Address Translation (NAT). Configuring a Windows server with two network interfaces is not as straightforward as it seems. With two network interfaces, there can only be one default gateway and it should be assigned to the external interface. In addition, DNS servers should not be configured on the external interface. The internal interface will have an IP address and subnet mask, but no default gateway. This interface should be configured to use your internal DNS servers. Static routes should be configured for any remote internal subnets. For more information, click here.

NLS Configuration – As I mentioned earlier, the NLS is used by DirectAccess clients to determine their network location. If the DirectAccess client can establish a connection to the NLS, it will believe that it is on the internal network and the DirectAccess tunnels will not be established. If a connection to the NLS cannot be established, the DirectAccess client believes it is outside the corporate network and will attempt to establish DirectAccess connectivity. It is for this reason that the NLS should not be resolvable in public DNS and should not be reachable externally. If it is, DirectAccess clients will always think they are inside the corporate network, and DirectAccess will never be established. Also, it is extremely important that the NLS be highly available. If the NLS server is offline or unreachable for any reason, DirectAccess clients that are on the internal network will suddenly think they are outside the corporate network and attempt to establish DirectAccess connectivity. This will fail, leaving DirectAccess clients unable to connect to any internal resources until the NLS is once again available. The NLS is simple to deploy, as it is nothing more than a web server with an SSL certificate installed. However, it is strongly recommended that you implement at least two NLS servers in a cluster, using either Network Load Balancing (NLB) or an external hardware load balancer. It is also recommended that these servers be dedicated to the NLS role, as DirectAccess clients will not be able to connect to them when they are outside the corporate network.

ISATAP – The Intrasite Automatic Tunnel Addressing Protocol (ISATAP) is used to enable the “manage out” scenario for DirectAccess. When ISTAP is enabled, an IPv4-only client on the corporate intranet can initiate outbound communication to connected DirectAccess clients. The DirectAccess server is automatically configured as an ISATAP router. However, to leverage ISATAP internally you must create a DNS record called ISTAP that resolves to the IPv4 address of the internal network interface of the DirectAccess server. Unfortunately, configuring ISTAP with DNS in this fashion enables ISTAP globally for all clients, with is potentially problematic. We recommend that ISTAP be deployed in a targeted manner to only those clients that require this connectivity. For more information about ISATAP deployment recommendations, click here.

If you’re planning to deploy DirectAccess, pay careful attention to these common issues. For the best experience, consider deploying DirectAccess on the Iron Networks advanced hardware appliance platform. You’ll get years of experience built in, and you can deploy with confidence knowing that your solution is configured according to the highest standards and best practices. DirectAccess has a lot of moving parts, and the infrastructure requirements often trip people up. Iron Networks also offers implementation services, so don’t hesitate to engage us to ensure the best chance of success for your DirectAccess deployment.