DirectAccess Client and Server Settings GPOs Deleted

Microsoft Windows Server Active DirectoryFor DirectAccess deployments where domain controllers are running Windows Server 2003 or Windows Server 2003 R2 using the File Replication Service (FRS) for replication, DirectAccess client and server settings Group Policy Objects (GPOs) may be deleted. If these GPOs are deleted, DirectAccess connectivity will be disrupted. If the GPOs cannot be recovered via backup, it will be necessary to rebuild the entire DirectAccess deployment from scratch.

Microsoft recently updated their DirectAccess Unsupported Configurations documentation to reflect new guidance for DirectAccess deployments where the FRS is used for the distribution of Active Directory GPOs. DirectAccess is no longer supported in environments where FRS is used for SYSVOL replication.

What this means is that if you plan to deploy DirectAccess, domain controllers must be running Windows Server 2008 or later, and Distributed File System Replication (DFS-R) must be used for replication.

More details can be found here.

DirectAccess Consulting Services Now Available

Microsoft Certified Solutions Associate (MCSA)For the last five years I’ve been helping organizations large and small deploy DirectAccess. During that time I have amassed a wealth of knowledge and experience with this unique technology. DirectAccess is not trivial to install, configure, or troubleshoot. Also, it’s easy to make mistakes in the planning and design phase that can turn in to serious issues later in the deployment. To make matters worse, many organizations are deploying DirectAccess for the first time, and without essential guidance they are prone to making common mistakes or choosing configuration options that are less than optimal both in terms of supportability and performance.

Having deployed DirectAccess for some of the largest companies in the world, there isn’t much I haven’t already encountered. If you are looking for the best chance of success for your DirectAccess deployment, consider a consulting engagement with me. I can provide assistance with all facets of DirectAccess implementation including planning and design, installation, configuration, and troubleshooting. Consulting services at reasonable rates are available for all types of DirectAccess work including:

  • New DirectAccess installations
  • Migration from previous versions of DirectAccess
  • Upgrade or expansion of existing DirectAccess deployment
  • Enterprise planning and design for large-scale, multisite DirectAccess deployments
  • DirectAccess high availability (local and geographic)
  • Manage-out for DirectAccess with external hardware load balancers and/or multisite configuration
  • Multisite DirectAccess with geographic redundancy for Windows 7 clients
  • Existing DirectAccess design review and security assessment
  • Windows Server 2012 R2 client-based VPN configuration
  • DirectAccess client connectivity troubleshooting
  • DirectAccess training

These services and many more can be performed on-site or remotely. If you are interested in obtaining my services, drop me a note at for more details.

DirectAccess Single NIC Load Balancing with Kemp LoadMaster

Kemp Technologies Load BalancersEarlier this year I authored the Windows Server 2012 R2 DirectAccess Deployment Guide for Kemp LoadMaster load balancers. The documentation described in detail how to configure the Kemp LoadMaster to provide load balancing for DirectAccess when configured with two network adapters. It also assumed that the DirectAccess server is configured to use the LoadMaster as its default gateway.

There are many scenarios in which the DirectAccess server does not use the LoadMaster as its default gateway, most commonly deployments where the DirectAccess server is configured with a single NIC. To support load balancing for DirectAccess configured with a single NIC, it will be necessary to make some changes to the LoadMaster configuration to enable load balancing support for this scenario.

To configure the Kemp LoadMaster for load balancing DirectAccess single NIC deployments, follow the guidance to create the virtual service as documented. After creating the virtual service for DirectAccess, expand Standard Options, deselect Transparency, and then select Subnet Originating Requests.

DirectAccess Single NIC Load Balancing with Kemp LoadMaster

This will configure the LoadMaster to forward traffic to the DirectAccess server using the internal IP address of the LoadMaster as the source IP address for the connection instead of the original public address of the client. This allows the DirectAccess server to return DirectAccess traffic to the LoadMaster without having to use it as its default gateway.

DirectAccess DNS Records Explained

After installing and configuring DirectAccess with Windows Server 2012 R2, several new host records appear automatically in the internal DNS (assuming dynamic DNS is supported, of course). One of them is directaccess-corpConnectivityHost and the other is directaccess-WebProbeHost. These DirectAccess DNS entries are used by Windows 8 and later clients for connectivity checks at various stages of DirectAccess connection establishment.

DirectAccess DNS Records Explained

Figure 1 – DirectAccess DNS records for IPv4-only network.

DirectAccess DNS Records Explained

Figure 2 – DirectAccess DNS records for dual-stack IPv4/IPv6 network.

Here is a detailed description for each of these DirectAccess DNS entries.

directaccess-corpConnectivityHost – This DNS host record includes both A and AAAA records when deployed on IPv4-only networks. Its A host record resolves to, which is the IPv4 loopback address. Its AAAA host record resolves to an IPv6 address that is a combination of the DirectAccess NAT64 IPv6 prefix and 7F00:1 (the hexadecimal equivalent of When DirectAccess is configured on a network with native IPv6, the directaccess-corpConnectivityHost DNS record will only include a single AAAA record resolving to ::1.

This host record is used by the DirectAccess client to determine if name resolution for the corporate namespace is working after the IPv6 transition tunnel (6to4, Teredo, or IP-HTTPS) has been established. It does this by attempting to resolve the hostname directaccess-corpConnectivityHost.<corp_fqdn> (e.g. to an IPv6 address that it expects (the organization’s NAT64 prefix + 7F00:1 or ::1). If it does not resolve, or resolves to a different address, the client will assume that the transition tunnel was not established successfully and, if possible, fall back to another IPv6 transition protocol and repeat the process until it is successful.

Note: The DirectAccess client does not attempt to connect to the IP address resolved by directaccess-corpConnectivityHost. It simply compares the IP address returned by the query to the expected address (NAT64 prefix + 7F00:1 or ::1).

directaccess-WebProbeHost – This DNS host record includes only A records and resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. If load balancing is enabled, this host record will resolve to the virtual IP address (VIP) of the array. For multisite deployments there will be directaccess-WebProbeHost A host records for each entry point in the organization.

This host record is used by the DirectAccess client to verify end-to-end corporate network connectivity over the DirectAccess connection. The client will attempt to connect to the directaccess-WebProbeHost URL using HTTP. If successful, the DirectAccess connectivity status indicator will show Connected.

If any of these DirectAccess DNS records are missing or incorrect, a number of issues may arise. If the directaccess-corpConnectivityHost host record is missing or incorrect, DirectAccess IPv6 transition tunnel establishment may fail. If the directaccess-WebProbeHost record is missing or incorrect, the DirectAccess connectivity status indicator will perpetually show Connecting. This commonly occurs when an external load balancer is used and a virtual server isn’t created for the web probe host port (TCP 80). In addition, these DirectAccess DNS entries are not static and may be deleted if DNS scavenging of stale resource records is enabled on the DNS server.

Provisioning DirectAccess Clients using Windows Offline Domain Join

DirectAccess on Microsoft WindowsOne of the many advantages DirectAccess has over traditional client-based VPN is the ease with which DirectAccess clients can be provisioned. DirectAccess does not require any special software to be installed on the client. Everything that DirectAccess needs is included as part of the operating system. This makes onboarding a client for DirectAccess is as simple as adding a computer account to the DirectAccess client security group in Active Directory. That’s it! As soon as the client restarts it will be configured for DirectAccess.

This process works great if the client computer is already joined to the domain and has access to the LAN (either directly connected or via client-based VPN). But what if the client is in a remote location and isn’t yet joined to the domain? Offline Domain Join (ODJ) can help. ODJ is a feature of the Windows operating system introduced with Windows 7 and Windows Server 2008 R2 that allows an administrator to join a host to the domain without requiring the host to contact a domain controller. Beginning with Windows 8 and Server 2012, ODJ supports new command-line parameters that allow the administrator to configure the client machine to include DirectAccess certificates and policies.

Note: ODJ will only provision DirectAccess certificates and policies for Windows 8.x and later clients. ODJ with Windows 7 clients is limited to joining the domain only. ODJ cannot provision Windows 7 clients for DirectAccess.

To use ODJ to provision a DirectAccess client, first create a computer account in Active Directory and then add the account to the DirectAccess client security group. Next, open an elevated Command Prompt window on the DirectAccess server and execute the following command.

djoin.exe /provision /machine <client_machine_name>
/domain <domain_name> /policynames
<DirectAccess_client_settings_ GPO_name>
/certtemplate <DirectAccess_certificate_template_name>
/savefile <filename> /reuse

For example:

djoin.exe /provision /machine client5
/policynames "DirectAccess Client Settings"
/certtemplate machine
/savefile c:\users\rhicks\desktop\provision.txt /reuse

Provisioning DirectAccess Clients using Windows Offline Domain Join

On the DirectAccess client, copy the ODJ provisioning file locally. Open an elevated Command Prompt window and execute the following command.

djoin.exe /requestodj /loadfile <filename>
/windowspath <Windows_directory> /localos

For example:

djoin.exe /requestodj /loadfile c:\users\setup\provision.txt
/windowspath C:\Windows /localos

Provisioning DirectAccess Clients using Windows Offline Domain Join

After a restart, the client will be joined to the domain and now be able to establish a DirectAccess connection to the corporate network. Users can now log on with their domain credentials.

DirectAccess and the Free Kemp Technologies LoadMaster

Kemp Technologies Load BalancersBeginning with Windows Server 2012, DirectAccess includes native support for external load balancers. Where high availability is required (which is most deployments!) the use of an external load balancer (physical or virtual) has many advantages over Windows Network Load Balancing (NLB).

While NLB is easy to configure, it is not without serious drawbacks. NLB relies on network broadcasts, which limits its effectiveness in some environments. In addition, NLB supports only a single load distribution mode, which is round robin. NLB also lacks a convenient monitoring interface.

A dedicated load balancing solution provides more robust load balancing and better, more granular traffic control than NLB. Along with this greater control comes increased traffic visibility, with most solutions providing details and insight in to node health, status, and performance. Many solutions also offer Global Server Load Balancing (GSLB) support, which enhances geographic redundancy and offers improvements when performing automatic site selection in multisite deployments.

Often the barrier to adoption for a dedicated external load balancer is cost. Many of the leading solutions are incredibly powerful and feature-rich, but come with a substantial price tag. The Kemp Technologies LoadMaster Load Balancers solution is an excellent, cost-effective alternative and works quite well providing load balancing support for DirectAccess. And to make things even more interesting, they recently announced a completely FREE version of their commercial load balancing product.

The Free Kemp Technologies LoadMaster Load Balancer is fully functional and supported for use in production environments. It provides full layer 4-7 support and includes reverse proxy, edge security, web application firewall (WAF) functionality, and GSLB. It can be installed on most major virtualization platforms including Microsoft Hyper-V, VMware, and more. The free LoadMaster is also available in Kemp Technologies LoadMaster Load Balancer on the Microsoft Azure Public Cloud Platform, as well as the VMware and Amazon public cloud platforms.

The free LoadMaster does have some restrictions, however. For example, you cannot create high availability clusters of LoadMasters. Also, the free LoadMaster is limited in terms of network throughput (20Mbps) and SSL/TLS transaction per second (50, using 2048 bit keys). There is also a limit on the number of virtual servers you can create (1000). The free LoadMaster must also have access to the Internet as it must be able to call home to validate its license every 30 days. You can find a complete model comparison matrix between the free and commercial Kemp LoadMasters Kemp LoadMaster Comparison Chart.

As the free version of the Kemp LoadMaster does not support clustering, technically you still have a single point of failure. However, it can still deliver a net improvement in stability and uptime, as the LoadMaster is a purpose-built platform that requires much less servicing and maintenance than a typical Windows server.

DirectAccess Deployment Guide for Kemp LoadMaster Load BalancersFor detailed information about configuring the Kemp LoadMaster to provide load balancing services for DirectAccess, be sure to download the DirectAccess Deployment Guide for Kemp LoadMaster Load Balancers. And if you end up liking the free Kemp LoadMaster load balancer (and I’m confident you will!) you can always upgrade to the full commercial release at any time.

For more information about the free Kemp LoadMaster load balancer, click Free Kemp LoadMaster Load Balancer.

DirectAccess and the TLS Logjam Attack

Another critical flaw affecting Transport Layer Security (TLS) was discovered recently that could put some organizations at risk. The “Logjam” attack exploits a weakness in how the Diffie-Hellman key exchange is used. An attacker, acting as a man-in-the-middle, can potentially force a downgrade of the TLS connection, resulting in the use of weak cryptography. The Qualys SSL Labs SSL Server Test has been updated to identify this vulnerability. When testing a DirectAccess server you will receive the following warning message.

“This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.”

DirectAccess and the Logjam Attack

DirectAccess leverages SSL and TLS as part of the IP-HTTPS IPv6 transition protocol, which is used to tunnel IPv6 packets over the IPv4 Internet. These IPv6 packets are encrypted using IPsec. If an attacker were to break the SSL/TLS connection they would gain nothing. Because of this, a dedicated DirectAccess server is unaffected by the Logjam attack. Mitigating it would provide no additional protection, so you can safely ignore the warning about weak DH key exchange parameters being supported.

However, if DirectAccess has been configured to use one-time password (OTP) authentication, the client-based VPN role has been enabled and configured, or the Web Application Proxy (WAP) role has been installed on the DirectAccess server, then the Logjam attack represents a serious risk and should be mitigated. Also, in some cases it may be desirable to make this change on a dedicated DirectAccess server just to prevent an audit finding and avoid having to explain why the DirectAccess workload would be unaffected by this attack.

To mitigate this vulnerability it will be necessary to remove support for cipher suites that use the Diffie-Hellman key exchange protocol on the DirectAccess server. This is accomplished by opening the Local Group Policy Editor (gpedit.msc) on the DirectAccess server and expanding Computer Configuration, Administrative Templates, and Network. Select SSL Configuration Settings and then double-click SSL Cipher Suite Order. Select Enabled and then replace the default list of cipher suites with the following list.


DirectAccess and the Logjam Attack

Once complete, restart the DirectAccess server. The Qualys SSL Labs server test should no longer give a warning about the use of weak Diffie-Hellman keys. In addition, this reordering and optimization of cipher suites will also improve the protocol support and key exchange scores, as shown here.

DirectAccess and the Logjam Attack

As a reminder, and overall rating of “F” is expected when testing a dedicated DirectAccess server. By design, DirectAccess provides support for null cipher suites to improve scalability and performance for Windows 8.x and later DirectAccess clients. More details here.

Upcoming DirectAccess Training Events in 2015

Did you attend the DirectAccess session at this year’s Microsoft Ignite conference? Of course not. There wasn’t one! Not to worry though, as I will be presenting DirectAccess sessions at several different events around the country later this year.

Techmentor ConferenceIf you’re looking for deep-dive DirectAccess training, I’ll be delivering a three-hour training session at the TechMentor Conference in Redmond, WA. The event takes place August 3-7, 2015. Don’t forget to use registration code TMRSK05 to save $500.00! If you are on the east coast of the U.S. you’ll be happy to hear that I will also be presenting a DirectAccess session at the TechMentor Conference to be held at the Royal Pacific Resort at Universal in Orlando, FL, from November 16-20. I’ll provide more details on this event soon.

IT Dev ConnectionsIn addition I will be delivering a few DirectAccess sessions at IT/Dev Connections in Las Vegas, NV. I’ll be covering topics such as DirectAccess design and configuration, as well as implementation tips, tricks, and best practices. This event will be held at the Aria Hotel and Resort from September 14-17, 2015.

Hope to see you at one of these great events this year!

DirectAccess Clients Unable to Access Citrix XenApp Resources

DirectAccess Clients Unable to Access Citrix XenApp ResourcesAfter implementing DirectAccess, remote connected clients may be unable to access resources published by Citrix XenApp. This can occur because the configuration for Citrix XenApp returns IPv4 addresses instead of hostnames to DirectAccess clients. As DirectAccess uses IPv6 exclusively for client to gateway communication, the connection fails.

To resolve this issue, it is necessary to configure Citrix XenApp to return fully qualified domain names (FQDNs) instead of IPv4 addresses. This will allow the DirectAccess DNS64 service to function properly and return an IPv6 address to the client, restoring connectivity to XenApp resources.

To configure Citrix XenApp to return FQDNs, refer to Citrix technical support article “CTX128436 – How to Enable DNS Address Resolution in XenApp 6.x” for more information.

Enable Teredo Support after DirectAccess Has Been Configured

DirectAccess leverages IPv6 transition protocols to enable clients to connect to the DirectAccess server when both are located on the IPv4 Internet. When the DirectAccess server is located in a perimeter or DMZ network behind a NAT device, only the IP-HTTPS IPv6 transition protocol is used. When the DirectAccess server is edge facing with public IPv4 addresses assigned to the external interface, the 6to4 and Teredo IPv6 transition protocols are also supported.

Note: It is generally recommended that the 6to4 IPv6 transition protocol be proactively disabled. More details here.

To support Teredo, the DirectAccess server must be configured with two consecutive public IPv4 addresses. When you configure DirectAccess for the first time, Teredo will automatically be configured if the installation detects the proper requirements for it. If you neglect to add the second consecutive public IPv4 address to the external network interface and configure DirectAccess, the installation will complete successfully without enabling Teredo support and Teredo will not appear in the list of services operations status, as shown here.

Enable Teredo Support after DirectAccess Has Been Configured

To enable Teredo support after you’ve configured DirectAccess, add the second consecutive public IPv4 address to the external network interface and then execute the following PowerShell command from an elevated command prompt.

Set-DAServer –TeredoState Enabled

Enable Teredo Support after DirectAccess Has Been Configured

Once complete, you’ll receive a warning message that states:

WARNING: Two consecutive IPv4 addresses have been detected on the Remote Access server, and Teredo is enabled. To use Teredo, ensure that internal servers allow inbound ICMP traffic.

Teredo requires that ICMPv4 Echo Requests be allowed inbound to any Intranet resource that a DirectAccess client will access. Ensure that all firewalls (host and network) are configured to allow ICMPv4 Echo Request inbound and outbound to ensure proper Teredo operation.

Once complete, close and then reopen the Remote Access Management console (in some cases a server restart may be required) to confirm Teredo support.

Enable Teredo Support after DirectAccess Has Been Configured


Get every new post delivered to your Inbox.

Join 73 other followers

%d bloggers like this: