At Celestix Networks, we’ve been deploying DirectAccess since the technology was introduced more than 5 years ago. During these years, we’ve learned a lot about deploying DirectAccess in the most secure, effective, and reliable way. We’ve been engaged countless times by customers, to salvage a DirectAccess implementation project that had gone wrong.
Although there are numerous ways in which a DirectAccess implementation can turn into a failure, there are a few common mistakes that we’ve seen repeated more than once. In today’s post, I’ll share with you some of the most common DirectAccess implementation mistakes we encounter, working with customers around the world.
1 . Using the Getting Started Wizard.
Although the DirectAccess “Getting Started Wizard” (GSW) is a quick and easy way to configure DirectAccess, it should be avoided at all costs. The GSW implements an overly simplistic configuration that doesn’t follow common DirectAccess best practices. In addition, it is inflexible and severely limiting. The GSW doesn’t require PKI, but instead uses self-signed certificates which is a bad security practice. These certificates use 1024 bit keys, which do not provide adequate protection for client to server communication. The GSW configuration does not provide support for Windows 7 clients, and will require significant changes in the future if features such as OTP, load balancing, or multisite redundancy are required. It is best to use the “Remote Access Setup Wizard” or the DirectAccess configuration wizard in the Comet management console (web-based), on the Celestix appliance platform to implement DirectAccess, using some of the advanced features for the best experience.
2 . Deploying Windows 7 or 8 Professional.
There’s nothing worse than getting your entire DirectAccess infrastructure prepared and configured, only to find out that your DirectAccess clients are running a non-Enterprise edition SKU. DirectAccess supports only Windows 7 Ultimate Edition and Windows 8.x and later Enterprise operating systems. If you’re planning a DirectAccess deployment, ensure that your clients are running Enterprise edition. For the best experience, choose Windows 8.x and later. Windows 7 still works, but lacks support for some of the new high availability and performance features of Windows Server 2012 R2. UPDATE: Celestix SecureAccess Client expands automatic connectivity to Windows Professional and Mac OS X computers. Now organizations can take advantage of always-on connections and manage out functionality for previously unsupported clients. Learn More
3 . Manual Certificate Configuration.
Best practices dictate that DirectAccess should be deployed using PKI-managed certificates. If you are deploying certificates to your DirectAccess servers and clients manually, not only are you making more work for yourself, you are setting yourself up for failure in the future. All certificates expire at some point, and using certificate auto enrollment will ensure that certificates are automatically renewed prior to expiration. Remember, DirectAccess ceases to function with expired certificates, so plan accordingly!
4. Enabling ISATAP for All Internal Hosts.
In the early days of DirectAccess it was an accepted practice to configure ISATAP for all internal hosts. However, experience has taught us that there are many unintended consequences for this, which can make things quite problematic. Today, we recommend that ISATAP be configured only for those hosts that require manage-out functionality. Often, this is only a few workstations in the organization, typically belonging to systems administrators or help desk engineers. Individual hosts can be configured with ISATAP, either manually or via Active Directory Group Policy.
5. Installing the Network Location server (NLS) on a Domain Controller.
This frequently comes up when working with some of our smaller customers. In an effort to save resources, a DirectAccess administrator may attempt to install IIS on an existing Active Directory domain controller and host the NLS there. This doesn’t work, because the NLS is not reachable by external DirectAccess clients. When the NLS is on the DC, the client is unable to authenticate and DirectAccess connectivity is impossible. You can collocate the NLS on another web server, or use another internal web resource as the NLS, as long as DirectAccess clients do not need to use those resources when they are remote.
If you can avoid these common DirectAccess implementation mistakes, you’ll save yourself a lot of pain in the future. For the highest chance of success, consider engaging with Celestix Professional Services to assist you in the planning, design, configuration, and implementation of your DirectAccess remote access solution. We deal with DirectAccess on a daily basis, and have deployed this technology for some of the largest organizations in the world. By partnering with us, you gain access to a wealth of knowledge and experience that can ensure your DirectAccess solution is secure, stable, robust, and resilient. Drop us a note at sales@celestix.com for more information.
