What’s New in Windows Server 2012 Remote Access (Part 1)

by [Published on 11 Sept. 2012 / Last Updated on 11 Sept. 2012]

In this article, we begin our introduction to the new Remote Access Server Role in Windows Server 2012.

If you would like to read the next part of this article series please go to What’s New in Windows Server 2012 Remote Access (Part 2).

Introduction

In today’s on-the-go, telecommuting, often-off-site business world, Windows Server 2012 brings us many new features and capabilities that make it a great remote access solution for businesses of all sizes. Microsoft’s remote access has been evolving for a long time. In Windows Server 2008 R2, we saw the introduction of the DirectAccess server role, by which you could have all your domain joined machines automatically connect to the corporate network without requiring users to establish a VPN connection. However, a problem with DirectAccess in Windows Server 2008 R2 was that it was primarily an enterprise solution because of its multiple requirements and complexity. SMBs were left out of the party. In addition, if you really wanted to deploy a remote DirectAccess solution, the Windows Server only version of DirectAccess wasn’t very viable. Therefore, you needed to deploy DirectAccess using the Microsoft Unified Access Gateway or UAG – adding more complexity and expense.

With Microsoft’s apparent lack of focus on TMG (on which UAG depends) and UAG itself in recent years, it didn’t make much sense for them to continue requiring that DirectAccess have a dependency on either of these server applications. The good news is that all the new and improved features that people have been wanting from DirectAccess are included with Windows Server 2012. Many of the features that were available only when you used UAG DirectAccess are now available in the Windows Server out of the box DirectAccess solution. In addition, Windows Server 2012 DirectAccess has been reworked so that all businesses, large and small, can choose deployment options that fit their level of networking sophistication.

But the Windows Server 2012 remote access solution isn’t only about DirectAccess. It simply brings DirectAccess into the remote access management fold and makes it an integrated part of the Windows Server 2012 routing and remote access solution. This means that the remote access VPN, site to site VPN and DirectAccess options are now all part of the new Remote Access Server role.

New features

Some exciting new features that you’ll find in the Windows Server 2012 Remote Access Server Role include the following:

  • DirectAccess and RRAS management integration. You can now manage DirectAccess and the other VPN based remote access services from the same interface.
  • Simplified DirectAccess management for small and medium organizations. DirectAccess was a complex and unwieldy beast as implemented in Windows Server 2008 R2. Requirements for two consecutive IP addresses, IPv6 requirements and other prerequisites made it unrealistic for most small companies to deploy DirectAccess. These requirements have been removed in the Server 2012 version and now anyone who is connected to the Internet through a machine that can allow inbound connections to TCP port 443 can benefit from DirectAccess.
  • Removal of PKI deployment as a DirectAccess prerequisite. The PKI and certificate configuration requirements for the Windows Server 2008 R2 DirectAccess deployment were complex and confusing – and they often led to long and difficult troubleshooting exercises. With the Windows Server 2012 DirectAccess, you don’t necessarily need certificates or PKI, thanks to the ability to use Kerberos constrained delegation.
  • Built-in NAT64 and DNS64 support for accessing IPv4-only resources. In the Windows Server 2008 R2 version of DirectAccess, you had to have an IPv6 capable intranet in order to get the most out of DirectAccess. This problem was fixed if you deployed UAG because it had the NAT64/DNS64 services, which removed the requirement that you have an IPv6 capable network on your intranet. With Windows Server 2012, these two key services are made part of the Windows Server 2012 platform, so you don’t have to add any other product to get DirectAccess working on your IPv4 only network.
  • Support for DirectAccess server behind a NAT device. A major deployment blocker for both large and mid-sized businesses was the fact that you could not deploy a DirectAccess server behind a NAT device. Large enterprises required that the DirectAccess server be located behind a firewall, and mid-sized enterprises didn’t have enough public IP addresses to go around. With the Windows Server 2012 DirectAccess solution, you can now put the DirectAccess server behind a NAT device – thus removing one of the most common deployment blockers for DirectAccess.
  • Simplified network security policy. The Windows Server 2008 R2 DirectAccess solution used a very complex set of security rules with IPsec to create multiple types of IPsec connections that served different purposes. This made DirectAccess difficult to deploy and even more difficult to troubleshoot when something went wrong. The Windows Server 2012 DirectAccess greatly simplifies the network security policies, which makes it easier to deploy and troubleshoot.
  • Load balancing support. High availability is a key requirement for any remote access solution. The reason for this is that often the remote access solution is going to be used heavily when there is some sort of event that prevents users from coming into the office. In that case, if the remote access solution is not highly available, users will not be able to get any work done that day, and of course that is a highly undesirable situation! In the Windows Server 2008 R2 DirectAccess solution, the out of the box support for high availability wasn’t very compelling. In order to get genuine high availability with DirectAccess at that time, you had to deploy UAG. Now with the Windows Server 2012 DirectAccess solution, Network Load Balancing support for DirectAccess servers is made available to you right out of the box.
  • Support for multiple domains. While multiple domain support was available in the Windows Server 2008 R2 DirectAccess solution, it was difficult to get set up and was overall considered to be a somewhat “fragile” solution. In the Windows Server 2012 DirectAccess deployment, support for multiple domains is a lot easier to set up and troubleshoot.
  • NAP integration. Network Access Protection (NAP) is a type of network access control technology that requires each DirectAccess client computer to prove its security status before being allowed onto the network. If the DirectAccess clients fail the security check, they are not allowed on the network through DirectAccess. NAP integration with DirectAccess was not available in the Windows-only version of DirectAccess so that once again, you had to bring in UAG to get NAP support. Now with Windows Server 2012 DirectAccess, you get support for NAP right out of the box.
  • Support for OTP (token based authentication). OTP (one-time password) using OAuth enables you to require users to present a one-time password to the DirectAccess server to authenticate the user to the DirectAccess server. This was not previously available in the Windows Server only version of DirectAccess so you had to bring in UAG to get OTP support (are you seeing a pattern here?). With Windows Server 2012, you get support for OTP right out of the box.
  • Automated support for force tunneling. Force tunneling is a configuration option in DirectAccess whereby you can force all network connections to go through the DirectAccess connection. If DirectAccess clients need to connect to corporate resources, those connections have to go through the DirectAccess tunnel. If DirectAccess clients want to connect to the Internet, then those requests also have to go through the DirectAccess tunnel. Force tunneling is the opposite of split tunneling, whereby you enable the clients to use the DirectAccess connection to connect to corporate resources and when the DirectAccess clients want to connect to Internet resources, they connect to them directly through whatever Internet connection they might already have. The split tunneling issue was a concern in the late 1990s and early-mid 2000s, but is much less of a concern today. The default configuration for DirectAccess in Windows Server 2008 R2 was to allow for split tunneling, and this led to a minor revolt among remote access admins. Therefore, guidance was created to enable force tunneling on the Windows-only version of DirectAccess, but that guidance was complex and difficult to follow. UAG made the process a lot simpler and that simplicity is another UAG feature that has now been integrated into the Windows Server 2012 DirectAccess implementation.
  • IP-HTTPS interoperability and performance improvements. IP-HTTP is an IPv6 transition protocol that enables DirectAccess clients on an IPv4 Internet to connect to the DirectAccess server. The problem with the previous version of the IP-HTTPS protocol was that it carried IPsec connections over a TLS transport, which significantly increased the encryption overhead for IP-HTTPS connections. That is the reason some folks referred to IP-HTTPS as the IPv6 transition protocol of last resort. However, the IP-HTTPS protocol was the preferred method for administrators, since it only required that TCP port 443 be open from end to end between DirectAccess client and server. Microsoft realized this and made changes to the IP-HTTPS protocol so that it would have better performance and be easier to manage.
  • Manage-out support. Manage-out refers to the ability to connect to DirectAccess clients from hosts on the corporate network. This makes it possible for Help Desk personnel to connect to DirectAccess clients so that they can make changes that are necessary. In addition, manage-out enables corporate IT to manage all the machines (OS updates, etc.) at all times, whether or not they are located on the corporate network. In fact, many IT organizations find that manage-out is the primary value of DirectAccess and enable only this feature, and do not enable inbound connections to the intranet through DirectAccess. Manage-out has been improved and simplified in the Windows Server 2012 DirectAccess solution.

Summary

In this article, we began our introduction to the new Remote Access Server Role in Windows Server 2012. We briefly discussed some of the new features included in the Windows Server 2012 Remote Access Server role with a primary focus on the new and improved features in DirectAccess. Next time, we’ll continue our overview of the new features and then we’ll dig in deeper into some of them in subsequent articles. See you then! –Deb.

If you would like to read the next part of this article series please go to What’s New in Windows Server 2012 Remote Access (Part 2).

Featured Links