Today I was working with a customer and they mentioned they had just been contacted about an enrollment problem on one of their CAs. They had recently added a template to one of their Windows Server 2012 R2 CAs. The template had been in use for a long time and is present on their other CAs. The user enrolling for the certificate was receiving an error about how the template was not available on the CA. We could look on the CA and see that the template was clearly there.
Here is what the user was reporting when they attempted to enroll (all screenshots are lab reproductions of the issue). The error stated “The requested certificate template is not supported by the CA. Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate Services policy:XXXXXXXXX. CRTSRV_E_UNSUPPORTED_CERT_TYPE”
On the CA we could clearly see template listed on the CA and we could also see the failed enrollment.
At first all of the obvious things were addressed. Perhaps the template being used by the user was different than what we were looking at. So we verified the template OID in the request matched the template we had on the CA.
We used Certutil -view -restrict “requestid=xxx” to dump the enrollment request from the CA database to verify what was sent, to eliminate any chance the user left off part of the story.
Next, we looked at the permissions on the template. The template should our user had read and enroll permission for the computer object they were enrolling (CMB).
But while we were looking here, I suddenly had an ah-ha moment! Do you see it? The permissions showed me not only what the error was, but how the problem had occurred. Don’t see it yet?
One of the things I often tell customers, and students in my PKI classes, is that all templates by default have Authenticated Users with Read permission. This is a default configuration and one I recommend that never changes – because of issues like this. Notice that the CA computer is not listed in the permissions above. So in affect, the CA can’t see/read the template itself. The template is “added” to a CA but an administrator. But that process “New/Certificate Template to Issue” merely places an attribute on the CA’s Enrollment Services object in AD. So all that is needed is read permission for the administrator to add a template.
So when the user attempted to enroll, it retrieved the Enrollment Services objects, saw what templates were listed as available, and then download the templates from AD. It formulated its enrollment and sent it to the CA. At this point, the CA didn’t “know” anything about the request template, in affect, it couldn’t see that template. So it denied the enrollment.
So the fix, it was an easy one – add Authenticated Users back to the template and grant it Read permissions.