1

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?

Massimo
  • 70,200
  • 57
  • 200
  • 323
  • You should add that your DCs use enrollment web services to get certificates. It can be important. – Crypt32 Mar 08 '20 at 15:25
  • Do the DC's continue to request a Kerberos Authentication cert if the template is unpublished, or if the Domain Controller Authentication template is configured to supersede the Kerberos Authentication template? – Greg Askew Mar 08 '20 at 15:31
  • @Crypt32 Added some details. – Massimo Mar 08 '20 at 15:47
  • @GregAskew yes and yes. It seems to be hardcoded in the DCs to try to obtain a "Domain Controller Authentication", a "Directory Email Replication" and a "Kerberos Authentication" certificate, even if the templates aren't there. – Massimo Mar 08 '20 at 15:49
  • I also tried removing the "enroll" and "autoenroll" permissions from the template for DCs; they still keep trying and the request gets denied. – Massimo Mar 08 '20 at 15:56

1 Answers1

2

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:

4.4.5.6.1 Determine if a CertificateTemplate Instance is Valid for Autoenrollment If any conditions in the following list are true, autoenrollment SHOULD NOT process a new enrollment for the specific CertificateTemplate instance

<...> skipped for brevity

  • There exists an instance of CertificateTemplate in the CertificateEnrollmentPolicy.Templates list whose CertificateTemplate.SupersededTemplates list contains a value equal to the current CertificateTemplate.CommonName

 

Note: In 2014, [MS-CAESO] document was retired and its content was moved to a number of other protocols specs and I haven't tried to track this move. Given that nothing was changed since then, you can use an archived PDF copy of the document: Archived [MS-CAESO] PDF copy.

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:

  1. Connect to enrollment policy service (CEP) and request policy.
  2. CEP authenticates the client and reads all certificate templates from Active Directory where authenticated entity has at least Read permissions.
  3. CEP contacts CAs to get the list of templates allowed by each CA and constructs response as specified in [MS-XCEP] §3.1.4.1.3.23

Response message has nextUpdateHours which is:

An integer representing the number of hours that the server recommends the client wait before submitting another GetPolicies message.

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 run

certutil -pulse

to trigger autoenrollment. During this call, a new policy will be downloaded and autoenrollment should pick up the correct template.

Community
  • 1
Crypt32
  • 6,639
  • 1
  • 15
  • 33
  • Clearing the cache did the trick; disabling the "Kerberos Authentication" template works fine... after the DCs pick up the setting. – Massimo Mar 08 '20 at 16:38
  • 1
    Yes, caching is confusing when you move from RPC/DCOM to web services. But supercedence play its role as well. When I use `Kerberos Authentication` template, I always include previous DC templates to superseded list. And if you want to fallback to previous versions, you have to modify newer version to clear superseded list. – Crypt32 Mar 08 '20 at 16:41
  • That wasn't my case, but good to point it out. – Massimo Mar 08 '20 at 16:45