Windows Server 2012 DirectAccess Network Location Server Not Working Properly

After configuring a Windows Server 2012 DirectAccess server to use an intranet-based Network Location Server (NLS), you may notice that the operations status in the remote access management console indicates a critical problem with NLS, when in fact you can browse the NLS server from the DirectAccess server.

DirectAccess Network Location Server Issue

The issue here is that the DirectAccess server, in addition to being able to successfully connect to the NLS using an HTTP GET, must also be able to ping the NLS server. However, inbound ICMP is often blocked on web servers which results in the DirectAccess server marking the service as failed. The issue can be quickly resolved by modifying the host firewall policy to allow inbound ICMPv4 echo requests. For example, in my test lab I’m using a Microsoft Windows Server 2012 server with Internet Information Services (IIS) installed. A new access rule can be added to the Windows Firewall with Advanced Security (WFAS) by executing the following PowerShell command:

New-NetFirewallRule -Name “Allow Inbound ICMPv4 Echo Request” -DisplayName “Allow Inbound ICMPv4 Echo Request” -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 172.16.1.241, 172.16.1.242 -Profile Domain -Action Allow -Enabled True

Note that my lab server is domain joined, so I’ve specified the WFAS profile to be the Domain profile. In addition I’ve included the IPv4 addresses assigned to the internal network interfaces of my two DirectAccess servers. You’ll need change the command as required to work in your environment.

Installing and Configuring DirectAccess Connectivity Assistant 2.0 on Windows 7 Clients

When DirectAccess first appeared as a feature in Windows Server 2008 R2, one of the challenges was determining quickly and easily if a DirectAccess client had successfully established remote network connectivity, and more importantly if that connection was unsuccessful or had dropped for any reason. To address this issue, Microsoft released the DirectAccess Connectivity Assistant (DCA) version 1.0, first introduced in February of 2010 as part of the Windows Optimized Desktop Toolkit. It has been updated a number of times since its initial release, and in Windows 8 the DCA functionality is now part of the base operating system. The DCA is helpful from a diagnostic and troubleshooting perspective, as it provides an intuitive visual indicator for DirectAccess connectivity status. More importantly, the DCA is required to support One-Time Passwords (OTP).

As of this writing, the latest version of the DCA is version 2.0, which can be downloaded here. DCA 1.0 and 1.5 are both supported with Windows Server 2012 DirectAccess, unless you need to provide support for OTP, which of course will require DCA 2.0. It is possible to perform an in-place upgrade from DCA 1.5, but if you’ve deployed DCA 1.0 you’ll have to uninstall prior to installing DCA 2.0. It’s important to understand that DCA 2.0 is explicitly NOT supported with Windows Server 2008 R2 DirectAccess or Server 2008R2/Forefront UAG DirectAccess. In addition, the DCA 2.0 MSI installation package can be deployed automatically using Active Directory Group Policy, System Center Configuration Manager, or any other third-party software distribution tool.

To install and configure DCA 2.0 on your Windows 7 DirectAccess clients, download DCA 2.0 and extract all of the files, then run the either the 32 bit or 64 bit version of the MSI on the client, depending on your operating system. The settings for the DCA are managed exclusively with group policy, so once you’ve installed DCA 2.0 on the client, log on to a domain controller and copy the file DirectAccess_Connectivity_Assistant_2_0_GP.admx to the C:\Windows\PolicyDefinitions folder. In addition, copy the file DirectAccess_Connectivity_Assistant_2_0_GP.adml to the C:\Windows\PolicyDefinitions\en-US folder. Next open the Group Policy Management Console and create a new Group Policy Object (GPO) for your Windows 7 DCA settings. Right-click the GPO and choose Edit.

directaccess_dca2_windows7_001

In the Group Policy Management Editor expand Computer Configuration, Policies, and Administrative Templates and then highlight DirectAccess Connectivity Assistant. Double-click Support Email, select the option to enable the setting and enter an e-mail address. This setting is optional, but is required if you want to allow your remote DirectAccess users to e-mail client logs to a helpdesk administrator.

directaccess_dca2_windows7_02

Click Next Setting to configure the DirectAccess Dynamic Tunnel Endpoints (DTEs). Select the option to enable the setting, then click the Show button. To ensure that you are using the correct DTEs, I suggest collecting this information from the registry of the DirectAccess server by opening an elevated PowerShell prompt on the DirectAccess server and issuing the following command…

Get-Item –Path HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters

…and note the entries for DTE1 and DTE2. Copy these addresses to the GPO setting using the syntax PING:<DTE_IPv6_Address>.

directaccess_dca2_windows7_03

directaccess_dca2_windows7_04

Click Next Setting to configure LocalNamesOn. This setting is optional, and when enabled will allow the DirectAccess client to use local name resolution, which effectively disables DirectAccess connectivity on the client side.

directaccess_dca2_windows7_05

Click Next Setting to configure Corporate Resources. Select the option to enable the setting and click Show. This setting enables a health check from the DirectAccess client to this resource to determine if the DirectAccess tunnels are up and that corporate network access connectivity is indeed working correctly. You can use ping, UNC file path, or an HTTP URL. I prefer to use the HTTP method as it seems to be the most reliable. Any internal web server will work, but keep in mind that if it is unavailable for any reason the DCA will indicate that network connectivity is not available when in fact it is working correctly. For that reason I’d suggest selecting a highly available (load balanced) internal web server if possible. DO NOT use the network location server (NLS) for this connectivity check. The syntax for this setting is HTTP:<internal_webserver_URL>. It is also recommended that you use the server’s FQDN when configuring this setting. You can also specify an IPv6 address, but an IPv4 address will not work.

directaccess_dca2_windows7_06

Click Next Setting to configure the Admin Script Location. This setting is optional and used only if you want to run a custom script on the Windows 7 DirectAccess client to gather additional information used for troubleshooting.

directaccess_dca2_windows7_07

Once complete, right-click WMI Filters in the Group Policy Management Console and choose New.

directaccess_dca2_windows7_002

Provide a descriptive name for the new WMI filter and click Add. Enter the following WMI query and click Ok.

select * from Win32_OperatingSystem where Version like "6.1%"

directaccess_dca2_windows7_003

Finally, edit the Security Filtering for this GPO by removing Authenticated Users and adding the DirectAccess client security group. In addition, link the GPO to the WMI filter for Windows 7 clients. Once complete, link the GPO to the domain.

directaccess_dca2_windows7_004

After you’ve completed the DCA group policy settings, refresh group policy configuration on the client by issuing a gpupdate /force command from an elevated command prompt. The DCA should now indicate that corporate network connectivity is working correctly.

directaccess_dca2_windows7_08

SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP

From a client perspective, DirectAccess is an IPv6 only solution. It requires IPv6 connectivity from end-to-end to provide seamless, transparent, always-on remote access. DirectAccess clients are most commonly connected to the IPv4 Internet, so to overcome the limitations imposed by the exclusive use of IPv6 for transport, DirectAccess leverages IPv6 transition technologies such as 6to4, Teredo, or IP-HTTPS to tunnel IPv6 DirectAccess client communication over the IPv4 Internet. These transition protocols are favored by the operating system in the order in which I have listed them here. 6to4 uses IP protocol 41 for transport and requires that the client have a public IPv4 address, so if the DirectAccess client is behind a firewall that does not allow outbound IP protocol 41, or is located behind a NAT and has a private IPv4 address, it will fall back to Teredo. Teredo uses UDP for transport on port 3544, and if this communication is blocked by a firewall the DirectAccess client will then fall back to IP-HTTPS. IP-HTTPS, as its name implies, tunnels DirectAccess IPv6 traffic in HTTP, which is authenticated and encrypted using SSL or TLS.

Historically the challenge with the IP-HTTPS IPv6 transition protocol is that it encrypts DirectAccess communication which is already encrypted using IPsec. This double encryption places significant demands on CPU and memory resources on the DirectAccess server, resulting in poor throughput and performance and limiting the overall scalability of the solution. To address these shortcomings, Windows Server 2012 DirectAccess introduced support for IP-HTTPS NULL encryption. SSL/TLS is still used for authentication, but the IPsec traffic is no longer double encrypted. This dramatically reduces resource consumption on the DirectAccess server, resulting in improved performance and allowing many more DirectAccess clients to be handled by a single server. The only drawback is that IP-HTTPS NULL encryption is only supported with Windows 8 clients. When Windows 7 clients connect to a Windows Server 2012 DirectAccess server using IP-HTTPS, they will continue to use encrypted IP-HTTPS.

An ideal solution would be to terminate SSL off box using a dedicated hardware appliance like the F5 BIG-IP Local Traffic Manager (LTM). Unfortunately there is no provision in Windows Server 2012 DirectAccess to enable SSL termination for IP-HTTPS traffic. However, using some of the advanced features of the LTM, we can effectively offload SSL on the F5 by configuring LTM to emulate Windows 8 DirectAccess client behavior. This is accomplished by having the F5 LTM exclusively negotiate the use of a NULL encryption cipher suite with the Windows Server 2012 DirectAccess server on behalf of Windows 7 DirectAccess clients.

Note: This post assumes that you are familiar with the configuration and management of the F5 BIG-IP LTM solution, and that you’ve already imported your SSL certificates and configured nodes, pools, and virtual servers for your Windows Server 2012 DirectAccess server.

To configure the F5 LTM to provide SSL offload for Windows 7 DirectAccess clients, we’ll need to create SSL profiles to allow the use of specific cipher suites for our IP-HTTPS traffic. In its default configuration, the BIG-IP LTM does not support the use of NULL encryption cipher suites. Since Windows 8 DirectAccess clients use NULL cipher suites exclusively, we need to explicitly enable these on the LTM to support our Windows 8 clients. Since our Windows 7 clients will use only encrypted cipher suites, we’ll be sure to include those as well. To do this, open the F5 management console, expand Local Traffic, Profiles, SSL, and then click the green icon next to Client.

f5_directaccess_iphttps_offload_01

Provide a name for the new Client SSL Profile, select Advanced configuration, check the Custom box and specify DEFAULT:NULL for Ciphers. Be sure to select the appropriate SSL certificate and key. Click Finished at the bottom of the screen to save these settings. This change allows NULL cipher suites in addition to encrypted cipher suites, allowing us to support both Windows 8 and Windows 7 DirectAccess clients.

f5_directaccess_iphttps_offload_02

Next we need to configure the LTM to use only NULL cipher suites when communicating with the Windows Server 2012 DirectAccess server. To do this, expand Profiles, SSL, and then click the green icon next to Server.

f5_directaccess_iphttps_offload_03

Provide a name for the new Server SSL Profile, select Advanced configuration, check the Custom box and specify NULL-SHA for Ciphers. Click Finished at the bottom of the screen to save these settings. The end result here will be to force the exclusive use NULL encryption cipher suites for all IP-HTTPS traffic, regardless if it is a Windows 8 or Windows 7 client.

f5_directaccess_iphttps_offload_04

Once you’ve completed the client and server SSL profiles, it will be necessary to assign these profiles to the virtual servers that represent your Windows Server 2012 DirectAccess server. Navigate to Virtual Servers and click on Virtual Server List. Click the virtual server that corresponds to your DirectAccess server, and then scroll down to the bottom of the page. For SSL Profile (Client), select DA_IPHTTPS_CLIENT and add that to the list. Repeat this step for the SSL Profile (Server), this time selecting DA_IPHTTPS_SERVER. Click Update to apply these changes.

f5_directaccess_iphttps_offload_05

Once complete, the F5 BIG-IP LTM will now effectively be offloading SSL traffic on behalf of Windows 7 DirectAccess clients by emulating the Windows 8 DirectAccess client behavior and using only NULL encryption for IP-HTTPS sessions established with the Windows Server 2012 DirectAccess server. Although I can see no issues with this deployment model, be advised that this configuration may not be supported by Microsoft, so make these changes at your own risk. I’ll be working with Microsoft and F5 to get this solution reviewed and tested and I will provide clarification on supportability here once I have that information.

Special thanks to Jeff Bellamy, Ryan Korock, and John Wagnon at F5 for their assistance with this developing solution.

DirectAccess Session at Microsoft TechEd 2013

This month I had the honor and privilege to present a Windows Server 2012 DirectAccess session at Microsoft TechEd North America and Europe 2013. For those of you who attended in person, thank you very much! I certainly hope that you found the session informative and worthwhile. For those of you who were not able to attend in person, you can watch a recording of the session for free at Microsoft’s MSDN Channel 9 web site here. Enjoy!

Windows Server 2012 DirectAccess TechEd 2013 Session

%d bloggers like this: