Certificate Autoenrollment in Windows XP

By David B. Cross

Acknowledgements

Michael Kessler, Technical Editor, Microsoft Corporation

Abstract

The Microsoft® Windows® XP operating system provides a number of enhancements to certificate services and public key infrastructure (PKI). These enhancements enable organizations to automatically deploy public key- based certificates to users.

This article is intended for IT managers and system administrators. It provides a technical walkthrough of the certificate autoenrollment feature, along with an in-depth explanation of how this feature works and key troubleshooting information.

On This Page

Introduction
How Autoenrollment Works
Configuring the Certificate Templates
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® XP introduces the capability to automatically enroll users and computers for certificates—including smart card-based certificates.

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

  • Certificate renewal

  • Superseding of certificates

  • Multiple signature requirements

Quick and Simple

Certificate autoenrollment is based on the combination of group policy settings and version 2 certificate templates. This combination allows the Windows XP Professional 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, EFS, SSL, 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 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. 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 will complete and install 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 user—dependent upon the specifications in the certificate template.

Dependencies

The autoenrollment feature has several infrastructure requirements. These include:

  • Windows Server 2003 schema and Group Policy updates

  • Windows 2000 or Windows Server 2003 domain controllers

  • Windows XP Client

  • Windows Server 2003, Enterprise Edition running as an Enterprise certificate authority (CA)

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

How Autoenrollment Works

This section discussed how autoenrollment works. Topics covered include: 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 Edition 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 and Winlogon

The autoenrollment process is triggered by the Winlogon process, and is designed to be activated and management 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 logon for users and is refreshed every eight hours. The refresh interval can be configured using Group Policy.

For additional information, see the section in this article on Updating Group Policy.

Note: Unlocking the workstation does not trigger autoenrollment: only 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 housekeeping—except 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, the NTAuth container and certificate templates. 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 at all. The user's or machine's "MY" 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.

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 LDAP to simply respond whether or not a given certificate type exists without downloading and processing the certificates locally.

Autoenrollment also manages the "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:

  • If a request already exists in the "REQUEST" store, this certificate will be removed from the summarized requirements list.

  • If a request has been pending for more than 60 days, the request will be deleted and the requirements list will remain "as-is".

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 pended, autoenrollment will retrieve the pending request for the user.

Template supercede rules will be evaluated and appropriate additions and deletions will be processed for the requirements list. For example: If the template says "X supercedes Y," it means 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 its 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 it to a CA. Once this has completed, the requirements list is updated.

If a certificate is issued from the CA, the certificate is installed in the user's or machine's MY store. If the certificate is pended [specified by the CA Manager approval checkbox 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 is invoked.

  • Approximately 60 seconds after logon, the balloon user interface (UI) is displayed. If no user interaction is explicitly defined on the certificate template, no UI will be displayed to the user. This delay is incorporated to allow for speedy application and shell response times during the logon and booting of the client machine.

  • If the 60 second delay is not desired, the following registry key may be added on a per user basis:

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 combined with pending requests.

  • The balloon UI waits for the user to see the balloon and activate via a mouse click. Note that after approximately 15 seconds the balloon popup is replaced by a certificate icon that may be activated via the mouse in the taskbar tray.

  • If no activation occurs within seven hours, the balloon UI will disappear and the silent thread will re-activate at the next logon, machine reboot or Group Policy refresh interval, whichever is first.

  • Once the user activates the UI, the "REQUEST" store is checked first for pending requests.

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 in order 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 reenroll templates when Reenroll all certificate holders has been set. Refer to the Certificate Renewal section later in this article for additional information.

Certificate Authority Interfaces

For a non-Microsoft CA to accept autoenrollment requests from a Windows XP client, the foreign CA must be able to emulate the ICertRequest2 interface as defined in the Platform Software Development Kit (SDK).

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

  • GetCAProperty

  • Submit

  • GetLastStatus

  • GetRequestId

  • GetFullResponseProperty

  • GetCertificate

  • Release

  • RetrievePending

These methods can be found in the Platform SDK at: https://msdn2.microsoft.com/en-us/library/default.aspx.

Configuring 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 certificate template must first be created in Active Directory to enable autoenrollment.

Default Settings

The following are default settings:

  • Only root domain administrators for Microsoft Windows 2000 domain upgrades may configure templates.

  • Both domain administrators from the root domain, and enterprise administrators for fresh installations of Windows Server 2003 domains may configure templates.

  • Certificate template ACLs are viewed in the Certificate Templates MMC snap-in.

  • Certificate templates can be cloned or edited using the Certificate Templates MMC snap-in.

Note Only a domain with the Windows Server 2003 schema will support version 2 templates and only a Windows Server 2003, Enterprise Edition 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. From the Start menu, click Run.

  3. In the Run dialog box, in the Open box, type mmc.exe, and then click OK.

  4. From 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 with the mouse and selecting Manage.

  9. In the console tree, click Certificate Templates.

  10. In the details pane, right-click the Smartcard User template with and then click Duplicate Template as shown in Figure 1 below.

    Figure 1: Creating a new template for autoenrollment of a smart card

    Figure 1: Creating a new template for autoenrollment of a smart card

    The General tab of the new template properties dialog will open and be displayed**.**

  11. In the Template display name field, type in a unique name for the template name as shown in Figure 2 below.

    Figure 2: Naming the template

    Figure 2: Naming the template

    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 user's MY store. Active Directory is queried and determines if the user should be enrolled. This is an extremely valuable feature for users that 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 as shown in Figure 3 below. 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.

    (In this example, the Gemplus GemSAFE Card CSP is chosen and will be the only smart card that will be enabled with this template. If the user does not have this smart card, he or she will not be able to enroll for this certificate template.)

    Figure 3: Defining how the certificate request should be processed

    Figure 3: Defining how the certificate request should be processed

    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, he or she will have to cancel the prompts for the unavailable CSPs. 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 Require user input for autoenrollment check box as shown in Figure xx above. (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. Select 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. Select 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. Select 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 show 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 (registration authority) 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, please refer to your smart card and CSP vendor for additional information.

Certificate Template Permissions

In order for a user or a 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 in order to enroll for a selected certificate template.

  • The Read permission allows the template to be discovered by the user.

  • The Enroll permission is enforced by the enterprise certificate authority when a user requests a certificate for a selected template. The enterprise certification authority must also have Read permissions on a template in order to enumerate the template in the directory and issue certificates based on that template. Normally, the enterprise certificate authority is included in the Authenticated Users group which has Read permissions by default on a template.

  • The Full Control permission is given to enterprise administrators and the primary domain administrators group by default when installing a fresh Windows Server 2003 domain. If a domain has been upgraded from Windows 2000, enterprise administrators will not have this permission by default. The Full Control permission allows a user to set or modify the permissions on a selected template.

  • The Autoenroll permission is set on a template when it is desired for a user or computer to automatically enroll for a selected certificate template. The Autoenroll permission is needed in additional to the Enroll permission for a user to enroll for a given certificate template. Only version 2 templates, or newly created templates may have the Autoenroll ACE set.

  • The Write permission allows a user to modify the contents of a certificate template. It should be noted that only version 2 certificates with a Windows Server 2003 schema may be modified. Version 1 certificate templates only allow ACLs to be modified.

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. From Administrative Tools, open the Certification Authority snap-in.

  2. In the console tree, expand the certification authority, and then click Certificate Templates as shown below in Figure 4.

    Figure 4: Selecting certificate templates

    Figure 4: Selecting certificate templates

  3. Right-click Certificate Template, then click New, and then click Certificate Template to Issue.

  4. In the Enable Certificate Templates dialog box, see Figure 5 below, click Auto Enroll Smartcard User; this is the certificate template name that was created previously. Then click OK. (Refer back to Creating a New Template for the Autoenrollment of a Smart Card.)

    Figure 5: Enabling a certificate template on a CA

    Figure 5: Enabling a certificate template on a CA

    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.

Configuring Group Policy

This section shows how to configure the Group Policy settings for a site, domain or 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, then click Properties.

  3. Select the Group Policy tab and then click the Edit button, as shown below in Figure 6 below.

    Figure 6: Selecting Group Policy configuration options

    Figure 6: Selecting Group Policy configuration options

    Note: Machine policy for automatic enrollment of machine and domain controller certificates is configured identically, though controlled through the machine policy of a Group Policy object.

  4. Click User Configuration settings, then Windows Settings, Security Settings and finally Public Key Policies. Right-click the Autoenrollment Settings object, as shown in Figure 7 below, then select Properties

    Figure 7: Selecting Autoenrollment Settings

    Figure 7: Selecting Autoenrollment Settings

  5. Ensure that the Enroll certificates automatically radio button is selected as shown in Figure 8 below. To enable automatic renewal, certificate cleanup and publishing in Active Directory, also select the other two check boxes.

    Figure 8: Selecting Autoenrollment Settings

    Figure 8: Selecting Autoenrollment Settings

  6. Click OK. Autoenrollment has now been enabled.

User Autoenrollment

This section illustrates manually pulsing autoenrollment and smart card enrollment

Key Points

User autoenrollment for a smart card requires manual steps, 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 8 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. Select Run from the Start menu.

  3. Type in "mmc.exe" and press Enter. An empty MMC shell starts up.

  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 the Add button. A list of the registered snap-ins on the current machine appears.

  6. Double-click the Certificates snap-in. Choose My User Account then click the Finish button. If enrolling the machine for a certificate, such as a domain controller or a Web server, choose Computer account.

  7. Click Next.

  8. Choose Local Computer, then click Finish.

  9. Click the Close button on the Add Standalone Snap-in dialog box, and then click OK on the Add/Remove Snap-in dialog box. The MMC now contains the personal certificate store for the user.

  10. Right-click on the top of the tree on Certificate–Current User. Select All Tasks from the context menu and then Automatically Enroll Certificates as shown in Figure 9 below.

    Figure 9: Automatically enrolling certificates

    Figure 9: Automatically enrolling certificates

Note: It will take approximately one minute for the Certificate Enrollment balloon to be displayed, unless the registry key mentioned previously has been set. (Refer to Balloon User Interface above.)

Smartcard Enrollment

  1. Click on 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 self-registration authority.

  2. Click the Start button, as shown in Figure 10 below, and 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

    Figure 10: Begin enrolling certificates

  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 user's 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 the Cancel button. 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 as shown in Figure 11 below; the wizard will continue as shown in Figure 12.

    (The following example is only one example of the dialog a user may receive. The smart card UI varies depending on the CSP being used.)

    Figure 11: Replacing credentials dialog box

    Figure 11: Replacing credentials dialog box

    Figure 12: Enrolling certificates

    Figure 12: Enrolling certificates

  7. If a PIN is necessary for the smart card, a dialog box will be displayed. Enter the appropriate PIN and click Enter. Enrollment will complete.

    Note: The incorrect entry of the PIN will often prompt a limited number of opportunities to retry.

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, as illustrated in Figure 13 below.

Figure 13: Notifying the user of errors while enrolling certificates

Figure 13: Notifying the user of errors while enrolling certificates

Note: Users are not prompted when enrollment succeeds.

Certificate Renewal

This section discusses renewal intervals, forced reenrollment and smart card renewal.

Renewal Intervals

Windows XP, when combined with a Windows Server 2003 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.

Important certificate renewal criteria include the following:

  • Automatic certificate renewal will only occur when 80% of the certificate lifetime has passed, or when the renewal interval period specified on the template has been reached—whichever timeframe is smaller.

  • If the renewal period is greater than 20% of the certificate lifetime, autoenrollment will not automatically attempt certificate renewal until the 80% threshold has been reached.

Forcing Reenrollment

An administrator may force all users to reenroll for a given template by updating the 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 reenroll for that template.

To manually force the template version to be updated, thereby forcing reenrollment, right-click on the template and select Reenroll All Certificate Holders as shown in Figure 14 below.

Figure 14: Manually forcing certificate reenrollment

Figure 14: Manually forcing certificate reenrollment

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 forced onto the card. This action will generate an event in the machine's 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 is explicitly blocked by autoenrollment.

Autoenrollment Functions

This section discusses deleting expired and revoked certificates in the userCertificate attribute and the user's MY store.

Deleting Expired and Revoked Certificates

Autoenrollment deletes expired and revoked certificates in the userCertificate attribute on the user object in Active Directory. This feature is enabled automatically 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 certificates; it 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 Certificates in MY Store

Certificates in the user's MY store may also be managed through the autoenrollment process. On a per-template basis, Autoenrollment can be enabled to delete expired and revoked certificates. This feature is enabled by setting this policy on the Request Handling tab in the Properties of a given certificate template, as shown in Figure 15 below.

Figure 15: Managing certificates

Figure 15: Managing certificates

If the Delete revoked or expired certificates check box is not enabled, autoenrollment will archive all expired and revoked certificates in the user's MY store. As mentioned before, 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.

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-DELTE 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 as shown in Figure 16 below.

Figure 16: Forcing a Group Policy update

Figure 16: Forcing a Group Policy update

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 as shown in Figure 17 below. This setting overrides any pending setting on the CA itself.

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

Figure 17: Setting the requirement for certificate manager approval

Figure 17: 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.

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 the following section. 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 user's private key is used to sign the new certificate request. The CMC (Certificate Management Messages over CMS) 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 select the Issuance Requirements tab.

  • To add a signature or issuance requirement, click the This number of authorized signatures check box and add the appropriate number in the following number field as shown in Figure 18 below.

Once that has been done, you may add specific requirements for the signing certificate

Figure 18: Setting the number of authorized signatures

Figure 18: Setting the number of authorized signatures

Self RA Example: You could add the Application Policy for a smart card logon certificate that would be used to enroll for an Encrypting File System (EFS) certificate. This would mandate that a user sign his or her 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 reenroll, change or combine previously issued certificate enrollments into a new certificate enrollment. Autoenrollment always examines existing certificates in the user's 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:

  • Changing certificate lifetime

  • Increased key size

  • Addition of 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 and select the Superseded Templates tab as shown in Figure xx below.

  2. Click the Add button.

  3. Select the template that you want to supersede, as shown in Figure 19 below. Click OK.

    Figure 19: Selecting a template to supersede

    Figure 19: Selecting a template to supersede

  4. The template will be added to the Superseded Templates tab, as shown in Figure 20 below. If you wish to add additional templates that should be superseded with this new template, click the Add button and repeat. Otherwise click the OK button.

    Figure 20: Listing superseded templates

    Figure 20: Listing superseded templates

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

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

Name

Type

Common Name

Windows 2000

Windows XP

BULL SmarTLP3

Serial

 

Yes

Yes

GEMPLUS GCR410P

Serial

GemPC410

Yes

Yes

GEMPLUS GPR400

PCMCIA

GemPC400

Yes

Yes

Litronic 220

Serial

 

Yes

Yes

Rainbow Technologies SCR3531

Serial

 

Yes

No

Schlumberger Reflex 20

PCMCIA

 

Yes

Yes

Schlumberger Reflex 72

Serial

 

Yes

Yes

SCM Microsystems SCR120

PCMCIA

 

Yes

Yes

SCM Microsystems SCR200

Serial

 

Yes

Yes

SCM Microsystems SCR300

USB

 

Yes

Yes

GEMPLUS GemPC430

USB

 

No

Yes

HP ProtectTools

Serial

 

No

Yes

Schlumberger Reflex Lite

Serial

 

No

Yes

SCM Microsystems SCR111

Serial

 

No

Yes

Systemneeds External

Serial

 

No

Yes

Omnikey AG CardMan 2020

USB

Utimaco CardMan

No

Yes

Omnikey AG CardMan 4000

PCMCIA

Utimaco CardMan

No

Yes

Omnikey AG CardMan 2010

Serial

Utimaco CardMan

No

Yes

Table 2 Smart Cards

Name

Capacity

Windows 2000

Windows XP

Gemplus GemSAFE

4k

Yes

Yes

Schlumberger Cryptoflex

4k

Yes

Yes

Schlumberger Cryptoflex

8k

Yes

Yes

Gemplus GemSAFE

8k

No

Yes

Infineon (formerly Siemens)

 

No

Yes

Schlumberger Cyberflex Access

16k

No

Yes

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:

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

Autoenrollment automatically downloads root certificates and cross-certificates from the 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: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache

EFS always attempts to enroll for the Basic EFS template. The EFS driver generates an autoenrollment request that Autoenrollment tries to fulfill. For customers that want to ensure that a specific template is used for EFS (such as to include key archival), the new template should supercede the Basic EFS template. This will ensure that Autoenrollment will not attempt enrollment for Basic EFS any more.

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 supercede these templates with a new version 2 template.

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 the feature for when an autoenrollment failure occurs

  1. Open the specified template in the Certificate Templates MMC snap-in.

  2. Select the Request Handling tab.

  3. Check the Require user input for autoenrollment check box, as shown in Figure 21 below.

    Figure 21: Enabling the warning feature for when autoenrollment fails

    Figure 21: Enabling the warning feature for when autoenrollment fails

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 not go away despite the fact the user has removed and inserted the card. The only choice is to choose the cancel button and fail the enrollment.

Enhanced Event 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 autoenrollment processes, 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

Samples of successful event log messages are shown below.

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.

For more information, visit Help and Support Services at https://support.microsoft.com/default.aspx?scid=fh;EN-US;kbhowto&sd=GN&ln=EN-US&FR=0.

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.

For more information, visit Help and Support Services at https://support.microsoft.com/default.aspx?scid=fh;EN-US;kbhowto&sd=GN&ln=EN-US&FR=0.

Event Type:

Information

Event Source:

AutoEnrollment

Event Category:

None

Event ID:

27

Date:

2/26/2001

Time:

3:26:03 PM

User:

NTDEV\dcross

Computer:

COMPUTER1

Description: Automatic certificate enrollment for logged on user is cancelled.

For more information, visit Help and Support Services at https://support.microsoft.com/default.aspx?scid=fh;EN-US;kbhowto&sd=GN&ln=EN-US&FR=0.

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.

For more information, see Help and Support Center at https://support.microsoft.com/.

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.

For more information, see Help and Support Center at https://support.microsoft.com/.

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 Sevrer1.haybuv.com.

For more information, see Help and Support Center at https://support.microsoft.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.

For more information, see Help and Support Center at https://support.microsoft.com/.

Note This even signifies the fact that the private key was used during a certificate renewal.

Failed Event Log Messages

Samples of failed event log messages are shown below.

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.

For more information, see Help and Support Center at https://support.microsoft.com/.

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

For more information, visit Help and Support Services at https://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, etc.

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.

For more information, see Help and Support Center at https://support.microsoft.com/.

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

For more information, see Help and Support Center at https://support.microsoft.com/.

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.

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.

For more information, see Help and Support Center at https://support.microsoft.com/.

Note: This is the same error as previous one, but involving 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.

For more information, see Help and Support Center at https://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.

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.

For more information, see Help and Support Center at https://support.microsoft.com/.

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

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 "

Summary

Windows XP provides user certificate autoenrollment. This allows administrators to easily deploy certificates throughout the enterprise while requiring no user interaction. User certificate autoenrollment in Windows XP Professional builds on Microsoft's long-established reputation for shipping robust public key infrastructure (PKI) components that have a low total cost of ownership. Since PKI is an integral part of the Windows XP Professional operating system, Windows XP 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 XP 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.

See the following resources for further information: