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.
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.”
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.
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
Mitz
/ May 3, 2021Thank you Richard for the amazing posts on Direct Access. Just checking if you came across anyone who ever managed to successfully deploy Direct Access on AWS. Have gone through your posts on it not being officially supported on Azure. Based on a requirement, we deployed AD, PKI for certificates, Direct Access on separate AWS EC2 Windows Server 2019 instances. Deployed Direct Access server with single NIC, dual NIC but just couldn’t get it working – yet same setup appears to work on-premise on Hyper-V. Issues faced:
– Clients PCs unable to get group policies – event viewer on client PCs show sysvol path inaccessible – rightly so, as domain controller wasn’t public facing
– Direct Access diagnostic tool showed errors of “No usable certificate found” and sysvol, Failed to connect to domain sysvol share
– Direct Access server kept switching to Domain Profile on the Firewall when using single NIC or both NICs (internal & external NICs switch to Domain profile even after temporarily switching to private/ public) – one of your posts distinctly mentions external nic shouldnt be on domain profile.
So just curious to know if anyone ever got it working seamlessly.
Richard M. Hicks
/ May 3, 2021Yes, I’ve deployed DirectAccess on AWS many times. It’s been a while since I’ve done this though, so things could change. However, I’d still expect it to work.
Bruno
/ February 15, 2022Hi Richard, is there still no formal MS statement of non-support for DirectAccess hosted on AWS? When deploying DirectAccess on AWS, does it support manage out using ISATAP?
Richard M. Hicks
/ February 15, 2022Not to my knowledge. And no, ISATAP doesn’t work in Azure or AWS due to limitations with the way the underlying network infrastructure operates.