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.
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.
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.
Jon Rodriguez
/ August 9, 2013Great post, Richard, thank you!
Simon
/ April 30, 2014Can we create a similar policy for the server certificate auto enrollment?
Richard Hicks
/ May 5, 2014You 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. 🙂
stephane
/ April 21, 2016hello,
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
Stéphane
Richard M. Hicks
/ April 23, 2016I’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, 2016Thank 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.
Stéphane
Richard M. Hicks
/ August 5, 2016Thanks for the update. It is never easy changing root CA servers with DirectAccess. :/
Nick
/ August 3, 2016We’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? 🙂
Richard M. Hicks
/ August 4, 2016I 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. 🙂
Regi4life
/ October 14, 2016Hello,
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,
Regi
Richard M. Hicks
/ October 19, 2016Updating 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.
Jason
/ February 3, 2017Just 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
Richard M. Hicks
/ February 4, 2017I’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, 2017Hi 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
Richard M. Hicks
/ March 18, 2017If 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, 2017Thanks 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
Jason
/ February 3, 2017Let 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?
Richard M. Hicks
/ February 4, 2017I have no idea. It’s not something I have ever tried or tested myself. If you do try it, let me know what your experience is. 🙂
Andy Barzyk
/ February 14, 2017Can you give us some insight on where to find the Direct Access IPsec Properties?
Richard M. Hicks
/ February 16, 2017You’ll have to be more specific. Are you talking about the certificate template properties or the DirectAccess IPsec connection security rule itself?
Paul Crosbie
/ April 12, 2017Same 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?
Richard M. Hicks
/ April 13, 2017This 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!
Richard M. Hicks
/ April 13, 2017I’ve updated this post to add some clarification for this. Let me know if it makes more sense now. 🙂
Paul Crosbie
/ April 13, 2017Yes. That makes much more sense.
BTW your blogs are invaluable.
Richard M. Hicks
/ April 14, 2017Thanks Paul! 🙂
fabie
/ January 19, 2018Hi,
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?
Richard M. Hicks
/ January 20, 2018Odd. 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.
AC
/ December 18, 2018If 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 🙁
Richard M. Hicks
/ December 19, 2018Absolutely. 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. 🙂
Jason
/ March 8, 2022Hi Richard,
We need to change which Root CA is trusted for DA connections… We already have the new machine certs being issues no problems, is it just a matter of changing the Root CA specified in the DA configuration or do we need to do any additional changes? (and it there anything else we should be cautious of?)
Cheers!
Jason
Richard M. Hicks
/ March 8, 2022Lots of things. 🙂 Changing the root CA in DirectAccess will immediately disconnect ALL of your DirectAccess clients. The only way to restore connectivity is for them to update group policy, which means bringing them back to the office or connecting with another VPN. There is a way to do this without interruption though. Reach out to me directly and I’ll provide you with more details.
Fredrik Edentoft
/ June 5, 2023Facing similar issue.
A while ago we did change Root CA.
We used to have an issuing CA (pki2_sub1) cross signed between two roots (pki1_root and pki2_root), and swapped it out to instead use the root CA (pki2_root)).
We just made sure all clients had dual certificates, one from the cross signed issuing CA and one from another issuing CA signed by the new root (pki2_sub2).
Doing that we could just swap out the trust setting from pki2_sub1 to pki2_root after making sure “all” clients had the new certificate, and after that remove all the client certificates from pki2_sub1.
But now, we are moving to a brand new PKI (pki3), and the same manouver don’t seem to work.
Jason
/ June 6, 2023We ended up spinning up a new DA infrastructure (now based on Server 2022) using our new Root CA and migrating systems across by changing the GPO assigned to them.
This is the 2nd time we’ve done a migration like this & both times its been pretty painless. Change the group membership of the computer, next gupdate they’ll pull the new GPO & DA will drop for a short period (most of our staff didn’t even notice it) and connect to the new DA.
One thing to keep an eye on though, make sure systems don’t end up with both DA GPO’s assigned to them, they’ll connect to neither in that case.
Richard M. Hicks
/ June 6, 2023I’ve used this procedure more than a few times myself. 🙂 Thanks for the update!