Renew DirectAccess Self-Signed Certificates

Renew DirectAccess Self-Signed CertificatesImportant! Updated July 15, 2019 to support all versions of Windows Server including Windows Server 2012 and 2012 R2. Also added functionality to renew self-signed certificates individually.

When DirectAccess is deployed using the Getting Started Wizard (GSW), sometimes referred to as the “simplified deployment” method, self-signed certificates are created during the installation and used for the IP-HTTPS IPv6 transition technology, the Network Location Server (NLS), and for RADIUS secret encryption. Administrators may also selectively choose to use self-signed certificates for IP-HTTPS, or when collocating the NLS on the DirectAccess server. The RADIUS encryption certificate is always self-signed.

Renew DirectAccess Self-Signed Certificates

Certificate Expiration

These self-signed certificates expire 5 years after they are created, which means many DirectAccess administrators who have used this deployment option will need to renew these certificates at some point in the future. Unfortunately, there’s no published guidance from Microsoft on how to accomplish this. However, the process is simple enough using PowerShell and the New-SelfSignedCertificate cmdlet.

PowerShell Script on GitHub

The PowerShell script to renew DirectAccess self-signed certificates has been published on GitHub. You can download Renew-DaSelfSignedCertificates.ps1 here.

Important Considerations

When the IP-HTTPS and NLS scripts above are executed, DirectAccess clients outside will be immediately disconnected and will be unable to reconnect until they update group policy (the RADIUS encryption certificate can be updated without impacting users). This will require connecting to the internal network locally or remotely using another VPN solution. In addition, internal clients that are not online when this change is made will be unable to access internal resources by name until they update group policy. If this happens, delete the Name Resolution Policy Table (NRPT) on the client using the following PowerShell command and reboot to restore connectivity.

Get-Item -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig” | Remove-Item -Confirm:$false

Additional Information

PowerShell Recommended Reading for DirectAccess Administrators

Top 5 DirectAccess Troubleshooting PowerShell Commands

 

 

Always On VPN SSTP Connects then Disconnects

Always On VPN SSTP Connects then DisconnectsWhen Always On VPN clients are configured to use the Secure Socket Tunneling Protocol (SSTP) with Windows Server Routing and Remote Access Service (RRAS), administrators may encounter a scenario in which a client can establish a VPN connection using SSTP successfully, but is then disconnected immediately. The system event log contains an entry with Event ID 6 from the RasSstp source that includes the following error message.

“The SSTP-based VPN connection to the remote access server was terminated because of a security check failure. Security settings on the remote access server do not match settings on this computer. Contact the system administrator of the remote access server and relay the following information.”

Always On VPN Connect and Disconnect with SSTP

Common Causes

The two most common causes of this issue are when SSTP is configured for SSL offload, and when a VPN client is on a network where SSL inspection is taking place.

SSTP Offload

The most common cause of this issue is when SSL offload is configured for SSTP on an external load balancer or application delivery controller (ADC). To prevent interception from a Man-in-the-Middle attack, the VPN client sends the certificate hash of the SSL certificate used when the VPN connection was established. If this information does not match what is configured on the RRAS server, the connection is assumed to be compromised and the connection is immediately dropped.

SSL Inspection

Another scenario where this issue may occur is when a VPN client is behind a network device configured to perform SSL deep-packet inspection (DPI). SSTP VPN clients will be unable to connect to the VPN server in this scenario.

Resolution

When offloading SSL to another device, the RRAS server must be configured to know which SSL certificate is being presented to remote clients. This information is stored in the following registry key.

HKLM:\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters\SHA256CertificateHash

However, this registry entry requires a binary value, which makes it a challenge to configure manually. To resolve this problem, it is recommended that the same SSL certificate installed on the load balancer/ADC also be installed on the VPN server (even though SSL will be offloaded). To do this, first import the SSL certificate and private key in to the Local Computer certificate store, then open the RRAS management console and perform the following steps.

  1. Right-click the VPN server and choose Properties.
  2. Select the Security tab.
  3. Uncheck Use HTTP in the SSL Certificate Binding section.
  4. Select the appropriate SSL certificate from the Certificate drop-down list (click View to verify).
  5. Click Apply.

This will add the correct SSL certificate information to the registry. Next, re-enable HTTP for SSL offload by performing the following steps.

  1. Check Use HTTP in the SSL Certificate Binding section.
  2. Click Apply.

PowerShell Configuration

If the SSL certificate cannot be installed on the VPN server, or to automate this configuration across multiple servers remotely, download and run the Enable-SstpOffload PowerShell script from my GitHub repository here and run the following command.

Enable-SSTPOffload -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

For example…

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Additional Information

Windows 10 Always On VPN Load Balancing and SSL Offload

Windows 10 Always On VPN SSTP Load Balancing with F5 BIG-IP

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

 

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

After installing and configuring DirectAccess in Windows Server 2019 you may encounter an error message indicating that IP-HTTPS is not working properly. Looking at the Operations Status overview in the Dashboard of the Remote Access Management console shows that the IP-HTTPS interface is in error.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

IP-HTTPS Route Error

Viewing the detailed Operations Status shows the following error message.

Error: The IP-HTTPS route does not have published property enabled.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Missing Route

Looking at the routing table on the DirectAccess server reveals that a route to the client IPv6 prefix is indeed missing.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Resolution

To resolve this error message, add the client IPv6 route to the DirectAccess server’s routing table and publish it. This is accomplished by running the following PowerShell commands on the DirectAccess server.

$IPv6prefix = (Get-RemoteAccess).ClientIPv6Prefix
New-NetRoute -AddressFamily IPv6 -DestinationPrefix $IPv6prefix -InterfaceAlias “Microsoft IP-HTTPS Platform Interface” -Publish Yes

Next, restart the Remote Access Management service (RaMgmtSvc) using the following PowerShell command.

Restart-Service RaMgmtSvc -PassThru

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Once complete, refresh the management console and the IP-HTTPS error message should be resolved and the operations status should state that it is now working properly.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

 

Additional Information

SSL Certificate Conisderations for DirectAccess IP-HTTPS

DirectAccess Expire IP-HTTPS Certificate and Error 0x800b0101

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803PowerShell is an essential tool for Windows administrators for configuration, task automation, monitoring, reporting, and problem resolution. When troubleshooting DirectAccess connectivity using the IP-HTTPS IPv6 transition technology, the Get-NetIPHttpsConfiguration and Get-NetIPHttpsState PowerShell commands are important for assessing the configuration and current state of the IP-HTTPS connection. When DirectAccess connectivity fails, these are some of the first commands an administrator will use to identify and resolve the issue.

Get-NetIPHttpsState

Get-NetIPHttpsState is especially helpful when IP-HTTPS connectivity fails because it returns an error code and interface status information that can provide clues as to why the connection was not completed successfully.

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

No Output in 1803

Beginning with Windows 10 1803, the DirectAccess administrator will notice that Get-NetIPHttpsState returns no data. The output of Get-NetIPHttpsState is blank.

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

Changes in 1803

As it turns out, this is a bug first introduced in Windows 10 1803 that is the result of a fundamental change in the way in which the IP-HTTPS interface is implemented in Windows. As of this writing, the bug has not been addressed in Windows 10 1803 or 1809.

Workaround

The good news is that there’s an easy workaround for this. Instead of using Get-NetIPHttpsState, the administrator can retrieve essential information about the IP-HTTPS interface using the following netsh command.

netsh interface httpstunnel show interface

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

Additional Information

SSL Certificate Considerations for DirectAccess IP-HTTPS 

Troubleshooting DirectAccess IP-HTTPS Error Code 0x800b0109

Troubleshooting DirectAccess IP-HTTPS Error Code 0x80090326

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Troubleshooting DirectAccess IP-HTTPS Error Code 0x2af9

Troubleshooting DirectAccess IP-HTTPS Error Code 0x800b0101

DirectAccess IP-HTTPS and Symantec SSL Certificates

DirectAccess IP-HTTPS and Symantec SSL CertificatesAn SSL certificate is required to support the IP-HTTPS IPv6 transition technology when configuring DirectAccess. Implementation best practices dictate using a public SSL certificate signed by a trusted third-party vendor such as Entrust, Verisign, DigiCert, and others. SSL certificates issued by a private PKI are acceptable if the client trusts the issuing CA. Self-signed certificates are supported in some deployment scenarios, but their use is generally discouraged. For more detailed information regarding SSL certificate considerations for DirectAccess IP-HTTPS click here.

Symantec Issued Certificates

Symantec is a popular commercial SSL certificate provider that has been commonly used for many years. However, due to integrity issues associated with their PKI management practices, Google and Mozilla announced they will soon be deprecating these certificates. This means users who browse to an HTTPS web site protected with a Symantec SSL certificate will receive a warning in their browser indicating the certificate is not trusted.

DirectAccess IP-HTTPS

It is important to note that there is no impact at all for DirectAccess when the server is configured to use an SSL certificate issued by Symantec. There is nothing you need to do to address this issue in this scenario. However, if a wildcard certificate is installed on the DirectAccess server and it is also used on other public-facing web servers in the organization, it is likely that the certificate will replaced, perhaps by another certificate provider. In this case, DirectAccess IP-HTTPS must be configured to use the new or updated SSL certificate.

Updating IP-HTTPS SSL Certificate

To update the DirectAccess IP-HTTPS SSL certificate, import the SSL certificate along with the private key in to the local computer certificate store on each DirectAccess server. Next identify the thumbprint of the new SSL certificate. Finally, open an elevated PowerShell command window and enter the following command.

$thumbprint = “ssl_cert_thumbprint”
$cert = Get-ChildItem -Path cert:\localmachine\my | where {$_.thumbprint -eq $thumbprint}
Set-RemoteAccess -SslCertificate $cert -PassThru

Be sure to replace “ssl_cert_thumbprint” with the actual thumbprint of your SSL certificate. 😉 In addition, for load-balanced and/or multisite deployments, run these PowerShell commands on each server in the enterprise.

Additional Information

SSL Certificate Considerations for DirectAccess IP-HTTPS

DirectAccess IP-HTTPS Null Cipher Suites Not Available 

DirectAccess IP-HTTPS Performance Issues

DirectAccess IP-HTTPS Performance Issues

DirectAccess IP-HTTPS Performance IssuesPerformance issues with DirectAccess are not uncommon. In fact, there are numerous threads on Microsoft and third-party forums where administrators frequently complain about slow download speeds, especially when using the IP-HTTPS IPv6 transition technology. Based on my experience the problem does not appear to be widespread but occurs with enough regularity that it is worthy of further investigation.

DirectAccess Design

The inherent design of DirectAccess is a major limiting factor for performance. DirectAccess uses a complex and heavy communication channel, with multiple layers of encapsulation, encryption, and translation. Fundamentally it is IPsec encrypted IPv6 traffic, encapsulated in HTTP, and then encrypted with Transport Layer Security (TLS) and routed over IPv4. It is then decrypted, decapsulated, decrypted again, then converted back to IPv4. The high protocol overhead incurred with multiple layers of encapsulation, encryption, and translation result in increased packet fragmentation, which further reduces performance.

DirectAccess Performance

Even under the best circumstances, DirectAccess performance is limited by many other factors, most notably the quality of the network connection between the client and the server. DirectAccess performs reasonably well over high bandwidth, low latency connections. However, network performance drops precipitously as latency increases and packet loss is encountered. This is to be expected given the design of the solution.

Intermediary Devices

It is not uncommon to find intermediary devices like firewalls, intrusion detection systems, malware scanners, and other security inspection devices limit the performance of DirectAccess clients. In addition, many security appliances have bandwidth caps enforced in software for licensing restrictions. Further, incorrect configuration of inline edge devices can contribute to increased fragmentation, which leads to poor performance as well.

Slow Downloads over IP-HTTPS

Many people report that download speeds seem to be artificially capped at 355Kbps. While this seems to be a display bug in the UI, there is plenty of evidence to indicate that, in some scenarios, DirectAccess is incapable of high throughput even over high-quality connections. Some who have deployed DirectAccess and VPN on the same server have reported that download speeds are only limited when using DirectAccess over IP-HTTPS and not with VPN using Secure Socket Tunneling Protocol (SSTP), which also uses TLS. This has led many to speculate that the issue is either a bug or a design flaw in the IP-HTTPS tunnel interface itself.

TCP Window Scaling Issues

In some of the network traces I’ve analyzed I’ve seen evidence that seems to support this theory. For example, a network trace taken when downloading a file over DirectAccess with IP-HTTPS showed the TCP window never scaled beyond 64K, which would seriously impede performance. Interestingly this doesn’t seem to happy when the client uploads files over IP-HTTPS. Clearly something unusual is happening.

Microsoft KB Article

Microsoft recently released a vaguely-worded KB article that appears to lend credence to some of these findings. The article seems to acknowledge the fact there are known issues with DirectAccess performance, but it lacks any specific details as to what the root cause is. Instead, it simply advises migrating to Windows 10 Always On VPN.

Summary

DirectAccess IP-HTTPS performance issues don’t appear to affect everyone, and the problem only seems to apply to file downloads and not to other types of traffic. However, there is mounting evidence of a systemic issue with DirectAccess performance especially over IP-HTTPS. Customers are advised to closely evaluate their uses cases for DirectAccess and if remote clients are frequently required to download large files over a DirectAccess connection, an alternative method of file transfer might be required. Optionally customers can consider evaluating alternative remote access solutions that offer better performance such as Windows 10 Always On VPN or third-party solutions such as NetMotion Mobility.

Additional Resources

Always On VPN and the Future of DirectAccess

What’s the Difference Between DirectAccess and Always On VPN?

NetMotion Mobility as an Alternative to Microsoft DirectAccess

What is the Difference Between DirectAccess and Always On VPN?

Always On VPN Device Tunnel Configuration Guidance Now AvailableDirectAccess has been around for many years, and with Microsoft now moving in the direction of Always On VPN, I’m often asked “What’s the difference between DirectAccess and Always On VPN?” Fundamentally they both provide seamless and transparent, always on remote access. However, Always On VPN has a number of advantages over DirectAccess in terms of security, authentication and management, performance, and supportability.

Security

DirectAccess provides full network connectivity when a client is connected remotely. It lacks any native features to control access on a granular basis. It is possible to restrict access to internal resources by placing a firewall between the DirectAccess server and the LAN, but the policy would apply to all connected clients.

Windows 10 Always On VPN includes support for granular traffic filtering. Where DirectAccess provides access to all internal resources when connected, Always On VPN allows administrators to restrict client access to internal resources in a variety of ways. In addition, traffic filter policies can be applied on a per-user or group basis. For example, users in accounting can be granted access only to their department servers. The same could be done for HR, finance, IT, and others.

Authentication and Management

DirectAccess includes support for strong user authentication with smart cards and one-time password (OTP) solutions. However, there is no provision to grant access based on device configuration or health, as that feature was removed in Windows Server 2016 and Windows 10. In addition, DirectAccess requires that clients and servers be joined to a domain, as all configuration settings are managed using Active Directory group policy.

Windows 10 Always On VPN includes support for modern authentication and management, which results in better overall security. Always On VPN clients can be joined to an Azure Active Directory and conditional access can also be enabled. Modern authentication support using Azure MFA and Windows Hello for Business is also supported. Always On VPN is managed using Mobile Device Management (MDM) solutions such as Microsoft Intune.

Performance

DirectAccess uses IPsec with IPv6, which must be encapsulated in TLS to be routed over the public IPv4 Internet. IPv6 traffic is then translated to IPv4 on the DirectAccess server. DirectAccess performance is often acceptable when clients have reliable, high quality Internet connections. However, if connection quality is fair to poor, the high protocol overhead of DirectAccess with its multiple layers of encapsulation and translation often yields poor performance.

The protocol of choice for Windows 10 Always On VPN deployments is IKEv2. It offers the best security and performance when compared to TLS-based protocols. In addition, Always On VPN does not rely exclusively on IPv6 as DirectAccess does. This reduces the many layers of encapsulation and eliminates the need for complex IPv6 transition and translation technologies, further improving performance over DirectAccess.

Supportability

DirectAccess is a Microsoft-proprietary solution that must be deployed using Windows Server and Active Directory. It also requires a Network Location Server (NLS) for clients to determine if they are inside or outside the network. NLS availability is crucial and ensuring that it is always reachable by internal clients can pose challenges, especially in very large organizations.

Windows 10 Always On VPN supporting infrastructure is much less complex than DirectAccess. There’s no requirement for a NLS, which means fewer servers to provision, manage, and monitor. In addition, Always On VPN is completely infrastructure independent and can be deployed using third-party VPN servers such as Cisco, Checkpoint, SonicWALL, Palo Alto, and more.

Summary

Windows 10 Always On VPN is the way of the future. It provides better overall security than DirectAccess, it performs better, and it is easier to manage and support.

Here’s a quick summary of some important aspects of VPN, DirectAccess, and Windows 10 Always On VPN.

Traditional VPN DirectAccess Always On VPN
Seamless and Transparent No Yes Yes
Automatic Connection Options None Always on Always on, app triggered
Protocol Support IPv4 and IPv6 IPv6 Only IPv4 and IPv6
Traffic Filtering No No Yes
Azure AD Integration No No Yes
Modern Management Yes No (group policy only) Yes (MDM)
Clients must be domain-joined? No Yes No
Requires Microsoft Infrastructure No Yes No
Supports Windows 7 Yes Yes Windows 10 only

Always On VPN Hands-On Training

If you are interested in learning more about Windows 10 Always On VPN, consider registering for one of my hands-on training classes. More details here.

Additional Resources

Always On VPN and the Future of Microsoft DirectAccess

5 Important Things DirectAccess Administrators Should Know about Windows 10 Always On VPN

3 Important Advantages of Windows 10 Always On VPN over DirectAccess

DirectAccess NRPT Configuration with Split DNS

DirectAccess NRPT Configuration with Split DNSThe Name Resolution Policy Table (NRPT) in Windows provides policy-based name resolution request routing for DNS queries. DirectAccess uses the NRPT to ensure that only requests for resources in the internal namespace, as defined by the DirectAccess administrator, are sent over the DirectAccess connection. DNS queries for all other namespaces are sent to the DNS servers defined on the client’s network interface.

Note: This behavior changes when force tunneling is enabled. In this case, all DNS queries are sent over the DirectAccess connection with the exception of the NLS and the DirectAccess server’s public hostname(s). If force tunneling is enabled, the configuration guidance described below is not required.

Split DNS

NRPT configuration is straightforward when the internal and external namespaces are unique. However, when split DNS is used, meaning when the internal and external namespaces are the same, DirectAccess configuration is more challenging. Typically, there may be many resources that should not go over the DirectAccess connection, such as public-facing web servers, email and unified communications servers, federation servers, etc. Without additional configuration, requests for all of these services would go over the DirectAccess connection. That may or may not be desirable, depending on the requirements of the implementation.

DirectAccess Server

One crucial public resource is the DirectAccess server itself. When using split DNS, the DirectAccess implementation’s public hostname will, by default, be included in the internal namespace. In this scenario, the DirectAccess client will fail to establish a connection to the DirectAccess server.

Troubleshooting

When troubleshooting failed connectivity, the output of ipconfig will show the IP-HTTPS tunnel interface media state as “Media disconnected”.

DirectAccess NRPT Configuration with Split DNS

The output of Get-NetIPHttpsState will also return an error code 0x2AF9 with an interface status “Failed to connect to the IPHTTPS server; waiting to reconnect”.

DirectAccess NRPT Configuration with Split DNS

To further troubleshoot this issue, examine the output of Get-NetIPHttpsConfiguration. Test name resolution of the FQDN listed in the ServerURL field. If the issue is related to NRPT configuration, the client will fail to resolve this name to an IP address. Testing from a non-DirectAccess client should resolve correctly, however.

DirectAccess NRPT Configuration with Split DNS

NRPT Configuration

If split DNS is employed, it is necessary to include the DirectAccess server’s public hostname in the NRPT as an exemption. This will cause the DNS query for the public hostname to use public DNS servers, allowing the DirectAccess client to establish a connection successfully.

To resolve this issue, open the Remote Access Management console on the DirectAccess server, highlight DirectAccess and VPN under Configuration, and then click Edit on Step 3. Select DNS, and then double-click on an empty row in the table.

DirectAccess NRPT Configuration with Split DNS

Enter the public hostname for the DirectAccess deployment in the DNS suffix field (the public hostname can be found by clicking Edit on Step 2). Do NOT specify a DNS server. Click Apply, click Next twice, and then click Finish.

DirectAccess NRPT Configuration with Split DNS

Note: For multisite deployments, be sure to include the public hostname for each entry point in the enterprise. Also, if multisite is configured to use GSLB, include the GSLB hostname as well.

PowerShell

Alternatively, you can run the following PowerShell commands to automatically configure the NRPT for split DNS. For multisite deployments, be sure to run these commands on at least one DirectAccess server in each site.

$hostname = Get-RemoteAccess | Select-Object -ExpandProperty ConnectToAddress
Add-DAClientDnsConfiguration -DnsSuffix $hostname -PassThru

If multisite is configured to use GSLB, run the following PowerShell commands on one DirectAccess server in the enterprise.

$gslbfqdn = Get-DAMultiSite | Select-Object -ExpandProperty GslbFqdn
Add-DAClientDnsConfiguration -DnsSuffix $gslbfqdn -PassThru

Additional Information

Troubleshooting DirectAccess IP-HTTPS Error 0x2af9

DirectAccess DNS Not Working Properly

DirectAccess DNS Records Explained

Troubleshooting Name Resolution Issue on DirectAccess Clients

DirectAccess IP-HTTPS Null Cipher Suites Not Available

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableMicrosoft first introduced support for null cipher suites for the IP-HTTPS IPv6 transition technology in Windows Server 2012, and it is supported for DirectAccess in Windows 8.x and Windows 10 clients. Using null cipher suites for IP-HTTPS eliminates the needless double encryption that occurs when using encrypted cipher suites. DirectAccess is a unique workload where SSL/TLS encryption isn’t really required because the payload being transported in HTTPS is already encrypted.

No Encryption by Design

When supporting Windows 8.x and Windows 10 clients, ensuring null cipher suites (TLS_RSA_WITH_NULL_SHA and TLS_RSA_WITH_NULL_SHA256) are enabled and operational is crucial to providing the highest levels of performance and scalability for the remote access solution. When following implementation best practices, this isn’t really an issue. However, in some cases null cipher suites may be disabled. This will result in reduced scalability and degraded performance for Windows 8.x and Windows 10 clients.

Validating SSL/TLS Configuration

The easiest way to verify that null cipher suites are being offered by the DirectAccess server is to use the Qualys SSL Labs server test site. Ideally you should see a result similar to this.

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableFigure 1. Qualys SSL Labs server test site results for properly configured DirectAccess server.

Don’t be alarmed by the overall rating “F”. That happens because the Qualys test site is designed to test web servers where using null cipher suites would be a serious security issue. As I stated previously, the DirectAccess workload is unique in that its HTTPS payload is already encrypted, so using null cipher suites is acceptable in this scenario.

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableFigure 2. Qualys SSL Labs server test site results for properly configured DirectAccess server showing support for null SSL/TLS cipher suites.

Null Cipher Suites Missing

When performing the Qualys SSL labs server test on a DirectAccess server, an overall rating of “A” is not desirable and indicates the DirectAccess server is misconfigured. This is caused by the lack of support for null cipher suites.

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableFigure 3. Qualys SSL Labs server test site results for misconfigured DirectAccess server.

Common Causes

Null cipher suites for SSL and TLS can be disabled for a variety of reasons. Below are some of the most common causes for the lack of support for null cipher suites for DirectAccess.

Self-Signed Certificates – Using the Getting Started Wizard (simplified deployment) will configure DirectAccess using a self-signed certificate for IP-HTTPS. Using a self-signed certificate is discouraged for numerous reasons, most importantly because it disables support for null cipher suites.

Security Hardening – Security administrators may proactively disable support for null cipher suites in a misguided effort to “improve security” for DirectAccess. While this is acceptable and recommended on a web server, it is not advisable to disable null cipher suites on a DirectAccess server.

SSL Certificate Signing Algorithm – Using an SSL certificate signed with an Elliptical Curve (EC) key as opposed to an RSA key will result in the loss of support for null cipher suites for IP-HTTPS. High security/assurance certificates signed with EC keys are not recommended for use on DirectAccess servers and should be avoided if possible.

DirectAccess Configuration Options – Enabling One-Time Password (OTP) authentication on the DirectAccess server will also result in a loss of support for null cipher suites. Also, adding additional roles to the DirectAccess server such as client-based VPN or the Web Application Proxy (WAP) can also result in null cipher suites being disabled.

Summary

Null cipher suites are implemented by design on DirectAccess servers to enhance performance for Windows 8.x and Windows 10 clients and improve overall scalability for the implementation. They eliminate the pointless double encryption of DirectAccess communication, which itself is already encrypted. For optimal performance and scalability, be sure to follow implementation best practices and use a PKI-managed (public or private) SSL certificate signed with an RSA key (SHA-256 recommended). Resist the urge to “harden” the DirectAccess server by disabling support for null cipher suites, and avoid the use of SSL certificates signed with EC keys. In addition, carefully consider DirectAccess deployment options such as OTP authentication and consider deploying roles such as VPN and WAP on a separate server.

Additional Information

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

DirectAccess and FIPS Compliant Algorithms for Encryption

SSL Certificate Considerations for DirectAccess IP-HTTPS 

 

 

DirectAccess and FIPS Compliant Algorithms for Encryption

DirectAccess administrators may be required to enable Federal Information Processing Standards (FIPS) compliant algorithms for encryption, hashing, and signing on DirectAccess servers to meet certain regulatory and compliance requirements.

DirectAccess and FIPS Compliant Algorithms for Encryption

Performance Impact

Be advised that enabling this setting will disable support for null cipher suites for the IP-HTTPS IPv6 transition technology. This will result in the double encryption of all DirectAccess client communication, which will increase resource consumption on DirectAccess servers. This leads to reduced scalability and degraded performance for all DirectAccess clients, including Windows 8.x and Windows 10.

If enabling FIPS compliant cannot be avoided, additional compute capacity (CPU and memory) should be provisioned. For best results, add additional servers to distribute the workload and improve performance for DirectAccess clients.

Always On VPN

If you’re looking for better security and performance, consider migrating to Windows 10 Always On VPN. Always On VPN fully supports FIPS compliant algorithms without the negative performance impact associated with DirectAccess. If you’d like to learn more about security and Always On VPN, fill out the form below and I’ll get in touch with you.

Additional Resources

Always On VPN and the Future of DirectAccess 

5 Things DirectAccess Administrators Should Know About Always On VPN 

3 Important Advantages of Always On VPN over DirectAccess 

%d bloggers like this: