Unavailable Certificate Templates in a Multi-Domain Forest.

In my previous blog post we looked at the permissions needed on the “CertSrv Request DCOM interface” of the Issuing Enterprise Certificate Authority. As you will know right now is that this DCOM services is used by the “remote create instance request” send by enrollment agents to the CA, and what the minimal permissions for the DCOM service should be to successful process remote certificate requests.

In this blog post I like to take you with me looking at some issues sending remote certificate requests to an issuing Enterprise CA in a multi-domain Forest. In this scenario I worked on an Active Directory Forest including two domain trees where we need to configure additional areas within the certificate service environment. The reason why is, when we deploy an Enterprise Issuing CA in a multi-domain Forest the certificate services setup does not automatically set permissions to handle requests from outside the certification authority’s domain.

By default, enrollment agents from outside the Certification Authority’s domain will not be able to enroll a certificate due to lack of permissions and trust causing the unavailability of certificate templates.

For example, if you run a PowerShell cmdlet to request a new certificate from outside the other domain(s), you end up with the following description.

[ps]..> $dnsnames=”srv1.corpabc.com”
[ps]..> $cert = Get-Certificate -Template ‘Device TLS’ -Url ‘ldap:///CN=lnlabscorp-CA’ -DnsName $dnsnames -CertStoreLocation Cert:\LocalMachine\My

Or if we use the certificate manager snap-in, in the Microsoft management Console to send a certificate request where we leverage the Active Directory Enrollment policy, we experience status issues in the response searching for certificate templates.

Looking under the hood.

The result on the requests to the certificate service are telling us that we have issues receiving available certificate templates and/or that we have no permission to request a new certificate. To manage this issue, we first look at the process of retrieving certificate templates. The following process flow take place querying certificate templates.

Source: docs.microsoft.com

As you will see in the process flow above, is that an enroll agent is sending a LDAP query to the Active Directory searching for available certificate templates. And this is where it goes wrong in my scenario.

Setting up an Enterprise CA will add Active Directory objects in the “Configuration partition” of the Forest. And as you know, this partition is replicated throughout the Forest which ensures that AD integrated services are available for all domains in a Forest.

By default, the setup will take care of the default permissions in the domain where the CA resides but it does not take care of all the permission for the other domain(s) in the Forest.

In my setup the first domain is mandatory for the certificate service.

Configure permissions and trust.

With that said, we need to take care of two things to make sure the certificate service is available to enroll certificates in the other domain(s) of the Forest too.

  1. Configure the CA as a trusted Issuer in the other domain(s).
  2. Setup template permissions to allow access.

The first thing we need to do is to deploy the certificate of the CA (Issuing, Policy and Root depending on the tiers of your PKI) holding the public Key. This certificate we need to install on the “Trusted Root CA” (and/or Intermediate CA) certificate containers of our devices in the other domain(s).

To do this, we create an export of the CA certificate(s) holding the public key, and setup a “Public Key Policy” leverage an “Active Directory group policy object” (GPO). I will not go into many details on this because I believe you already know how to manage this.

GPO public key policy

Note: We need this certificate to close the certificate chain to make sure we can trust the CA so that the issued certificates and used templates are valid.

The second thing we need to do is to configure the appropriate permissions on the certificate template(s) we provide for the enroll agents in the other domains of the Forest. I created a template called “Device TLS” before, setup the attributes we need and now add these permissions to this template:

  • <seconddomain>\agents – Read, Enroll.
  • <seconddomain>\computers – Enroll.

Note: Notice I delegate the permissions to global groups from the second domain in the forest by adding these to the “Device TLS” template in the first domain.

Check availability of our certificate service.

At this point I run my PowerShell cmdlets again to request a new certificate with the template I did create before and as you see the certificate service is now fully available to enrollment agents outside the CA’s domain, and my request is successful.

[ps]..> $dnsnames=”srv1.corpabc.com”
[ps]..> $cert = Get-Certificate -Template ‘Device TLS’ -Url ‘ldap:///CN=lnlabscorp-CA’ -DnsName $dnsnames -Subjectname “CN=$dnsnames” -CertStoreLocation Cert:\LocalMachine\My
[ps]..> $cert | FL

Great, now the certificate manager snap-in is also showing a successful result too, see the availability of the certificate template I create. Now we can carry on sending remote certificate requests from all domains to certificate service in our forest.


With this simple setup I try explaining the concept on an AD integrated certificate service in a multi-domain forest. We did experience some enrollment issues in the second domain due to lack of permissions and trust causing the unavailability of certificate templates. We managed this by taking care of the following two things:

  1. Configure the CA as a trusted Issuer in the other domain(s).
  2. Setup template permissions to allow access.

Note: Always use RBAC to design your environment and restrict enrollment agents to only those identities who are authorized for the job.

Thank you for reading!!

Additional readings:

Enroll on Behalf of Request and Renewal