Inspired by the popular “Eat This, Not That!” weight loss and nutrition books, I’ve decided to share a few DirectAccess deployment tips using this familiar format. As a secure remote access solution, DirectAccess provides seamless and transparent, always-on remote corporate network connectivity for managed Windows clients. DirectAccess relies heavily on many common Microsoft platform technologies including Active Directory Domain Services (AD DS), Active Directory Certificate Services (AD CS), IPsec, IPv6, and more. DirectAccess also supports several different deployment scenarios to meet the needs of large and small organizations. With so many options and inter dependencies, it is easy to make poor design choices and end up implementing a solution that doesn’t work or isn’t supported.

So let’s consider a few important configurations and see what we should and shouldn’t be doing!

1. Do This! – Create a security group for DirectAccess clients.

Don’t Do This! – Use ‘Enable DirectAccess for Mobile Computers Only’.

Why? Because selecting the option to Enable DirectAccess for mobile computers only configures the DirectAccess client Active Directory (AD) Group Policy Object (GPO) to apply to all domain computers. It then relies on WMI filtering to identify the processor type as a mobile processor. This is less than ideal for a few reasons. First, it assumes that all of your DirectAccess clients will be using a mobile processor. Often this is not the case. In addition, the WMI filtering isn’t always 100% accurate, which leads to some clients not getting the proper configuration. Also, some features like multisite deployment require a security group. Creating one at the outset provides the flexibility to implement this important geographic redundancy feature without having to make additional changes. Finally, a dedicated security group for DirectAccess clients allows for the convenient application of additional client settings such as certificate auto enrollment, disabling of unused IPv6 transition protocols, etc.

2.  Do This! – Deploy DirectAccess in a Perimeter/DMZ Network.

Don’t Do This! – Configure DirectAccess with exclusive access to a Read-Only Domain Controller (RODC).

Security best practices dictate that the DirectAccess server be deployed in a perimeter or DMZ network behind an edge-facing enterprise-class firewall. The DirectAccess server will be better protected there, but resist the temptation to deploy an RODC for it. Although this sounds intuitive, DirectAccess requires access to a full writable domain controller for proper operation.

3.  Do This! – Plan for geographic redundancy.

Don’t Do This! – Configure DirectAccess for multisite prior to production.
For organizations with more than one physical location, it is advisable to implement DirectAccess using the multisite deployment model. In this configuration, Windows 8.x and later clients will dynamically select an entry point that is nearest to them. Windows 7 clients cannot take advantage of this feature, and must be assigned to a specific site. It’s important to understand that making the change from single site to multisite configuration is disruptive. In fact, if you have clients in the field when you  make this change they will be cut off until such time as they return to the office, or connect using client-based VPN to update group policy. For this reason, we recommend enabling multisite prior to production deployment even if there are no plans to support it immediately. If you wish to take advantage of this feature in the future, you can safely deploy additional entry points without impacting existing DirectAccess clients.

So there you have it! Three quick do’s and don’ts to make your DirectAccess deployment go a little smoother. Celestix Networks offers professional services to assist you with the planning, design, configuration, and implementation of a DirectAccess solution.

If you’re interested in having us help you with your project, drop a note to [email protected] for more details.