“RPC server unavailable” error requesting Certificates.

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.