Windows Server 2003 PKI Certificate Autoenrollment

Certificate autoenrollment in Windows Server 2003, Windows XP, and Windows 2000 automatically creates certificates for users and machines. Autoenrollment handles certificate enrollment, certificate renewal, and certain housekeeping tasks, such as removing revoked certificates from a user's or machine's certificate store and downloading trusted root Certification Authority (CA) certificates and cross-certificates (a new way to set up CA trust relationships in Windows 2003) from Active Directory (AD). Win2K public key infrastructure (PKI) supports certificate autoenrollment only for machine certificates and Encrypting File System (EFS) user certificates. Fortunately, Windows 2003 PKI extends certificate autoenrollment for users to all certificate types.

Windows PKI uses certificate autoenrollment several ways:

Certificate autoenrollment requires additional client-side code. At press time, Microsoft bundled only user autoenrollment client logic with Windows 2003 and XP, but the company will soon introduce machine autoenrollment client logic for Windows 2003, XP, and Win2K. User and machine autoenrollment requires that the machine and user be part of an AD domain.

Let's look at how to set up user and machine certificate autoenrollment in a Windows 2003 PKI environment. Let's also look at some of autoenrollment's nuts and bolts.

How Autoenrollment Works
The Winlogon process triggers certificate autoenrollment (i.e., the autoenrollment event). The Winlogon process is initiated every time a user performs an interactive logon and every time an administrator applies machine- or user-based group policies. By default, the process applies group policies every 90 minutes. You can trigger GPO updates manually, and unlocking a workstation doesn't trigger a certificate autoenrollment event.

During an autoenrollment event, the client OS queries AD to download the content of a set of predefined certificate stores to the local store on the client machine. These stores include NTAuth, the trusted root CA, certificate templates, and Authority Information Access (AIA—for cross-certificates) AD containers. Both the NTAuth and trusted root CA containers download trustworthy CA certificates to Windows domain clients. The certificate templates container contains a definition of all certificate types that the forest supports. The AIA container lets enterprise PKI users download trusted CA certificates from AD. Autoenrollment then processes the certificate templates, analyzes their properties, and creates a requirements list of tasks to be performed during the autoenrollment event. The requirements list includes the following:

The autoenrollment process then searches AD for an enterprise CA that can issue the certificates. If it finds a CA, it passes the requirements list to the CA, which processes the certificate-enrollment and renewal requests. If the CA issues a certificate, the autoenrollment process installs it in the user's or machine's MY certificate store container. If the certificate's state is set to pending (for certificate requests that require administrator approval), the autoenrollment process saves the request information in the user's or machine's certificate enrollment request store.

At the end of the autoenrollment process, the outcome (success or failure) of the process is logged in the local system's Application event log. If autoenrollment fails, a summary dialog box appears.

You can configure the autoenrollment process to log more verbose information and events in the Application event log. Simply set the AEEventLogLevel registry subkey (of type REG_DWORD) to a value of 0 in the following registry subkeys:

Autoenrollment events trigger more than just certificate autoenrollment. They also download trusted root CA certificates from the AD-based CAs and NTAuth stores to the local machine's Trusted Root Certification Authorities certificate store. The autoenrollment process doesn't download the complete NTAuth store, however; it downloads only the differences in the content between the user certificate and the NTAuth store.

Autoenrollment events download cross-certificates from AD to the local machine's certificate store. As with trusted root CA certificates, the process downloads only the changes. Autoenrollment also enumerates the pending certificate requests in the user's certificate enrollment request store. After the CA issues the certificate, the process downloads the certificate and installs it in the user's certificate store. If the request has been pending for more than 60 days, the process removes the request from the user's request store.

The autoenrollment process also deletes expired and revoked certificates in the user certificate attribute of the user's AD object and in the user's local machine certificate store. The latter occurs only if you select the Delete revoked or expired certificates property on the Request Handling tab in the certificate template properties.

Setting Up Certificate Autoenrollment
As with Win2K, Windows 2003 lets you enable machine-certificate autoenrollment from the GPO public key policy's Automatic Certificate Request Settings container. To start the Automatic Certificate Request Setup Wizard, which Figure 1 shows, right-click the container and select New, Automatic Certificate Request. This container is in the User Configuration, Windows Settings, Security Settings, Public Key Policies GPO container.

To set up user certificate autoenrollment, you need to make configuration changes in the Microsoft Management Console (MMC) Certificate Templates and Group Policy snap-ins. To enable autoenrollment at the template level, open the Certificate Templates snap-in, then open the template. Select the Security tab, and set the appropriate ACL settings to give users or groups autoenroll permissions, as Figure 2 shows.

You can set these user autoenrollment properties only on Version 2 certificate templates. (Version 1 certificate templates shipped with Win2K; unlike Windows 2003's Version 2 certificate templates, Version 1 certificate template properties can't be changed.) Be aware that only domains with Windows 2003 schemas support Version 2 templates and only Windows 2003, Enterprise Edition or Windows 2003, Datacenter Edition AD-integrated CAs can issue certificates based on Version 2 certificate templates.

Requiring user input on machine certificate templates will make machine autoenrollment fail. To make user certificate autoenrollment occur without user intervention, leave the default settings on the Request Handling tab unchanged. If you want to prompt the user to start the autoenrollment process, select Prompt the user during enrollment. User input is required when you enroll smart card certificates. The user must enter a smart card in the smart card reader and, in most cases, a PIN.

To enable autoenrollment at the GPO level, open the Group Policy snap-in. Select Computer Configuration, Windows Settings, Security Settings, Public Key Policies, then open the Autoenrollment Settings Properties dialog box, which Figure 3 shows. Select the Enroll certificates automatically and Update certificates that use certificate templates check boxes. If you want the autoenrollment process to perform certificate renewal and other certificate housekeeping tasks, make sure that you also select the Renew expired certificates, update pending certificates, and remove revoked certificates check box.

If you set up user autoenrollment to occur without user input, everything happens automatically without user intervention. If you set it up to occur with user input, a warning balloon appears in the user's taskbar tray. After about 15 seconds, a certificate icon replaces the warning balloon. When the user clicks the balloon or the certificate icon, a dialog box appears that prompts the user to choose whether to start the autoenrollment process. If the user clicks Remind Me Later in this dialog box, the warning balloon reappears at the next GPO refresh interval or at the next interactive logon. The warning balloon appears 60 seconds after the interactive logon sequence. If you want the balloon to appear immediately after the interactive logon sequence, set the HKEY_CURRENT_USERSoftwareMicrosoftCryptographyAutoEnrollmentAEExpress registry subkey (of type REG_DWORD) to a value of 1.

Forcing Automatic Enrollment and Renewal
You can force certificate enrollment to occur immediately, without waiting for the next logon or automatic GPO refresh. To force certificate enrollment for user and machine certificates, use the gpupdate.exe command-line utility to manually force a GPO update, which in turn triggers an autoenrollment event.

To force certificate enrollment only for user certificates, open the MMC Certificates snap-in and your personal certificate store. In the context menu, right-click Certificates - Current User and select All Tasks, Automatically Enroll Certificates.

You can also force renewal of specific user or machine certificate types. In the Certificate Templates snap-in, right-click the template and select Reenroll All Certificate Holders. Selecting this option increases the certificate template's version number, which triggers the autoenrollment event. To manually force a download of the root CA and of the cross-certificates that are stored in AD and are downloaded as part of the autoenrollment process, you must delete the HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyAutoEnrollmentAEDirectoryCache registry subkey and all subordinate subkeys on the client machine.

Advanced Autoenrollment Options
Now let's look at some of the advanced autoenrollment options, such as the requirement for certificate manager approval, the selfRA feature, the concept of superseding certificate templates, and the meaning of the Do not automatically reenroll if a duplicate certificate exists in Active Directory certificate template property. These options are available only on Version 2 certificate templates.

Version 2 certificate templates have a property called CA certificate manager approval on the Issuance Requirements tab, as Figure 4 shows. If you set this property, CA manager approval is required before the CA will issue the certificate. Until the CA manager approves the request, it adds the request to the CA's pending request store. The autoenrollment process then periodically checks the CA for approved requests and automatically installs the certificates on the client machine. The CA manager can approve pending certificate requests from the pending request container in the CA snap-in.

SelfRA is a new Windows 2003 PKI feature that lets you set special enrollment requirements on Version 2 certificate templates. To sign a new certificate request, selfRA requires an existing (previously issued) certificate and its associated private key. SelfRA is also configured from the Issuance Requirements tab on the certificate template properties and works in conjunction with autoenrollment. However, autoenrollment can't deal with requests that require more than one signature to authorize the enrollment request. You can set the following selfRA-related properties:

Superseding certificate templates let CA administrators automatically reenroll users for certain certificate types. For example, you can change a property of a particular certificate type (e.g., the lifetime or content of an X.509 extension) by issuing a new certificate. To set up superseding templates, click Add on the Superseded Templates tab of the New User Properties dialog box of a Version 2 certificate template. Figure 5 shows the Add Superseded Template dialog box.

Do not automatically reenroll if a duplicate certificate exists in Active Directory is another useful autoenrollment certificate template property that's available under the General tab of a Version 2 certificate template. When you enable this property, autoenrollment won't enroll a user for a certificate if a similar certificate exists in the user's AD object, even if a certificate doesn't exist in My Container in the user's certificate store. The autoenrollment process queries AD to determine whether to enroll the user. This option is useful for users who don't have roaming profiles and who log on to multiple machines. Without this setting, those users would be automatically enrolled for a certificate on every machine they log on to.

Ease of Use
Certificate autoenrollment is a useful feature from a PKI user's point of view. Compared with the feature set of other PKI products on the market, Windows 2003 PKI autoenrollment is a unique feature that gives Windows 2003 an important advantage.