Microsoft DirectAccess

In this article we will learn about a very famous security product of Microsoft known as Microsoft Direct Access. It is a product built over an old security concept of Virtual Private Network (VPN), but with completely different technology. So let's dig deeper into this.

What is DirectAccess?

DirectAccess, also known as Unified Remote Access, is a VPN-like technology that provides intranet connectivity to client computers when they are connected to the Internet. Unlike many traditional VPN connections, which must be initiated and terminated by explicit user action, DirectAccess connections are designed to connect automatically as soon as the computer connects to the Internet.

DirectAccess uses IPv6 to reach the intranet resource. Worried that your environment is not IPv6 ready yet? Don't worry, DirectAccess encapsulates the IPv6 traffic over IPv4 to be able to reach the intranet over the Internet and all the traffic is encrypted using IPSec. The IPSec mode, whether tunnel or transport mode, can be used. Clients and servers are connected using standards like 6to4, Teredo tunneling, or IP-HTTPS, depending on the mode in which they are operating.

DirectAccess vs VPN

With getting the basic definition of DirectAccess, one must be wondering how it is different from the already in use VPN technology. The below points may be able to settle all your doubts:

• The endpoint clients are always managed. Client just needs for the host on which it is installed to be connected to Internet, and the management server will be able to keep the client updated with the latest policies.
• Since the endpoint client is always managed by the corporate management server, the threat base is always of low profile as compared to the VPN client, which may or may not connect to the centralized management server for a long time, leading to outdated policies and security base.
• DirectAccess works on the concept of creating two tunnels, where the first server is the basis of establishing the second tunnel. The first tunnel is used to access the management configuration and configuration infrastructure through the second tunnel. General network access isn't available until the user logs on and creates the infrastructure tunnel.
• The DirectAccess client is always serviceable. If IT needs to connect to the DirectAccess client to perform custom software configuration or troubleshoot an issue on the DirectAccess client, there is no problem getting access, because the connection between the DirectAccess client and IT management stations is bidirectional.

Deployment Scenarios

DirectAccess first comes with a 2008 flavor, and in 2008 DirectAccess had some limitations in deployment scenarios. Requirements for deployment are:

• 2 sequential public IPv4 IPs on the external interface
• 2 NICs: a public NIC and a private NIC

Come 2012, DirectAccess has increased the deployment scenarios as listed below:

Behind a NAT - Now DirectAccess servers can be placed behind an edge device that does NAT translation. In this scenario, the DirectAccess Server does not have a public IP.

Single NIC – This deployment supports NAT deployment.

IP-HTTPS – As with 2008, it requires 2 IPv4 addresses. Now with 2012, DirectAccess eliminates the requirement for 2 sequential IPv4 addresses.

NLB Scenario – IT can support up to 8 nodes when using Windows NLB and up to 32 nodes when using a hardware load balancer.

Advantages of DirectAccess

Below are the advantages of DirectAccess:

• Ease of management of users and their devices: since the DirectAccess client can connect to intranet automatically provided there is Internet connectivity on the host, corporate now can manage the devices by enforcing policies. This means all actions are not visible to the user or the end user needs not to do anything, which is a contrast to VPN where a user has to initiate the connection. Thus all the security updates are automatically pushed on to the clients as soon the first tunnel i.e. infrastructure tunnel is created between the client and centralized server.
• Ease of use and transparency for users: Since all the actions between the DirectAccess client and server are done behind the scenes, DirectAccess poses a lot of ease for users to access protected intranet resources with full protection.

DirectAccess Implementation Mistakes

Though DirectAccess poses a very simple technology to handle, a lot of mistakes happen during implementation.

• Operating System - For DirectAccess clients, only Enterprise or Ultimate versions of Windows 7/8 are supported. No other operating system SKUs is supported.
• Certificate Issues – Certificate usage is another deployment issue under DirectAccess. DirectAccess leverages digital certificates for IPsec authentication and encryption, and thus certificates needs to be deployed over DirectAccess server and clients. A common issue is the usage of an 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. DirectAccess requires an SSL certificate to be installed 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 internal PKI as long as the CRL is publicly available. For best scenarios, a public CA should be used to issue. 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 internal PKI.
• Network Interface Configuration – Dual homed is the most recommended network configuration for DirectAccess. Configuring a Windows server with two network interfaces is complicated. 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.
• NLS Configuration – NLA non resolvable DNS entry generally causes problems. 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. 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.

References

• http://en.wikipedia.org/wiki/DirectAccess
• http://technet.microsoft.com/en-gb/windows/dn168168.aspx
• http://blogs.technet.com/b/tip_of_the_day/archive/2013/11/15/tip-of-the-day-direct-access-deployment-scenarios.aspx