Auto-enrollment is configured through Group Policy and can be set for both types of subjects; users and computers. The location in a GPO is:
Computer: Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Service Client – Auto-enrollment
User: User Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Service Client – Auto-enrollment
Enhanced event logging for auto-enrollment
To understand certificate auto-enrollment it helps to enable enhanced logging. By default, auto-enrollment logs errors/failures and successful enrollments in the Application Event log on the client machine.
To enable enhanced logging of auto-enrollment processes, the following registry values must be created:
User Auto-enrollment
HKCU\Software\MicrosoftCryptography\Autoenrollment
Create a new DWORD value named AEEventLogLevel; set value to 0.
Machine Auto-enrollment
HKLM\Software\Microsoft\Cryptography\Autoenrollment
Create a new DWORD value named AEEventLogLevel, set value to 0.
Note All failures and errors are automatically logged. It is not necessary to enable the registry key to turn on failure logging.
Now since auto-enrollment is enabled, the Domain Controllers change their behavior. After a new auto-enrollment is triggered we will the the following events (in reverse order) in the Application log of enhanced logging is enabled:
Event ID: 47
Message: Certificate enrollment for Local system could not enroll for a KerberosAuthentication certificate. A valid certification authority cannot be found to issue this template.
Event ID: 47
Message: Certificate enrollment for Local system could not enroll for a DomainControllerAuthentication certificate. A valid certification authority cannot be found to issue this template.
Event ID: 47
Message: Certificate enrollment for Local system could not enroll for a DirectoryEmailReplication certificate. A valid certification authority cannot be found to issue this template.
Event ID: 57
Message: The “Microsoft Platform Crypto Provider” provider was not loaded because initialization failed.
Event ID: 56
Message: Certificate enrollment for Local system for the template DomainController was not performed because this template has been superseded.
Let’s look at these from bottom to top:
ID 56 indicates that the DC has now switched from the hard coded behavior of requesting a certificate based on the Domain Controller template. Since auto-enrollment is now enabled it knows that that certificate template has been superseded. The next events with ID 47 informs us that although the DC would now like to use the new templates, they are not available on any CA in the forest.
As we can see from a previous table in this post, all CAs have the Domain Controller template in their default template list, meaning they can all support the “legacy” hard-coded behavior of any DC to request a certificate based on that template. However, as we have seen, when auto-enrollment is enabled the DC’s preference changes to prefer templates that supersede this template. The Domain Controller E-mail Replication (v2) and Domain Controller Authentication (v2) templates both supersede the Domain Controller (v1) template, and if they are available a DC prefers those. The Kerberos Authentication certificate is even more preferred by DC and they will enroll for a certificate based on this template even if they already have a certificate based on either the Domain Controller (v1) template or the Domain Controller Authentication (v2) template. The Kerberos Authentication certificate is fully backwards compatible with the other templates and can be used for smart card logon. So lets enable the templates and see how the DC’s behavior changes.
First lets enable the legacy Domain Controller template:
On the CA: certutil.exe -SetCAtemplates +DomainController
On the DC: certutil-exe –pulse
This will change nothing since the DC is now configured for auto-enrollment as knows that the Domain Controller Template is superseded. The DC will log a warning that the Domain Controller template has been superseded and the the Domain Controller Authentication, Directory E-mail Replication and Kerberos Authentication templates are all unavailable. So let’s enable the next template; Domain Controller Authentication:
On the CA: certutil.exe -SetCAtemplates +DomainControllerAuthentication
On the DC: certutil-exe –pulse
The DC will now successfully auto-enroll for and receive a certificate based on this template. A new event will be generated in the Application log:
Event ID: 19
Message: Certificate enrollment for Local system successfully received a DomainControllerAuthentication certificate with request ID from certification authority .
Warnings are still generated for the Directory E-mail Replication and Kerberos Authentication template based certs. They are still unavailable.
OK, let’s enable the next template; Directory E-mail Replication:
On the CA: certutil.exe -SetCAtemplates +DirectoryEmailReplication
On the DC: certutil-exe –pulse
The DC will now successfully auto-enroll for and receive a certificate based on this template. A new event will be generated in the Application log.
Event ID: 19
Certificate enrollment for Local system successfully received a DirectoryEmailReplication certificate with request ID from certification authority .
Again, there will be warnings for the Kerberos Authentication template certificate.
Last template: Kerberos Authentication:
On the CA: certutil.exe -SetCAtemplates +KerberosAuthentication
On the DC: certutil-exe –pulse
The DC will now successfully auto-enroll for and receive a certificate based on this template, even though it already has certificates based on the Domain Controller Authentication and Directory E-mail Replication templates. A new event will be generated in the Application log:
Event ID: 19
Certificate enrollment for Local system successfully received a KerberosAuthentication certificate with request ID from certification authority .
Still, there will be a warning about the Domain Controller template being superseded. This will happen as long as enhanced logging is enabled.
Now the DC will have three certificates based on the Domain Controller Authentication, Directory E-mail Replication and Kerberos Authentication templates. And just to make this perfectly clear; the DC will request always request a certificate based on each of these three templates if they are available.
Computer: Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Service Client – Auto-enrollment
User: User Configuration\Windows Settings\Security Settings\Public Key Policies\Certificate Service Client – Auto-enrollment
Enhanced event logging for auto-enrollment
To understand certificate auto-enrollment it helps to enable enhanced logging. By default, auto-enrollment logs errors/failures and successful enrollments in the Application Event log on the client machine.
To enable enhanced logging of auto-enrollment processes, the following registry values must be created:
User Auto-enrollment
HKCU\Software\MicrosoftCryptography\Autoenrollment
Create a new DWORD value named AEEventLogLevel; set value to 0.
Machine Auto-enrollment
HKLM\Software\Microsoft\Cryptography\Autoenrollment
Create a new DWORD value named AEEventLogLevel, set value to 0.
Note All failures and errors are automatically logged. It is not necessary to enable the registry key to turn on failure logging.
Now since auto-enrollment is enabled, the Domain Controllers change their behavior. After a new auto-enrollment is triggered we will the the following events (in reverse order) in the Application log of enhanced logging is enabled:
Event ID: 47
Message: Certificate enrollment for Local system could not enroll for a KerberosAuthentication certificate. A valid certification authority cannot be found to issue this template.
Event ID: 47
Message: Certificate enrollment for Local system could not enroll for a DomainControllerAuthentication certificate. A valid certification authority cannot be found to issue this template.
Event ID: 47
Message: Certificate enrollment for Local system could not enroll for a DirectoryEmailReplication certificate. A valid certification authority cannot be found to issue this template.
Event ID: 57
Message: The “Microsoft Platform Crypto Provider” provider was not loaded because initialization failed.
Event ID: 56
Message: Certificate enrollment for Local system for the template DomainController was not performed because this template has been superseded.
Let’s look at these from bottom to top:
ID 56 indicates that the DC has now switched from the hard coded behavior of requesting a certificate based on the Domain Controller template. Since auto-enrollment is now enabled it knows that that certificate template has been superseded. The next events with ID 47 informs us that although the DC would now like to use the new templates, they are not available on any CA in the forest.
As we can see from a previous table in this post, all CAs have the Domain Controller template in their default template list, meaning they can all support the “legacy” hard-coded behavior of any DC to request a certificate based on that template. However, as we have seen, when auto-enrollment is enabled the DC’s preference changes to prefer templates that supersede this template. The Domain Controller E-mail Replication (v2) and Domain Controller Authentication (v2) templates both supersede the Domain Controller (v1) template, and if they are available a DC prefers those. The Kerberos Authentication certificate is even more preferred by DC and they will enroll for a certificate based on this template even if they already have a certificate based on either the Domain Controller (v1) template or the Domain Controller Authentication (v2) template. The Kerberos Authentication certificate is fully backwards compatible with the other templates and can be used for smart card logon. So lets enable the templates and see how the DC’s behavior changes.
First lets enable the legacy Domain Controller template:
On the CA: certutil.exe -SetCAtemplates +DomainController
On the DC: certutil-exe –pulse
This will change nothing since the DC is now configured for auto-enrollment as knows that the Domain Controller Template is superseded. The DC will log a warning that the Domain Controller template has been superseded and the the Domain Controller Authentication, Directory E-mail Replication and Kerberos Authentication templates are all unavailable. So let’s enable the next template; Domain Controller Authentication:
On the CA: certutil.exe -SetCAtemplates +DomainControllerAuthentication
On the DC: certutil-exe –pulse
The DC will now successfully auto-enroll for and receive a certificate based on this template. A new event will be generated in the Application log:
Event ID: 19
Message: Certificate enrollment for Local system successfully received a DomainControllerAuthentication certificate with request ID from certification authority .
Warnings are still generated for the Directory E-mail Replication and Kerberos Authentication template based certs. They are still unavailable.
OK, let’s enable the next template; Directory E-mail Replication:
On the CA: certutil.exe -SetCAtemplates +DirectoryEmailReplication
On the DC: certutil-exe –pulse
The DC will now successfully auto-enroll for and receive a certificate based on this template. A new event will be generated in the Application log.
Event ID: 19
Certificate enrollment for Local system successfully received a DirectoryEmailReplication certificate with request ID from certification authority .
Again, there will be warnings for the Kerberos Authentication template certificate.
Last template: Kerberos Authentication:
On the CA: certutil.exe -SetCAtemplates +KerberosAuthentication
On the DC: certutil-exe –pulse
The DC will now successfully auto-enroll for and receive a certificate based on this template, even though it already has certificates based on the Domain Controller Authentication and Directory E-mail Replication templates. A new event will be generated in the Application log:
Event ID: 19
Certificate enrollment for Local system successfully received a KerberosAuthentication certificate with request ID from certification authority .
Still, there will be a warning about the Domain Controller template being superseded. This will happen as long as enhanced logging is enabled.
Now the DC will have three certificates based on the Domain Controller Authentication, Directory E-mail Replication and Kerberos Authentication templates. And just to make this perfectly clear; the DC will request always request a certificate based on each of these three templates if they are available.
Tags
Certificates