When a DirectAccess client computer builds its IPsec tunnels back to the corporate network, it has the ability to require a certificate as part of that authentication process. In earlier versions of DirectAccess, the one in Server 2008 R2 and the one provided by Unified Access Gateway (UAG), these certificates were required in order to make DirectAccess work. Setting up the certificates really isn't a big deal at all. As long as there is a CA server in your network, you are already prepared to issue the necessary certificates at no cost. Unfortunately, though, there must have been enough complaints back to Microsoft in order for them to make these certificates recommended instead of required, and they created a new mechanism in Windows 8 and Server 2012 called KerberosProxy that can be used to authenticate the tunnels instead. This allows the DirectAccess tunnels to build without the computer certificate, making that authentication process easier to set up initially, but less secure overall.
I'm here to strongly recommend that you still utilize certificates in your installs! They are not difficult to set up, and using them makes your tunnel authentication stronger. Further, many of you may not have a choice and will still be required to install these certificates. Only simple DirectAccess scenarios that are all Windows 8 or higher on the client side can get away with the shortcut method of foregoing certificates. Anybody who still wants to connect Windows 7 via DirectAccess will need to use certificates as part of their implementation. In addition to Windows 7 access, anyone who intends to use the advanced features of DirectAccess, such as load balancing, multi-site, or two-factor authentication, will also need to utilize these certificates. With any of these scenarios, certificates become a requirement again, not a recommendation.
In my experience, almost everyone still has Windows 7 clients that would benefit from being DirectAccess-connected, and it's always a good idea to make your DA environment redundant by having load-balanced servers. This further emphasizes the point that you should just set up certificate authentication right out of the gate, whether or not you need it initially. You might decide to make a change later that would require certificates, and it would be easier to have them installed from the get-go than trying to incorporate them later into a running DA environment.
In order to distribute certificates, you will need a CA server running in your network. Once certificates are distributed to the appropriate places, the rest of our work will be accomplished from our Server 2016 DirectAccess server.
Follow these steps to make use of certificates as part of the DirectAccess tunnel authentication process:
- The first thing that you need to do is distribute certificates to your DA servers and all DA client computers. The easiest way to do this is by building a new template on the CA server that is duplicated from the in-built Computer template. Whenever I create a custom template for use with DirectAccess, I try to make sure that it meets the following criteria:
- The Subject Name of the certificate should match the Common Name of the computer (which is also the FQDN of the computer)
- The Subject Alternative Name (SAN) of the certificate should match the DNS Name of the computer (which is also the FQDN of the computer)
- The certificate should serve the Intended Purposes of both Client Authentication and Server Authentication
- For the actual distribution of these certificates, I'm going to direct you to review a couple of other recipes in this book. You can issue these certificates manually using Microsoft Management Console (MMC), as described in the Using MMC to request a new certificate recipe in Chapter 4, Working with Certificates. Otherwise, you can lessen your hands-on administrative duties by enabling Autoenrollment, which is discussed in the Configuring Autoenrollment to issue certificates to all domain joined systems recipe in Chapter 4, Working with Certificates.
- Now that we have certificates distributed to our DirectAccess clients and servers, log-in to your primary DirectAccess server and open up the Remote Access Management Console.
- Click on Configuration in the top-left corner. You should now see steps 1 through 4 listed.
- Click Edit… listed under step 2.
- Now you can either click Next twice or click on the word Authentication to jump directly to the authentication screen.
- Check the box that says Use computer certificates.
- Now we have to specify the Certification Authority server that issued our client certificates. If you used an intermediary CA to issue your certificates, make sure to check the appropriate checkbox. Otherwise, most of the time, certificates are issued from a root CA, and in this case you would simply click on the Browse… button and look for your CA in the list.
- Make any other appropriate selections on the Authentication screen. For example, many times when we require client certificates for authentication, it is because we have Windows 7 computers that we want to connect via DirectAccess. If that is the case for you, select the checkbox for Enable Windows 7 client computers to connect via DirectAccess.
Requiring certificates as part of your DirectAccess tunnel authentication process is a good idea in any environment. It makes the solution more secure, and enables advanced functionality. The primary driver for most companies to require these certificates is the enablement of Windows 7 clients to connect via DirectAccess, but I suggest that anyone using DirectAccess in any capacity make use of these certs. They are simple to deploy, easy to configure, and give you some extra peace of mind knowing that only computers with a certificate issued directly to them from your own internal CA server are going to be able to connect through your DirectAccess entry point.