In normal condition, each computer with DirectAccess enabled must be checked for all prerequisites before leaving the company office. That’s a wise advice. With Windows 7 Operating systems, the IPSEC certificate must be present in the computer certificate store. With Windows 8 you can have the same problem if your DirectAccess infrastructure require Certificate for IPSEC tunnel authentication.
Maybe because my customer was so happy with his new DirectAccess laptops that he forgot this wise advice to perform basic prerequisites checks.
Problems began with laptops shipped overseas. DirectAccess Connectivity Assistant reports shows that the required certificate for DirectAccess was missing. Two simple tests can be performed with PowerShell or « CertUtil.Exe ».
Problem, how to recover these clients without ship computers back to the office for recovery. That was the challenge.
My solution was to use a computer to request a certificate on behalf-of DirectAccess clients to recover. To perform such operating some prerequisites are required:
Local administrator privilege will be required on DirectAccess clients to recover
A temporary certificate template will be required
Create the temporary certificate
This step aim to create and publish a new certificate based on existing « DA Certificate » template. This is required for multiple reasons:
- First, the « DA template » generate certificate using subject information retrieved from Active Directory
- Public key cannot be exported from current certificate template
So let start with the DA Certificate duplication. This certificate will be used only by computers compatible with V3 certificates. This means we can select « Windows Server 2008 Enterprise » option.
This new certificate template will be named « Offline of DA Certificates ». This certificate template will be dedicated to recovery scenario. For this reason, you can reduce validity period.
In the « Request Handling » tab, we configure this certificate template to allow private key export. This is required because certificate request won’t be performed on the computer requiring the certificate.
In the « Subject Name » tab, we select to use information that will be provided in the certificate request to generate the subject name of the certificate. It’s also required because certificate request will not be performed by computer witch require the certificate.
This certificate must be published in Active Directory and available for certificate request through the Microsoft Management Console certificate snap-in.
Requesting the certificate
Certificate request can be performed on any client computer that can reach perform the request (connected on LAN or DirectAccess). With the classic Certificate snap-in of the Microsoft Management Console we start the request certificate wizard. This request must be performed at computer store level, not user.
Here begin the tricky steps. Even if our new certificate template is available, we need to provide additional information to complete the certificate request. We must click on the « More information is required to enroll for this certificate. Click here to configure settings ».
In the subject tab, we need two information. First the subject name, then the DNS Name. Theses information must be provided with this format:
- CN=<Computername>.<Active Directory FQDN>
- <Computername>.<Active Directory FQDN>
In illustration bellow, I provided these inputs for « CLIENT7.DIRECTACCESSLAB.LOCAL » computer and click to the « Add > » button.
Certificate request is not yet complete. From my point of view, this certificate usage is limited to recovery scenarios, so limited in time. At the end of the recovery process, this certificate will no longer be required. That’s why I put a comprehensive description.
At last, I check that the certificate private key option is checked. Otherwise, we won’t be able to export private key.
Now certificate request is complete, we can send it to the Active Directory certificate Services for processing.
At the end of the enrollment process, we have a certificate witch name does not match our computer name. This certificate must be exported.
Most important, this export must include the private key. Option is available because the certificate template allow it.
The PFX file will include all required information. Export process will delete certificate from our computer. We don’t need it here.
Because our PFX file include sensitive information (private key), package must be protected with a password (A strong password will be a good idea).
Now you’re ready to send this PFX file to the DirectAccess computer to recover. You can send it by mail but just send the PFX file and provide the required password by an alternate communication path for security reason.
Once we import the PFX file on the DirectAccess computer to recover we can restart the IP Helper Service. If your certificate subject name match computer DNS name, DirectAccess will be operational as illustrated bellow:
That’s great but we need to fix the problem and use the Certificate snap-in of the Microsoft Management Console to perform a certificate enrollment. We will request the missing certificate: « DA Certificate ».
At the end of the enrollment process we have two certificate in the computer store. We must delete the temporary certificate. If we have a look at the certificate, it’s easy to recognize witch certificate to delete because it’s another certificate template.
Once we delete the temporary certificate, we just have to restart the IP Helper service a last time to force DirectAccess to use the only remaining certificate in the computer store to initiate IPSEC tunnels.
Even with Windows 8 and Unified Remote Access, performing some basic tests before shipping DirectAccess computers to users remain an excellent idea. The certificate missing case, is easy to solve. It’s to the case if the Group Policies were not applied to computers
BenoîtS – Simple and Secure by Design but Business compliant