An important scalability improvement introduced in Windows Server 2012 DirectAccess is the support for null encryption for Windows 8.x DirectAccess clients using the IP-HTTPS IPv6 transition protocol. Using null encryption eliminates the overhead imposed by the needless encryption of DirectAccess IPsec communication, which itself is already encrypted. This double encryption significantly increases resource consumption on both the client and server, and can have a negative impact on scalability and performance. When a Windows 8.x client establishes an IP-HTTPS connection to a Windows Server 2012 or 2012 R2 DirectAccess server, it will negotiate only cipher suites that use null encryption. Windows 7 clients cannot take advantage of null encryption and continue to use encrypted cipher suites.
Note: It is possible to replicate some of the benefits of null encryption for Windows 7 clients using an Application Delivery Controller (ADC) such as the F5 Networks Local Traffic manager (LTM) to perform SSL offloading. See SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP for more information.
For both performance and scalability, the best deployment results are achieved when using a Windows Server 2012 or 2012 R2 DirectAccess server and Windows 8.x clients. However, null encryption for IP-HTTPS is no longer available in the scenario where client-based remote access VPN is configured on the same server as DirectAccess. As you can see below, when DirectAccess is deployed by itself, the server offers null encryption cipher suites which Windows 8.x clients can take advantage of.
Figure 1 – Cipher Suites for DirectAccess Only
However, when the client-based remote access VPN role is enabled on the same DirectAccess server, null encryption cipher suites are no longer available for use by DirectAccess clients.
Figure 2- Cipher Suites for DirectAccess and VPN
This occurs because the Secure Sockets Tunneling Protocol (SSTP) client-based remote access VPN protocol requires SSL/TLS encryption to provide confidentiality for tunneled network communication. Unfortunately, disabling support for SSTP alone does not return null encryption cipher suites for DirectAccess clients unless the VPN role is removed completely. Of course none of this is readily apparent to the administrator, who may be completely unaware that they’ve sacrificed the efficiency of IP-HTTPS null encryption for Windows 8.x clients in order to support SSTP for client-based remote access VPN clients.
If you plan to support Windows 8.x clients using IP-HTTPS and want to take full advantage of the scalability and performance benefits associated with IP-HTTPS null encryption in Windows Server 2012/R2 DirectAccess, it is recommend that you deploy client-based remote access on a separate system.
Posted by Richard Hicks on June 24, 2014
The Network Location Server (NLS) is a critical infrastructure component for DirectAccess deployments. The NLS is used by DirectAccess clients to determine if the client is located inside or outside of the corporate network. If the NLS becomes unavailable, DirectAccess clients that are already outside the corporate network are unaffected. However, DirectAccess clients that are inside the corporate network will mistakenly believe that they are outside and the Name Resolution Policy Table (NRPT) will be enabled, forcing name resolution requests for hosts in the internal namespace to be sent to the DNS64 service running on the DirectAccess server. If the DirectAccess server is unreachable from the internal network (a common scenario for a variety of reasons), DirectAccess clients inside the corporate network will be unable to connect to any local network resources by name until the NLS is once again reachable.
Configuring the Network Connectivity Assistant to Allow DirectAccess clients to use local name resolution does not resolve this issue. Although it sounds intuitive, it doesn’t resolve this specific issue where the NLS is unreachable.
When the option to Allow DirectAccess clients to use local name resolution is enabled, the client can only choose to disconnect (use local name resolution) after it has successfully established a connection to the DirectAccess server. If the DirectAccess connection shows that it is still connecting, the option to disconnect is not available.
To address this issue, Microsoft has released update KB2953212 for Windows 8.x clients that allows the disabling of the NRPT regardless if the client has successfully established a DirectAccess connection. With this update, if a DirectAccess client is located on the corporate network and is unable to reach the NLS, the user will be able to disable the NRPT (effectively disconnect DirectAccess) and once again connect to resources on the corporate network.
This update is certainly no excuse not to deploy your NLS in a highly-available configuration using Windows Network Load Balancing (NLB) or a third-party external load balancer (hardware or software), but it can be a life-saver if your NLS becomes unavailable for any reason. I’d recommend deploying this update to all of your Windows 8.x DirectAccess clients soon.
For more information and to download the hotfix, click here.
Posted by Richard Hicks on May 15, 2014
Microsoft recently released a hotfix to resolve an issue where Windows 7 SP1 DirectAccess clients fail to connect to a DirectAccess server with the IP-HTTPS IPv6 transition protocol and using One-Time Password (OTP) authentication via the DirectAccess Connectivity Assistant (DCA) 2.0. In this scenario you may receive an HTTP 403 error from the DirectAccess server in response to the certificate signing requests and a 0x80040001 error after entering the OTP.
You can learn more about the hotfix for DCA 2.0 on Windows 7 SP1 and download the associated hotfix here.
Posted by Richard Hicks on May 9, 2014
I’m very excited to announce that I’ll be presenting at TechDays in San Francisco on June 5 & 6, 2014! I’ll be delivering a session on cloud and remote access networking in Windows Server 2012 R2. Not only will this session include DirectAccess, but I will also be covering client-based VPN, site-to-site VPN, and the new Web Application Proxy role. If time permits, I might even sneak in some details about Workplace Join and Work Folders. Registration is open now, so sign up soon. Hope to see you there!
Posted by Richard Hicks on May 5, 2014
When troubleshooting DirectAccess connectivity issues on Windows 8.x clients you may find the option to generate advanced troubleshooting logs missing. On Windows 8 clients, the Collect Logs button will be grayed out. On Windows 8.1 clients it will be missing altogether.
This issue is caused by not providing an e-mail address when configuring the DirectAccess server.
To resolve this issue, supply an e-mail address and apply the configuration. The e-mail address does not necessarily have to be valid. It simply has to be present in order to have the option to generate DirectAccess advanced troubleshooting logs. After the clients have updated their group policy, the option to collect advanced troubleshooting logs will be available.
Posted by Richard Hicks on April 22, 2014
Microsoft recently published knowledge base article KB2928193, announcing the availability of a Routing and Remote Access Service (RRAS) rules update for the Best Practices Analyzer (BPA) in Windows Server 2012 R2. If you are using Windows Server 2012 R2 for client-based remote access VPN or site-to-site VPN, you are encouraged to install this update prior to executing a BPA scan. You can download the update here.
Posted by Richard Hicks on April 9, 2014
A while back I wrote about an issue that I encountered when attempting to configure DirectAccess in Windows Server 2012 R2 using a dedicated Network Location Server (NLS). In this deployment scenario, the Remote Access Setup Wizard would fail and return the following error message:
The configuration was rolled back successfully. The URL specified for the network location server cannot be resolved to an IP address.
Upon further investigation, the NLS server name does indeed resolve correctly, and clicking validate when defining the NLS works without issue. Originally I proposed a workaround that involved changing a registry setting. However, after working with Microsoft to identify the issue they have released a hotfix to resolve this issue correctly. You can download the hotfix here.
Posted by Richard Hicks on March 26, 2014
When Windows Server 2012 is configured for DirectAccess or client-based remote access Virtual Private Networking (VPN), a memory leak may occur in the Remote Access Management service when remote clients access the Internet using the DirectAccess or VPN connection. Microsoft knowledgebase article KB2895930 describes the issue in detail and includes a link to the hotfix to resolve this issue.
Posted by Richard Hicks on March 25, 2014
I’m happy to announce that I have recently re-joined the team at Celestix Networks! I’m excited for the opportunity to once again work with the industry leading Microsoft OEM hardware appliance manufacturer. Historically, Celestix has produced the bestselling line of edge security and remote access products based on Microsoft Forefront Threat Management Gateway (TMG) 2010 and Forefront Unified Access Gateway (UAG) 2010. With these products now formally end-of-life, we’ll be focusing on delivering the same advanced capabilities for next-generation DirectAccess solutions, as well as some new solutions focused on enabling public cloud integration and providing secure remote access for Bring Your Own Device (BYOD) scenarios. Visit the Celestix web site more information on our current edge security, remote access, and strong authentication offerings. Also, connect with me on social media to receive the latest updates on our upcoming cloud security solutions.
Posted by Richard Hicks on March 25, 2014
To aid in troubleshooting Windows DirectAccess client configuration and connectivity, Microsoft recently made available the Windows DirectAccess Client Troubleshooting Tool. The tool, which is a portable executable based on the .NET Framework and does not require installation, operates by performing a series of tests and health checks on a connected DirectAccess client. As of this release, the troubleshooting tool checks network interface configuration, Network Location Server (NLS) reachability, IP connectivity and the status of transition technologies, Windows Firewall with Advanced Security configuration, computer certificate status, as well as network connectivity over the infrastructure and user IPsec DirectAccess tunnels.
The tool also features an optional debug mode that provides highly detailed information gathered from each of the tests executed.
The tool is supported on both Windows 7 and Windows 8.x clients. If you implement or support DirectAccess, this utility will certainly speed up your troubleshooting by providing deep insight in to the configuration and current connectivity status for your DirectAccess clients. You can download the Microsoft DirectAccess client troubleshooting tool here.
Posted by Richard Hicks on February 24, 2014