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