Server 2012 R2 member server or domain controller can't enroll computer certificate

This article is titled Server 2012 domain controller can't enroll computer certificate, however this also applies to Server 2008 R2 and 2012.

This issue came about by receiving a call early Monday morning reporting that some devices couldn't connect to our wireless network. We immediately suspected an NPS issue, as users reported devices on other SSID were not affected.

Upon investigating the issue, We found one of our NPS connection request policies complaining there was no valid certificate available to authenticate EAP/PEAP requests. This was strange as all NPS are members of AD and should receive certificates via automatic certificate enrollment. In fact all these NPS initially received a certificate when they joined the domain via automatic enrollment.

Next we opened the Certificates (Local Computer) MMC snap-in and went to local computer personal certificates, the only certificate listed had expired the previous night, problem confirmed.



The Problem

Upon attempting to manually request a new certificate we were greeted with "Certificate types are not available". It was almost as if there was no certificate services in the domain.

We jumped onto another domain joined server and found we could successfully enroll a computer certificate and inspection of other servers showed they all had up to date and valid certificates, only this one server was affected.

The only difference between the problematic server and other servers tested was our faulting server was a domain controller. This led us to the Certificate Templates snap-in on the Certificate Authority (CA) server.



The Resolution

1. Go to your CA and open the Certificate Templates snap-in. 

2. Right click Computer (or whatever Certificate you are trying to enroll and click properties) 

3. Open the Security tab 

4. Add "Domain Controllers" read and enroll permission, apply and close. If your member servers are experiencing this issue, you may need to add "Domain Computers" with read and enroll.

On our CA, "Domain Controllers" was missing permissions on the Computer certificate. As soon as we added Domain controllers with read and enroll permissions, the NPS could immediately enroll a new certificiate.

Originally when our domain controller was a member server, it was part of the Domain Computers group, which had the required read and enroll permissions and therefore received a certificate upon joining the domain. However the member server was then upgraded to a DC and when it attempted to request a new certificate it was denied as it didn't have appropriate permission.

A big problem caused by a simple and easy to fix error.

TMG 2010 Certificate Enrollment Fails - RPC server is unavailable

During some recent TMG 2010 maintenance, we noticed the TMG computer certificate had expired a few months earlier, this should never occur as our Active Directory CA should re-issue a certificate when expiration is near.

We first attempted to manually re-request the certificate via the Certificates MMC snap-in and were presented with an error saying "The RPC server is unavailable."

'

Our eventlogs suggested that a DCOM problem may have occurred. After checking DCOM and the RPC Service we were unable to uncover any issues.

The Solution

It turns out TMG itself introduces this error intentionally. The "Enable strict RPC compliance" setting, which is enabled by default, blocks the RPC functionality required for AD based certificate enrollment to work. Fortunately the fix is straight forward.

1. Open your TMG console 

2. Navigate to "Firewall Policy" 

3. Right click "Firewall Policy", select "All Tasks", select "System Policy" and finally select "Edit System Policy"
 

4. Under "Authentication Services" select "Active Directory 

5. Untick "Enforce strict RPC compliance
 

6. Click "OK" 

7. Apply the policy changes

You should of course do the appropriate research before disabling this setting, in some super high security environments you may not wish to disable RPC compliance, however in our environment it made no difference.

After waiting a few minutes for the policy changes to occur our problem was resolved, certificate enrollment once again worked perfectly.