Introduction to auto-enrollment

Auto-enrollment is a useful feature of Active Directory Certificate Services (AD CS). It allows the administrator to configure subjects to automatically enroll for certificates, retrieve issued certificates, and renew expiring certificates without requiring subject interaction. The subject does not need to be aware of any certificate operations, unless you configure the certificate template to interact with the subject. A subject in this case can be either a user account or a machine account. (And just a reminder; certificate auto-enrollment is only possible with version 2 certificate templates and these are only available with a Windows Server 2003 Enterprise based Certificate Authority or newer, and a domain with the Windows Server 2003 schema or newer.)

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 ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesCertificate Service Client – Auto-enrollment
User: User ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesCertificate Service Client – Auto-enrollment

The dialog box is identical and looks like this when enabled:

Just for reference, here is how this dialog looked in Windows XP/Windows Server 2003:

Back then it was located under User/Computer ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesAutoenrollment Settings.

While in the computer part of the GPO you will also notice another setting which deals with auto-enrollment:

Computer ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesAutomatic Certificate Request Settings

This settings configures which types of certificates a computer should automatically enroll for; Computer, Domain Controller, Enrollment Agent (Computer) or IPSec. This setting has no value by default, instead you have to complete a short wizard to add a value to it by right-clicking and selecting New: Automatic Certificate Request. This will bring up the wizard:

The steps above will lead to the following setting:

The first setting mentioned, Certificate Service Client – Auto-enrollment, controls whether and how auto-enrollment should be performed. This setting, on the other hand, specifies which certificate template to request certificates for. In some cases the client know which templates it wants certificates from, and only needs to be told to auto-enroll. Other times you have to specify this setting as well to tell the client about the certificates templates you want it to auto-enroll based on. The Automatic Certificate Request Settings key is only available in a domain based GPO, not in local policy. For detailed information about this setting look here:

Auto-enrollment of certificates is triggered by one of these events:

Computer reboot and subsequent Group Policy application/refresh
Interactive logon and subsequent Group Policy application/refresh (Winlogon.exe calls userinit.exe that performs the auto-enrollment based on Group Policy.)
Group Policy refresh, either periodic or forced
certutil.exe –pulse command

By default there are no auto-enrollment settings configured in a Windows domain. Neither the Default Domain Policy nor the Default Domain Controllers Policy contain auto-enrollment settings so none of your computer or user accounts will automatically enroll for any certificates. There are, however, a few exceptions to this rule. One, of which, are Domain Controllers.

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

HKCUSoftwareMicrosoftCryptographyAutoenrollment

Create a new DWORD value named AEEventLogLevel; set value to 0.

Machine Auto-enrollment

HKLMSoftwareMicrosoftCryptographyAutoenrollment

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.

Certificate templates

According to TechNet: Enterprise certification authorities (CAs) use certificate templates to define the format and content of certificates, to specify which users and computers can enroll for which types of certificates, and to define the enrollment process, such as auto-enrollment, enrollment only with authorized signatures, and manual enrollment. Associated with each certificate template is a discretionary access control list (DACL) that defines which security principals have permissions to read and configure the template, as well as to enroll or auto-enroll for certificates based on the template. The certificate templates and their permissions are defined in Active Directory® Domain Services (AD DS) and are valid within the forest. If more than one enterprise CA is running in the Active Directory forest, permission changes will affect all enterprise CAs.

Read the whole text here.

Domain Controller related certificate templates

Domain controllers are interested in the following certificate templates, but depending on the DCs operating system version and the CA’s OS version it depends on what they prefer:

Name	Description	Key Usage	Subject Type	Applications used for enhanced key usage	Application policies or enhanced key usage
Domain Controller	Used by domain controllers as all-purpose certificates and is superseded by two separate templates: Domain Controller Authentication and Directory E-mail Replication	Signature and encryption	DirEmailRep	Client authentication Server authentication	4.1
Domain Controller Authentication	Used to authenticate Active Directory computers and users	Signature and encryption	Computer	Client authentication Server authentication Smart card logon	110.0
Directory E-mail Replication	Used to replicate e-mail within AD DS	Signature and encryption	DirEmailRep	Directory service e-mail replication	115.0
Kerberos Authentication	New in Windows Server 2008, this template is similar to the Domain Controller Authentication template and offers enhanced security capabilities for Windows Server 2008 domain controllers authenticating Active Directory users and computers	Signature and encryption	Computer	Client authentication Server authentication Smart card logon KDC authentication	110.0

The Kerberos Authentication template deserves special mention. Again, from TechNet:

Kerberos Authentication Template

The purpose of the Kerberos Authentication template is to issue certificates to domain controllers, which present the certificates to client computers during user and computer network authentication. Certificates issued via this new template contain two specific attributes. Rather than relying on the DNS name of the computer, applications can verify the following:

The enhanced key usage extension of the certificate contains Key Distribution Center (KDC) authentication.
The domain name is in the subject alternative name extension of the certificate.

By the authority of the issuing CA, these attributes prove that the computer presenting the certificate is a domain controller for the domain contained in the subject alternative name. This new template is recommended for domain controllers running Windows Server 2008. For domain controllers running Windows Server 2003, the Domain Controller Authentication template or the Kerberos Authentication template can be used.

Client computers running Windows Vista, Windows Server 2008 or later can be configured to check for the new enhanced key usage entry by enabling strong KDC validation on the following registry entry:

HKLMSYSTEMCurrentControlSetControlLsaKerberosParameterskdcvalidation

The default value of 0 disables strong KDC validation. To enable strong KDC validation, set this DWORD value to 2.

The following table shows which certificate template can be used for CAs running different versions of Windows, based on which version of Windows the domain controller is running.

*Domain Controller*	*Windows2000 Server-based CA (version 1 only)*	*Windows Server 2003-based CA*	*Windows Server 2008-based CA*
*Windows 2000 Server (enroll for version 1 templates only)*	Domain Controller	Domain Controller	Domain Controller
*Windows Server 2003*	Domain Controller	Domain Controller or Domain Controller Authentication Directory E-mail Replication	Kerberos Authentication or Domain Controller Authentication Directory E-mail Replication
**Windows Server 2008**	Domain Controller	Domain Controller or Domain Controller Authentication Directory E-mail Replication	Kerberos Authentication Directory E-mail Replication
Windows Server 2012	Domain Controller	Domain Controller or Domain Controller Authentication Directory E-mail Replication	Kerberos Authentication Directory E-mail Replication

Note

If the CA administrator has not manually assigned the Domain Controller Authentication and Directory E-mail Replication certificate templates to a Windows Server 2003–based CA or a Windows Server 2008–based CA, domain controllers running Windows Server 2003 still use the default Domain Controller certificate template. If a Windows Server 2008–based CA is available and configured to issue the Kerberos Authentication template, a domain controller running Windows Server 2003 or Windows Server 2008 will enroll for a Kerberos Authentication certificate, even if it already has a Domain Controller Authentication certificate.

The Kerberos Authentication certificate template is fully backward-compatible with the previous domain controller templates; for example, when the domain controller has a Kerberos Authentication certificate, smart card logon can be performed even with a client computer running Windows 2000 Professional.

The following table shows the default templates in Windows Server 2008 and Windows Server 2003.

Template name	Windows 2000 Server	Windows Server 2003	*Windows Server 2008/2012*
Directory E-mail Replication			X
Domain Controller	X	X	X
Domain Controller Authentication		X
Kerberos Authentication			X

Domain Controller auto-enrollment behavior

It depends when Domain Controllers auto-enroll for the different certificates listed in this post. All domain controllers are hard coded to automatically enroll for a certificate based on the Domain Controller template if it is available for enrollment at a certificate authority in the forest. Hard coded in this case means it is in the code, it is not configured in any local or domain based policy. This is one of the few cases where Windows will auto-enroll for a certificate without auto-enrollment being configured in Group Policy. If the Domain Controller certificate template is not available and enhanced logging for auto-enrollment is enabled you will see the following event in the Application log of a domain controller:

Event ID: 47

Message: Certificate enrollment for Local system could not enroll for a DomainController certificate. A valid certification authority cannot be found to issue this template.

Unless you configure auto-enrollment; that is that. The DC will not auto-enroll for any other certificate on its own. However, if you do enable auto-enrollment, preferably at the domain level so the settings applies to all computers/users in your domain, the behavior changes.

To enable auto-enrollment you need to configure a domain GPO like this:

This will enable auto-enrollment, renew, update and remove certificates and do all these for certificates based on templates.

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 <CA Name>.

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 <CA name>.

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 <CA name>.

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.

Tips and tricks

If your want to check the status of the certificates on your DC; run certutil.exe –DCInfo. It will enumerate all your DCs and check their certificates.
To reinstall the default certificate templates that come with your version of Windows Server into the Configuration NC; run certutil.exe –InstallDefaultTemplates. Note: this will not set up any CAs to issue any templates, just reinstall the template definitions into your Active Directory forest. To list your current templates from Active Directory; run certutil.exe –Templates.

More information

Oh, and in case you are wondering, the other exception to the default “no auto-enrollment” behavior is EFS, which will always attempts to enroll for the Basic EFS template. The EFS driver generates an auto-enrollment request that Auto-enrollment tries to fulfill.

Morgan Simonsen's Blog

Monthly Archives: June 2013

Active Directory Domain Controllers and certificate auto-enrollment