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
/domain lab.richardhicks.net
/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.

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA

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

Hotfix Available for DirectAccess OTP Configuration Issues

If you’ve ever tried configuring DirectAccess to use One-Time Password (OTP) authentication, you’ve no doubt discovered that the native Microsoft Remote Access Management console would return the following error when trying to detect and locate Certificate Authority (CA) servers.

No CA servers can be detected, and OTP cannot be configured. Ensure that
servers added to the list are available on each domain controller in the
corporate network.

Configure DirectAccess with OTP Authentication

The workaround for this issue required dropping to the command line and executing PowerShell commands to complete this configuration as I outlined here.

Thankfully Microsoft has made available a hotfix to address this issue, returning full GUI functionality for configuring DirectAccess and OTP authentication. For additional details about this hotfix and to request the update itself, click here.

Critical Update MS15-034 and DirectAccess

Microsoft Security Bulletin MS15-034 Vulnerability in HTTP.sys affects DirectAccessThe April 2015 monthly security update release from Microsoft includes a fix for a serious vulnerability in HTTP.sys. On an unpatched server, an attacker who sends a specially crafted HTTP request will be able to execute code remotely in the context of the local system account. DirectAccess leverages HTTP.sys for the IP-HTTPS IPv6 transition protocol and is critically exposed. Organizations who have deployed DirectAccess are urged to update their systems immediately.

More information can be found on MS15-034 here.

Monitoring DirectAccess Machine and User Activity with Windows Component Event Logging

Monitoring DirectAccess Machine and User Activity with Component Event LoggingThe monitoring of DirectAccess machine and user activity presents some unique challenges for security administrators. All DirectAccess client communication destined for the internal corporate network is translated by the DirectAccess server and appears to originate from the DirectAccess server’s internal IPv4 address. Also, the public IPv4 address for DirectAccess clients using the IP-HTTPS IPv6 transition protocol is not visible using the native reporting tools. In addition, vital information such as source ports used by the DirectAccess server for internal connections and source ports used by DirectAccess clients is not available. This lack of granular connection logging creates a serious blind spot for administrators conducting forensic investigations.

As veteran Microsoft Premier Field Engineer (PFE) Martin Solis described in detail in a recent blog post, all of these details are in fact logged. However, gathering this information is not exactly intuitive. To collect this essential information it will be necessary to leverage Windows component event logging. By searching the IPHLPSVC, Base Filtering Engine Connections, Base Filtering Resource Flows, and WinNAT operational logs, it is possible to gather all of the information necessary for uniquely identifying DirectAccess corporate network communication.

Be sure to read Martin’s excellent article about using Windows component event logging to monitor DirectAccess machine and user activity, which can be found here.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

For DirectAccess manage out scenarios, it is necessary to configure the Windows firewall on the DirectAccess client to allow any required inbound communication from the corporate network. For example, if management hosts on the internal network need to initiate Remote Desktop sessions with remote connected DirectAccess clients, the Remote Desktop – User Mode (TCP-In) Windows firewall rule will need to be enabled for the Public and Private profiles.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

While enabling this rule will allow remote desktop connections to be made from the corporate network, its default configuration will also accept remote desktop connections from any network. From a security perspective this is not desirable.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

A better solution is to restrict access to connections originating only from the corporate network. To do this it will be necessary to identify the ISATAP prefix used internally. To determine the corporate ISATAP prefix, run the ipconfig command on a management workstation that is configured for ISATAP. The ISATAP prefix will be the first 96 bits of the IPv6 address assigned to the ISATAP tunnel adapter (essentially everything with the exception of the embedded IPv4 address).

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

On the DirectAccess client, right-click the firewall rule and choose Properties. Choose the Scope tab and then select These IP addresses . Click Add and then enter the ISATAP prefix as shown here.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

Once the firewall rule is configured to restrict access to the ISATAP prefix, only corporate management workstations on the internal network will have access to remote DirectAccess clients.

Follow

Get every new post delivered to your Inbox.

Join 67 other followers

%d bloggers like this: