Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

Organizations are rapidly deploying Windows server infrastructure with public cloud providers such as Amazon Web Services (AWS) and Microsoft Azure. With traditional on-premises infrastructure now hosted in the cloud, DirectAccess is also being deployed there more commonly.

Supportability

Interestingly, Microsoft has expressly stated that DirectAccess is not formally supported on their own public cloud platform, Azure. However, there is no formal statement of non-support for DirectAccess hosted on other non-Microsoft public cloud platforms. With supportability for DirectAccess on AWS unclear, many companies are taking the approach that if it isn’t unsupported, then it must be supported. I’d suggest proceeding with caution, as Microsoft could issue formal guidance to the contrary in the future.

DirectAccess on AWS

Deploying DirectAccess on AWS is similar to deploying on premises, with a few notable exceptions, outlined below.

IP Addressing

It is recommended that an IP address be exclusively assigned to the DirectAccess server in AWS, as shown here.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

Prerequisites Check

When first configuring DirectAccess, the administrator will encounter the following warning message.

“The server does not comply with some DirectAccess prerequisites. Resolve all issues before proceed with DirectAccess deployment.”

The warning message itself states that “One or more network adapters should be configured with a static IP address. Obtain a static address and assign it to the adapter.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

IP addressing for virtual machines are managed entirely by AWS. This means the DirectAccess server will have a DHCP-assigned address, even when an IP address is specified in AWS. Assigning static IP addresses in the guest virtual machine itself is also not supported. However, this warning message can safely be ignored.

No Support for Load Balancing

It is not possible to create load-balanced clusters of DirectAccess servers for redundancy or scalability on AWS. This is because enabling load balancing for DirectAccess requires the IP address of the DirectAccess server be changed in the operating system, which is not supported on AWS. To eliminate single points of failure in the DirectAccess architecture or to add additional capacity, multisite must be enabled. Each additional DirectAccess server must be provisioned as an individual entry point.

Network Topology

DirectAccess servers on AWS can be provisioned with one or two network interfaces. Using two network interfaces is recommended, with the external network interface of the DirectAccess server residing in a dedicated perimeter/DMZ network. The external network interface must use either the Public or Private Windows firewall profile. DirectAccess will not work if the external interface uses the Domain profile. For the Public and Private profile to be enabled, domain controllers must not be reachable from the perimeter/DMZ network. Ensure the perimeter/DMZ network cannot access the internal network by restricting network access in EC2 using a Security Group, or on the VPC using a Network Access Control List (ACL) or custom route table settings.

External Connectivity

A public IPv4 address must be associated with the DirectAccess server in AWS. There are several ways to accomplish this. The simplest way is to assign a public IPv4 address to the virtual machine (VM). However, a public IP address can only be assigned to the VM when it is deployed initially and cannot be added later. Alternatively, an Elastic IP can be provisioned and assigned to the DirectAccess server at any time.

An ACL must also be configured for the public IP that restricts access from the Internet to only inbound TCP port 443. To provide additional protection, consider deploying an Application Delivery Controller (ADC) appliance like the Citrix NetScaler or F5 BIG-IP to enforce client certificate authentication for DirectAccess clients.

Network Location Server (NLS)

If an organization is hosting all of its Windows infrastructure in AWS and all clients will be remote, Network Location Server (NLS) availability becomes much less critical than with traditional on-premises deployments. For cloud-only deployments, hosting the NLS on the DirectAccess server is a viable option. It eliminates the need for dedicated NLS, reducing costs and administrative overhead. If multisite is configured, ensure that the NLS is not using a self-signed certificate, as this is unsupported.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

However, for hybrid cloud deployments where on-premises DirectAccess clients share the same internal network with cloud-hosted DirectAccess servers, it is recommended that the NLS be deployed on dedicated, highly available servers following the guidance outlined here and here.

Client Provisioning

All supported DirectAccess clients will work with DirectAccess on AWS. If the domain infrastructure is hosted exclusively in AWS, provisioning clients can be performed using Offline Domain Join (ODJ). Provisioning DirectAccess clients using ODJ is only supported in Windows 8.x/10. Windows 7 clients cannot be provisioned using ODJ and must be joined to the domain using another form of remote network connectivity such as VPN.

Additional Resources

DirectAccess No Longer Supported in Microsoft Azure

Microsoft Server Software Support for Azure Virtual Machines

DirectAccess Network Location Server (NLS) Guidance

DirectAccess Network Location Server (NLS) Deployment Considerations for Large Enterprises

Provisioning DirectAccess Clients using Offline Domain Join (ODJ)

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

DirectAccess SSL Offload and IP-HTTPS Preauthentication with F5 BIG-IP

Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course

Implementing DirectAccess with Windows Server 2016 Book

DirectAccess DNS Records Explained

After installing and configuring DirectAccess with Windows Server 2012 R2, several new host records appear automatically in the internal DNS (assuming dynamic DNS is supported, of course). One of them is directaccess-corpConnectivityHost and the other is directaccess-WebProbeHost. These DirectAccess DNS entries are used by Windows 8 and later clients for connectivity checks at various stages of DirectAccess connection establishment.

DirectAccess DNS Records Explained

Figure 1 – DirectAccess DNS records for IPv4-only network.

DirectAccess DNS Records Explained

Figure 2 – DirectAccess DNS records for dual-stack IPv4/IPv6 network.

Here is a detailed description for each of these DirectAccess DNS entries.

directaccess-corpConnectivityHost – This DNS host record includes both A and AAAA records when deployed on IPv4-only networks. Its A host record resolves to 127.0.0.1, which is the IPv4 loopback address. Its AAAA host record resolves to an IPv6 address that is a combination of the DirectAccess NAT64 IPv6 prefix and 7F00:1 (the hexadecimal equivalent of 127.0.0.1). When DirectAccess is configured on a network with native IPv6, the directaccess-corpConnectivityHost DNS record will only include a single AAAA record resolving to ::1.

This host record is used by the DirectAccess client to determine if name resolution for the corporate namespace is working after the IPv6 transition tunnel (6to4, Teredo, or IP-HTTPS) has been established. It does this by attempting to resolve the hostname directaccess-corpConnectivityHost.<corp_fqdn> (e.g. directaccess-corpConnectivityHost.corp.example.net) to an IPv6 address that it expects (the organization’s NAT64 prefix + 7F00:1 or ::1). If it does not resolve, or resolves to a different address, the client will assume that the transition tunnel was not established successfully and, if possible, fall back to another IPv6 transition protocol and repeat the process until it is successful.

Note: The DirectAccess client does not attempt to connect to the IP address resolved by directaccess-corpConnectivityHost. It simply compares the IP address returned by the query to the expected address (NAT64 prefix + 7F00:1 or ::1).

directaccess-WebProbeHost – This DNS host record includes only A records and resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. If load balancing is enabled, this host record will resolve to the virtual IP address (VIP) of the array. For multisite deployments there will be directaccess-WebProbeHost A host records for each entry point in the organization.

This host record is used by the DirectAccess client to verify end-to-end corporate network connectivity over the DirectAccess connection. The client will attempt to connect to the directaccess-WebProbeHost URL using HTTP. If successful, the DirectAccess connectivity status indicator will show Connected.

If any of these DirectAccess DNS records are missing or incorrect, a number of issues may arise. If the directaccess-corpConnectivityHost host record is missing or incorrect, DirectAccess IPv6 transition tunnel establishment may fail. If the directaccess-WebProbeHost record is missing or incorrect, the DirectAccess connectivity status indicator will perpetually show Connecting. This commonly occurs when an external load balancer is used and a virtual server isn’t created for the web probe host port (TCP 80). In addition, these DirectAccess DNS entries are not static and may be deleted if DNS scavenging of stale resource records is enabled on the DNS server.

%d bloggers like this: