Certificate Autoenrollment in Windows Server 2003

On This Page

	Introduction
	How Autoenrollment Works
	Configuring an Enterprise CA
	Configuring Group Policy
	User Autoenrollment
	Certificate Renewal
	Autoenrollment Functions
	Updating Group Policy
	Advanced Features
	Supported Hardware
	Troubleshooting
	Summary
	Related Links

Introduction

Microsoft Windows Server 2003, Enterprise Edition introduces the capability to automatically enroll users and computers for certificatesincluding smart cardbased certificates.

Using the autoenrollment feature, organizations can manage the certificate lifecycle for users, which includes:

Certificate autoenrollment is based on the combination of Group Policy settings and version 2 certificate templates. This combination allows the Windows XP Professional or Windows Server 2003 client to enroll users when they log on to their domain, or a machine when it boots, and keeps them periodically updated between these events.

Automatic enrollment of user certificates provides a quick and simple way to issue certificates to users and to enable public key infrastructure (PKI) applications, such as smart card logon, Encrypting File System (EFS), Secure Sockets Layer (SSL), Secure/Multipurpose Internet Mail Extension (S/MIME), and others, within an Active Directory directory service environment. User autoenrollment minimizes the high cost of normal PKI deployments and reduces the total cost of ownership (TCO) for a PKI implementation when Windows XP Professional clients are configured to use Active Directory.

Supports Pending Certificate Requests and Certificate Renewal

User autoenrollment in Windows XP Professional and Windows Server 2003 supports both pending certificate requests and renewal features.

Requesting a Certificate

You can manually or automatically request a certificate from a Windows Server 2003 certificate authority (CA). This request is held until administrative approval is received or the verification process is completed. Once the certificate has been approved or issued, the autoenrollment process completes and installs your certificate automatically.

Renewing a Certificate

The process for renewing an expired user certificate also takes advantage of the autoenrollment mechanism. Certificates are automatically renewed on behalf of the userdependent on the specifications in the certificate template.

Dependencies

The autoenrollment feature has several infrastructure requirements. These include:

Note: Autoenrollment Group Policy settings may only be applied when using a Windows XP Professional or Windows Server 2003 computer.

Topics Covered

Top of page

How Autoenrollment Works

This section discusses how autoenrollment works, including autoenrollment and Winlogon, an analysis of the components of the autoenrollment process, and working with certificate authority interfaces.

Key Points

Autoenrollment works best in a Windows Server 2003 Enterprise environment where the Windows XP client is integrated with Active Directory.

Only domain-joined machines can use certificate autoenrollment. Although the autoenrollment process does not explicitly look for domain-joined machines, the Winlogon process will not activate userinit.exe unless the machine/user is part of a domain.

Autoenrollment Timing

The autoenrollment process is normally triggered by the Winlogon process, and is designed to be activated and managed by a domain-based Group Policy. Both machine-based and user-based Group Policy can activate autoenrollment for machines and users. By default, the Group Policy is applied at reboot for machines, or at logon for users, and is refreshed every eight hours. The refresh interval can be configured using Group Policy. Autoenrollment is also triggered by an internal timer that activates every eight hours after the last time autoenrollment was activated.

For additional information, see Updating Group Policy.

Note: Unlocking the workstation does not trigger autoenrollmentonly a full interactive logon or a Group Policy refresh will initiate the Winlogon trigger.

The Autoenrollment Process

The autoenrollment feature handles all aspects of certificate enrollment, renewal, and certificate housekeepingexcept in the case where user interaction is explicitly defined on a certificate template in Active Directory. When the autoenrollment process is triggered by Winlogon or a Group Policy refresh interval, the operating system queries Active Directory to download the appropriate certificate stores into the local store on the client machine; for example, root CA certificates, cross-certificates, and the NTAuth container. The autoenrollment process also downloads certificate templates from the forest and caches the list in the registry at the same time. The last step performed by autoenrollment is user-object cleanup (userCertificate attribute) in Active Directory. Revoked, expired, and superseded certificates are removed from the user object automatically; however, expired certificates are not removed unless a new valid certificate is issued at the same time. Certificates in the local user profile or on the user object in Active Directory are only managed if the certificate corresponds to a certificate template in Active Directory. Foreign certificates and certificates that do not contain the template extension are not managed. This is a transparent activity that is processed asynchronously.

Requirements List

The autoenrollment process will then process the list of templates and create a requirements list for any templates that have an autoenroll access control entry (ACE) set on the template for the current machine or user. The machine and/or user must also have the Read ACE set on the template or the template will not be enumerated. The users or machines MY (personal) store will also be processed at this time to look for revoked certificates, certificates without private keys, time invalid certificates and so on, and add these certificates to the requirements list. For more information on certificate stores, refer to the Microsoft Platform SDK: http://msdn.microsoft.com/library/en-us/security/security/managing_certificates_with_certificate_stores.asp

It is very possible that a user may have a certificate in the MY store but not have permissions set on a template access control list (ACL) in Active Directory. These will be processed and added to the list, but enrollment will most likely fail due to the fact that the template permissions do not allow enrollment/renewal at the updated point in time.

Items in the requirements list may be removed if an appropriate valid certificate is found in the MY store. If a certificate template is marked to check Active Directory for an existing certificate, Active Directory will be queried for an existing duplicate certificate on the userCertificate attribute of the user object and the requirement will be removed from the list, if successful.

Note: Checking Active Directory for the presence of an existing certificate associated with the user or machine object can affect performance and may delay autoenrollment processing due to the network and directory requirements for performing this operation. This is because the actual certificates in the userCertificate attribute will be downloaded and examined. When this happens, the directory cannot be queried via Light Weight Directory Access Protocol (LDAP) to simply respond whether a given certificate type exists without downloading and processing the certificates locally.

Autoenrollment also manages the CryptoAPI REQUEST store for the user. This process enumerates each pending request in the store and then installs the pending certificate, if possible, from the issuing CA. If a certificate is to be archived or deleted, based on the certificate template rule, it will be processed as follows:

Autoenrollment can be used to retrieve pending requests only for certificates with template information, for example, an initial request involving a certificate template. The autoenroll ACL on the certificate template is not necessary for the autoenrollment process to retrieve a pending certificate request. If the user enrolls via a Web page and the certificate request is pending, autoenrollment will retrieve the pending request for the user.

Template supersede rules will be evaluated and appropriate additions and deletions will be processed for the requirements list. For example, if the template says "X supersedes Y ", it means that if you have been told to enroll for X and Y, you really only need X. If you only have Y, you still must get X. This is the last step in rule processing. After it is done, the requirements list is complete.

For each template that does not require user interaction, the autoenrollment process will create the requests in the background and submit them to a CA. Once this is done, the requirements list is updated.

Autoenrollment always performs a revocation check of the entire certificate chain starting with the issuing certificate authority to ensure that the CA offering enrollment services is not revoked before performing enrollment. If the CA is revoked, autoenrollment will not send requests to that certificate authority. However, autoenrollment will ignore revocation errors if a CDP (CRL Distribution Point) extension does not exist in the CA certificate or if the revocation status is offline.

If a certificate is issued from the CA, it is installed in the users or machines MY store. If the certificate is pended [specified by the CA Manager approval check box in the Certificate Template Microsoft Management Console (MMC) snap-in], the request information is saved in the REQUEST store.

Balloon User Interface

For each request that requires user interaction as per the certificate template, the balloon user interface (UI) is invoked.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEExpress

Using this key in a normal production environment is not recommended. If it is used, it must be created on a per-user basis.

Important: Machine certificates do not support user interaction and should not be configured to require this setting.

Issuing the Template

Once a certificate template with the proper ACE has been enumerated, the autoenrollment process will search for a Microsoft Enterprise Certificate Authority in Active Directory that can issue the template. If more than one Enterprise CA is found, the client will try each CA in the list in random order (for load balancing) until a CA responds and is able to issue a certificate.

The client contacts a CA through a Distributed Component Object Model (DCOM) interface and supplies a security context through DCOM to provide an authenticated request. The default policy module of the Microsoft Enterprise CA enforces certificate profiles and enrollment security as defined by the templates.

If the certificate authority is set to pend the request for an administrator or certificate manager to examine and approve, autoenrollment will periodically query the CA during every Group Policy refresh interval for approved requests. Autoenrollment will also re-enroll templates when Reenroll all certificate holders has been set in Group Policy. For more information, see Certificate Renewal.

Certificate Authority Interfaces

The following methods are used by the autoenrollment process for contacting and enrolling against a Microsoft Enterprise CA.

These methods can be found in the Platform SDK at http://msdn.microsoft.com/library/default.aspConfiguring the Certificate Templates

This section covers how to configure certificate templates and provides a step-by-step example of how to create a new template for the autoenrollment of a smart card. Certificate template permissions are also explained.

Key Point

A version 2 certificate template must first be created in Active Directory to enable autoenrollment.

Default Settings

The following are default settings.

Note: Only a domain with the Windows Server 2003 schema will support version 2 templates, and only a Windows Server 2003, Enterprise Edition or Datacenter Edition certificate authority may issue a version 2 template certificate.

Creating a New Template for the Autoenrollment of a Smart Card

To create a new template for autoenrollment of a smart card

1.	Log on as a domain administrator.
2.	Click the Start button, and then click Run.
3.	In the Run dialog box, in the Open box, type mmc.exe, and then click OK.
4.	On the File menu, click Add/Remove Snap-in.
5.	In the Add/Remove Snap-in dialog box, click Add.
6.	In the Add Standalone Snap-in dialog box, click Certificate Templates, and then click Add. Note: The Certificate Templates MMC snap-in is available on the Server version of Windows Server 2003 or on Windows XP Professional through the Administration Tools Pack installation on the Server media.
7.	Click Close.
8.	Click OK. Note: The Certificate Templates MMC snap-in may also be invoked using the Certification Authority MMC snap-in by selecting the Certificate Templates folder, right-clicking, and then selecting Manage.
9.	In the console tree, click Certificate Templates.
10.	In the details pane, right-click the Smartcard User template, and then click Duplicate Template (Figure 1). The General tab of the new template properties dialog box appears. Figure 1: Creating a New Template for Autoenrollment of a Smart Card See full-sized image.
11.	In the Template display name field, type a unique name for the template (Figure 2). Figure 2: Naming the Template See full-sized image. Note: If the Do not automatically reenroll if a duplicate certificate exists in Active Directory is enabled, autoenrollment will not enroll a user for the certificate template, even if a certificate does not exist in the users MY store. Active Directory is queried and determines if the user should be enrolled. This is an extremely valuable feature for users who do not have roaming profiles and log on to multiple machines. Without this setting and without roaming profiles, the user will automatically be enrolled on every machine that is logged on to (including servers).
12.	Click the Request Handling tab (Figure 3). This tab is used to define how the certificate request should be processed, including the cryptographic service providers (CSP) and minimum key sizes that will be used by the enrollment template. Figure 3: Defining How the Certificate Request Should Be Processed See full-sized image. Important: If more than one smart card CSP is made available on this tab, the user may be prompted for every CSP that is selected when enrolling for this template. The behavior may vary depending on the CSPs available on the client machine. If the user has only one smart card, the prompts for the unavailable CSPs will have to be cancelled. This behavior is by design. It is also important to select a minimum key size that is supported by the selected CSP; otherwise, enrollment will fail.
13.	Select the Prompt the user during enrollment check box (Figure 3). (Enrollment for smart card requires user input to succeed.) Important: If the certificate template is not going to be used for smart cards or if it is not desired for the user to be prompted to enroll for certificates, this option is not required. Machine certificates should not have this enabled or machine autoenrollment will fail.
14.	Click the Subject Name tab. This tab is used to define how the subject name and certificate properties will be built. It is recommended to use the default selections when enrolling for a smart card template.
15.	Click the Extensions tab. This tab is used to define how the various extensions will be added to this certificate template during enrollment. It is recommended that you use the default settings. Note: Application Policies is a replacement for Extended Key Usage (EKU) in Windows Server 2003, although EKU is still supported for legacy applications and client operating systems.
16.	Click the Security tab. This tab is used to define which users or groups may enroll or autoenroll for a certificate template. A user or group must have the Read, Enroll, and Autoenroll permissions to automatically be enrolled for a certificate template.
17.	Click OK when finished. The Autoenrollment column should now show Allowed.

Note: The Autoenrollment column will automatically indicate if a template is suitable for autoenrollment. The user will not be able to change the status. If a template has more than one registration authority (RA) signature required or if the subject is supplied by the requester, autoenrollment will not be allowed. The column does not reflect the state of the autoenroll ACL on the template. Important: A smart card that has been issued on Windows XP client or Windows XP Enrollment Station (RA) might only be compatible with a Windows XP client. The compatibility varies between various smart card and CSP vendors. If you need to be able to log on to both Windows 2000 and Windows XP, see your smart card and CSP vendor for additional information.

Certificate Template Permissions

For a user or computer to enroll for a certificate template, it must have appropriate permissions (ACEs) set on the template in Active Directory. A user or computer must have both Enroll and Read permissions to enroll for a selected certificate template.

Top of page

Configuring an Enterprise CA

This section shows how a Microsoft Enterprise CA must be configured to issue a certificate template after it has been created.

How to Configure an Enterprise CA

To configure an Enterprise CA

1.	On the Administrative Tools menu on a Windows Server 2003 console, open the Certification Authority snap-in.
2.	In the console tree, expand the Certification Authority, and then click Certificate Templates (Figure 4). Figure 4: Selecting Certificate Templates See full-sized image.
3.	Right-click Certificate Templates, click New, and then click Certificate Template to Issue.
4.	In the Enable Certificate Templates dialog box (Figure 5), click Auto Enroll Smartcard User (this is the certificate template name that was created previously), and then click OK. (See Creating a New Template for the Autoenrollment of a Smart Card.) Figure 5: Enabling a Certificate Template on a CA See full-sized image. Note: Due to replication latency and template caching in the registry, a certificate authority may not be able to issue a certificate template immediately. The timing of issuance is dependent on replication latency between domain controllers.
5.	Close the Certification Authority MMC snap-in.

Top of page

Configuring Group Policy

This section shows how to configure the Group Policy settings for a site, domain, or organizational unit (OU).

How to Configure Group Policy

Group Policy settings for a site, domain, or OU must be configured to enable certificate autoenrollment in a domain.

To configure Group Policy

1.	Open the Active Directory Users and Computers MMC snap-in.
2.	Right-click the site, domain, or OU that you want to configure Group Policy for, and then click Properties.
3.	Click the Group Policy tab, and then click Edit (Figure 6). Figure 6: Selecting Group Policy Configuration Options See full-sized image. Note: Machine policy for automatic enrollment of machine and domain controller certificates is configured identically, even though it is controlled through the machine policy of a Group Policy object.
4.	Click User Configuration, Windows Settings, Security Settings, and finally Public Key Policies. In Object Type, right-click Autoenrollment Settings (Figure 7), and then click Properties. Figure 7: Selecting Autoenrollment Settings See full-sized image.
5.	Ensure that Enroll certificates automatically is selected as well as the two check boxes under this option (Figure 8). Automatic renewal, certificate cleanup, and publishing in Active Directory are only enabled with all options selected. Note: Both machine and user policy must be configured to enable certificate enrollment for both types. Figure 8: Selecting Autoenrollment Settings See full-sized image.
6.	Click OK. Autoenrollment is now enabled.

Top of page

User Autoenrollment

This section illustrates manually pulsing autoenrollment and smart card enrollment.

Key Points

User autoenrollment for a smart card requires mandatory manual steps and user interaction, unlike other certificate types. Once autoenrollment has been enabled, the user will receive an informational balloon on the taskbar at the next Group Policy pulse interval (default of eight hours) or at the next logon.

Manually Pulsing Autoenrollment

Autoenrollment may be pulsed manually through the Certificates MMC snap-in.

To manually trigger autoenrollment

1.	Log on to the domain with the appropriate user account.
2.	Click the Start button, and then click Run.
3.	Type mmc.exe, and press ENTER. An empty MMC shell starts.
4.	Select the File menu, and then select Add/Remove Snap-In. A dialog box appears with a list of the snap-ins that have been added to the MMC shell.
5.	Click Add. A list of the registered snap-ins on the current machine appears.
6.	Double-click the Certificates snap-in, select My User Account, and then click Finish. If enrolling the machine for a certificate, such as a domain controller or a Web server, select Computer account.
7.	Click Next.
8.	Select Local Computer, and then click Finish.
9.	In the Add Standalone Snap-in dialog box, click Close. In the Add/Remove Snap-in dialog box, click OK. The MMC now contains the personal certificate store for the user.
10.	Right-click the top of the tree on CertificateCurrent User, select All Tasks on the context menu, and then select Automatically Enroll Certificates (Figure 9). Figure 9: Automatically Enrolling Certificates See full-sized image. Note: It will take approximately one minute for the Certificate Enrollment balloon to be displayed, unless the registry key mentioned previously has been set. (See Balloon User Interface.)

Smart Card Enrollment

1.	Click the balloon or the corresponding certificate icon in the system tray once the Certificate Enrollment balloon is displayed. After a short period of time, the balloon will automatically disappear, and only the icon in the system tray will remain. After clicking the balloon, the Autoenrollment UI will start. Note: The certificate enrollment balloon and wizard are not only for smart card enrollment but also for self-registration authority.
2.	Click the Start button (Figure 10). The wizard will begin. (The Remind Me Later button will cause the Certificate Enrollment balloon to re-appear at the next Group Policy pulse interval or the next interactive logon.) Figure 10: Begin Enrolling Certificates See full-sized image.
3.	If a smart card with the required CSP on the certificate is not inserted in the smart card reader, the user will be prompted to insert a smart card. Insert the smart card and click OK. Note: If the certificate template on the users machine contains more than one CSP, the user may have to cycle through the wizard to reach the desired smart card CSP.
4.	If the displayed smart card CSP is not the desired CSP, click Cancel. The next CSP listed in the certificate template will be displayed.
5.	After inserting an appropriate smart card, click OK. The wizard will continue. Note: If the smart card contains a private key and certificate in Slot0 (default container), the user will be warned about replacing the credentials on the smart card. Important: Due to limitations with the smart card CSPs, smart card logon with both Windows 2000 and Windows XP requires that Slot0, or the default container on the card, be used to hold the certificate and private key used for smart card logon. If the card contains multiple keys and certificates, the last generated key and certificate will be marked as the default container on the card.
6.	If it is desired to replace the credentials on the smart card, click Yes (Figure 11). The wizard will continue (Figure 12). (The following is only one example of the dialog box a user may see. The smart card UI varies depending on the CSP being used.) Figure 11: Replacing Credentials Dialog Box Figure 12: Enrolling Certificates See full-sized image.
7.	If a PIN is necessary for the smart card, a dialog box will be displayed. Enter the appropriate PIN and click Enter. Enrollment completes. Note: If you enter the PIN incorrectly, the number of times you can retry will be limited. The success or failure of the autoenrollment process will be logged in the Application event log on the local computer. Also, a summary dialog box will appear for failed certificate requests that involved user interaction. If a failure occurs during enrollment, the user will be notified of the failure (Figure 13). Figure 13: Notifying the User of Errors While Enrolling Certificates See full-sized image. Note: Users are not prompted when enrollment succeeds.

Top of page

Certificate Renewal

This section discusses renewal intervals, forced re-enrollment, and smart card renewal.

Renewal Intervals

Windows XP Professional or Windows Server 2003 clients, when combined with a Windows Server 2003, Enterprise Edition certificate authority, will perform automatic renewal of certificates as specified on a per-template basis. Renewal intervals are dictated by the certificate template, which is set to six weeks (before expiration) by default. When certificate renewal is performed, the old (previous) certificate enrollment is always archived automatically on the client machine, and the user directory object is updated.

Important certificate renewal criteria include the following:

Forcing Re-Enrollment

An administrator may force all users to re-enroll for a given template by updating the major version number of the template. When Active Directory is queried during logon for required certificate templates, the version number is examined. If the version number has incremented, the certificate template is considered to be updated and the user must re-enroll for that template.

To manually force the template version to be updated (thereby forcing re-enrollment)

•	Right-click the template and select Reenroll All Certificate Holders (Figure 14). Note: Templates are not updated automatically. By default, templates are updated at a minimum interval of 10 minutes. Figure 14: Manually Forcing Certificate Re-Enrollment See full-sized image.

Smart Card Renewal

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

Note: 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.

Revoked Certificates and Renewal

Revoked certificates may not be renewed and may not 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.

Top of page

Autoenrollment Functions

This section discusses various functions performed by the autoenrollment process on Active Directory domain-joined machines.

Download of Active Directory Certificates and Trust Objects

Autoenrollment automatically downloads and manages trusted root certificates, cross-certificates, and NTAuth certificates from Active Directory into the local machine registry for domain-joined machines. All users who log on to the machine inherit the trust and downloaded certificates that are downloaded and managed by autoenrollment.

Deleting Expired and Revoked Certificates

Autoenrollment deletes expired and revoked certificates in the userCertificate attribute on the user object in Active Directory. This feature can be enabled through user or machine Group Policy to help ensure that only valid and active certificates are used for encryption operations.

The exit module on the Windows Server 2003 CA also helps to manage the user account in Active Directory, but only deletes expired certificatesit does not remove revoked certificates due to performance reasons. In general, there is no value in publishing a signing certificate to the user object in Active Directory, except for purposes of record-keeping.

Managing User Certificates in the CryptoAPI MY Store

Certificates in the users local MY certificate store may also be managed through the autoenrollment process. On a per-template basis, autoenrollment can be enabled to delete expired and revoked signature certificates. Encryption certificates and keys are never automatically deleted. However, autoenrollment only manages certificates that correspond to certificate templates defined in Active Directory that contain the certificate template extension. This feature is enabled by setting this policy on the Request Handling tab in the Properties of a given certificate template (Figure 15).

Figure 15: Managing Certificates
See full-sized image.

If the Delete revoked or expired certificates check box is not enabled, autoenrollment will archive all expired and revoked certificates in the users MY store. As mentioned previously, this setting does not affect the userCertificate attribute in Active Directory for the user object.

Note: This feature is only enabled with encryption keys, not signature key types, which are not normally published to Active Directory.

Top of page

Updating Group Policy

This section discusses how to update User and Machine Group Policy.

User and Machine Group Policy

User autoenrollment is triggered by the Winlogon process (interactive logon with CTRL+ALT+DELETE keys) or at Group Policy refresh intervals. Normally, User Group Policy is refreshed at logon and Machine Group Policy is refreshed at machine reboot. Group Policy may be manually refreshed using the gpupdate.exe tool that is included in Windows XP.

Manually Forcing a Group Policy Update

To manually force a Group Policy update (for a user or a machine)

•	Run gpupdate.exe with the -Force option at the command line (Figure 16). Figure 16: Forcing a Group Policy Update See full-sized image.

Top of page

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 17). 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 17: Setting the Requirement for Certificate Manager Approval
See full-sized image.

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.

Note: 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 18). Now you may add specific requirements for the signing certificate. Figure 18: Setting the Number of Authorized Signatures See full-sized image.

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.

Benefits

Superseding certificate templates is especially useful in the following scenarios.

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 20), and then click Add.
2.	Select the template you want to supersede (Figure 19), and then click OK. Figure 19: Selecting a Template to Supersede See full-sized image.
3.	The template will be added to the Superseded Templates tab (Figure 20). If you wish to add additional templates that should be superseded with this new template, click Add and repeat. Otherwise, click OK. Figure 20: Listing Superseded Templates See full-sized image.

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

Top of page

Supported Hardware

This section lists the smart card readers and smart cards that are supported in the default installations of Windows 2000 and Windows Server 2003.

Table 1 Smart Card Readers

Table 2 Smart Cards

Note: The GEMPLUS GemPC430 is not supported on Windows Server 2003.

Top of page

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.

Key Issues

The following key issues need to be considered when troubleshooting autoenrollment.

Infrastructure Requirements

Windows XP clients and Windows Server 2003 CAs will always request LDAP-signed communications with domain controllers as a security function. Before deploying autoenrollment or a Windows Server 2003 CA, all domain controllers running Windows 2000 should be upgraded to Service Pack 3 or greater.

Root and Cross-Certificate Download from Active Directory

Autoenrollment automatically downloads root certificates 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 Server 2003, Enterprise Edition CA, the proper procedure is to supersede the Basic EFS template with a new version 2 certificate template.

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.

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

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"; set value to 0.

Machine Autoenrollment

HKEY_LOCAL_MACHINE\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.

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.

For more information, see Help and Support Services at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

For more information, see Help and Support Services at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

For more information, see Help and Support Services at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: 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.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: 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.

For more information, see Help and Support Services at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: 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.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

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

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: 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.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

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

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: 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.

For more information, see Help and Support Center at http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us&fr=0

Note: 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

A new tool (script) is included on the Windows XP Professional and Windows Server 2003 client to query a local system for various events. This script can be used to identify autoenrollment errors on the client and perform appropriate actions. The command line help for this tool is noted and provided as follows:

Z:\>eventquery /?  
Microsoft (R) Windows Script Host Version 5.6  
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.  
----------------------------------------------------------------------  
EVENTQUERY.vbs [/S system [/U username [/P password]]] [/FI filter]  
        [/FO format] [/R range] [/NH] [/V] [/L logname | *]  
Description:  
  The EVENTQUERY.vbs script enables an administrator to list  
  the events and event properties from one or more event logs.  
Parameter List:  
  /S   system     Specifies the remote system to connect to.  
  /U   [domain\]user  Specifies the user context under which the  
              command should execute.  
  /P   password    Specifies the password for the given  
              user context.  
  /V           Specifies that the detailed information  
              should be displayed in the output.  
  /FI  filter     Specifies the types of events to  
              filter in or out of the query.  
  /FO  format     Specifies the format in which the output  
              is to be displayed.  
              Valid formats are "TABLE", "LIST", "CSV".  
  /R   range      Specifies the range of events to list.  
              Valid Values are:  
                'N' - Lists 'N' most recent events.  
               '-N' - Lists 'N' oldest events.  
              'N1-N2' - Lists the events N1 to N2.  
  /NH          Specifies that the "Column Header" should  
              not be displayed in the output.  
              Valid only for "TABLE" and "CSV" formats.  
  /L   logname     Specifies the log(s) to query.  
 /?           Displays this help/usage.  
  Valid Filters Operators allowed  Valid Values  
  ------------- ------------------ ------------  
  DATETIME    eq,ne,ge,le,gt,lt  mm/dd/yy(yyyy),hh:mm:ssAM(/PM)  
  TYPE      eq,ne        ERROR, INFORMATION, WARNING,  
                    SUCCESSAUDIT, FAILUREAUDIT  
  ID       eq,ne,ge,le,gt,lt  non-negative integer  
  USER      eq,ne        string  
  COMPUTER    eq,ne        string  
  SOURCE     eq,ne        string  
  CATEGORY    eq,ne        string  

Note: Filter "DATETIME" can be specified as "FromDate-ToDate"

   Only "eq" operator can be used for this format.  
Examples:  
  EVENTQUERY.vbs  
  EVENTQUERY.vbs /L system  
  EVENTQUERY.vbs /S system /U user /P password /V /L *  
  EVENTQUERY.vbs /R 10 /L Application /NH  
  EVENTQUERY.vbs /R -10 /FO LIST /L Security  
  EVENTQUERY.vbs /R 5-10 /L "DNS Server"  
  EVENTQUERY.vbs /FI "Type eq Error" /L Application  
  EVENTQUERY.vbs /L Application /FI "Datetime eq 06/25/00,03:15:00AM-06/25/00,03:15:00PM"  
  EVENTQUERY.vbs /FI "Datetime gt 08/03/00,06:20:00PM"           /FI "Id gt 700" /FI "Type eq warning" /L System  
  EVENTQUERY.vbs /FI "Type eq error OR Id gt 1000 "  

Top of page

Summary

Windows Server 2003, Enterprise Edition through the 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 XP Professional and Windows Server 2003 operating systems builds on Microsofts long-established reputation for shipping robust PKI components that have a low TCO. Since PKI is an integral part of the Windows XP Professional operating system, Windows Server 2003 PKI provides some distinct advantages over third-party add-in components. These advantages include:

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 2003 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.

Top of page

Related Links

Top of page