Microsoft DirectAccess - A to Z

Over the past few months I have been investigating a new remote access solution from Microsoft called DirectAccess. During this time I have posted multiple articles explaining the technology, requirements, set-up and advantages/disadvantages. Now my investigation has now come to an end (for the time being), I thought I would post all the articles again, so that they can be read in order:

Microsoft DirectAccess

Microsoft DirectAccess Testing

How to configure Microsoft DirectAccess

Advantages of Microsoft DirectAccess

Disadvantages of Microsoft DirectAccess

This is certainly a technology that I believe will play an important part in the future of remote access and although it does currently have some limitations, these should be addressed automatically over the next few years as industry moves towards Windows 7 and the Internet fully embraces IPv6.

Disadvantages of Microsoft DirectAccess

Those who follow my blog will know I have a keen interest in remote access technologies. Over the past few months I have been testing a new remote access technology from Microsoft, called DirectAccess. If you have not come across DirectAccess before I suggest you check out my previous articles, specifically my last article where I analysed some of the advantages of Microsoft DirectAccess. As with all new technology, there are always pros and cons. This article aims to outline some of the more significant disadvantages.

As stated in my previous article, integration is one of DirectAccess's main strengths. The ability for the operating system to be able to handle remote access, without the need for additional software, is a significant advantage. It provides an easy to use and transparent experience for the end user, as well as simplified support for administrators. Unfortunately it is integration that is also one of DirectAccess's biggest weaknesses. For example, to be able to use DirectAccess the end user must be running Windows 7 (Professional, Ultimate or Enterprise) and your backend infrastructure must be running Windows 2008 R2 with access to Public Key Infrastructure (PKI). These are very strict requirements that force you use proprietary Microsoft technologies (both client and server). They are also all very modern technologies that are still early in their respective product life cycles and as a result most organisations (SMB or Enterprise) have probably only just begun the long and costly process of upgrading their legacy infrastructure. The second big issue with this tight integration is the lack of flexibility for other non-Microsoft devices. For example, if you take Cisco's current remote access solution AnyConnect, it offers the flexibility for your users to connect from just about any device, including Windows, Mac OS X, Linux and even iOS devices, such as the iPhone and iPad. This flexability is incredibly important as the modern worker will probably use a combination of devices (laptop, tablet, smartphone) for different circumstances to ensure they can remain productive. DirectAccess does not currently offer this flexibility and even other popular Microsoft proprietary operating systems such as Windows XP or the yet to be released Windows Phone 7 Series are not compatible with DirectAccess.

Another issue for DirectAccess is the requirement for IPv6. This immediately sounds like a networking problem, however this is not actually the case, as it is possible to transmit IPv6 packets over an IPv4 network, using translation technologies such as 6to4 and Teredo tunnelling. The real issue is that your client applications must support IPv6 and if they don't, they won't be able to use DirectAccess. So the important question is "how many client side applications don't support IPv6?". Well unfortunately, as a general rule of thumb, any applications over five years old will probably be incompatible. For example, even Microsoft's own client side applications such as OCS 2007 R2 (part of their popular unified communications suite) do not support IPv6 and we are still waiting to hear if the currently unreleased OCS "wave 14" (due some time this year) will bring this much needed support. If you speak with Microsoft about this limitation they will state that in these scenarios you could use their Unified Access Gateway (UAG) product, which is generally deployed alongside DirectAccess to provide scalability (and in this case backwards compatibility). However, in my opinion, this is cheating, as you would no longer be using DirectAccess and therefore immediately lose many of the key advantages.

As you can see, most of DirectAccess's disadvantages come from its own strict requirements on modern technologies, such as Windows 7, Windows Server 2008 R2 and IPv6. Although these are issues today, if we fast forward a few years things will probably be very different, as I would predict that most organisations will have began upgrading their client/server infrastructure as part of their standard life cycle management and IPv6 should have finally been forced upon the world. In this scenario, the advantages of DirectAccess start to significantly outweigh the disadvantages. Unfortunately until then I still feel that DirectAccess is just a glimpse of the future and a lot could still change between now and then.

Advantages of Microsoft DirectAccess

Those who follow my blog will know that I have been investigating a new remote access technology from Microsoft, called DirectAccess. If you haven't already, I suggest you check out my "introduction to DirectAccess" article.

Today I would like to look at the advantages that DirectAccess has over traditional VPN solutions and if it can be used as a direct replacement, or if the two technologies should be used in parallel.

The best place to start is to provide an overview of the key advantage of DirectAccess when directly compared to a traditional VPN setup.

This table is very high level, however it does outline the key technical advantages of DirectAccess (such as ease of connection and transparency for the end user). It also shows DirectAccess's main disadvantage, which is it's strict requirements for modern Microsoft technologies (such as Windows 7 & Server 2008 R2).

Let's take a deeper dive into these advantages to understand how they impact the remote access experience in the real world.

Simplicity

The main aim of DirectAccess is to make connecting remotely as simple and as fast as connecting from the office. This is achieved by DirectAccess automatically connecting the user’s computer to the corporate network every time an Internet connection is available. When the connection is established the user has access to e-mail, shared folders, and all internal network applications (just as if they were connected on the LAN). DirectAccess also automatically monitors your connection and is able to react to changing network conditions in real time, without prompting the user for manual intervention.

This approach differs from traditional VPN solutions because they require user intervention to manually establish and monitor the VPN connection. Only once the connection is established do they have access to the corporate network and if there is a change in network connectivity, the user must manually decide how best to handle the change.

Flexibility

Modern remote access techniques must be able to connect through a wide variety of networks; for example, from home over DSL or Cable, public Wi-Fi or mobile Internet (3G/4G). Each of these connections has a different set of security rules that may not always be in your control. As a result, traditional VPN’s which use a limited set of remote access protocols, can often be blocked by firewalls. Some modern remote access technologies, such as SSL based VPN can bypass these firewalls, however only offer limited access to resources on the internal network. Both of these scenarios result in frustration and loss of productivity for the end user.

DirectAccess works differently. It utilises a variety of different remote access protocols to guarantee that the end user can always connect securely, irrespective of location or connection type. The Microsoft TechNet Benefits article explains how:

"To allow users to establish a secure connection to the DirectAccess server from anywhere, DirectAccess supports a variety of different protocols to establish IPv6 connectivity to the DirectAccess server. On the IPv6 Internet, DirectAccess client computers connect by using native IPv6. On the IPv4 Internet, DirectAccess client computers connect by using IPv6 transition technologies. If a firewall blocks these protocols, DirectAccess uses IP over HTTPS (IP-HTTPS).

IP-HTTPS uses the same protocol that Web browsers use when communicating with Web sites that require encryption. Therefore, IP-HTTPS can pass through any firewall that allows Web browsing, even if the firewall blocks VPN connections. IP-HTTPS uses Secure Sockets Layer (SSL) encryption to prevent firewalls from examining the data stream. Because DirectAccess protocol selection is automatic, users stay connected to the internal network without having to understand the underlying technical complexity."

Manageability

Traditional VPN solutions present a challenge to IT administrators as true remote users may not connect to the internal network for weeks at a time. This prevents them from downloading the latest group policy objects and software updates, leaving their machines vulnerable to attack.

DirectAccess mitigates this risk by allowing IT administrators to continuously manage the remote computer anytime it is connected to the Internet. This is possible because the user does not need to take any action to connect to the internal network, instead DirectAccess automatically connects as soon as an Internet connection is detected. This helps guarantee the remote computer is always available to the IT administrator and helps ensure that the organisation meets any security or regulatory compliance requirements.

Security

Traditional VPN solutions encrypt data between the remote computer and the corporate gateway (normally a concentrator or security appliance). It is then standard policy to have several layers of security (access lists, user authentication, etc) through to specific services.

DirectAccess can be configured to work in exactly the same way, however has additional capabilities which take security one step further. This works by offering granular security levels up to "end-to-end access". This means that the remote computer is not only authenticated and encrypted over the public Internet, but also through the internal corporate network all the way to the end point (usually a server). DirectAccess security options can be split into three main categories:

• Full Intranet Access. Like a VPN, DirectAccess communications are encrypted and authenticated across the Internet. Communications on the internal network are not protected.
• Selected Server Access. DirectAccess communications are encrypted and authenticated across the Internet. Additionally, communications between DirectAccess client computers and internal network servers are authenticated, but not encrypted.
• End-to-End Access. DirectAccess communications are encrypted and authenticated across the Internet between DirectAccess client computers and internal network servers.

By covering Simplicity, Flexibility, Manageability and Security I believe I have covered the most important aspects of remote access (excluding cost of delivery). As you can see, DirectAccess offers many advantages over traditional VPN solutions, however it's reliance on Microsoft proprietary technology might be a deal breaker (especially in the short term). What I believe may happen is that DirectAccess becomes more feasible as customers naturally upgrade to the latest client and server technologies as part of their normal life cycle management process. I think Microsoft realise this which is why they have not been aggressively marketing the technology at this time.

To learn how you can configure DirectAccess for testing, please refer to my article "How to configure DirectAccess".

How to configure Microsoft DirectAccess

In my previous article "Microsoft DirectAccess Testing" a colleague and I showed a working test lab setup of the new remote access technology from Microsoft known as DirectAccess. To accompany that testing we have now completed a video guide that details every step of the configuration so that it can be easily replicated.

To summarise the previous article we configured the following setup using a test lab setup guide provided by Microsoft.

This setup successfully simulates DirectAccess and should be your first step (proof of concept) before attempting to use DirectAccess in a production environment.

Before we begin it is important that you have the correct hardware and software available. You will need six computers which will act as both servers and clients. We used averagely spec'ed Intel C2D slim-line desktops, all were 64bit capable and had 2GB of Memory. The only other hardware requirements is that one of the six computers must have two network interface cards. For software you will need Windows Server 2008 R2 (must be release two) and Windows 7 Ultimate. If you do not have access to TechNet or MSDN you can download them both for a trial period of 30 days for free from Microsoft.

Now that you are familiar with the hardware and software requirements you are ready to check out the video guide. The guide weighs in at just over one hour (you read that right), but should be the perfect companion for the written Microsoft test lab setup guide. Due to it's length the guide has been split into parts so that it can be hosted on YouTube.

YouTube Channel (28 Parts - Available in HD)

The next stage is to move this simulation in to a real world environment using Microsoft Forefront Unified Access Gateway (UAG). Once we have completed this stage I will post the outcomes and configuration guide. In the meantime I recommend you check out the following Microsoft TechNet resources to familiarise yourself with the advance features of DirectAccess and UAG.

TechNet - Microsoft DirectAccess

Forefront Edge Security – Direct Access, UAG and IAG

Direct Access and UAG video - Deep dive with a Program Manager

Stay tuned for more updates on Microsoft DirectAccess.

Microsoft DirectAccess Testing

I have previously written about Microsoft DirectAccess and how it aims to become the new standard in remote access for corporate networks.

DirectAccess is a new feature in Windows 7 and Windows Server 2008 R2 that enables remote users to securely access shared folders, web sites, and applications without connecting to a virtual private network (VPN). The main advantage this has over traditional VPN solutions, is that it is integrated into the Operating System so that whenever you have an Internet connection available, Windows will automatically attempt connect to your corporate network. If your connection drops or you change location, Windows will continuously attempt to reconnect on your behalf.

With the release of Windows 7 in October 2009, I have been eagerly waiting for some new information on DirectAccess. Unfortunately it seems like the whole industry is waiting for the same thing and the only company to have delivered DirectAccess so far is Microsoft. As a result, myself and a colleague have setup a DirectAccess test environment to help us better understand the product and see if it lives up to Microsoft's bold claims.

The setup was configured using the Microsoft DirectAccess test lab setup guide. The initial setup is for simulation purposes only and does not connect over the Internet, however it does validate the architecture, configuration and prove the concept. The diagram below shows an overview of the test setup:

In the simulation, DA1 (DirectAccess Server), DC1 (Domain Controller) and APP1 (Application Server) are all directly connected to the corporate network (10.0.0.0/24). INET1 and NAT1 simulate the Internet, the INET1 server provides DNS and DHCP services, while NAT1 simulates a home broadband router that performs network address translation. DA1 (DirectAccess Server) also has a connection to the Internet as it acts as your termination point (or concentrator in the Cisco world). We also have a client machine that can connect directly to the corpnet (simulating work LAN), Internet (simulating a direct Internet connection) or homenet (simulating your home Internet connection).

The video below shows the test lab setup and demonstrates connecting a client to the corporate network and then directly to the Internet. When connected to the Internet you can see DirectAccess seamlessly establish the connection with the corporate network allowing you to access the Intranet and file shares as if you were connected locally.

Please Note: The video was shot on an iPhone and as a result the sound levels are not great. If you are having issues please connect headphones.

The next video adds the NAT1 server which simulates a user connecting from their home through a standard Internet router. During this demonstration we also look at Teredo tunnelling and IP-HTTPS which are key protocols that allow DirectAccess to work.

Teredo tunnelling is designed to grant IPv6 connectivity to nodes that are located behind IPv6-unaware NAT devices (the majority of home Internet routers). It defines a way of encapsulating IPv6 packets within IPv4 UDP datagrams that can be routed through NAT devices and on the IPv4 Internet, allowing DirectAccess to connect.

In certain situations Teredo tunnelling will still fail due to specific ports being blocked. If this happens, Windows 7 will attempt to use the IP-HTTPS protocol which uses SSL on TCP port 443 to connect the DirectAccess client to a DirectAccess server on the edge of your corporate network.

Without these two protocols DirectAccess would not be able to establish a connection in common real world scenarios such as behind a device performing NAT or from networks with tight port restrictions on their network edge (such as other corporate networks).

Please Note: The video was shot on an iPhone and as a result the sound levels are not great. If you are having issues please connect headphones.

That concludes this stage of our testing. To summarise, in this simulation we have successfully demonstrated Microsoft DirectAccess establishing a connection when connected directly from the Internet and from behind a device performing NAT, such as a home Internet router. We have also simulated the use of IP-HTTPS where specfific ports are blocked and Teredo tunnelling is unable to operate.

This testing is just the beginning. The next stage is to move this simulation into a real world scenario, where the DirectAccess server is actually connecting over the Internet. I also intend to post a follow-up showing the individual configuration on each server (however this information can already be found in the Microsoft DirectAccess test lab setup guide).

It is still too early to provide a verdict as to whether DirectAccess will be a success, however as testing progresses we should start to unravel its secrets and understand how it stands up to everyday use.