Windows 8.1 DirectAccess Connection Properties

Microsoft recently announced the availability of Windows 8.1 Enterprise preview. If you’ve downloaded the software to evaluate DirectAccess, you may be wondering where the DirectAccess connection properties have gone. In Windows 8, the DirectAccess connection properties can be accessed by pressing Window Key + I, clicking the active network icon, and then right-clicking Workplace Connection.

DirectAccess Connection Properties

DirectAccess Connection Properties

To access the DirectAccess connection properties in Windows 8.1, press Window Key + I, click Change PC Settings, and then click Network.

Highlight Connections and click Workplace Connection.

Highlight Connections and click Workplace Connection.

Highlight Connections and click Workplace Connection.

Highlight Connections and click Workplace Connection.

DirectAccess Computer Certificate Auto-enrollment

DirectAccess requires computer certificates to be installed on the DirectAccess server and DirectAccess clients. These certificates are used for IPsec, which provides a secure, encrypted communication channel between the DirectAccess client and the DirectAccess server. IPsec ensures the necessary integrity, confidentiality, and non-repudiation required for secure remote access. When using a Public Key Infrastructure (PKI) to issue computer certificates to DirectAccess clients, it can be helpful to automate this process by configuring certificate auto-enrollment using Active Directory group policy.

To begin, open the Group Policy Management Console and expand Domains. Next, expand your domain, right-click Group Policy Objects and choose New. Enter a descriptive name for the new GPO and click Ok. Right-click the GPO you just created and choose Edit. Expand Computer Configuration, Windows Settings, Security Settings, and Public Key Policies. Highlight Public Key Policies, and then double-click Certificate Services Client – Auto-Enrollment. For the Configuration Model choose Enabled. It is recommended that you also choose to Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates.

DirectAccess Certificate Auto-enrollment

Close out of the Group Policy Editor and then link this computer certificate auto-enrollment GPO to your domain. Target only DirectAccess client and server security groups with this GPO instead of all domain computers by configuring Security Filtering to apply this GPO only to DirectAccess client and server machines.

DirectAccess Certificate Auto-enrollment

Finally, on your certificate server, right-click the DirectAccess certificate template, choose Properties, and then choose Security. Make certain the Enroll and Autoenroll permissions are set to Allow for all DirectAccess client and server security groups.

DirectAccess Certificate Auto-enrollment

 

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.

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

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

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.

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.

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!

Additional Resources

Always On VPN and the Future of DirectAccess

5 Things DirectAccess Administrators Should Know about Always On VPN

3 Important Advantages of Always On VPN over DirectAccess

Always On VPN Hands-On Training Classes

Disconnecting DirectAccess Clients on Windows Server 2012

DirectAccess provides seamless and transparent, always-on remote network connectivity. It does this without requiring action from the user. While this is an important feature and benefit of a DirectAccess remote access solution, it can also present a challenge for security administrators when a DirectAccess client device is lost or stolen.

To prevent a DirectAccess device from establishing remote network connectivity, simply disable or delete the device’s computer account in Active Directory. This will prevent the establishment of the IPsec tunnels, which are authenticated in part using the computer account and Kerberos. The caveat here is that this will not terminate a session that is already established. In this scenario it will be necessary to also proactively disconnect the already established IPsec tunnels from the client in question. To accomplish this, open an elevated PowerShell prompt on the DirectAccess server and execute the following command:

Get-NetIPsecMainModeSA | where {$_.RemoteFirstId.Identity –like “*computer_name*”} | Remove-NetIPsecMainModeSA

For example, to terminate established IPsec tunnels for a computer name CLIENT1 the command would look like this:

Get-NetIPsecMainModeSA | where {$_.RemoteFirstId.Identity –like “*client1*”} | Remove-NetIPsecMainModeSA

When the client attempts to reestablish its connection it will fail to authenticate because its computer account is no longer valid in Active Directory. Now the trick is to get those users to tell us immediately when they’ve lost their laptops. That’s an entirely different problem, however. 😉

Special thanks for my good friend Jason Jones for his input on this solution. Thanks JJ!

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.

Windows Server 2012 DirectAccess Session at TechEd 2013

Are you planning to attend Microsoft TechEd this year? If so, I’m happy to announce that I’ll be delivering a session entitled “The Future Is Now! Next Generation Remote Access Today with Windows Server 2012 DirectAccess”. I’ll be presenting at both TechEd North America in New Orleans, LA, and at TechEd Europe in Madrid, Spain. Looking forward to seeing you there!

Microsoft TechEd North America 2013

Microsoft TechEd Europe 2013

TechDays San Francisco 2013

It’s that time again. TechDays San Francisco 2013 is fast approaching! The event will be held on May 2-3, 2013. This is an excellent event for IT professionals and developers alike to learn from some of the best and brightest. The speaker list includes industry experts Richard Campbell, Jeff Hicks, Laura Hunter, Mark Minasi, and more! I will be delivering a session on (you guessed it!) DirectAccess in Windows Server 2012. Registration is open now, so register today. Hope to see you there!

TechDays San Francisco 2012

%d bloggers like this: