DirectAccess WinRM Conflicts and Errors

Introduction

When installing DirectAccess for the first time, an administrator may encounter the following error message while running the Remote Access Setup wizard.

Error. The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: “winrm quickconfig”.

DirectAccess WinRM Conflicts and Errors

Troubleshooting

Running winrm quickconfig in an elevated PowerShell command window returns the following message.

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.

DirectAccess WinRM Conflicts and Errors

Clicking Check prerequisites again does not resolve the error message.

Post-Installation Errors

If DirectAccess is already installed and working properly, an administrator may encounter a scenario in which the operations status page displays nothing, yet remote DirectAccess clients are connected and able to access corporate resources without issue.

DirectAccess WinRM Conflicts and Errors

In addition, clicking Edit on Step 2 in the Remote Access Management console and choosing Network Adapters produces an error message stating “An error occurred when validating interfaces”. You can select a network adapter from the drop-down list, but the Next and Finish buttons are grayed out.

DirectAccess WinRM Conflicts and Errors

Conflicts with WinRM

These errors are commonly caused by a conflict with WinRM Service settings enforced via Active Directory group policy. To confirm this, open an elevated PowerShell command window run the winrm enumerate winrm/config/listener command. The listener configuration source will be listed as GPO.

DirectAccess WinRM Conflicts and Errors

The administrator will also find the presence of the following registry keys on the DirectAccess server.

HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\AllowAutoConfig
HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\IPv4Filter
HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\IPv6Filter

Resolution

To resolve this conflict, prevent the GPO with this setting from being applied to the DirectAccess server(s). You will find this GPO setting in the Group Policy Management console (GPMC) by navigating to Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Service and setting the state of Allow remote server management through WinRM to Not configured.

DirectAccess WinRM Conflicts and Errors

Additional Resources

DirectAccess and Windows 10 Better Together

DirectAccess and Windows 10 in Education

VIDEO – DirectAccess and Windows 10 in Action 

BOOK – Implementing DirectAccess with Windows Server 2016

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Introduction

Communication between the DirectAccess client and server takes place exclusively over IPv6. When DirectAccess servers and/or clients are on the IPv4 Internet, an IPv6 transition technology must be employed to allow those clients to connect to the DirectAccess server. DirectAccess deployment best practices dictate that only the IP-HTTPS IPv6 transition technology be used. IP-HTTPS uses SSL/TLS for server authentication and optionally encryption. To improve security and performance for IP-HTTPS, an Application Delivery Controller (ADC) like the Citrix NetScaler can be configured to perform SSL offloading and client preauthentication for DirectAccess IP-HTTPS connections.

Please note that the following caveats apply when enabling SSL offload for DirectAccess clients:

  • Enabling SSL offload and IP-HTTPS preauthentication on an ADC for DirectAccess is formally unsupported by Microsoft.
  • SSL offload should not be enabled with DirectAccess is configured to use one-time password (OTP) authentication. Offloading SSL will break OTP functionality.

IP-HTTPS Challenges

The IP-HTTPS IPv6 transition technology is a simple and effective way to allow DirectAccess clients and servers to communicate by encapsulating IPv6 traffic in HTTP and routing it over the public IPv4 Internet. However, there are two critical issues with the default implementation of IP-HTTPS in DirectAccess. One is a security issue, the other affects performance.

Security

The DirectAccess server does not authenticate clients establishing IP-HTTPS connections. This could allow an unauthorized client to obtain an IPv6 address from the DirectAccess server using the IPv6 Neighbor Discovery (ND) process. With a valid IPv6 address, the unauthorized user could perform internal network reconnaissance or launch a variety of Denial of Service (DoS) attacks on the DirectAccess infrastructure and connected clients. More details here.

Performance

Windows 7 DirectAccess clients use encrypted cipher suites when establishing IP-HTTPS connections. However, the payload being transported is already encrypted using IPsec. This double encryption increases resource utilization on the DirectAccess server, reducing performance and limiting scalability. More details here.


Note: Beginning with Windows Server 2012 and Windows 8, Microsoft introduced support for null encryption for IP-HTTPS connections. This eliminates the needless double encryption, greatly improving scalability and performance for DirectAccess clients using IP-HTTPS.


SSL Offload for DirectAccess IP-HTTPS

The Citrix NetScaler can be configured to perform SSL offload to improve performance for Windows 7 DirectAccess clients using IP-HTTPS. Since DirectAccess does not natively support SSL offload, the NetScaler must be configured in a non-traditional way. While the NetScaler will be configured to terminate incoming IP-HTTPS SSL connections, it must also use SSL for the back-end connection to the DirectAccess server. However, the NetScaler will be configured only to use null cipher suites when connecting to the DirectAccess server. Even though Windows 7 clients will still perform double encryption to the NetScaler, this configuration effectively offloads from the server the heavy burden of double encrypting every IP-HTTPS connection for all connected DirectAccess clients. This results in reduced CPU utilization on the DirectAccess server, yielding better scalability and performance.

SSL Offload and Windows 8.x/10 Clients

Offloading SSL for Windows 8.x/10 clients will not improve performance because they already use null cipher suites for IP-HTTPS when connecting to a Windows Server 2012 or later DirectAccess server. However, terminating SSL on the NetScaler is still required to perform IP-HTTPS preauthentication.

Supported NetScaler Platforms for DirectAccess SSL Offloading

The following configuration for Citrix NetScaler can be performed on any release of the VPX virtual ADC platform. However, be advised that there is a known issue with older releases on the MDX and SDX hardware platforms that will prevent this from working. For MDX and SDX deployments, upgrading to release 11.1 build 50.10 or later will be required.

Configure Citrix NetScaler for IP-HTTPS SSL Offload

To enable SSL offloading for DirectAccess IP-HTTPS on the Citrix NetScaler, open the NetScaler management console, expand Traffic Management and Load Balancing, and then perform the following procedures in order.

Add Servers

  1. Click Servers.
  2. Click Add.
  3. In the Name field enter a descriptive name for the first DirectAccess server.
  4. Select IP Address.
  5. In the IP Address field enter the IP address of the first DirectAccess server.
  6. Click Create.
  7. Repeat these steps for any additional servers in the load-balanced cluster.

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Add Services

  1. Click Services.
  2. Click Add.
  3. In the Service Name field enter a descriptive name for the service.
  4. Select Existing Server from the Server drop-down list.
  5. Choose the first DirectAccess server in the cluster.
  6. Choose SSL from the Protocol drop-down list.
  7. Click Ok.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler
  8. Edit SSL Parameters.
    1. In the Protocol section uncheck SSLv3.
    2. Click Ok.
  9. Edit SSL Ciphers.
    1. Click Remove All.
    2. Click Add.
    3. Type NULL in the Search Ciphers box.
    4. Check the box next to the first entry for SSL3-NULL-SHA.
    5.  Click the right arrow to add the cipher to the list.
    6. Click Ok.
    7. Click Done.
    8. Repeat these steps for any additional servers in the load-balanced cluster.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

A warning message may be displayed indicating that no usable ciphers are configured on the SSL vserver/service. This message can be safely ignored.

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Add Virtual Server

  1. Click Virtual Servers.
    1. Click Add.
    2. In the Name field enter a descriptive name for the virtual server.
    3. Choose SSL from the Protocol drop-down list.
    4. In the IP Address field enter the IP address for the virtual server.
    5. Click Ok.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

      Note: When enabling load balancing in DirectAccess, the IP address assigned to the first DirectAccess server is reallocated for use as the load balancing Virtual IP Address (VIP). Ideally this IP address will be assigned to the load balancing virtual server on the NetScaler. However, this is not a hard requirement. It is possible to configure the VIP on the NetScaler to reside on any subnet that the load balancer has an interface to. More details here.


  2. In the Services and Groups section click No Load Balancing Virtual Server Service Binding.
    1. Click on the Select Service field.
    2. Check all DirectAccess server services and click Select.
    3. Click Bind.
    4. Click Continue.
  3. In the Certificate section click No Server Certificate.
    1. Click on the Select Server Certificate field.
    2. Choose the certificate to be used for DirectAccess IP-HTTPS.
    3. Click Select.
    4. Click Bind.
    5. Click Continue.
  4. Edit SSL Ciphers.
    1. Click Remove All.
    2. Click Add.
    3. Type ECDHE in to the Search Ciphers box.
    4. Check the box next to TLS1-ECDHE-RSA-AES128-SHA.
    5. Click the right arrow to add the cipher to the list.
    6. Type NULL in to the Search Ciphers box.
    7. Check the box next to SSL3-NULL-SHA.
    8. Click the right arrow to add the cipher to the list.
    9. Click Ok.
    10. Click Done.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

      Note: If Windows 8.x/10 clients are supported exclusively, SSL3-NULL-SHA is the only cipher suite required to be configured on the virtual server. If Windows 7 client support is required, the TLS1-ECDHE-RSA-AES128-SHA cipher suite should also be configured on the virtual server.


  5. Edit SSL Parameters.
    1. Uncheck SSLv3.
    2. Click Ok.

      Note: If Windows 8.x/10 clients are supported exclusively, TLSv1 can also be unchecked on the virtual server. If Windows 7 client support is required, TLSv1 must be enabled.


  6. In the Advanced Settings section click Persistence.
    1. Choose SSLSESSION.
    2. Enter 10 minutes for the Time-out (mins) value.
    3. Click Ok.
    4. Click Done.

Optional IP-HTTPS Preauthentication

To enable IP-HTTPS preauthentication to prevent unauthorized network access, perform the following procedures on the Citrix NetScaler appliance.

  1. Expand Traffic Management, Load Balancing, and then click Virtual Servers.
  2. Select the DirectAccess virtual server and click Edit.
    1. In the Certificate section click No CA Certificate.
    2. Click the Select CA Certificate field.
    3. Choose the certificate for the CA that issues certificates to DirectAccess clients and servers.

      Note: The CA certificate used for DirectAccess can be found by opening the Remote Access Management console, clicking Edit on Step 2, and then clicking Authentication. Alternatively, the CA certificate can be found by running the following PowerShell command.

      (Get-RemoteAccess).IPsecRootCertificate | Format-Table Thumbprint


    4. Click Select.
    5. Choose CRL Optional from the CRL and OCSP Check drop-down list.
    6. Click Bind.
  3. Edit SSL Parameters.
    1. Check the box next to Client Authentication.
    2. Choose Mandatory from the Client Certificate drop-down list.
    3. Click Ok.
    4. Click Done.
      DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Summary

Leveraging the advanced capabilities of the Citrix NetScaler ADC can improve performance when supporting Windows 7 clients and enhance security for all DirectAccess clients using IP-HTTPS. In terms of supportability, all of the changes described in this article are completely transparent and do not alter the native DirectAccess client or server configuration. If a Microsoft support engineer declines support due to this configuration, switching from SSL offload to SSL bridge is all that’s required to restore full supportability.

Additional Resources

NetScaler release 11.1 build 50.10 (requires login) – https://www.citrix.com/downloads/netscaler-adc/firmware/release-111-build-5010

Release notes for build 50.10 of NetScaler 11.1 release – https://www.citrix.com/content/dam/citrix/en_us/documents/downloads/netscaler-adc/NS_11_1_50_10.html

VIDEO: Enable Load Balancing for DirectAccess – https://www.youtube.com/watch?v=3tdqgY9Y-uo

DirectAccess IP-HTTPS preauthentication using F5 BIG-IP – https://directaccess.richardhicks.com/2016/05/23/directaccess-ip-https-preauthentication-using-f5-big-ip/

DirectAccess SSL offload for IP-HTTPS using F5 BIG-IP – https://directaccess.richardhicks.com/2013/07/10/ssl-offload-for-ip-https-directaccess-traffic-from-windows-7-clients-using-f5-big-ip/

Implementing DirectAccess with Windows Server 2016 book – http://directaccessbook.com/

Implementing DirectAccess with Windows Server 2016 Book Now Available

I am very excited to announce that my new DirectAccess book, Implementing DirectAccess with Windows Server 2016 from Apress media, is now shipping! The book is available on popular online sites like Amazon.com, Barnes & Noble, Springer.com, Apress.com, and others. The book is also available in electronic formats such as Amazon Kindle and Barnes & Noble Nook, as well as a variety of subscription formats including Safari, Books24x7, and SpringerLink.

Implementing DirectAccess with Windows Server 2016

This book contains detailed and prescriptive guidance for the planning, design, implementation, and support of a DirectAccess remote access solution on Windows Server 2016. It also includes valuable insight, tips, tricks, and best practice recommendations gained from my many years of deploying DirectAccess for some of the largest organizations in the world.

Current DirectAccess administrators will also find this book helpful, as the majority of content is still applicable to DirectAccess in Windows Server 2012 and Windows Server 2012 R2. In addition, the book also includes essential information on the design and deployment of highly available and geographically redundant DirectAccess deployments.

Troubleshooting DirectAccess can be a daunting task, so I’ve dedicated an entire chapter in the book to this topic. For those responsible for the maintenance and support of DirectAccess in their organization, this chapter alone will be worth the investment.

Be sure to order your copy today!

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 Load Balancing Tips and Tricks Webinar

KEMP Technologies LoadMaster Load BalancerEnabling load balancing for DirectAccess deployments is crucial for eliminating single points of failure and ensuring the highest levels of availability for the remote access solution. In addition, enabling load balancing allows DirectAccess administrators to quickly and efficiently add capacity in the event more processing power is required.

DirectAccess includes support for load balancing using integrated Windows Network Load Balancing (NLB) and external load balancers (physical or virtual). External load balancers are the recommended choice as they provide superior throughput, more granular traffic distribution, and greater visibility. External load balancers also more scalable, with support for much larger DirectAccess server clusters, up to 32 nodes. NLB is formally limited to 8 nodes, but because it operates at layer 2 in the OSI model and relies on broadcast heartbeat messages, it is effectively limited to 4 nodes.

The KEMP Technologies LoadMaster load balancer is an excellent choice for load balancing the DirectAccess workload. To learn more about configuring the LoadMaster with DirectAccess, join me for a free live webinar on Tuesday, August 16 at 10:00AM PDT where I’ll discuss DirectAccess load balancing in detail. I will also be sharing valuable tips, tricks, and best practices for load balancing DirectAccess.

DirectAccess Load Balancing Tips and Tricks Webinar

Don’t miss out. Register today!

Additional Resources

DirectAccess Load Balancing Overview

Load Balancing DirectAccess with the KEMP Loadmaster Load Balancer

Maximize your investment in Windows 10 with DirectAccess and the KEMP LoadMaster Load Balancer

KEMP LoadMaster DirectAccess Deployment Guide

DirectAccess and Windows 10 in Education

DirectAccess and Windows 10 in EducationIntroduction

DirectAccess provides seamless and transparent, always on remote network connectivity for managed Windows clients. It is commonly installed in large enterprises to provide better management for field-based assets, and to streamline the remote access experience for end users. Today, DirectAccess is a mature technology that is widely deployed across many verticals, but education is one that is often overlooked.

Benefits of DirectAccess

For commercial enterprises, the benefits of DirectAccess are many. Windows 10 DirectAccess clients have ubiquitous access to on-premises applications and data without requiring user interaction. This streamlined user access improves productivity and reduces helpdesk costs. DirectAccess is always on, allowing client machines to stay in contact with domain controllers and systems management servers, ensuring they are always managed.

DirectAccess in Education

Many of the same benefits DirectAccess provides for the enterprise are also important in the education sector. Often administrators for schools and colleges have many Windows-based machines that they must both manage and provide secure remote access for. In addition, they struggle with the same issues that enterprises do, such as maintaining configuration and security posture for devices that are predominantly remote.

Windows 10 and Education

Windows 10 November Update Available TodayThe Windows 10 Education SKU is a supported client operating system for DirectAccess, enabling educational institutions using this license to implement a remote access solution with DirectAccess using Windows Server 2012 R2 or Windows Server 2016. Implementing a DirectAccess remote access solution can result in significant cost savings, as DirectAccess requires no investments in proprietary hardware and has no associated per-user licensing.

Windows 10 Anniversary Update

Microsoft is making a concerted effort to address the education sector with new and compelling features to be included in the Windows 10 Anniversary Update, released earlier this week. For example, they have introduced apps that simplify the setup of school PCs. App discovery and purchasing are easier, and stylus support is improved. Native integration with Office 365 is another important factor. There are also a number of significant new security features that will make migrating to Windows 10 a worthy investment.

DirectAccess and Windows 10 in Education

Summary

If you are an administrator working for any educational institution and are struggling with maintaining and supporting your field-based Windows devices, consider a DirectAccess remote access solution today. With DirectAccess implemented, users will be more productive and remote machines better managed. DirectAccess can also be deployed using existing infrastructure, and it supports flexible network deployment along with many scalability features that will ensure the highest levels of availability.

Additional Resources

Video: DirectAccess and Windows 10 in Action
3 Important Things about Windows 10 and DirectAccess
DirectAccess and Windows 10 Better Together
DirectAccess Consulting Services
Book: Implementing DirectAccess with Windows Server 2016

DirectAccess Now a Supported Workload in Microsoft Azure

DirectAccess Now a Supported Workload in Microsoft Azure

Important Update! Microsoft has recently reversed their decision to support DirectAccess in Microsoft Azure. The Microsoft Server Software Support for Microsoft Azure Vitual Machines document has once again been revised to indicate that DirectAccess is formally unsuported in Azure.

Update: Detailed guidance for deploying DirectAccess in Azure can be found here.

This is great news for organizations moving their infrastructure to the Microsoft Azure public cloud! Microsoft recently made some important changes to their published support statement for server software running on Azure virtual machines. Although no formal announcement was made, they quietly removed DirectAccess from the list of unsupported roles for Windows Server 2012 R2.

DirectAccess Now a Supported Workload in Microsoft Azure

I’ve performed some limited testing with DirectAccess using Resource Manager VMs in Microsoft Azure and it appears to be stable. In addition, some of the challenges I encountered previously when implementing DirectAccess in Azure using Classic VMs have now been resolved. I’ll be publishing some guidance for deploying DirectAccess in Azure soon.

Additional Resources

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

Windows 10 Multisite DirectAccess with GSLB Webinar

Kemp Technologies LoadMaster Load BalancerWindows 10 clients include full support for all enterprise DirectAccess scalability and redundancy features, including automatic site selection and transparent failover for multisite deployments. However, the native site selection process is limited in functionality and often yields unexpected results.

To provide better client support for multisite DirectAccess, a Global Server Load Balancer (GSLB) solution such as the Kemp Technologies LoadMaster GEO can be deployed. Using the LoadMaster’s GSLB functionality can significantly enhance multisite site selection for Windows 10 clients. In addition, it can be used to enable new scenarios not supported natively such as weighted distribution and active/passive failover.

Kemp Technologies LoadMaster Load Balancer

To learn more about how address the shortcomings of DirectAccess multisite using the Kemp LoadMaster GEO, join me for a live webinar on Thursday, July 14, 2106 at 10:00AM EDT where I’ll discuss the following topics.

  • How Global Server Load Balancing (GSLB) works
  • How Windows 10 clients choose an entry point
  • Understand the limitations of the native site selection process for Windows 10 clients
  • How to use the Kemp LoadMaster GEO to provide true geographic redundancy
  • How to enable active/passive failover for disaster recovery

You can register for this free live webinar here.

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.

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Note: For information about configuring the Citrix NetScaler to perform IP-HTTPS preauthentication, click here. For information about configuring Windows Server 2012 R2 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IPRecently I wrote about security challenges with DirectAccess and the IP-HTTPS IPv6 transition technology. Specifically, IP-HTTPS transition tunnel connections are not authenticated by the DirectAccess server, only the client. This allows an unauthorized device to obtain an IPv6 address on the DirectAccess client network. With it, an attacker can perform network reconnaissance using ICMPv6 and potentially launch a variety of Denial-of-Service (DoS) attacks. For more details, click here.

Note: DirectAccess IPsec data connections not at risk. Data is never exposed at any time with the default configuration.

Mitigation

To mitigate these issues, it is recommended that an Application Delivery Controller (ADC) be used to terminate SSL connections and enforce client certificate authentication. Doing this will ensure that only authorized connections will be accepted by the DirectAccess server. In addition, there are some scalability and performance benefits to implementing this configuration when supporting Windows 7 clients.

Important Considerations

Performing IP-HTTPS preauthentication on the F5 BIG-IP is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the F5 appliance breaks OTP authentication.

F5 BIG-IP Configuration

To configure the F5 BIG-IP to perform SSL offload for DirectAccess IP-HTTPS, follow the guidance documented here. In addition, to configure the F5 BIG-IP to perform preauthentication for DirectAccess clients, when creating the client SSL profile, click Custom above the Client Authentication section and choose Require from the Client Certificate drop-down list and Always from the Frequency drop-down list. In addition, choose your internal PKI’s root Certification Authority (CA) certificate from the Trusted Certificate Authorities drop-down list and from the Advertised Certificate Authorities drop-down list.

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Summary

Enabling client certificate authentication for IP-HTTPS connections ensures that only authorized DirectAccess clients can establish a connection to the DirectAccess server and obtain an IPv6 address. It also prevents an unauthorized user from performing network reconnaissance or launching IPv6 Denial-of-Service (DoS) attacks.

%d bloggers like this: