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.

%d bloggers like this: