Deploying DirectAccess in Microsoft Azure

Introduction

DirectAccess Now a Supported Workload in Microsoft AzureMany organizations are preparing to implement DirectAccess on Microsoft’s public cloud infrastructure. Deploying DirectAccess in Azure is fundamentally no different than implementing it on premises, with a few important exceptions (see below). This article provides essential guidance for administrators to configure this unique workload in Azure.

Important Note: There has been much confusion regarding the supportability of DirectAccess in Azure. Historically it has not been supported. Recently, it appeared briefly that Microsoft reversed their earlier decision and was in fact going to support it. However, the Microsoft Server Software Suport for Microsoft Azure Virtual Machines document has once again been revised to indicate that DirectAccess is indeed no longer formally supported on Azure. More details can be found here.

Azure Configuration

The following is guidance for configuring network interfaces, IP address assignments, public DNS, and network security groups for deploying DirectAccess in Azure.

Virtual Machine

Deploy a virtual machine in Azure with sufficient resources to meet expected demand. A minimum of two CPU cores should be provisioned. A VM with 4 cores is recommended. Premium storage on SSD is optional, as DirectAccess is not a disk intensive workload.

Network Interfaces

It is recommended that an Azure VM with a single network interface be provisioned for the DirectAccess role. This differs from on-premises deployments where two network interfaces are preferred because deploying VMs in Azure with two NICs is prohibitively difficult. At the time of this writing, Azure VMs with multiple network interfaces can only be provisioned using PowerShell, Azure CLI, or resource manager templates. In addition, Azure VMs with multiple NICs cannot belong to the same resource group as other VMs. Finally, and perhaps most importantly, not all Azure VMs support multiple NICs.

Internal IP Address

Static IP address assignment is recommended for the DirectAccess VM in Azure. By default, Azure VMs are initially provisioned using dynamic IP addresses, so this change must be made after the VM has been provisioned. To assign a static internal IP address to an Azure VM, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network Interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click IP configurations.
  6. Click Ipconfig1.
  7. In the Private IP address settings section choose Static for the assignment method.
  8. Enter an IP address for the VM.
  9. Click Save.

Deploying DirectAccess in Microsoft Azure

Public IP Address

The DirectAccess VM in Azure must have a public IP address assigned to it to allow remote client connectivity. To assign a public IP address to an Azure VM, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network Interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click IP configurations.
  6. Click Ipconfig1.
  7. In the Public IP address settings section click Enabled.
  8. Click Configure required settings.
  9. Click Create New and provide a descriptive name for the public IP address.
  10. Choose an address assignment method.
  11. Click Ok and Save.

Deploying DirectAccess in Microsoft Azure

Deploying DirectAccess in Microsoft Azure

Public DNS

If the static IP address assignment method was chosen for the public IP address, create an A resource record in public DNS that resolves to this address. If the dynamic IP address assignment method was chosen, create a CNAME record in public DNS that maps to the public hostname for the DirectAccess server. To assign a public hostname to the VM in Azure, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Overview.
  4. Click Public IP address/DNS name label.Deploying DirectAccess in Microsoft Azure
  5. Under Settings click Configuration.
  6. Choose an assignment method (static or dynamic).
  7. Enter a DNS name label.
  8. Click Save.

Deploying DirectAccess in Microsoft Azure

Note: The subject of the SSL certificate used for the DirectAccess IP-HTTPS listener must match the name of the public DNS record (A or CNAME) entered previously. The SSL certificate does not need to match the Azure DNS name label entered here.

Network Security Group

A network security group must be configured to allow IP-HTTPS traffic inbound to the DirectAccess server on the public IP address. To make the required changes to the network security group, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click Network security group.
  6. Click the network security group assigned to the network interface.
  7. Click Inbound security rules.
  8. Click Add and provide a descriptive name for the new rule.
  9. Click Any for Source.
  10. From the Service drop-down list choose HTTPS.
  11. Click Allow for Action.
  12. Click Ok.

Deploying DirectAccess in Microsoft Azure

Note: It is recommended that the default-allow-rdp rule be removed if it is not needed. At a minimum, scope the rule to allow RDP only from trusted hosts and/or networks.

DirectAccess Configuration

When performing the initial configuration of DirectAccess using the Remote Access Management console, the administrator will encounter the following warning message.

“One or more network adapters should be configured with a static IP address. Obtain a static address and assign it to the adapter.”

Deploying DirectAccess in Microsoft Azure

This message can safely be ignored because Azure infrastructure handles all IP address assignment for hosted VMs.

The public name of the DirectAccess server entered in the Remote Access Management console must resolve to the public IP address assigned to the Azure VM, as described previously.

Deploying DirectAccess in Microsoft Azure

Additional Considerations

When deploying DirectAccess in Azure, the following limitations should be considered.

Load Balancing

It is not possible to enable load balancing using Windows Network Load Balancing (NLB) or an external load balancer. Enabling load balancing for DirectAccess requires changing static IP address assignments in the Windows operating system directly, which is not supported in Azure. This is because IP addresses are assigned dynamically in Azure, even when the option to use static IP address assignment is chosen in the Azure management portal. Static IP address assignment for Azure virtual machines are functionally similar to using DHCP reservations on premises.

Deploying DirectAccess in Microsoft Azure

Note: Technically speaking, the DirectAccess server in Azure could be placed behind a third-party external load balancer for the purposes of performing SSL offload or IP-HTTPS preauthentication, as outlined here and here. However, load balancing cannot be enabled in the Remote Access Management console and only a single DirectAccess server per entry point can be deployed.

Manage Out

DirectAccess manage out using native IPv6 or ISATAP is not supported in Azure. At the time of this writing, Azure does not support IPv6 addressing for Azure VMs. In addition, ISATAP does not work due to limitations imposed by the underlying Azure network infrastructure.

Summary

For organizations moving infrastructure to Microsoft’s public cloud, formal support for the DirectAccess workload in Azure is welcome news. Implementing DirectAccess in Azure is similar to on-premises with a few crucial limitations. By following the guidelines outlined in this article, administrators can configure DirectAccess in Azure to meet their secure remote access needs with a minimum of trouble.

Additional Resources

Implementing DirectAccess in Windows Server 2016
Fundamentals of Microsoft Azure 2nd Edition
Microsoft Azure Security Infrastructure
DirectAccess Multisite with Azure Traffic Manager
DirectAccess Consulting Services

DirectAccess IP-HTTPS Preauthentication


Introduction

DirectAccess IP-HTTPS PreauthenticationRecently I’ve written about the security challenges with DirectAccess, specifically around the use of the IP-HTTPS IPv6 transition technology. In its default configuration, the DirectAccess server does not authenticate the client when an IP-HTTPS transition tunnel is established. This opens up the possibility of an unauthorized user launching Denial-of-Service (DoS) attacks and potentially performing network reconnaissance using ICMPv6. More details on this can be found here.

Mitigation

The best way to mitigate these security risks is to implement an Application Delivery Controller (ADC) such as the F5 BIG-IP Local Traffic Manager or the Citrix NetScaler. I’ve documented how to configure those platforms here and here.

No ADC?

For those organizations that do not have a capable ADC deployed, it is possible to configure the IP-HTTPS listener on the Windows Server 2012 R2 server itself to perform preauthentication.

Important Note: Making the following changes on the DirectAccess server is not formally supported. Also, this change is incompatible with one-time passwords (OTP)  and should not be performed if strong user authentication is enabled. In addition, null cipher suites will be disabled, resulting in reduced scalability and degraded performance for Windows 8.x and Windows 10 clients. Making this change should only be done if a suitable ADC is not available.

Configure IP-HTTPS Preauthentication

To configure the DirectAccess server to perform preauthentication for IP-HTTPS connections, open an elevated PowerShell command window and enter the following command.

ls Cert:\LocalMachine\My

DirectAccess IP-HTTPS Preauthentication

Copy the thumbprint that belongs to the SSL certificate assigned to the IP-HTTPS listener. Open an elevated command prompt window (not a PowerShell window!) and enter the following commands.

netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certhash=[thumbprint]
appid={5d8e2743-ef20-4d38-8751-7e400f200e65}
dsmapperusage=enable clientcertnegotiation=enable

DirectAccess IP-HTTPS Preauthentication

For load-balanced clusters and multisite deployments, repeat these steps on each DirectAccess server in the cluster and/or enterprise.

Summary

Once these changes have been made, only DirectAccess clients that have a computer certificate with a subject name that matches the name of its computer account in Active Directory will be allowed to establish an IP-HTTPS transition tunnel connection.

Configure Citrix NetScaler for DirectAccess NLS

DirectAccess and Citrix NetScaler WebinarIntroduction

The Network Location Server (NLS) is a crucial DirectAccess supporting infrastructure component. It is secure web server that DirectAccess clients use to determine if they are inside or outside of the corporate network.

NLS Availability

The NLS should be highly available. If this service is not available, DirectAccess clients on the internal network will think they are outside and attempt to establish a DirectAccess connection. Typically, this results in the DirectAccess client not being able to reach internal resources by hostname. Full connectivity for DirectAccess clients on the internal network will not be restored until the NLS is online.

It is recommended that the NLS be deployed in a load-balanced cluster for high availability. However, this requires deploying multiple servers, adding more cost, complexity, and management overhead to the solution.

NLS and Citrix NetScaler

Configuring the Citrix NetScaler to serve as the NLS is an attractive alternative to deploying additional servers for this role. Using the NetScaler for the NLS reduces costs by leveraging existing infrastructure. In addition, the NetScaler requires less servicing than a typical Windows server, and is often itself already highly available.

Configure Citrix NetScaler

To configure the NetScaler to serve as a DirectAccess NLS, open the NetScaler management console, expand AppExpert, and then select Actions. Click Add, provide a descriptive name for the responder action, and then enter the following in the Expression field and click Create.

"HTTP/1.0 200 OK" +"\r\n\r\n" + "DirectAccess Network Location Server (NLS)" + "\r\n"

Configure Citrix NetScaler for DirectAccess NLS

Select Policies, click Add, and then provide a descriptive name for the responder policy. Enter HTTP.REQ.IS_VALID in the Expression field and click Create.

Configure Citrix NetScaler for DirectAccess NLS

Expand Traffic Management, expand Load Balancing and select Services. Click Add, provide a descriptive name for the service, choose New Server, and enter the IPv4 loopback address 127.0.0.1. Select SSL for the Protocol, enter a random port number for the Port and then click More.

Configure Citrix NetScaler for DirectAccess NLS

Uncheck the box next to Health Monitoring and click Ok and Done.

Configure Citrix NetScaler for DirectAccess NLS

Select Virtual Servers and click Add. Provide a descriptive name for the virtual server, select SSL for the Protocol, enter an IP address for the virtual server and click Ok.

Configure Citrix NetScaler for DirectAccess NLS

Under Services and Service Groups click No Load Balancing Virtual Server Service Binding.

Configure Citrix NetScaler for DirectAccess NLS

Click to select a service, choose the service created previously and click Ok, Bind and Ok.

Configure Citrix NetScaler for DirectAccess NLS

Under Certificates click No Server Certificate.

Configure Citrix NetScaler for DirectAccess NLS

Click to select a server certificate, choose the SSL certificate to be used by the NLS and click Ok, Bind, and Ok.

Configure Citrix NetScaler for DirectAccess NLS

Under Advanced click Policies, and then click the + icon. From the Choose Policy drown-list choose Responder and click Continue. Click to select a Policy Binding and choose the responder policy created previously. Click Ok, Bind, and Done.

Configure Citrix NetScaler for DirectAccess NLS

Testing NLS Functionality

Open a web browser on a client connected to the internal network and browse to the NLS URL. Ensure that there are no certificate errors and that the NetScaler is responding with the configured web page.

Configure Citrix NetScaler for DirectAccess NLS

Summary

The Network Location Server (NLS) is an important, and often overlooked, supporting infrastructure component for DirectAccess. It is used by DirectAccess clients to determine their network location. If it is unavailable for any reason it can be very disruptive. Ensuring that the NLS is highly available is critical. Configuring the NLS on the Citrix NetScaler can be a cost-effective alternative to deploying additional servers, while at the same time reducing the chance of an outage due to NLS failure.