If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real Time Article Update newsletter.
Introduction
It seems like it was only yesterday when Windows Server 2008 was released to the public. Now, in 2009, we have to think about the next client and server operating systems. We now have to consider Windows 7 and Windows Server 2008 R2. New client and server operating systems always have some goodies that make upgrading worth considering, but sometimes, those improvements and/or new features are incremental instead of revolutionary, and therefore we do not feel a big motivation to speed up our adoption plans.
I do not think that this is case for Windows 7 and Windows Server 2008 R2. A lot of organizations decided not to upgrade to Windows Vista, and therefore are still running mostly on Windows XP machines. These companies realize that they can not run a decade old operating system forever, and they no longer think they need to, since they have been mightily impressed with Windows 7. With Windows 7’s improved performance, lower hardware requirements, and exceptional security enhancements, there are very few reasons not to upgrade. Windows Server 2008 R2 is a little different, in that like previous R2 releases, there are some new features and capabilities, but nothing as revolutionary as what Windows 7 brings to the table.
Is there something revolutionary included in the upcoming Windows Server 2008 R2? I would argue that there is. At least there is if you pair up Windows 7 with Windows Server 2008 R2. What is this revolutionary feature? DirectAccess.
DirectAccess is a new Microsoft VPN solution that is intended to change the way you work with and think about VPN connectivity. In fact, Microsoft does not even want you to think of DirectAccess as a VPN solution (which is it) because they think that you have had such bad experiences with VPNs over the years that if you hear that DirectAccess is a VPN technology, you would not be as excited as I am and maybe you will avoid learning enough to realize that DirectAccess completely changes the VPN playing field.
VPNs gave your users the ability to connect to resources on your corporate network by providing a virtual network level (layer 2) connection to your corpnet. This sounds like a good thing – ideally the VPN should have provided your users the same computing experience they have when they are actually plugged into the company network, either over an Ethernet or a wireless connection.
Was that actually the case? What are some of the problems introduced by traditional network level VPNs?
- Firewalls and Web proxy devices often do not allow outbound connections for the protocols needed to connect to your VPN server
- NAT devices require NAT editors for some VPN protocols. Often the NAT editors are missing or poorly implemented (such as the Linksys PPTP NAT editor). In addition, IPsec based VPN suffer from the fact that vendors do not enforce RFC compliance, such as the IPsec implementation in some SonicWall VPN servers.
- There is no way to ensure that source and destination networks are actually on different network IDs because people tend to use similar private address spaces. When the source and destination network ID is the same, users are not able to connect to the corporate network because of subnet collision
- Users need to manually initiate the VPN connection. This introduces complexity for the users and also generates help desk calls if the user perceives that something isn’t working, even if the VPN connection is not the problem
- Since VPN connections have to be manually initiated by the users, the users’ machines are not accessible to IT until the user makes the connection. The puts these disconnected machines outside of IT’s administrative controls, and makes it difficult to keep purportedly managed devices in compliance with corporate security and management policies
Given all the problems we have had with network level VPNs, it is surprising that we use them at all. In fact, network-level VPNs are being used less and less as other remote access solutions are being implemented in their place. These other solutions are not only simpler for the users they are actually more secure because they help enforce the security principle of least privilege. With least privilege, users have access to the services and data they need to accomplish their work, but nothing more.
For example, consider the following technologies:
- Outlook Web Access (OWA): OWA gives users access to Exchange services using a Web browser connection over HTTPS. Users do not need network level access to connect to their mail and calendar information
- Outlook RPC/HTTP: The RPC/HTTP protocol enables users to benefit from the full, rich Outlook client without requiring the full level of network access enabled by a network layer VPN connection. The Outlook RPC/MAPI communications are encapsulated in an HTTP connection and encrypted with SSL
- Terminal Services Gateway: Instead of enabling full network level access to allow remote desktop connections to a terminal server or desktop operating system on the corporate network, you can take advantage of TSG to encapsulate RDP connections in an HTTP tunnel and then encrypt it with SSL. Again, there is no need for a full network level connection to give users the terminal services connectivity they require
Of course, exposing these services to the Internet represents very poor security design, since that would allow an extremely hostile Internet unlimited access to your application front-end servers. A solution is required to protect the front-end servers. Two of the most common solutions are advanced firewalls that have blended network and proxy firewall feature sets and SSL VPN gateways.
Two good solutions include:
- Forefront Threat Management Gateway 2010: The Forefront TMG (TMG) is a blended proxy and network level firewall with comprehensive spam protection, Web malware protection, and advanced IDS/IPS capabilities. In addition to its Web proxy and network level firewall feature sets, it also provides sophisticated inbound SSL bridging capabilities, so that the TMG firewall can be used to pre-authenticate and inspect inbound connections to your application server front-ends. This significantly reduces the risks inherent in exposing these application server front-end to attackers on the Internet
- Intelligent Application Gateway 2007 (IAG) and the upcoming Unified Access Gateway (UAG): The IAG and UAG are comprehensive SSL VPN solutions that allow you to protect the front-end application servers from Internet attackers. IAG 2007 and UAG provide multiple SSL VPN technologies to secure remote access to information on the corporate network. IAG 2007 and UAG add to the security provided by firewall technologies such as Forefront TMG by layering on enhanced positive and negative logic filters that block known bad connections and potentially zero day attacks, and introduce authentication options over and above what other SSL VPN gateway solutions can provide.
While application server front end technologies and security gateways are certainly helpful in reducing risks and complexities compared to traditional network layer VPN solutions, it certainly seems like there is still a lot of work to be done in this area. You have to set up the application server, then, you have to set up the application server front-end server (which needs to be put in a DMZ because it is an Internet facing host) and then you need to configure a firewall or an SSL VPN gateway in front of the front-end servers. You have to set the appropriate access controls between all the security zones and you need to monitor all the connections between different security zones. A single point of failure anywhere in this “chain of mistrust” can bring the whole thing crumbling down.
ACK! There has to be a better way.
DirectAccess to the Rescue
Whether or not there is a better way depends on the type of client machines you are working with. For unmanaged clients of unknown security configuration and state, you are better off using front-end connections to application servers that are protected by advanced firewalls or SSL VPN gateways. There is no way you can put lipstick on the unmanaged pig and pretend that network level VPN connections for these hosts can be made secure. Least privilege is the strongest tool in your belt when it comes to unmanaged hosts and the firewall and gateway solutions are the best ways to enforce least privilege.
What about managed hosts? What about your users who have laptops that your company has given them? You have gone out of your way to create a secure build for each of these laptops and whenever users connect to the corporate LAN, they get policy updates and are checked for the latest security and application updates before being allowed on the corpnet, thanks to Microsoft Network Access Protection (NAP).
The problem is that these users might never come back to the corporate network, or worse, never connect to it at all. You might create the new laptop build and then ship the computer to a user in a different state, different country or different continent. At this point, the computer is typically out of your control until the user comes back to the corporate LAN, either by coming to headquarters, visiting a branch office, or maybe using a traditional network level VPN. You never knew when any of these might happen, or if they will ever happen at all. This means that your carefully crafted managed laptop will quickly age and fall completely out of compliance. Worse yet, you would not even know what is going on since it will not be completely accessible to your System Center management, monitoring and reporting solutions.
DirectAccess changes all that. When you have Windows 7 clients and a Windows Server 2008 R2 DirectAccess server, the Windows 7 client automatically calls the DirectAccess server when the computer starts up. The client uses IPsec to secure the connection and uses IPv6 to connect to servers on the corporate network. Since the clients are behind NAT devices, and they’re going over an IPv4 Internet, Windows 7 clients can use a number of NAT Traversal and IPv6 transition technologies to allow connections to the DirectAccess server and then to the servers on the corpnet.
Notice that the users do not need to log on for the DirectAccess connection to be established. This means you can manage these machines as long as they are turned on. The DirectAccess connection is bidirectional, so you are able to connect to those machines, inventory those machines and apply security and management policies to those machines, just as if they were connected to your network.
When the user logs on, a second VPN connection is established. However, unlike the typical PPTP, L2TP/IPsec or SSTP VPN, the users log onto the DirectAccess VPN automatically. The users do not need to put a checkmark in a checkbox; the user does not need to click a button that says “connect to corpnet”. The user also does not need to worry about being behind a firewall or proxy, since the only requirement is that the firewall or proxy allows outbound HTTPS access. Since SSL is the “universal firewall port”, the users should never have any problems connecting to the DirectAccess servers.
So now what? Consider the following:
- Users open Outlook and it just works because the client machine has a virtual network level connection to IPv6 enabled machines on the network
- Users do not need to ever use OWA, since their native MAPI connections to Exchange are easily enabled over the DirectAccess VPN
- When a user gets an e-mail message that contains a link to a file server or a SharePoint site on the intranet, the user just clicks the link and it works. You don’t need to think about publishing these resources to the Internet and dealing with DNS issues related to translating intranet to Internet names
- Computers are automatically evaluated by NAP and remediated based on corporate policy. This happens whenever the computer starts and automatically connects to the DirectAccess VPN. This means your managed machines should always we in compliance
These are just a few examples of what you gain when deploying DirectAccess on your network. It is clear that DirectAccess is not only a very cool remote access VPN solution, but is something that will change how you approach the entire concept of VPNs in the future.
Conclusion
Remember, we are talking about managed computers here. These are domain member computers that you considered under corporate control and governance. You should have much higher expectations for these machines than you have for unmanaged machines. As you can see, DirectAccess allows you to realize your higher expectations for these machines, regardless of where that machine is located. DirectAccess allows you to extend your domain’s strong management and security policy controls to all machines under your stewardship, and do it any time that machine is turned on, even if the user doesn’t log on to the machine.
In part 2 of this article series, I will dive into the details of DirectAccess and talk about the requirements, the protocols, and the knowledge you will need to get a DirectAccess solution working. There are a number of moving parts, but not nearly as many as other solutions (such as NAP).You should be able to get up and running with DirectAccess relatively quickly. But you will need to check out the “gotcha’s” and other potential bumps in the road that I will discuss with you in part 2. See you then! -Tom.
If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our WindowSecurity.com Real Time Article Update newsletter.
