Windows 2012 DirectAccess legacy client considerations

Let’s start this new year with a resolution : Correct previously published blog post including not accurate information (Thank you Alex ).

It might appear strange but with Unified Remote Access included with Windows Server 2012, Windows 7 DirectAccess Clients are considered as legacy clients. Legacy clients can connect to a Windows Server 2012 based DirectAccess infrastructure if we enable some compatibility features that I will describe in this blog post.

By default, A Windows Server 2012 based infrastructure is configured to operate in Kerberos proxy mode. In this default configuration, only Windows 8 clients can connect. In Kerberos Proxy mode, there is a single IPSEC Tunnel and certificates are not required. That’s a new DirectAccess deployment option available with Windows Server 2012. If you want to support Windows 7 clients, don’t forget to enable this checkbox :


When you activate the “Enable Windows 7 Clients computers to connect Via DirectAccess” checkbox, computer certificates become mandatory. That’s the minimum requirement to support Windows 7 Clients in a Windows Server 2012 based DirectAccess infrastructure.

Single-Site/Multiple site impact

Multi-site feature is introduced with Windows Server 2012. From user point of view a DirectAccess clients can have multiple entry point for a DirectAccess infrastructure. User can even select witch entry point to use. Unfortunately, this feature is only compatible with Windows 8. For this reasons, Windows 7 clients connecting to a multi-site DirectAccess infrastructure need a dedicated group policy that provide a single entry point for the DirectAccess infrastructure. As a conclusion, we cannot have Windows 7 and Windows 8 clients members of the same group in Multisite deployment (This possibe when Multi-site option is not enabled).

Windows 7 clients are considered as legacy clients. This means that :

  • They still rely on Teredo for DirectAccess
  • They need an IPSEC certificate to establish IPSEC tunnels
  • They will have their own dedicated DirectAccess configuration
  • They need a dedicated security group

From a DirectAccess point of view, there are two kind of clients,so there are two client-side GPO. This also means that there are two security group. You can find it with the Add-DAclient PowerShell command illustrated bellow :


Great, but if we try to configure the “DownlevelSecurityGroupNameList” parameter with a single-site DirectAccess deployment, you will have the following error message :


In multisite deployments scenarios, we need separate security groups, one for Windows 8 clients and another one for legacy clients. Your Multi-site deployment can be composed of at least a single site. Legacy clients will only be able to connect to one entry point. Let’s switch our DirectAccess infrastructure to Multi-site :


One important thing to notice with multi-site mode : you must separate Windows 7 and Windows 8 clients computers into different security groups because each operating system will have it’s own dedicated client-side GPO. Once we have at least one DirectAccess entry point we can configure it to support legacy clients with the Add-DAClient as illustrated bellow :


By now, we have a Windows Server 2012 DirectAccess infrastructure witch is almost ready to accept legacy DirectAccess clients. Let’s have a look at the result of a Get-DAServer command :


Server configuration seems to be fine. I have a certificate for IPHTTPS and an root certificate authority selected. With Windows 7, you still need certificates for DirectAccess. I would say that you always need certificates for DirectAccess because you always deploy it with Network Access Protection. But there is something bad with my configuration : The Teredo state parameter witch is disabled. When disabled (because no consecutive IPv4 public addresses or parameter disabled), client-side and Server-side GPO does not include Teredo configuration. With Windows Server 2012, this is no longer a problem.

If you configure your Internet-facing with a single IPv4 address, Teredo cannot be used (from the server point of view). Two public IPv4 addresses are always required on server side. Because Windows Server 2012 now allow to deploy DirectAccess behind a NAT device, Teredo is no longer a requirement.

Technically speaking you can enable it with the following PowerShell command, but its not mandatory :


And now, you remember why you need to create inbound rule for ICMP traffic . Now my configuration is fully operational from a technical point of view. But from user perspective there is something missing : The DirectAccess Connectivity Assistant 2.0. It’s included with Windows 8 and configured by the Client-side GPO but not for Windows 7, and more important, version 2.0 is required. This version is only supported when DirectAccess client is connected to a Windows Server 2012 based DirectAccess infrastructure. So don’t forget to create an additional client-Side GPO to configure the DirectAccess Connectivity Assistant for Legacy clients.

Edit : After some research and advices from Jason Jones, Teredo is a mandatory requirement for the Windows Server 2008 R2/UAG DirectAccess generation, not for Windows Server 2012. If Teredo is not operational for the DirectAccess client, IPHTTPS will be fine and even better with Windows Server 2012 based DirectAccess infrastructure. For many clients, having Microsoft box connected on LAN and Internet was not acceptable from a Security point of view. With Windows Server 2012, this is no longer a problem.

Thank you Jason.

BenoîtS – Simple and Secure by Design but Business compliant


Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.