Implementing Key Archival Walkthrough
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
The first step in enabling key archival on a CA is enrolling for one or more KRA certificates.
Enrolling a Key Recovery Agent
The first step is to enroll KRAs for KRA Certificates. The following section explains the steps for enrolling a KRA.
Configuring the Certificate Templates
A certificate template suitable for creating KRA certificates is installed in Active Directory. By default, only an Enterprise Administrator or a Domain Administrator may request a KRA certificate as defined by the default ACLs on the KRA certificate template. The certificate template ACLs can be viewed in the Certificate Templates MMC snap-in; in addition, using the Certificate Templates MMC snap-In, certificate templates can be cloned or edited.
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.
To configure a certificate template
Log on as an Enterprise or Domain Administrator to the CA machine.
Click the Start button, click Run, and then type certtmpl.msc.
Click OK.
.gif "Art Image")
Figure 15: Certificate Templates MMC Snap-InIn the details pane, double-click Key Recovery Agent.
In the Key Recovery Agent Properties dialog box, click the Security tab.
.gif "Art Image")
Figure 16: Key Recovery Agent Template PropertiesAdd the appropriate user(s) or group(s) with both Read and Enroll permission.
Click OK to close the dialog box.
Next, the Certification Authority must be configured to issue this type of certificate.
Certificate Template Permissions
For a user or a computer to enroll for a certificate template, it must have appropriate permissions [access control entries (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. The Read permission allows the template to be discovered by the user and the Enroll permission is enforced by the enterprise CA when a user requests a certificate for a selected template. The enterprise CA must also have Read permissions on a template to enumerate the template in the directory and issue certificates based on that template. Normally, the enterprise CA 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 by default on installation of a fresh Windows Server 2003 domain. If a domain has been upgraded from Windows 2000, Enterprise Administrators will not have this permission by default and 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 a user or computer wants to automatically enroll for a selected certificate template. The Autoenroll permission is needed in addition to the Enroll permission for a user to enroll for a given certificate template.
The Write permission allows a user to modify the contents of a certificate template. Note that only a version 2 certificate with a Windows Server 2003 schema may be modified and version 1 certificate templates may only have the ACLs modified.
Smart Card Support
Smart cards are supported for use in conjunction with KRA certificates. It may be necessary to use a smart card and CSP that supports at least an 8-KB smart card to enroll for a KRA certificate on a smart card. If a smart card does not have adequate memory to support a KRA certificate, the following error will be generated on enrollment.
Error: 0x80100028
An attempt was made to write more data than would fit in the target object
All recovery operations are supported using a Smartcard. The system will prompt the recovery agent to insert an appropriate Smartcard when the key is needed to decrypt the recovery BLOB.
Configuring an Enterprise CA to Issue KRA Certificates
An Enterprise CA must be configured to issue a KRA certificate.
To configure an EnterpriseCA to issue a KRA certificate
On the Administrative Tools menu, open the Certification Authority snap-in.
In the console tree, expand Certification Authority, and then click Certificate Templates.
Right-click the Certificate Templates node, click New, and then click Certificate Template to Issue.
In the Select Certificate Template dialog box, click Key Recovery Agent, and then click OK.
Close the Certification Authority MMC snap-in.
The last manual step is to add the Certification Authority machine account to the Pre-Win2K Compatible Access group in every domain in which users will be using key archival. If this mandatory step is not performed, a CA Officer may not be able to manage groups of users. The Pre-Win2K Compatible Access group allows the CA to enumerate a user account and determine the group membership for CA Manager’s capability.
Enrolling a User with a KRA Certificate
A user may enroll for a certificate with a CA by using the Certificates MMC snap-in or through the CA Web pages. In the case of the KRA template, the template is marked to be “pended” by the CA, which requires that the certificate request be approved first by a CA Administrator or a Certificate Manager before it is issued. Pended certificate requests may only be retrieved through the Web enrollment interface or through the auto-enrollment process. For more information, see Appendix B: Additional Information.
Important
It is strongly recommended not to automatically enroll KRA certificates as this may cause confusion for CA Administrators when automatic enrollment is unintentionally initiated resulting in additional KRA certificates in Active Directory.
KRA Web Enrollment
To enroll through a Web page
Connect to the CA using a Web URL, for example:
https://<CA Machine Name>/Certsrv
Note
.gif "note")
NoteThe Microsoft Certification Authority uses an ActiveX control known as xenroll.dll, which can be downloaded to client browsers that support ActiveX controls. Windows XP and Windows Server 2003 clients both ship with the ActiveX control pre-installed. </div></td> </tr> </tbody> </table> A Web site will open allowing you to request a certificate.Select Request a Certificate.
On the next Web page, select Advanced Certificate Request.
Select Create and submit a request to this CA.
The next page will allow the user to select various configuration options, including the type of certificate to request. Choose Key Recovery Agent as the Certificate Template.
Warning
.gif "Caution")
CautionA key size of 8192 or larger may take several hours to generate on the client. (Key pairs are always generated by the client CSP, not the CA.) This may slow public key operations on the CA when keys are archived. Key sizes of 2048 are much more reasonable for standard security needs; a key size of 8192 is used only as an example. </div></td> </tr> </tbody> </table> The keys should be marked as exportable. This will enable an administrator (KRA) to export the private keys from the local store of the workstation to a disk or other medium for safe storage. Strong private key protection is also recommended, as this will require a password to be used when accessing the private key.When finished, click Submit.
The Web page will show that the request is being generated. When the key generation and request is complete, if the request had included Enable strong private key protection, a dialog box will appear showing that a protected item is being created (KRA private key).
.gif "Art Image")
Figure 17: Private Key Security Level Dialog BoxThe dialog box will present the opportunity to set the security level on the private key. If the workstation will be used for KRA operations and the private key is to be kept in the protected store, it is recommended that the security level be set to High. This will ensure that access to the private key will require a separate password.
.gif "Art Image")
Figure 18: Private Key Security Level Dialog BoxClick Next.
.gif "Art Image")
Figure 19: Private Key Security Level Dialog BoxChoose a password, confirm it, and then click Finish.
.gif "Art Image")
Figure 20: Private Key Security Level Dialog BoxClick OK to confirm. The Web page will appear and offer a link to install the certificate. If the Certification Authority is configured to set all certificate requests to pending, the user will have to return to the Web link to install the certificate after the CA administrator or a CA Officer has approved the request.
Important
.gif "Important")
ImportantThe user may have to return to the Web link using the same machine that was used to generate the request. This is due to the fact that certificate pending information is stored as a browser cookie. If auto-enrollment is enabled in Active Directory for the user, the user will not be required to actually return to the Web page. The auto-enrollment process will automatically retrieve the certificate for the user when available. For more information about the auto-enrollment process, see the Certificate Auto-Enrollment in Windows XP white paper in Appendix B: Additional Information. </div></td> </tr> </tbody> </table> > [!IMPORTANT] > <DIV class=alert>ImportantIf the issuing CA is in a hierarchy, a second option will appear on the Web page to download the entire path (certificate chain). You should choose to download the entire chain.
</div></td>
</tr>
</tbody>
</table>
The default KRA certificate template requires that the certificate request be pended and not issued automatically. When a certificate request is pended, a CA Officer (Certificate Manager) must manually issue the certificate, assuming that the request was valid. Pending certificate requests can be issued through the Certification Authority MMC and by selecting the pending request node.
The Certificate Manager (or administrator of the server, if role separation is not enabled) can right-click the certificate request and choose to issue or deny the request. For more information about Certificate Managers, see Configuring Certificate Managers.
After the certificate has been issued, the user (KRA) can return to the Web pages to retrieve the pending request.
The user should select View the status of a pending certificate request.
The Web page will display all the pending requests for that user that have been requested from that machine. As mentioned previously, this is managed through Web browser cookies. The user should select the appropriate certificate.
The last page allows the user to install the selected certificate and private key into the local MY store of the user.
Configuring the CA to Allow Key Archival
This section details the steps required to configure the CA to allow key archival.
Note: If the Certification Authority is enabled to enforce role separation, only a CA Administrator may configure KRAs on a CA. Role separation is enabled through the registry and only a local server administrator may configure the registry. The easiest way to enable the CA for role separation is to use the certutil.exe command-line tool:
certutil -setreg ca\RoleSeparationEnabled 1
It is necessary to stop and start certificate services for the setting to take affect.
Note
Certutil.exe and other tools may be installed on a Windows XP Professional machine by installing the Administrative Tools (adminpak.msi) that are found in the \i386 directory on all Windows Server 2003 CD-ROM media.
Enabling a Key Recovery Agent
To enable a KRA
Log on as Administrator of the server or CA Administrator, if role separation is enabled.
On the Administrative Tools menu, open Certification Authority.
In the console tree, select the CA.
Right-click the CA name, and then click Properties.
Click the Recovery Agents tab.
.gif "Art Image")
Figure 21: Recovery Agents TabTo enable key archival, click Archive the key.
By default, the CA will only use one KRA. However, a KRA certificate must first be selected for the CA to begin archival. To select a KRA certificate, click Add.
The system will find valid KRA certificates and display the available KRA certificates.
KRA certificates are normally published to Active Directory by an Enterprise CA when enrollment occurs. KRA certificates are stored under the KRA container in the Public Key Services branch of the configuration partition in Active Directory. Since a CA may issue multiple KRA certificates, each KRA certificate will be added to the multi-valued userAttribute attribute of the CA object.
Select one certificate and click OK. You may view the highlighted certificate to ensure that you have selected the intended certificate.
.gif "Art Image")
Figure 22: Recovery Agents TabAfter one or more KRA certificates have been added, click OK to enable key archival on the CA. However, Certificate Services must be stopped and started to enable the use of the selected KRAs. KRA certificates are only processed at service start.
Configuring Certificate Managers
To recover the private keys of a user, the CA enforces that a person be a Certificate Manager (if defined) and also holds a private key for a valid KRA certificate. As a best practice, most organizations separate these two roles. By default, the CA Administrator is a Certificate Manager for all users unless otherwise explicitly defined. A KRA is not necessarily a CA Officer (Certificate Manager). They may be segmented as separate roles. A KRA is defined as a person who holds a private key for a valid KRA certificate.
A CA Officer is defined as a Certificate Manager who has the security permission on the CA to Issue and Manage Certificates. The security permissions are configured on a CA using the Security tab on the CA Properties in the Certification Authority MMC snap-in.
.gif "Art Image")
Figure 23: Security Tab
A CA Administrator can define more specific CA Officer Roles on a Certification Authority by using the Certificate Managers Restrictions tab. By default, any user or group that has the permission to Issue and Manage Certificates is also a CA Officer and can issue, revoke, or export a recovery BLOB for any other user who has been issued a certificate from that CA.
.gif "Art Image")
Figure 24: Certificate Managers Restrictions Tab
A CA Administrator can define that individual CA Officers have the ability to issue, revoke, and recover certificates for defined sets of user(s) and group(s) by selecting the Restrict certificate managers option. Once the option has been selected, a CA Administrator may define CA Officers’ roles as required.
Important
Once this is complete, it is also necessary to add the machine account of the CA to the Pre W2K Compatible Access Group of every domain in which users will be archived and recovered. This is necessary to provide proper group membership enumeration for role restriction enforcement when performing recovery functions. Certificate Managers will not be able to recover users unless this task is performed first in every user domain.
Configuring User Templates
To enable a user template for key archival, select the template that should enforce key archival and select the Archive subject’s encryption private key check box. Once the check box has been selected, the CA will always enforce key archival for that template.
.gif "Art Image")
Figure 25: Request Handling Tab
Note
A Windows Server 2003 CA will not allow archival of a key marked for signature only and will reject the request, even if sent programmatically to the CA.