Vulnerability in DirectAccess Could Allow Security Feature Bypass

With the November 2013 security bulletin release, Microsoft advises that DirectAccess includes a vulnerability that could allow security feature bypass. This update affects all supported versions of Microsoft Windows and addresses an issue with how the DirectAccess server authenticates connections with DirectAccess clients. The vulnerability could be leveraged by an attacker to pose as a man-in-the-middle and intercept their communication. For more details, please review Microsoft Security Advisory 2862152.

Microsoft Security Update MS13-064 and DirectAccess

With the August security update release cycle, Microsoft issued security bulletin MS13-064 to address a vulnerability in the Windows NAT driver that could result in a denial of service. The vulnerability could be exploited by an attacker who sends a specially crafted ICMP packet to the server running the Windows NAT Driver service. The vulnerability exists only on Windows Server 2012 and the affected driver, winnat.sys, is present when the DirectAccess role is installed. This vulnerability only affects only full installations of Windows Server 2012. Windows Server 2012 Core is not affected. If you are running DirectAccess on a full installation of Windows Server 2012, make sure you install this update as soon as possible to be protected from potential denial of service attacks. For more information about this update, click here. For a comprehensive list of updates that apply to DirectAccess on Windows Server 2012 as well as previous versions, please refer to Jason Jones’ DirectAccess hotfix summary page.

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.

Network Interface Configuration for Multihomed Windows Server 2012 DirectAccess Servers

When preparing a Windows Server 2012 DirectAccess server with two network interfaces, proper configuration of the network interfaces is vital to the operation and security of the remote access solution, especially in edge-facing scenarios. Preparing a server with two network interfaces might seem trivial, but there are some important and often overlooked settings that may lead to trouble. In this post I’d like to outline the proper network interface configuration for a Windows Server 2012 DirectAccess server in an edge-facing deployment scenario. It is important to note that you should configure your network interfaces prior to installing and configuring DirectAccess.

The first step is to rename the network interfaces with intuitive names that identify their role. Typically I use Internal and External. This will make DirectAccess configuration much easier, as you will see when you are configuring DirectAccess using the deployment wizards. To rename the network interfaces, open the Networking and Sharing Center from the Control Panel and choose the option to Change adapter settings. Optionally you can simply highlight the network interface you wish to rename and hit F2. Assign new names to the network interfaces as appropriate.

direct_access_multihome_01

Next, right-click the Internal network interface and choose Properties. Enter an IPv4 address, subnet mask, and DNS servers as required. Notice that I have not entered a default gateway here. This is absolutely critical and one of the most common mistakes made when configuring a multihomed DirectAccess server. On a server with multilple network interfaces there can be only one default gateway, and the gateway must reside on the External network interface.

direct_access_multihome_02

In the absence of a default gateway on the Internal network interface, static routes will be required to reach any remote internal subnets. To add a static route, open an elevated PowerShell command prompt and add any necessary routes using the following syntax:

New-NetRoute -InterfaceAlias <Interface_Name> -DestinationPrefix <SubnetID/Mask> -NextHop <Gateway_Address>

For example, my lab network has a remote subnet of 172.16.2.0/24 that is reachable through a router interface of 172.16.1.254.

New-NetRoute -InterfaceAlias Internal -DestinationPrefix 172.16.2.0/24 -NextHop 172.16.1.254

It’s also a good idea to unbind any protocols that are not required. For example, in my implementation I will not be leveraging QoS or NIC teaming, nor will I require the Link-Layer Topology Discovery services so I’ve unchecked those boxes accordingly.

direct_access_multihome_03

Perform this same exercise for the External network interface. Enter an IPv4 address and subnet mask, and this time be sure to include the default gateway for the External network. Notice that I have not entered any DNS servers here. Resist the urge to enter the DNS servers provided by your ISP. They are not required here.

direct_access_multihome_04

Since this DirectAccess server will be edge-facing and connected directly to the public Internet, it is a good idea to unbind all protocols from the network interface with the exception of IPv4 and IPv6.

direct_access_multihome_05

In addition, uncheck the option to Enable LMHOSTS lookup and also chooseDisable NetBIOS over TCP/IP.

direct_access_multihome_08

Important Note:  Beginning with Windows Server 2016, making changes to the network interface binding order is no longer required, and this option has been removed from the UI.

One last change that needs to be made, and perhaps the most critical and often overlooked setting, is the network interface binding order. This change can be made by pressing the Alt key on the keyboard to display the drop-down menu and choosing Advanced Settings.

direct_access_multihome_06

Make certain that the Internal network interface is listed first in the list of connections.

direct_access_multihome_07

So that’s it! You can now proceed with installing and configuring DirectAccess in full confidence that your network interfaces are configured properly!

The Drawbacks of Supporting Windows 7 Clients with Windows Server 2012 DirectAccess

Windows Server 2012 DirectAccess includes many new features to enhance scalability and performance. To take full advantage of many of these capabilities you must use Windows 8 Enterprise edition for your DirectAccess clients. Windows 7 Enterprise and Ultimate clients are supported, but there are a few important features that can’t be leveraged. Here are some examples:

IP-HTTPS Improvements – Windows Server 2012 supports NULL encryption for the IP-HTTPS IPv6 transition protocol. This eliminates the performance penalty and negative scalability caused by needlessly redundant encryption of DirectAccess client communication (IPsec encrypted traffic encrypted again with SSL/TLS). Windows 8 clients only request these NULL encryption cipher suites when establishing DirectAccess connectivity. However, Windows 7 clients do not support NULL encryption and will instead request an encrypted cipher suite when performing SSL/TLS negotiations.

Automatic Site Selection for Multi-Site – With Windows Server 2012 the administrator can configure multiple DirectAccess gateways to provide geographic redundancy for DirectAccess clients. Windows 8 clients are configured to intelligently select the nearest entry point and automatically reconnect to another gateway if the connection to the originally selected entry point fails. In contrast, Windows 7 clients can be configured for only a single entry point. The Windows 7 client is unaware of any other entry points and if the original connection becomes unavailable for any reason it will not have corporate network access until that entry point is back online.

Public Key Infrastructure (PKI) – The removal of the requirement to have an internal PKI to support DirectAccess clients is a popular feature for many organizations wanting to deploy DirectAccess (I don’t necessarily agree with this, but that’s the subject of another post!). Although Windows Server 2012 DirectAccess can be configured to use self-signed certificates, this deployment model is only supported for Windows 8 clients. If you plan to provide support for Windows 7 clients you will need a working internal PKI.

DirectAccess Connectivity Assistant – The Windows 8 client includes native functionality to indicate the status of DirectAccess connectivity and also includes a facility with which to quickly gather detailed log data for troubleshooting. Windows 8 clients can also establish DirectAccess connectivity when they are located behind an authenticating web proxy. For Windows 7 clients, the DirectAccess Connectivity Assistant (DCA) provides some of this functionality, but it is an optional component that must be deployed separately. Even with the DCA installed, Windows 7 clients cannot establish DirectAccess connections when a web proxy server requires authentication.

Although Windows 7 Enterprise and Ultimate editions are supported for DirectAccess when connecting to a Windows Server 2012 DirectAccess server, Windows 8 Enterprise clients should be deployed whenever possible to ensure the best and most complete experience.

Hotfix for Windows 7 DirectAccess Clients

This month Microsoft released an important hotfix to address a DirectAccess connectivity issue for Windows 7 clients connecting to a Windows Server 2012 DirectAccess Server. The hotfix specifically resolves an issue where Windows 7 clients face a very long delay reestablishing a DirectAccess session using the IP-HTTPS IPv6 transition protocol after recently disconnecting from a VPN session. In this scenario, Windows 7 DirectAccess clients may take as long as 15 minutes to automatically reestablish a DirectAccess session using IP-HTTPS. During this time the IP-HTTPS adapter state is displayed as disconnected. Refer to Microsoft KB 2796313 more information and to download the hotfix.

Presenting DirectAccess at Microsoft TechDays Belgium 2013

Join me in Belgium for Microsoft TechDays 2013! The event takes place at Kinepolis in Antwerp on March 5-6-7. I will be presenting a session on DirectAccess in Windows Server 2012 on March 7. The event will include sessions from many top speakers including Marcus Murray, Paula Januskiewicz, Tom Decaluwe, and more. There will be separate tracks for IT professionals and developers, so there will be something of interest to everyone. In addition, all attendees will receive a free 3 month TechNet subscription. Register today and don’t miss out on this amazing event!

Microsoft TechDays Belgium 2013

DirectAccess and the Microsoft Surface Pro

With the recent release of the Microsoft Surface Pro, many people have been asking me about DirectAccess connectivity for these devices. One of the requirements for DirectAccess connectivity is that the device be joined to a domain, a capability that the Surface RT lacked. Although the Surface Pro runs the full version of Windows 8, it is Windows 8 Professional. Sadly, DirectAccess connectivity is only supported for Windows 8 Enterprise edition clients, along with Windows 7 Enterprise and Ultimate editions.

Windows Server 2012 DirectAccess Client Requirements

So, if you have just purchased a new Microsoft Surface Pro and are hoping to configure it as a DirectAccess client, I’m afraid you’re out of luck. In my opinion, the lack of DirectAccess support for Windows 8 and Windows 7 Professional is a serious flaw, especially when you consider all of the great use cases you can imagine when you have a full featured tablet with always-on, secure remote network connectivity. It’s a shame, really. Let’s hope this changes in the future!

Update: Read my post on how to install Windows 8 Enterprise and configure DirectAccess on the Microsoft Surface Pro here.

December 2012 Windows Updates and DirectAccess Connectivity Issues

The December 2012 collection of Windows updates included a number of changes that may adversely affect connectivity for DirectAccess clients. The December updates included changes to the Windows Root Certificate store and a hotfix for the IP Helper Service. Either or both of these updates could potentially prevent DirectAccess clients from connecting via the IPHTTPS IPv6 transition protocol. For more information read this post from the Forefront UAG Product Team.

Discussing DirectAccess on the People Talking Tech Podcast

Recently I had the opportunity to chat with fellow Microsoft Most Valuable Professional (MVP) Denny Cherry on his People Talking Tech podcast. We had a great time conversing about DirectAccess in Windows Server 2012. Give it a listen!

%d bloggers like this: