During one recent DirectAccess deployment, we encountered a special case I called the : “Too fast to deploy DA clients”. Some DirectAccess clients were operational but some others were not. While starting troubleshooting, we noticed that all failed computers shared the same issue : No IPsec certificate. Everything was OK, except the IPsec certificate.
Challenge, how to restore DirectAccess connectivity without return these computers to France? We could start building a complex infrastructure to distribute IPsec certificates but we were short in time. Because all computers were located in the same location, we had an idea. Why not using another computer to request computer on behalf of others. That’s a good idea. Let start to see how to do this magic trick.
First of all, we need another Certificate Template for these DirectAccess Clients. If we take a look at some properties of my default DA certificate we can notice that DNS name information will be retrieved from Active Directory. Even if we include this information in an Certificate request file, this information will be ignored. For this reason, we need an extra certificate template. This new certificate template will be based on my existing DA certificate template except a few points that must be fixed. In my lab, this new certificate template will be named “Offline Da Certificate”.
A new certificate template
In my point of view, certificate file time for this special certificate template must be limited to one day. This is not a normal situation. When DirectAccess connectivity will be restored, we would no longer need this certificate.
Second point, we need to authorize private key exportation. This is mandatory otherwise, the certificate will be useless when imported on the Computer having the problem.
And most important we must reconfigure how ADCS will generate subject name that will be registered in delivered certificates. By default, information are extracted from Active Directory. We cannot use this option. Information will be supplied in the request. Note that in the capture bellow, the checkbox “Use Subject information from existing certificates for Auto enrollment renewal request” is no checked. That’s a temporary certificate, there is no need to renew it!
Request an Offline certificate
Once this new certificate template is published and available on any DirectAccess clients computers, we can start. On an operational DirectAccess client computer, we must logon with required privileges. Our goal is to request a computer certificate on behalf of another. Il my case CLIENT1.DIRECTACCESSLAB.LAN is operational and CLIENT2.DIRECTACCESSLAB.LAN. Si let’s perform a computer certificate enrollment, online, thanks to DirectAccess. This will be a classic new request, no need to perform the request offline
We will choose “Offline Da Certificate”, but before enrolling, more information’s are expected. So let’s fill in the blanks.
First missing information, Subject name. We need this information twice, in Distinguished name but also in DNS format. Because theses information are no longer extracted from Active Directory, we must provide them. We could stop here and submit the request but simple way does not means dirty way.
On the General tab, we will provide the friendly name of the Certificate and a description. This last information will be useful. At the end of the process, our CLIENT2.DIRECTACCESSLAB.LAN will have DirectAccess operational and two certificate. How can we remove the good one?
Request was processed. Now we have two certificates on CLIENT1.DIRECTACCESSLAB.LAN. Hopefully we can distinguish the good certificate to export.
Most important, we must export this certificate with it’s private key. Otherwise, certificate will be unusable on CLIENT2.DIRECTACCESSLAB.LAN. Do don’t forget to check the good checkbox!
A computer with multiple identifies will generate problems at short terms. In order to avoid problems, I recommend to delete the private key once export was performed.
Because we export the private key, this sensitive information must be secured in the PFX file.
Import certificate on Failed DirectAccess client
Now let’s move to CLIENT2.DIRECTACCESSLAB.LAN and perform a certificate Import in the Computer node. Sure, we have required information, …
And magic, we have an IPsec certificate available in the computer node. This is a temporary certificate. Now it’s time to restore DirectAccess Connectivity.
Restating the computer is a solution but if you have required privileges to import a certificate in the computer store, you can also restart the IP Helper Service.
This is not magic, this is only DirectAccess. Bellow, we can see I have an IPHTTPS Tunnel. Great. Let’s see if it works.
A simple “NETSH.EXE ADVFIREWALL MONITOR SHOW MMSA” prove we have IPsec Tunnels. But we can do more. We can prove that this computer is now able to request it’s missing DA certificate.
Simply run a “CERTUTIL.EXE –PULSE” and the computer will contact enrollment servers to see what certificates can be enrolled.
yes, the good one. Our failing CLIENT2.DIRECTACCESSLAB.LAN was able to enroll it’s missing certificate. Problem we have now two valid certificates. How can we be sure to delete the good one?
Have a look at the description extension field. That’s why I always fill it.
As a conclusion, even if you are confident about your DirectAccess infrastructure, never forget to perform a checklist on DirectAccess enabled computers before they leave outside. This particular problem was easy to solve, but it would be more complicated if group policies objects did not applied. That’s another challenger for a future post.
BenoîtS – Simple and Secure by Design but Business compliant