As per this question, I have an environment where certificates based on the "Kerberos Authentication" template cannot be issued (there are remote sites without direct connectivity to the CA, certificate enrollment uses CEP/CES, but the Kerberos Authentication template requires the CA to connect back to the requesting DC; full details in the linked question).
We can live without those certificates… but all domain controllers keep requesting them when auto-enrollment is enabled.
I tried disabling the template, but the DCs keep trying and failing with the error "The requested certificate template is not supported by this CA".
How can I tell DCs to only request a "Domain Controller Authentication" certificate and stop trying to get a "Kerberos Authentication" one?
Best Answer
There can be two inputs for this issue:
Part 1: Template supercedence
In certificate template settings (certtmpl.msc), there is Superseded Templates tab, where you can specify a list of templates that are superseded by current template. This setting is used only by certificate autoenrollment feature.
During autoenrollment, client examines every template and checks if current template is listed as *superseded* in any other template. If it is listed, then current template is skipped. This behavior is defined in [MS-CAESO] protocol specifications, §4.4.5.6.1:
This answers first half of question: why allowed for autoenrollment template is not autoenrolled. Thus, check if neither of templates is configured to supersede
Domain Controller Authentication
template. If there is such, remove it from superseded list.And check if
Domain Controller Authentication
is added for issuance to CA that is enabled for web enrollment.Part 2: MS-XCEP Cache
When clients use certificate enrollment web services (Microsoft CEP/CES), they do following:
Read
permissions.Response message has
nextUpdateHours
which is:Default value is 8 hours. Client caches this response and may not attempt to request new policy with updated template list for this period of time. Although, there is boolean
policiesNotChanged
field which can be used by clients to poll for changes, but from practice I can tell that clients do not perform polling. Instead, they use this bit to determine if cached policy should be replaced or not. This is just my opinion, because any changes in policy have big latency on clients.Either, wait for at least 8 hours and see if the issue is resolved automatically when clients fetch new policy from CEP server or try to force policy retrieval:
Delete all contents from
%systemdrive%\ProgramData\Microsoft\Windows\X509Enrollment
on target computer (DC) and then runto trigger autoenrollment. During this call, a new policy will be downloaded and autoenrollment should pick up the correct template.