The Microsoft Security Guy

Everyday life of Jason Jones working as a Senior Security Consultant for Microsoft Consulting Services (MCS) in the UK.

Windows Server 2012 DirectAccess: Microsoft DirectAccess Comparison Table

Windows Server 2012 DirectAccess: Microsoft DirectAccess Comparison Table

  • Comments 6
  • Likes

With the impending release of Windows Server 2012 we will have our third iteration of the Microsoft DirectAccess solution. Life began with the DirectAccess feature coming to Windows in the first release of Windows Server 2008 R2 a few years ago now; it was then supercharged using Forefront UAG to offer a truly more achievable solution which was much easier to implement for many organisations given the improvements offered by the Forefront UAG platform. Now with the release of Windows Server 2012, we have the third generation of the solution which is fully featured and delivered as part of the native operating system. Given the impending third generation release, I thought it might be useful to prepare a DirectAccess comparison table to compare the different technology versions available, as shown below:

DA Solution

Windows Server 2008 R2 DA

Forefront UAG 2010 SP1 DA

Windows Server 2012 DA

Feature

Simplified DirectAccess management for small and medium organisations

No

No

Yes

Automated DirectAccess server configuration

No

Yes

Yes

Mandatory PKI deployment as a DirectAccess prerequisite

Yes

Yes

No1

Built-in NAT64 and DNS64 support for accessing IPv4-only resources

No

Yes

Yes

Support for a DirectAccess server with a single network card

No

No

Yes

Support for a DirectAccess server behind a NAT device

No

No

Yes

Requires at least one Windows Server 2008/R2 Domain Controller

Yes

No

No

Requires at least one Windows Server 2008/R2 DNS Server

Yes

No

No

Load balancing support

No

Yes

Yes

Server fault tolerance

Limited2

Yes

Yes

Support for multiple AD domains

No

Yes

Yes

NAP integration

Yes

Yes

Yes

Support for OTP (token based authentication)

No3

Yes

Yes

IP-HTTPS interoperability and performance improvements

No4

No4

Yes

Manage-out only support

No

Yes

Yes

Multi-site support

Limited5

Limited6

Yes7

Support for Server Core

No

No

Yes

Support for Windows 7 clients

Yes

Yes

Yes

Support for Windows 8 clients

Unknown

Limited8

Yes

Windows PowerShell support

No

Limited9

Yes

User and server health monitoring

No

Yes

Yes

Diagnostics

No

No

Yes

Accounting and reporting

No

Limited10

Yes

Notes and small print:

Items in red represent significant improvement or changes.

1PKI is still mandatory for force tunnelling, Network Access Protection (NAP) integration or two-factor authentication deployment scenarios. A PKI-based solution is therefore still required for some enterprise-class deployments, dependent on the required features. 

2Hyper-V failover cluster is required.

3Smartcard only.

4IP-HTTPS is supported, but there is a performance overhead due to combined/double SSL and IPsec encryption. IP-HTTPS in Windows Server 2012 now support null SSL encryption and additional optimisations but requires Windows 8 clients.

5Complicated setup due to IPv6 requirements.

6Global Server Load Balancer (GSLB) is required.

7Automatic DirectAccess entry-point detection or user selected entry-point requires Windows 8 clients.

8Technically works, but the supportability status is currently unknown (full support provided in UAG SP3).

9Read-only PowerShell.

10Command line via PowerShell only.

As highlighted above, Windows Server 2012 offers the most feature-rich platform when compared to previous versions and can be considered as a superset of the functionality provided by the Forefront UAG SP1 offering. Many of the enhancements included in Windows Server 2012 DirectAccess are based upon direct feedback from customers and changes to facilitate easier adoption and deployment of the technology within both smaller organisations and enterprise environments alike. I am planning on creating two upcoming blog posts which will highlight the changes and benefits in Windows Server 2012 DirectAccess from the perspective of the smaller organisation and then also for the enterprise space. Given the improvements and changes, I think DirectAccess will be even more popular than ever…what do you think?

Comments
  • Thanks for the blog post. I'm sure Direct Access will become much more popular. We have several customers for whom we have already implemented it on W2012 or at least have it planned.

  • good stuff - the better VPN

  • Great comparison table, thanks! Is there anything like this for 2012 vs 2012 R2? Also for the null encryption support for IP-HTTPS, is this done out of the box, or is some configuration required?

  • @itismeap - 2012/R2 are functionally the same. Null encryption is only available for Win8/8.1 clients and is enabled by default. Win7 clients will continue to double encrypt :( Null encryption is a default part of 2012 and doesn't need to be explicitly enabled

  • Hi Jason,

    I am configuring the direct access on windows server 2012 r2. I am using the PKI and generated the certificate but at the time of configuring it shows Remote Procedure Failed error and configuration is rolled back. Can you please help us.

  • Tip for anybody implementing Windows 2012 Direct Access in a cluster (ours was with F5 load balancers and two DA servers in cluster) but this should apply to even NLB deployments -

    Some context –
    Each DA server in the cluster handles a unique IPv6 prefix for clients, this is basically to eliminate the need for tracking client sessions across cluster members for session persistence. For example one of our servers DA1 would handle fd00:a082:7:1000::/59 and DA2 would handle fd00:a082:7:1001::/59.
    When doing failover testing between servers, the client address would appropriately be re-assigned from the right prefix based on the server it failed over to. However, when connecting through DA2, clients would not be able to communicate with corporate network. Further digging around revealed IPSec tunnels on the client won’t even come up via DA2.
    After verifying all the components, I noticed that the tunnel endpoints, configured in the automatically created client GPO, belong to DA1 allocated address prefix. The tunnel endpoints were fd00:a082:7:1000::1 and fd00:a082:7:1000::2. If you look at the client prefix assigned by DA1 these fall in to the same range. But with DA2 assigned client prefix fd00:a082:7:1001::/59, the tunnel endpoint address is not part of the local subnet. This resulted in the client not being able to initiate IPSec tunnels because it doesn’t know how to reach the endpoint.
    I don’t know if this was overlooked by Microsoft/not properly tested or what, and there are no resources out there explaining this behavior that’s why I decided to save others from the headache.
    Now that we know the issue, there are multiple ways to tackle this. And no, advertising the prefix from DA2 did not work. So, I just threw in a quick and dirty fix –
    Add a computer startup script via GPO, to add routes for tunnel endpoints with a gateway of DA2 link-local address facing clients (IP-HTTPS interface link-local address of DA2), add a metric of 10 just as a precaution so you don’t interfere with DA1 –
    route -p add fd00:a082:7:1000::1/128 fe80::e048:79ef:7946:61e0 metric 10
    route -p add fd00:a082:7:1000::2/128 fe80::e048:79ef:7946:61e0 metric 10
    With these changes, when the client moves to DA2, above added routes take effect and the client will initiate IPSec tunnels properly. The behavior with DA1 stays the same. In the script, you might want to delete the routes first so you don’t keep adding on top of the same ones, every time the computer restarts.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment