This is a third part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:

• Certificate Autoenrollment in Windows Server 2016 (part 1)
• Certificate Autoenrollment in Windows Server 2016 (part 2)
• Certificate Autoenrollment in Windows Server 2016 (part 3)

---

Configuring Advanced Features

This section discusses templates that require certificate manager approval, self-registration authority, and how to supersede a certificate template.

Requiring certificate manager approval

A specific certificate template can require that a certificate manager (CA officer) approve the request prior to the CA actually signing and issuing the certificate. This advanced security feature works in conjunction with autoenrollment and is enabled on the Issuance Requirements tab of a given certificate template (Figure 25). This setting overrides any pending setting on the CA itself.

Once certificate manager approval is required, all automatic enrollment requests are not issued until a certificate manager manually approves the request.

Figure 25: Setting the Requirement for Certificate Manager Approval

The autoenrollment process will periodically check the CA for approved requests and install the certificates automatically. Smart cards, user certificates, and machine certificates support pending requests. In the case of smart cards, the user will be prompted to insert the smart card when the certificate is issued so that the certificate may be written to the card.

The autoenrollment process supports a maximum of one signature requirement on the template. This limitation exists to support the self-registration authority feature described in Self-Registration Authority. If multiple signatures are desired for a given certificate enrollment, manual enrollment should be used.

Self-registration authority

The self-registration authority (Self RA) is an advanced feature of certificate enrollment that may be combined with the autoenrollment process.

Self RA refers to certificate enrollment based on the existence of a previously enrolled certificate in which the users private key is used to sign the new certificate request. The Certificate Management Messages over CMS (CMC) protocol provides for this feature where one or more signatures may be used or required for a given certificate enrollment. Self RA requirements are defined in a certificate template which may be managed using the Certificate Templates MMC snap-in.

To add an issuance (signature) requirement to a certificate template, open the template and click the Issuance Requirements tab.

To add a signature or issuance requirement, select the This number of authorized signatures check box and add the appropriate number in the following number field (Figure 26).

Now you may add specific requirements for the signing certificate.

Figure 26: Setting the Number of Authorized Signatures

The previous setting is a useful configuration for customers who want to manually enroll users for smart cards with an enrollment station. Then they can supersede the original template with a new template with the previous settings to allow automatic renewal through the autoenrollment process, which will require the user to sign the renewal request with the old certificate.

Additional Self RA Example: You could add the Application Policy for a smart card logon certificate that would be used to enroll for an EFS certificate. This would mandate that users sign their request for an autoenrolled EFS certificate with a valid smart card certificate. The user would then be prompted to insert a smart card and enter a PIN when autoenrollment was activated for the EFS certificate.

Superseding certificate templates

Certificate autoenrollment also supports the concept of superseding a template or a previously enrolled certificate. Superseding a template allows an administrator to re-enroll, change, or combine previously issued certificate enrollments into a new certificate enrollment. Autoenrollment always examines existing certificates in the users store and determines if the template used in the issued certificate has been superseded. If a certificate template has been superseded, the user will automatically be enrolled with the new template, and the old certificates will be deleted or archived depending on the template setting.

Superseding certificate templates is especially useful in the following scenarios.

• Changing certificate lifetime
• Increasing key size
• Adding extended key usage or application policies
• Correcting enrollment policy errors
• Updating users from version 1 templates to version 2 templates

To create or modify a template to supersede an existing certificate

1. Open the Properties of the template to take precedence, click the Superseded Templates tab, (Figure 28) and then click Add.
2. Select the template you want to supersede (Figure 27), and then click OK.

   Figure 27: Selecting a Template to Supersede

3. The template will be added to the Superseded Templates tab (Figure 28). If you wish to add additional templates that should be superseded with this new template, click Add and repeat. Otherwise, click OK.

   Figure 28: Listing Superseded Templates

Superseding a certificate always generates a new private key for the user or machine.

Troubleshooting

This section outlines key scenarios that need to be considered when troubleshooting autoenrollment. It also covers how to prepare for autoenrollment failures and lists event logging messages. The following key issues need to be considered when troubleshooting autoenrollment.

Infrastructure requirements

In Active Directory environment, Windows 10 clients and Windows Server 2016 CAs will always request LDAP-signed communications with domain controllers as a security function.

Root intermediate and cross-certificate download from Active Directory

Autoenrollment automatically downloads root, intermediate and cross certificates from Active Directory whenever a change is detected in the directory or when a different domain controller is contacted. If a third-party root certificate or cross-certificate is deleted from the local machine store, autoenrollment will not download the certificates again until a change occurs in Active Directory or a new domain controller is contacted.

To manually force a new download, delete the following registry key and all subordinate keys on all affected machines:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache

EFS and autoenrollment

EFS always attempts to enroll for the Basic EFS template by default. The EFS component driver generates an autoenrollment request that autoenrollment tries to fulfill. For customers who want to ensure that a specific template is used for EFS (such as to include key archival), the new template should supersede the Basic EFS template. The Basic EFS template should also be removed from any Enterprise CA. This will ensure that autoenrollment will not attempt enrollment for the Basic EFS template any more. For customers who wish to replace the Basic EFS template with a certificate and key that is archived through the Windows CA, the proper procedure is to supersede the Basic EFS template with a new version 2 certificate template.

Revoked certificates and renewal

Revoked certificates cannot be renewed and cannot be used to sign a renewal request. This scenario is explicitly blocked by autoenrollment. In this scenario, a user must perform a new manual enrollment request instead of renewal.

Smartcard renewal

The Smartcard Logon and Smartcard User version 1 templates may not be renewed through autoenrollment. To renew a version 1 Smartcard Logon or Smartcard User template, the proper procedure is to supersede these templates with a new version 2 template.

Autoenrollment always attempts to generate a new key when performing certificate renewal. For smart cards with limited space that do not support additional key generation, autoenrollment will attempt to reuse the key; however, additional space will still be required to install the new certificate. If no space is available on the card for these operations, the renewal through autoenrollment may fail.

The renewal behavior of a smart card may vary depending on the type of smart card CSP being used and the state of the card at the time of renewal. In general, if the smart card being used has available space for an additional enrollment and the CSP supports multiple keys on a single card, autoenrollment will request the card to generate a new key for enrollment. If this succeeds, the certificate is written to the card and the container is marked as default.

The default container is the only container that the Winlogon process will enumerate for a smart card logon certificate and key in Windows XP and Windows Server 2003. Starting with Windows Vista and Windows Server 2008, Winlogon process can use any smart card container for smart card logon operations.

If the smart card or CSP cannot generate a new key on the card, the existing key will be reused and a new certificate will be forced onto the card. This action will generate an event in the machines application event log.

Autoenrollment will always use a newly generated key for all enrollment and renewal requests. The only exception to this rule is in the case of some smart card CSPs that cannot support a new key due to storage limitations on the smart card. If a key is reused, an event will be entered in the Client application log.

Autoenrollment and strong private key protection

The version 2 certificate template properties on the Request Handling tab support the ability to require a user password when the private key is used by applications. This is set by selecting the “Prompt the user during enrollment” option and requires user input when the private key is used. It is important to never use this option for smart card certificates as smart card CSPs also do not support this capability. If this option is chosen, autoenrollment may fail.

Removal of certificates on domain join/change domain

When a machine is removed from a domain or added to a new domain, all the downloaded certificates from Active Directory will be removed and refreshed if applicable. Certificates that were issued or autoenrolled from a previous forest will not be removed unless the machine is a domain controller. All client machines will automatically update certificates when the domain or machine information changes. When machines or users have certificates that are required for secure network communications, wireless communications, and so on, it may be necessary to delete the old certificates after joining a new domain or forest.

Autoenrollment failures

Autoenrollment will warn the user with a warning dialog box when an autoenrollment failure occurs. This feature is only enabled when user interaction is required on the certificate template.

To enable the warning feature for an autoenrollment failure

1. Open the specified template in the Certificate Templates MMC snap-in.
2. Click the Request Handling tab.
3. Click “Prompt the user during enrollment” on the Request Handling tab of the certificate template properties.

Re-initialized smart cards

If enrollment for a certificate is based on the existence of a smart card certificate and if the smart card has been re-initialized, the smart card Insertion dialog box will ask the user to insert a smart card matching the key container identified by the old certificate. Since the key container has been deleted, the Insertion dialog box will continue to display despite the fact that the user has removed and inserted the card. The only choice is to click Cancel and fail the enrollment.

Enhanced event logging

By default, autoenrollment logs errors/failures and successful enrollments in the Application event log on the client machine.

To enable enhanced logging of autoenrollment processes to include warning and informational messages, the following registry values must be created.

• User Autoenrollment

HKEY_CURRENT_USER\Software\Microsoft\Cryptography\Autoenrollment

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

• Machine Autoenrollment

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Autoenrollment

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

All failures and errors are automatically logged. It is not necessary to enable the registry key to turn on failure logging.

Event Log Messages

The following event log messages only appear when additional event logging is enabled.

Success Event Log Messages

The following are samples of successful event log messages.

Event Type:	Information
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	2
Date:	2/26/2001
Time:	12:52:02 PM
User:	N/A
Computer:	COMPUTER1
Description:	Automatic certificate enrollment for local system started.

Event Type:	Information
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	3
Date:	2/26/2001
Time:	12:52:10 PM
User:	N/A
Computer:	COMPUTER1
Description:	Automatic certificate enrollment for local system completed.

Event Type:	Information
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	27
Date:	2/26/2001
Time:	3:26:03 PM
User:	HAYBUV\USER1
Computer:	COMPUTER1
Description:	Automatic certificate enrollment for logged on user is cancelled.

Event Type:	None
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	28
Date:	6/25/2001
Time:	7:36:16 AM
User:	HAYBUV\USER1
Computer:	COMPUTER1
Description:	Automatic certificate enrollment for HAYBUV\User1 successfully installed one AutoEnrollSmart cardEmail certificate when retrieving pending requests. User interaction was required.

Event Type:	None
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	29
Date:	7/9/2001
Time:	6:39:29 AM
User:	HAYBUV\USER1
Computer:	COMPUTER1
Description:	Automatic certificate enrollment for HAYBUV\USER1 reused the private key when requesting one AutoEnrollSmart cardUser certificate.

Event Type:	None
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	20
Date:	7/9/2001
Time:	6:39:29 AM
User:	HAYBUV\USER1
Computer:	COMPUTER1
Description:	Automatic certificate enrollment for HAYBUV\USER1successfully renewed one AutoEnrollSmart cardUser certificate from certificate authority TestCA on Server1.haybuv.com.

Event Type:	None
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	29
Date:	7/17/2001
Time:	9:37:29 AM
User:	HAYBUV\user1
Computer:	TESTCA
Description:	Automatic certificate enrollment for HAYBUV\user1 reused the private key when requesting one Autoenroll Smart card User certificate.

This event signifies the fact that the private key was reused during a certificate renewal.

Failed Event Log Messages

The following are samples of failed event log messages.

Event Type:	Error
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	15
Date:	7/8/2001
Time:	3:09:41 PM
User:	N/A
Computer:	TEST1
Description:	Automatic certificate enrollment for Haybuv\User1 failed to contact Active Directory (0x8007054b). The specified domain either does not exist or could not be contacted. Enrollment will not be performed.

This error most often occurs when a user is logged on to a machine with cached credentials and is offline. Therefore, autoenrollment cannot continue and will be attempted later.

Event Type:	Error
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	15
Date:	2/24/2001
Time:	10:36:08 AM
User:	N/A
Computer:	TEST1
Description:	Automatic certificate enrollment for local system failed to contact a directory server (0x80072751). A socket operation was attempted to an unreachable host. Enrollment will not be performed.

This error most often occurs when a domain controller is not available or is not accessible by the client. Common causes include network errors, network connectivity, and so on.

Event Type:	Error
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	13
Date:	7/5/2001
Time:	9:37:44 AM
User:	N/A
Computer:	TEST1
Description:	Automatic certificate enrollment for local system failed to enroll for one HAYBUV IPSEC certificate (0x800706ba). The RPC server is unavailable.

This error typically occurs when the certificate authority is not available on the network or the service is stopped.

Event Type:	Error
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	13
Date:	7/5/2001
Time:	7:41:27 AM
User:	N/A
Computer:	TEST1
Description:	Automatic certificate enrollment for local system failed to enroll for one HAYBUV IPSEC certificate (0x8009400f). An attempt was made to open a certification authority database session, but there are already too many active sessions. The server may need to be configured to allow additional sessions.

This is a rare event when the certificate authority is under heavy load and cannot respond to the request in a timely manner. Autoenrollment will automatically try again at a later time.

Event Type:	Error
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	16
Date:	7/5/2001
Time:	2:53:34 AM
User:	N/A
Computer:	TEST1
Description:	Automatic certificate enrollment for local system failed to renew one HAYBUV IPSEC certificate (0x8009400f). An attempt was made to open a Certification Authority database session, but there are already too many active sessions. The server may need to be configured to allow additional sessions.

This is the same error as the previous one, but it involves a renewal.

Event Type:	Warning
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	7
Date:	7/24/2001
Time:	7:48:27 PM
User:	HAYBUV\USER1
Computer:	TEST1
Description:	Automatic certificate enrollment for HAYBUV\USER1 could not enroll for Key Recovery Agent certificate template due to one of the following situations. · Enrollment access is not allowed to this template. · Template subject name, signature, or hardware requirements cannot be met. · No valid certificate authority can be found to issue this template.

This is an autoenrollment error that occurs when a user has a certificate and private key installed that corresponds to a given template that is now expiring. Autoenrollment attempts to automatically renew the certificate; however, the user does not have applicable permissions for this template and therefore autoenrollment fails. Autoenrollment is based on certificates in the store as well as certificate template settings.

Event Type:	Error
Event Source:	AutoEnrollment
Event Category:	None
Event ID:	13
Date:	7/17/2001
Time:	9:22:10 AM
User:	HAYBUV\user1
Computer:	TESTCA
Description:	Automatic certificate enrollment for HAYBUV\user1 failed to enroll for one Autoenroll smart card user certificate (0x80094812). The e-mail name is unavailable and cannot be added to the Subject or Subject Alternate name.

This error occurs when the user account in Active Directory does not have a valid e-mail address on the user property page in Active Directory Users and Computers MMC snap-in. Enrollment for certificate templates in Active Directory requires an e-mail address to exist prior to enrollment.

Event Log Tools

With Windows 7 and Windows Server 2008 R2, there are several tools to query a local system for various events:

• Event Viewer (eventvwr.msc)

Event Viewer is a graphical too which is an MMC snap-in and is preinstalled in any Windows installation where graphical user interface (GUI) is enabled. Event Viewer tool is not available on Windows Server in Server Core mode installation.

• Wevtutil.exe (command-line)

The wevtutil.exe tool is preinstalled in any Windows installation starting with Windows Vista and Windows Server 2008.

• Get-WinEvent (PowerShell)

The Get-WinEvent cmdlet is shipped automatically with every PowerShell version starting with PowerShell 3.0 and above.

Summary

Windows Server 2016 through the Active Directory Certificate Services component provides user certificate autoenrollment. This allows administrators to easily deploy certificates throughout the enterprise while requiring no user interaction. User certificate autoenrollment in the Windows 10 Windows Server 2016 operating systems builds on Microsoft’s long-established reputation for shipping robust PKI components that have a low TCO. Since PKI is an integral part of the Windows 10 operating system, Windows Server 2016 PKI provides some distinct advantages over third-party add-in components. These advantages include:

• No per-certificate fees or per-user PKI licenses
• Centralized user security management
• Integration with normal enterprise management tasks
• Single sign-on capabilities to networks and applications
• Managed trust capabilities
• Support for all applications through CryptoAPI

Keep in mind that almost all third-party PKIs must be purchased separately and require per-certificate license fees and increased management tasks.

Overall, certificate autoenrollment features in Windows Server 2016 should provide organizations and enterprises with the ability to effortlessly deploy digital certificates and PKI-enabled applications with little or no additional cost to a normal IT operations budget.

---