DirectAccess Computer Certificate Auto-enrollment

DirectAccess requires computer certificates to be installed on the DirectAccess server and DirectAccess clients. These certificates are used for IPsec, which provides a secure, encrypted communication channel between the DirectAccess client and the DirectAccess server. IPsec ensures the necessary integrity, confidentiality, and non-repudiation required for secure remote access. When using a Public Key Infrastructure (PKI) to issue computer certificates to DirectAccess clients, it can be helpful to automate this process by configuring certificate auto-enrollment using Active Directory group policy.

To begin, open the Group Policy Management Console and expand Domains. Next, expand your domain, right-click Group Policy Objects and choose New. Enter a descriptive name for the new GPO and click Ok. Right-click the GPO you just created and choose Edit. Expand Computer Configuration, Windows Settings, Security Settings, and Public Key Policies. Highlight Public Key Policies, and then double-click Certificate Services Client – Auto-Enrollment. For the Configuration Model choose Enabled. It is recommended that you also choose to Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates.

DirectAccess Certificate Auto-enrollment

Close out of the Group Policy Editor and then link this computer certificate auto-enrollment GPO to your domain. Target only DirectAccess client and server security groups with this GPO instead of all domain computers by configuring Security Filtering to apply this GPO only to DirectAccess client and server machines.

DirectAccess Certificate Auto-enrollment

Finally, on your certificate server, right-click the DirectAccess certificate template, choose Properties, and then choose Security. Make certain the Enroll and Autoenroll permissions are set to Allow for all DirectAccess client and server security groups.

DirectAccess Certificate Auto-enrollment


Leave a comment


  1. Great post, Richard, thank you!

  2. Can we create a similar policy for the server certificate auto enrollment?

    • You certainly can, and it is an excellent idea. Initial provisioning typically isn’t difficult, but using automatic enrollment can ensure that the certificates are renewed automatically too, which can be a life saver in the future. 🙂

  3. stephane

     /  April 21, 2016


    We have migrated our old PKI1 tier to a new 2 tiers pki in a new branche. Now computers that have a computer certificate from the new PKI won’t connect to our 2012R2 DA.

    The DA is still configured with the old PKI and has a computer certificate from it.

    How can I change the Root Certificate configuration on my DA while making sure that client with “old” computer certificate will still connect to the DA?

    Thank you


    • I’m not sure that’s possible. It’s not something I’ve tested anyway, so I’d have to check the behavior in a lab to know more. Assuming the client has IPsec certificates from each PKI, the old and the new, changing the DirectAccess configuration to use the new PKI should in theory work. However, when that change occurs, it will immediately invalidate any existing IPsec security associations (SAs) and if the policy on the client still wants to use the old PKI, it might fail. I’ll test that out when time permits and post details when I have them.

      • Stéphane

         /  August 4, 2016

        Thank you for your help. Here is what I did:

        -Actual client with old computer certificate could not connect to the DA server when I changed its certificate with a new one from the newPKI branche. So I had to revert back.

        – I ‘ve deployed a new computer certificate template to all DA client client from the new PKI branche. So DA clients have now 2 computers certificates one from each PKI branche.

        – I then changed the certificate configuration on the DA server to use the one from the new PKI branche. Current connected DA client lost connection and could not connect until the new DA GPO was applied. Users had to come back first on the office or the support had to applied the GPO remotly by setting up an VPN connection.


      • Thanks for the update. It is never easy changing root CA servers with DirectAccess. :/

  4. Nick

     /  August 3, 2016

    We’re in the middle of a domain migration and the DA server is in a different domain (the old one) than the laptops connecting to it. When enrolling client certificates we get an error that the request template version isn’t correct (CERTSRV_E_BAD_TEMPLATE_VERSION).

    I manually fixed this by changing the request templates untill they had the same version.. this does feel like a quick and dirty fix though.. any thouhts? 🙂

    • I don’t see any issues with your fix at all. If there is a mismatch between the version templates, correcting the template is a perfectly valid fix. 🙂

  5. Regi4life

     /  October 14, 2016


    A public certifiacte is used for IP-HTTPS. The certificate is about to be expired. Before expiration, we count to replace it. So i would to know the impacts for the connected clients DirectAccess. The connection will stop ? The service will not be available during the update on the server side?

    Best regards,

    • Updating the IP-HTTPS certificate on the DirectAccess server should be minimally disruptive. When you update the certificate, any existing connections will be temporarily disconnected. However, they will reconnect automatically.

  6. Jason

     /  February 3, 2017

    Just curious on the issue with changing the root certificate and everyone having to bring systems into the office to get the new GPO settings for “First Authentication” ..
    I was looking at the Client side GPO and it looks like I would have the option to add in a second Authentication Method and could possibly select the new Root that we want to migrate over to and set it as the second option in the list. Then I could update DA to use the new Root and they would possibly reconnect? I’m trying to prevent having users that work externally to have to connect up internally to get the GPO changes. If there was a was to push it out manually beforehand that would be ideal. There must be others in the situation, in our case we need to migrate to a new Root for SHA2 support. We build a new Sub CA and created a new template derived from the default computer template and its configure to auto enroll all the computers. So all the DA clients have this new cert installed. But as others have noticed, I tried to cut it over last night by updating the DA config to start using the new Root and all the DA clients would not reconnect and I clued in that the changes I made also write out to the client GPO settings and they would not be receiving those since the tunnel was down. I had to roll back and once I selected the old Root I had lot of DA clients connected once again. Just looking for a clean way to flip over to the new root without any downtime. Is there a way to “manually” update the client side GPO to include the second Authentication Option Method with the new SHA2 Root cert … I know in the DA configuration it doesn’t seem to give you any options for that. Just curious your thought. Thanks

    • I’ll give you the standard disclaimer that “modifying DirectAccess client and server GPOs manually is explicitly not supported”. That said, it might be possible to manipulate them to accomplish what you want. However, I’ve never tried that myself. For my customers, having a solution that is “as supportable as possible” is a high priority. That said, the most non-disruptive way of migrating root CAs is to prepare a new parallel DirectAccess deployment and migrate users to the new deployment configure to use the new PKI. Once complete, the old DirectAccess infrastructure can be retired. I realize that might not be desirable for you, but that’s how I’ve historically approached this scenario.

    • Jakub

       /  March 16, 2017

      Hi Jason. Have you tried that solution? We are facing the same scenario with upgrading to the new root CA, now am I searching for some easy way to change DA setting without making to much outage for clients

      • If you are changing the root CA there’s not much you can do to prevent service disruption for clients that are outside of the network when you make the change. In cases such as this you can either have remote users come back to the office or connect to a VPN to update group policy. If that’s too much effort (for example you have many thousands of remote users) then implementing a new, parallel DirectAccess deployment that uses the new PKI and migrating users is probably the best approach.

      • Jakub

         /  March 19, 2017

        Thanks for your answer Richard,
        Fortunately we managed to do change of ourourPKI PKI without to much of disruption. Most of our DA users have Win7 with acces to backup VPN. Win10 users which have only DA were instructed in adavance about the change and all of them returned to the office for new GPOs.

        Probably some of you will face similar case in the future. If you want to get thru of it without to much effort, the advice is to plan the process accordingly and inform users to return to the office/use backup VPN. If you can not afford for even minimal outage you must create parallel DA env as Richard said

  7. Jason

     /  February 3, 2017

    Let me clarify what I just posted… I didn’t mean to say add a Second Authentication option… I meant to say that in the First Authentication option methods you can add a second entry in the list and select computer certificate with the new root and it will show up in the list and the description says that those higher in the list are tried first, but will it eventually try the second one?

  8. Can you give us some insight on where to find the Direct Access IPsec Properties?

    • You’ll have to be more specific. Are you talking about the certificate template properties or the DirectAccess IPsec connection security rule itself?

  9. Paul Crosbie

     /  April 12, 2017

    Same question as Andy. Your last step is “Finally, make certain the Enroll and Autoenroll permissions are set to Allow for all DirectAccess client and server security groups.” and it shows a picture of a box labeled “DirectAccess IPsec Properties”.
    Where do I find that please?

    • This is the properties page for a certificate template I’ve deployed called “DirectAccess IPsec”. In your PKI it will be whatever the name of the certificate template is that you are using to provision certificates for your DirectAccess clients. Hope that helps!

    • I’ve updated this post to add some clarification for this. Let me know if it makes more sense now. 🙂

  10. fabie

     /  January 19, 2018


    We have setup auto enrollment for directaccess but auto enroll only works when we are connected via Wifi or Lan Connection. When we have a laptop which is connected via Directaccess and is on 4g autoenroll doesnt work. Do you have any idea how we can get auto enrollment for directaccess / 4g connection?

    • Odd. Certificate auto enrollment should work as long as you have network connectivity of some type, DirectAccess included. I can only suggest that you look closely at your group policy settings and ensure that they are being applied to your remote clients as you expect. Also, check the event log for indications of certificate enrollment failure. They could yield some clue as to why it is failing.

  11. If you have a more complex PKI, for example, two tier with offline root and two or more issuing ca’s – is it supported to have multiple issuing CA’s dish out the DA computer template? We have found in the tech net docs the same root must be used… when we want resilience and add the template to more than one CA. The IPSec tunnels fail as the DA server and DA client can be issued from different CA issuing servers. Is this a limitation? Would be good to have some resilience, if the one CA server gets bombed it would be tricky to issue the remote clients a new certificate from another issuing CA if the tunnels won’t cone up 😦

    • Absolutely. You just need to specify in the DirectAccess configuration that the root CA is trusted, not one of the individual intermediates. Essentially if you trust the root all subordinate CAs are then also trusted. 🙂

  1. Configuration Guidance for DirectAccess Security Advisory KB2862152 | Richard Hicks' DirectAccess Blog
  2. DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101 | Richard Hicks' DirectAccess Blog
  3. DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: