How can I enable digital certificate autoenrollment in Windows Server 2003?

A.
Autoenrollment is available to Windows 2003 and Windows XP domain members for version 2 certificate templates (which can be issued only by enterprise certificate authorities--CAs--running Windows 2003 Enterprise or Datacenter Edition). The autoenrollment process grants certificates based on certificate templates that are supplied with Read, Enroll, and Autoenroll permissions for the users, groups, or computers who require autoenrollment. A modification is made to Group Policy to initiate the process during a Group Policy refresh or interactive logon event. Make sure that the certificate templates to be configured for autoenrollment don't require user input because if they do, the autoenroll process will fail.
In this example, we'll enable autoenrollment for certificates to be used for digital signatures and message encryption via Microsoft Office Outlook 2003:

Right-click the Exchange Signature Only template and select Duplicate Template from the menu.

Select the General tab and enter a name for the new template (e.g., Exchange Signature Only Custom). Don't enable digital signature publishing in AD (this is not needed for signatures because the certificate is enabled in the payload of the message sent).

Under the Request Handling tab, set the purpose to Signature. Select "Enroll subject without requiring any user input" and select the "Allow private key to be exported" check box, as Figure 5shows. Alternatively, if you have archiving enabled, you can select the "Archive subject's encryption private key" (the option might be grayed out depending on the type of certificate you're duplicating). It's advisable to enable the key archival in case a private key is lost)

Click the Subject Name tab and select "Build from this Active Directory information." Set "Subject name format" to "Fully distinguished name" and select the "Include e-mail name in subject name" check box.

Select the Security tab and ensure that Read, Enroll, and Autoenroll are enabled for the users (e.g., Domain Users) who will autoenroll as Figure 6 shows. Some companies have a process whereby users are added to a group if they require certain certificate autoenrollments, which then are processed on their next logon or Group Policy refresh. Click OK.

Repeat the above steps for Exchange User, except that under the General tab, you need to enable publishing to the AD (this results in the public certificate being placed in the user's userCertificate attribute for the user and is queried via the global catalog (GC) by the sending party and will be visible under the "Published Certificates" tab for the user in the Active Directory Users and Computers MMC snap-in). Also, under Request Handling, set the Purpose to Encryption.

Close the Manage templates snap-in.

Under Certificate Templates within the Certification Authority snap-in, right-click and select "New - Certificate Template to Issue."
11. Select a certificate that you want to issue and click OK, as Figure 7 shows. (Certificates that are already being issued aren't shown in the dialog box). Repeat this process for the certificates you just created (e.g., Exchange User Custom and Exchange Signature Only Custom.

Make sure you choose the copied template that you created and not the original (i.e., select Exchange User Custom, not Exchange User). The original template doesn't permit autoenroll.
Next you need to enable the Group Policy for the autoenrollment. To do so, perform these steps:

Open the GPO that applies to the container (e.g., domain or OU that will affect the users/computer requiring autoenrollment) or create a new GPO. (For example, open the MMC Active Directory Users and Computers snap-in, right-click the container, and select Properties. Select the Group Policy tab, select the GPO and click Edit, as Figure 8 shows.)

Under the GPO's Computer Configuration and User Configuration main branches, expand Windows Settings, Security Settings, Public Key Policies and double-click the Autoenrollment Settings. (You want to set this at both computer and user level.)

Enable the "Enroll certificates automatically" and select the two check boxes for renewing expired certificates and updating certificates that use certificate templates, as Figure 9 shows. Click OK

Close the GPO editor.

When users next logon or have Group Policy applied, they should receive the certificates within 90 seconds. You can verify that users received the certificates by performing these steps:

Start the MMC console (Start, Run, MMC).

From the File menu, select Add/Remove Snap-in.

Click Add from the Standalone tab of the Add/Remove snap-in dialog box.

Click OK to the main Add/Remove Snap-in dialog. You'll now see the certificates under Certificates, Current User, as Figure 11 shows.

You can check the Application event log for information related to autoenrollment on the client. (You can also view Failed Requests in the Certificate Authority MMC snap-in.) Figure 12 shows a failed autoenrollment from the client Application event log.

The failed autoenrollment occurred because the remote procedure call (RPC) server wasn't available on the CA that was running on Windows Server 2003 Enterprise Edition with Service Pack 1 (SP1) installed. Because the CA was enabled on the server after the Security Configuration Wizard (SCW) had been run, the services and ports needed by certificate servers weren't enabled. To resolve the problem, run the SCW (Start, Programs, Administrative Tools, Security Configuration Wizard) and enable the Certificate Server in the Select Server Roles section and the "Ports used by System RPC applications" option in the "Open Ports and Approve Applications" section.

To view the certificates that have been issued from a certificate server, expand the Issued Certificates branch of the Certification Authority MMC snap-in, as Figure 13 shows.

Be careful when using autoenrollment for the Exchange User certificate, which is used to encrypt messages when users log on to more than one machine and access mail. Messages are encrypted with a generated symmetric key (i.e., the key is used to both encrypt and decrypt the message) and the symmetric key is transmitted with the message encrypted with the recipient's public key. This means that only the recipient's private key can decrypt the symmetric key and thus decrypt the message.

The problem is that if you use autoenrollment and a user logs on to multiple machines, each machine will generate a new set of private and public keys for that user (because a separate profile is used on each machine). Thus, depending on which public key is used to encrypt a message, the recipient will be able to open the message only on the computer with the paired private key. On all other machines the corresponding private key is missing and the message is unreadable.

The solution is to store these certificates (private keys) on smart cards that travel with the user instead of on the machines or use roaming profiles so that the user always has the same profile and thus no additional certificate enrollments will take place.

With Windows 2003 and Windows Vista, Digital Identity Management Service (DIMS) enables credential roaming, in which the certificates and private keys are stored in AD, avoiding the problem. You can find more information about this problem at http://technet2.microsoft.com/WindowsServer/en/Library/d052e2b5-fd73-4bd0-8018-7713049463ee1033.mspx.