Deploying Certificate Templates (Implementing and Administering Certificate Templates in Windows Server 2003)

Applies To: Windows Server 2003 with SP1

After creating a version 2 certificate template, the next step is to deploy the certificate template. Deployment includes publishing the certificate template at one or more Certification Authorities, defining which security principals have Enroll permissions for the certificate template, and deciding whether to configure auto-enrollment for the certificate template.

Publishing Certificate Templates

Once a certificate template is created in the Certificate Templates MMC and the certificate template has replicated to all domain controllers in the forest, it can now be published for deployment. The main decision in publishing certificate templates is deciding which Certification Authority or Authorities will issue the certificates based on this certificate template.

An Enterprise CA can only issue certificates based on certificate templates that exist in the Certificate Templates container in the Certification Authority MMC console (Figure 9).

Figure 9: Defining the Certificate Templates Published at the EntCA Certification Authority

Permission Design

Certificate templates are published to the configuration naming context, which is stored on every domain controller in the forest in the path CN=Certificate Templates, CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRootDomain. Each certificate template exists as an object in the configuration naming context and has an associated DACL, which defines what specific operations a security principal can do with the certificate.

Use the following recommendations for permissions assignments:

• Assign permissions only to global groups or to universal groups. Certificate templates are defined in the configuration naming context. Permissions should only be assigned to global groups or to universal groups. It is not recommended to assign permissions to domain local groups. They are only recognized in the domain where the domain local group exists and can result in inconsistent application of permissions. It is recommended to never assign permissions directly to an individual user or computer account.

• To enable auto-enrollment, a user or computer must belong to domain groups that are granted Read, Enroll, and Autoenroll permissions.

• To enable enrollment via the Certificates MMC console, through Web-based enrollment, or through auto-renewal, set either domain or universal groups with Read and Enroll permissions.

• For certificate renewal, a user or computer must belong to a domain security group with Read and Enroll permissions. This is true whether the certificate is manually renewed or the renewal is implemented using auto-enrollment.

• Restrict Write and Full Control permissions to CA managers to ensure that the templates are not improperly configured.

Auto-Enrollment Considerations

Auto-enrollment allows a CA administrator to configure users and computers to automatically enroll for certificates, retrieve issued certificates, and renew expiring certificates without requiring subject interaction. The auto-enrollment process can be configured to function as a background task that does not require any user input.

To properly configure subject auto-enrollment, the administrator must plan the configuration of the certificate template that will use auto-enrollment. Several settings in the certificate template directly affect the behavior of subject auto-enrollment, as follows:

• User input requirements On the Request Handling tab (Figure 2) of the desired certificate template, the Require user input for auto-enrollment check box changes the behavior of auto-enrollment. When this check box is selected, subjects are prompted for any necessary information for obtaining or renewing a certificate. When this check box is cleared, auto-enrollment operates silently, without any notice to the subject.

  Note

  Because smart cards must prompt the user for their PIN, this option must be selected when a smart card CSP is selected.

• Limit the number of CSPs for an auto-enrollment certificate template If more than one smart card CSP is selected on the Request Handling tab (Figure 2), users may receive more than one dialog box when a Windows XP client retrieves the auto-enrolled certificate and begins to install it on the smart card. It is recommended that only one CSP be selected from this list for each template.

• Do not enable subject creation based on request information If the Supply in the request option is enabled on the Subject Name tab (Figure 3), auto-enrollment is disabled. This is because enabling the option prompts the subject to interactively create the subject name in the request, which will not work with auto-enrollment.

• Do not require more than one authorized signature for issuance Configuring more than one authorized signature in the Issuance Requirements tab (Figure 4) of the desired certificate template disables subject auto-enrollment based on this template. If the authorized signatures value is set to one, the requestor must sign the request with a private key from a valid certificate in their certificate store. This certificate must contain the application and/or issuance policies specified in the Application policy and Issuance policies lists on the same tab. If an appropriate certificate exists in the requestor's certificate store, auto-enrollment signs the request with this certificate's private key and will obtain and install the requested certificate automatically. For example, to increase the security for EFS certificate distribution, you can create a custom version 2 certificate template that requires the existence of the Smart Card Logon OID (1.3.6.1.4.1.311.20.2.2) in the signing certificate's Application policy.

• On the Issuance Requirements tab (Figure 4) of the desired certificate template, the Valid existing certificate option may affect subject auto-enrollment. This option tells the CA that the subject does not need to meet issuance requirements when renewing a valid certificate. Subjects who may have been unable to auto-enroll for the initial certificate may be able to use auto-enrollment to renew that certificate. For example, a user whose distinguished name has changed may still auto-enroll a certificate based on an existing valid certificate, rather than on their new credentials.

Delegating Template Management

You can delegate the ability to manage individual certificate templates or to create any certificate templates by defining appropriate permissions to global groups or universal groups that a user belongs to.

To delegate modification of a specific certificate template, assign a global or universal group the Read and Write permissions on the Security tab (Figure 8) of the certificate template. If you also wish to delegate administration permissions to the security groups, assign Full Control permissions so that the security group can modify the DACL for the certificate template.

To delegate the ability to create certificate templates to users who are not members of the Domain Admins group in the forest root domain, or members of the Enterprise Admins group, it is necessary to define the appropriate permissions in the Configuration naming context of the Active Directory.

To delegate the administration of all certificate templates, including the ability to duplicate and create new certificate temples, you must make the following permission assignments to a global or universal group that the user is a member of:

• CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot container = Full Control permissions

• Full Control permissions to every certificate template in the CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot container. The permissions assigned to the Certificate Templates container are not inherited by the individual Certificate Templates.

• Full control permissions to the CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC= ForestRoot container.