Categorie: IAAS

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.

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.

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.

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.

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.

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.

Summary.

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

Installing a Active Directory Domain- and Certificate Services within my Infrastructure as a Services (IAAS) environment, I ran into Issue’s deploying certificates. I am not able to remotely request certificates with, for instance, the certificate manager snap-in of the Microsoft management Console (MMC) at a Windows 10 clients and Windows 2016 IIS member servers. Next you will see a simple overview of my setup.

I run the certificate manager snap-in, in the Microsoft management Console where I select the computer account certificate store and then my personal certificate container. I choose “Request New Certificate” where the wizard opens an dialog to request a certificate, we leverage the Active Directory Enrollment policy for the request. After defining the certificate attributes, I am of to enroll the required certificate and end up with the following error message:

Certificate enrollment for Local system failed in authentication to all URLs for enrollment server associated with policy id: …..(The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)). Failed to enroll for template: …

Note: This Issue generates two events with ID numbers 82 and 13 in the application section of the event viewer on my member server.

Causing the unavailability of a RPC server spans many scenario’s, to begin with looking at network, firewall or service issues. Before I dive into the network layer or spitting down the local firewalls in my IAAS environment I first shoot of some basic test commands to see what is happening here.

Check Remote procedure calls to the CA

Assume there is an issue with the RPC channel to the CA server I leverage the following tests to find out if there are issues related to network or service availability. For action this I use the PowerShell command line to run some cmdlets an start off with the Nltest command to find out if there are problems with netlogon calls from the requesting member server to domain controller in the active directory domain.

This result tells me there is no issue with the netlogon service requests sending from the member sever.

Next I check if remote procedure calls (RPC) Service on the Enterprise Certificate Auhority is available to receive calls from my requesting member server. With this we also implicit check if some firewall setting or network related issues prevent us from connecting to the Certificate Authority.

Also this test is successful and give us the response we want. Using the CA server FQDN tells me that DNS is working fine as well.

Checking how the CA responding

We check network and service related scenario’s and they give no errors. With this we have to look further to find out if the CA is responding the correct way. These actions checks if there are issues with the following interfaces:

• Active Directory Certificate Services Request interface: Certutil -ping
• Active Directory Certificate Services Admin interface: Certutil -pingadmin

I the following commands I run on the PowerShell Command Line from off the member to the Enterprise Certificate Auhority server.

Both commands are telling us that the we have no issues related to the Enterprise Certificate Authority interfaces handling the request and we have to dig deeper.

Investigate the request flow with Wireshark

The test scenario’s in section above tells us there are no issues with network and services, so we must dig deeper into the request. For this I am going to use Wireshark and dive in to request we are sending from the Member server.

In this case I installed Wireshark on the member server but there other possible scenario’s to fiddle the network traffic. The figure below shows us the outcome of the Wireshark trace:

Analyzing the trace gives us an E_Accessdenied result back from the “CertSrv Request DCOM interface” of the Enterprise Certificate Authority. This DCOM services (see figure below) is used by the “remote create instance request” part of the trace which send from the member server to the CA.

The permissions on the DCOM interface

For “CertSrv Request DCOM interface” to work without errors, there need to be some security settings in place to guarantee the DCOM interface respond as it should be.

1- One is the builtin domain local security group “Certificate Service DCOM Access. This security group is automatically created during setup of the AD-CS role and should minimally have the “Authenticated Users” as a member of this group. Which in our case, this configuration suits this requirement.

Note: If the certification authority is installed on a member server, “Certificate Service DCOM Access” is created as a computer local group. The Everyone security group is added to “Certificate Service DCOM Access”.

2- Second are the security properties of the DCOM service. Opening the security properties of the Certsvc Request services in the DCOM Config (dcomcnfg) we see three area’s of permissions we can configure.

• The Certificate Service DCOM Access security group is granted local and remote access permissions.
• The Certificate Service DCOM Access security group is granted local and remote activation permissions.
• The Certificate Service DCOM Access security group is not granted local or remote launch permissions.

Note: We should not set the Everyone security group on the CertSrv Request DCOM interface, always restrict access to the interface for security reasons. In my case only the Certificate Service DCOM Access security group was added to the DCOM interface.

After investigating the settings on the two area’s above we find out there is nothing wrong, all security setting above are in place, as expected. Fact is, we still are not able to request a certificate and ending up with a E_Accessdenied.

The first two parts of permissions the don’t have anomalies so we have to look further Request DCOM interface.

Third part of the interface is the configuration permissions. Default there are the following permissions are set:

1. Application Packages
2. Creater Owner
3. System
4. MyDomain\Administrator
5. MyDomain\Users

Seems quite normal here too so I decide to check on the default security groups and there group members. I used the following reference for this: https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups

Checking the MyDomain\Users and found out there is no match with the Microsoft reference guide. We are missing the special groups INTERACTIVE and “Authenticated Users”. I decide to add these security principles one by one to the MyDomain\Users group. I started with “Authenticated Users” and off we go, this is solving the access denied issue causing the event “The RPC server is unavailable” on the client and member requesting a Certificate.

Summary

I recover the default memberships of the Mydomain\Users security group and this resolve the issue causing the event “The RPC server is unavailable” when requesting an certificate. Reason why we are missing the default members in the Mydomain\Users security group I still did not find out yet, but for now we are good to go and carry on setting up the environment using the Enterprise Certificate Authority.