SSL Certificate Considerations for DirectAccess IP-HTTPS

SSL Certificate Considerations for DirectAccess IP-HTTPSDirectAccess uses IPv6 exclusively for communication between the client and server. IPv6 transition technologies are used to support DirectAccess communication over the IPv4 public Internet. One of those IPv6 transition technologies, IP-HTTPS, uses HTTP for encapsulation and SSL/TLS for authentication of the DirectAccess server.

SSL Certificates

When configuring DirectAccess, an SSL certificate must be provided for IP-HTTPS. There are three different types of SSL certificates that can be used.

Public SSL Certificate – Using an SSL certificate signed by a public certification authority (CA) is the recommended best practice for configuring DirectAccess IP-HTTPS. This provides the highest level of assurance for DirectAccess clients connecting via IP-HTTPS.

Private SSL Certificate – Using an SSL certificate issued by the organization’s internal CA is an acceptable alternative to using a public SSL certificate in most cases. This can reduce the cost associated with obtaining the certificate, especially for multisite deployments.

Self-Signed Certificate – Using a self-signed certificate is not recommended and should be avoided in most deployment scenarios. A self-signed certificate provides no real assurance for DirectAccess clients. Crucially, using a self-signed certificate will disable support for null SSL and TLS cipher suites. This reduces the overall scalability and performance of the remote access solution.

SSL Certificate Considerations for DirectAccess IP-HTTPS

Figure 1. Null cipher suites not supported when using a self-signed SSL certificate for IP-HTTPS.

Certificate Requirements

The SSL certificate must include the Server Authentication (1.3.6.1.5.5.7.3.1) Enhanced Key Usage (EKU) Object Identifier (OID). It should use an RSA key of 2048 bits and be signed with SHA256. Using stronger keys provides no additional protection and should not be used. In addition, SSL certificates using ECDSA keys is not recommended, as they do not support null cipher suites.

Summary

In most cases, using a public SSL certificate is ideal. However, issuing a certificate from a private CA is also acceptable. Using self-signed certificates can be used for non-production testing and in very small production deployments, but should generally be avoided.

Additional Resources

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

DirectAccess and NetMotion Mobility Webinar

Update: You can view the on-demand recording of this webinar here.

DirectAccess on Windows Server 2016 CoreFor many years, DirectAccess has been the gold standard for enterprise remote access. Its seamless and transparent operation improves productivity for mobile workers, and since it is always on, administrators enjoy improved visibility and management for their field-based assets.

As incredible as DirectAccess is, it is not without its limitations. For example, DirectAccess works only with Windows Enterprise edition clients that are joined to the domain. Professional Edition and non-domain joined machines are not supported. It also lacks many of the security features enterprise organizations require, such as device health checks and granular network access. In addition, DirectAccess communication is complex, with many different layers of encapsulation, authentication, and encryption. High protocol overhead can lead to poor performance over high latency or low bandwidth connections.

NetMotion Mobility as an Alternative to DirectAccessNetMotion Mobility is a secure remote access solution that is an excellent alternative to DirectAccess. It provides the same seamless, transparent, always on remote connectivity that DirectAccess provides, while at the same time offering much more in terms of features and capabilities. It supports a much broader range of clients, includes native Network Access Control (NAC) and application filtering, and offers enhanced performance.

To learn more about NetMotion Mobility, join me on Wednesday, September 20 at 10:00AM PDT for a free live webinar with NetMotion. I’ll provide an overview of NetMotion Mobility and how it compares with DirectAccess. I’ll also demonstrate how it can help overcome some of the inherent limitations of DirectAccess too. Register today!

DirectAccess and NetMotion Mobility Webinar

DirectAccess Force Tunneling and Proxy Server Configuration

By default, DirectAccess is configured to use split tunneling. In this scenario, a remote DirectAccess client is connected to the internal corporate network and the public Internet at the same time. Some security administrators perceive split tunneling as a security risk, and the use of split tunneling may be prohibited by corporate security policy. In addition, enforcing web browsing policies on remote DirectAccess clients might be desired to reduce the risk of exposure from browsing unapproved web sites. In either case, force tunneling can be configured to meet these requirements.

When force tunneling is enabled, DirectAccess administrators can also define an on-premises proxy server for DirectAccess clients to use. The following is guidance for enabling force tunneling and configuring DirectAccess clients to use a proxy server to access the Internet.

Enabling Force Tunneling

To enable force tunneling, open the Remote Access Management console and perform the following steps.

  1. Expand Configuration and select DirectAccess and VPN.
  2. Click Edit on Step 1 Remote Clients.
  3. Click Select Groups in the navigation tree.
  4. Select the option to Use force tunneling.

DirectAccess Force Tunneling and Proxy Server ConfigurationFigure 1. Enable DirectAccess force tunneling in the Remote Access Management console.

Alternatively, force tunneling can quickly be enabled by opening an elevated PowerShell command window and running the following command.

Set-DAClient -ForceTunnel Enabled -PassThru

DirectAccess Force Tunneling and Proxy Server ConfigurationFigure 2. Enable DirectAccess force tunneling using PowerShell.

Configure a Proxy Server

Once force tunneling has been enabled, run the following PowerShell script to configure an on-premises proxy server for DirectAccess clients to use. Be sure to substitute the fully-qualified domain name (FQDN) and port for your proxy server in the $proxy variable below.

$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]

$proxy = “proxy.corp.example.net:8080”

$rule = (Get-DnsClientNrptRule -GpoName $gpo | Where-Object Namespace -eq “.” | Select-Object -ExpandProperty “Name”)

Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $rule -GpoName $gpo

If multisite is enabled and Windows 7 clients are supported, run the following PowerShell script on one DirectAccess server in each entry point.

$downlevelgpo = (Get-RemoteAccess).DownlevelGpoName
$downlevelgpo = $downlevelgpo.Split(‘\’)[1]

$proxy = “proxy.corp.example.net:8080”

$downlevelrule = (Get-DnsClientNrptRule -GpoName $downlevelgpo | Where-Object Namespace -eq “.” | Select-Object -ExpandProperty “Name”)

Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $downlevelrule -GpoName $downlevelgpo

Remove Proxy Server

Run the following PowerShell script to remove the proxy server, if necessary.

$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]

Set-DnsClientNrptRule -DAEnable $true -DAProxyType “UseDefault” -Name $rule -GpoName $gpo

$downlevelgpo = (Get-RemoteAccess).DownlevelGpoName
$downlevelgpo = $downlevelgpo.Split(‘\’)[1]

Set-DnsClientNrptRule -DAEnable $true -DAProxyType “UseDefault” -Name $downlevelrule -GpoName $downlevelgpo

Disable Force Tunneling

To disable force tunneling completely, run the following PowerShell command.

Set-DAClient -ForceTunnel Disabled -PassThru

Force Tunneling Caveats

When force tunneling is enabled, the user experience is typically poor when accessing the Internet. Web browsing performance is significantly reduced because of the added protocol overhead imposed by DirectAccess IPv6 transition technologies and IPsec encryption. This problem is further compounded when users access resources that are already encrypted, such as secure web sites. Increased packet fragmentation, along with the additional network latency caused by suboptimal network paths and increased network load on the server and Internet connection all contribute to degraded network performance for DirectAccess clients.

Force Tunneling Alternatives

Instead of enabling force tunneling, consider alternative solutions to address the security concerns associated with split tunneling. For example, implement technologies that enforce web browsing policies on the client. Many secure web gateways and next-generation firewalls (NGFW) have remote filtering capabilities that allow administrators to enforce web browsing policies on remote client machines. In addition, there are some excellent cloud-based solutions such as Zscaler and OpenDNS that can protect DirectAccess clients without the drawbacks associated with force tunneling.

Additional Information

Planning and Implementing DirectAccess with Windows Server 2016 video training course on Pluralsight
Managing and Supporting DirectAccess with Windows Server 2016 video training course on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book