Windows Server 2012 Remote Access

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.

With the recent announcement about the discontinuation of the TMG firewall, the topic of Windows Server 2012 networking has become even more interesting to TMG firewall admins and Windows Network admins of all stripes. For a long time, the TMG firewall (like ISA Server before it) was a cornerstone of Windows Networking and provided the security and the flexibility you needed to make sure your remote access solution worked securely and reliably. Now that we know the TMG firewall will eventually be relegated to the dustbin of history (after extended support ends in 2020), it's time to start thinking more about what the Windows platform itself has to offer you when it comes to remote access.

As you saw in Part 1 of this article series, the focus for remote access in the Windows Server 2012 era is the new unified remote access solution, which includes support for remote access VPN client connections, site to site VPN connections and DirectAccess. Let' complete the discussion we started in Part 1, and then talk about the implications of the new features.

Multisite support

If you worked with the UAG DirectAccess solution, you know that one of the most difficult scenarios is the one that involves multiple sites. Standing up a single UAG DirectAccess server is relatively easy if you have all the pieces in place in advance to make sure that when you do set up the UAG DirectAccess server or array it will be able to consume all the supporting services. The problems start when you try to set up two or more arrays at different sites. There are a number of reasons for this: problems with group policy configuration, DNS issues, and IPv6 problems. Tom put together a solution that would enable you to stand up a two-site UAG DirectAccess solution a couple of years ago and was in the process of completing a proof of concept setup, but he was moved to another team within Microsoft and never was able to finish that work. However, Microsoft realized that enabling multi-site connectivity for DirectAccess was a key enterprise requirement, so in Windows Server 2012, there is now full support for multi-site DirectAccess deployments.

In Windows Server 2012, you can configure DirectAccess so that Windows 8 clients will be able to discover the closest DirectAccess server or array and connect to that. Or, you can configure the clients to use a preferred DirectAccess server or array or you can let your users choose which DirectAccess server or array to use. For Windows 7 clients, you don't have this level of automation or flexibility, but users can still benefit from many of the same connectivity advantages if you choose to deploy an external Global Server Load Balancing Solution. However, this is something you will need to configure outside of Windows, since Windows Server 2012 itself doesn't provide this feature.

Support for Server Core

If you've worked with server core in the Windows Server 2008 R2 era, you probably think that you'd prefer almost any onerous task to working with a Server Core deployment. It was clear that Microsoft had not fully worked out the configuration issues when working with Server Core in the past, but it looks as if, with Windows Server 2012, the Server Core deployment is now actually manageable from a remote management workstation. The new RSAT tools and the Server Manager application that comes with Windows Server 2012 make it possible to relatively easily manage machines that are running services on a Server Core installation of Windows Server 2012.

There are a lot of advantages to running your DirectAccess servers using Server Core. The attack surface is much lower and you don't need to update the servers nearly as often. These are both great advantages when you need to provide a highly available service, such as the DirectAccess remote access solution. You can manage DirectAccess using remote PowerShell commands or you can use the new and improved Server Manager. Another nice thing about using a Server Core installation is that you can have more confidence in putting the Windows Server 2012 DirectAccess server at the edge of the network, even if you no longer have to do that as you did with the UAG DirectAccess solution.

Windows PowerShell support

Love it or hate it, PowerShell is here to stay. There are a number of reasons that Microsoft is making such a large investment in PowerShell and so if you want to continue being a Microsoft administrator, you'll probably have to learn at least some PowerShell eventually. Thus, the new DirectAccess solution in Windows Server 2012 includes full support for PowerShell, so that you will be able to do whatever it is that people do with PowerShell :).

User monitoring

All remote access solutions must support robust monitoring of who is connecting to the network and what they're doing while they're there. While the Windows Server 2012 iteration of DirectAccess doesn't provide nearly the level of detail you are able to get with the TMG firewall, it does have a much better level of monitoring than you could get with the UAG DirectAccess solution.

In Windows Server 2012, there is a new monitoring console that provides you with a great deal of useful information about the users who are connecting through the DirectAccess connection. The following is a list of what is exposed in the monitoring console, which is information that is obtained from Performance Monitor counters:

• Total number of active remote clients connected: this includes both DirectAccess and VPN remote clients. It lets you know how many concurrent connections there are for both DirectAccess and VPN connections, which is helpful in determining what your max is going to be, given your level of hardware.
• Total number of active DirectAccess clients connected: this shows only the total number of clients connected using DirectAccess. This is good if you want to know only who's connected via DirectAccess.
• Total number of active VPN clients connected: This shows only the total number of clients connected using a VPN. As with the previous counter, this is good if you want to know only the VPN connections.
• Total unique users connected: This includes both DirectAccess and VPN users, based on the active connections. I'm not sure how this is different from the total number of remote access clients connected. Maybe a single user who has more than one connection is not considered unique
• Total number of cumulative connections: This shows the total number of connections that have been serviced by the Remote Access Server since the last server restart. This might be useful for reporting purposes or maybe for MCSE cocktail parties, when you want to brag about how many connections you supported before having to restart
• Maximum number of remote clients connected: This shows the maximum number of concurrent remote users connected to the Remote Access Server since the last server restart. This is useful information for determining whether you can increase the number by adding more clients to the server or array in an attempt to make it topple over.
• Total data transferred: This is the total amount of inbound and outbound traffic passing through the Remote Access Server for both DirectAccess and VPN since the last server restart. It's interesting information, especially if you have a metered bandwidth service and need to figure out trends in usage so that you can plan for upgrading your ISP service.

    1.Inbound traffic – Total bytes/traffic into the remote access server/gateway
    2.Outbound traffic – Total bytes/traffic out of the remote access server/gateway

You can find information on individual users and discover what resources they're trying to connect to on the internal network. You can also filter the list of connected users so that you can easily find the one(s) that you're interested in. In addition, you can filter on one more of the following fields:

Field Name	Value
Username	The user name or alias of the remote user. Wildcards may be used to specify a group of users.
Hostname	The computer account name of the remote user. An IPv4 or IPv6 address can be specified as well.
Type	Either DirectAccess or VPN. If DirectAccess is selected, then all remote users connecting using DirectAccess are listed. If VPN is selected, then all remote users connecting using VPN are listed.
ISP address	The IPv4 or IPv6 address of the remote user
IPv4 address	The inner IPv4 address of the tunnel connecting the remote user to the corporate network
IPv6 address	The inner IPv6 address of the tunnel connecting the remote user to the corporate network
Protocol/Tunnel	The IPv6 transition technology used by the remote client, i.e., Teredo, 6to4 or IP-HTTPS in case of DirectAccess users, and PPTP, L2TP, SSTP or IKEv2 in case of VPN users
Resource Accessed	All users accessing a particular corporate resource or an endpoint. The value corresponding to this field is the hostname/IP address of the server/endpoint
Server	The Remote Access server to which clients are connected. This is relevant only for cluster and multisite deployments.

Server monitoring

If you've worked with DirectAccess in the past, you know that there are a number of services and technologies that comprise the entire working solution. You also know that it's hard to keep track of all of them! In Windows Server 2012, there is a server and service monitor console that helps you figure out whether everything is as it should be, and if it's not, it tries to tell you what is wrong.

In Windows Server 2012, there are status monitors for the following services:

    - 6to4
    - DNS
    - DNS64
    - Domain controller
    - IP-HTTPS
    - IPsec
    - ISATAP
    - Kerberos
    - Management Servers
    - NAT64
    - Network Adapters
    - Network Location Server
    - Network Security (IPsec DoSP)
    - Services
    - Teredo
    - Load Balancing
    - VPN addressing
    - VPN connectivity

Diagnostics

Troubleshooting DirectAccess has always been both an art and a science. The art came from needing the experience with DirectAccess in order to really understand where to start when it came to troubleshooting. Now with Windows Server 2012, we have new capabilities that will make troubleshooting easier. These include:

     - Detailed event logging for DirectAccess
    - Improved tracing and packet capture using a single click
    - Log correlation, which makes it easier to interpret events in the trace file
    - Flexible viewing options for logs

Site-to-site IKEv2 IPsec tunnel mode VPN

Support for IKEv2 on site to site VPNs is now available. This was available for remote access VPN client connections in the past and has now been extended to site to site VPN connectivity.