All posts for the month November, 2016

Multiple DirectAccess servers can be deployed in a load-balanced cluster to eliminate single crucial points of failure and to provide scalability for the remote access solution. Load balancing can be enabled using the integrated Windows Network Load Balancing (NLB) or an external physical or virtual load balancer.

NLB Drawbacks and Limitations

NLB is often deployed because it is simple and inexpensive. However, NLB suffers from some serious drawbacks that limit its effectiveness in all but the smallest deployments. For example, NLB uses network broadcasts to communicate cluster heartbeat information. Each node in the cluster sends out a heartbeat message every second, which generates a lot of additional network traffic on the link and reduces performance as more nodes are added. Scalability is limited with NLB too, as only 8 nodes are supported, although the practical limit is 4 nodes. Further, NLB supports only round-robin connection distribution.

DirectAccess is an IPv6 only solution, at least from the perspective of the client. When the DirectAccess client is remote, it communicates with the DirectAccess server using IPv6 exclusively. IPv6 transition technologies are used to enable this connectivity when the DirectAccess server and/or client are on the pubic IPv4 Internet.

IP-HTTPS

One of the IPv6 transition technologies used by DirectAccess is IP-HTTPS. With IP-HTTPS, IPv6 traffic is encapsulated in HTTP and delivered to the DirectAccess server using IPv4. IP-HTTPS is used exclusively when the DirectAccess server is located behind an edge firewall performing network address translation.

SSL Certificate

To support IP-HTTPS, an SSL certificate is installed on each DirectAccess server. The SSL certificate is commonly issued by a public certification authority, but it can also be issued by an internal PKI. The SSL certificate used for IP-HTTPS can and does expire, and when it does it will prevent any DirectAccess connection from being established using this transition technology.

Troubleshooting

When troubleshooting DirectAccess connectivity via IP-HTTPS, the first thing the administrator will notice is that the media state for the DirectAccess client’s IP-HTTPS tunnel adapter interface is shown as disconnected.

In addition, the Get-NetIPHttpsState PowerShell command returns an error code 0x800b0101 indicating Failed to connect to the IP-HTTPS server; waiting to reconnect.

Err.exe translates this error to CERT_E_EXPIRED, indicating that the SSL certificate is no longer valid.

Viewing the IP-HTTPS SSL certificate is not possible using a web browser. Instead, use Nmap and the ssl-cert script to view the certificate.

nmap.exe -n -Pn -p443 [FQDN] –script ssl-cert

In the Operations Status window of the Remote Access Management console on the DirectAccess server, the IP-HTTPS status is listed as Critical. Details show IP-HTTPS not working properly, with an error stating the IP-HTTPS certificate is not valid, and clearly indicating that the certificate is expired.

The IP-HTTPS status can also be viewed at the command line by issuing the following command in an elevated PowerShell command window.

Simply renewing the SSL certificate is not sufficient to restore IP-HTTPS connectivity for remote DirectAccess clients. The DirectAccess configuration must also be updated to use the new certificate. In the Remote Access Management console, highlight DirectAccess and VPN under Configuration and then click Edit on Step 2 (for load-balanced or multisite DirectAccess deployments, first highlight the individual server and then click Configure Server Settings).Click Network Adapters, click Browse, and then select the new SSL certificate.

Click Ok, Next, and then Finish twice and Apply. Repeat these steps for each server in the load-balanced cluster, and for all servers in all entry points in the enterprise.

Alternatively, the IP-HTTPS certificate can be updated in the DirectAccess configuration by opening an elevated PowerShell command window and entering the following commands.

Important Note: Be sure to execute these commands on each DirectAccess server in the load-balanced cluster, and for all servers in all entry points in the enterprise.

Self-Signed Certificates

When DirectAccess is deployed using the Getting Started Wizard (GSW), also known as a “simplified deployment“, a self-signed certificate is used for IP-HTTPS. By default, this certificate expires 5 years after it is created. The expiration of a self-signed certificate presentsa unique challenge. Although the self-signed certificate can’t be renewed, it can be re-created or cloned using the New-SelfSignedCertificate PowerShell command. However, DirectAccess clients will not trust this new certificate until they receive the updated client settings via group policy. DirectAccess clients outside the network will not be able to establish IP-HTTPS connections until they receive these new policies. When they attempt to connect to the DirectAccess server without first updating group policy, the IP-HTTPS status will indicate an error code 0x800b0109 which translates to CERT_E_UNTRUSTEDROOT.

If the expired self-signed certificate is replaced with another self-signed certificate (not recommended), DirectAccess clients will have to come back to the internal network or connect remotely via client-based VPN to update group policy and receive the new DirectAccess client settings. A better alternative is to replace the expired self-signed certificate with a public SSL certificate that matches the existing public hostname. This will allow remote clients to reestablish DirectAccess connectivity without the need to udpate group policy first.

Summary

Certificate expiration must be monitored closely to ensure the highest level of availability for the DirectAccess remote access solution. Certificate auto enrollment can be leveraged to ensure that IPsec certificates are automatically renewed prior to expiration. However, the IP-HTTPS certificate must be renewed manually and requires additional configuration after it has been updated.

Microsoft has historically not supported DirectAccess running on Windows Server in the Microsoft Azure public cloud. In the past, this was due to limitations imposed by the underlying cloud infrastructure, as I documented here. When Microsoft moved from the old service manager model (classic) to the newer resource manager infrastructure, many of the issues that prevented the DirectAccess workload from being stable were resolved. There are still some fundamental limitations to deploying DirectAccess in Azure as I documented here, but for the most part it was a workable solution. In fact, Microsoft even updated their support statement for DirectAccess on Azure, quietly removing it from the unsupported roles list in July 2016.

Sadly, Microsoft has reversed their decision on the support of DirectAccess in Azure. As many of you have noticed or commented on some of my posts, Microsoft recently added clarification on support for remote access on Windows Server in Azure, explicitly indicating that DirectAccess was not included in Remote Access support.