Tips and Tricks

Published: April 10, 2006

By Conrad Bayer
Group Program Manager, Windows Security

See other Security Tip of the Month columns

Microsoft Certificate Lifecycle Manager (CLM) is tightly integrated with the Active Directory service for authentication and authorization. Beta 1 of CLM was released in February and is available publicly.

This tip describes the CLM extended permissions, identifies where you implement CLM extended permissions, and provides strategies for permission assignments.

Before installing CLM you must extend the Windows Server 2003 schema. The schema extensions add seven CLM extended permissions that are used to delegate CLM management permissions to groups and users.

The CLM extended permissions are:

  1. CLM Audit. Allows the generation and display of CLM policy templates, the definition of management policies within a profile template, and the generation of CLM reports.

  2. CLM Enrollment Agent. Allows a user or group to perform certificate requests on behalf of another user. The issued certificate’s subject will contain the target user’s name, not the requestor’s name.

  3. CLM Enroll. Allows the initiation, execution, or completion of an enrollment request.

  4. CLM Recover. Allows the initiation of encryption key recovery from the CA database.

  5. CLM Renew. Allows the initiation, execution, or completion of an enrollment request. The renewal request replaces a user’s certificate that is near its expiration date with a new certificate with a new validity period.

  6. CLM Revoke. Allows the revocation of a certificate before the expiration of the certificate’s validity period.

  7. CLM Request Unblock Smart Card. Allows a smart card’s User PIN to be reset, allowing access to the key material on a smart card to be reestablished.

When you assign permissions in a CLM environment, there are five different permission assignment locations that determine the actual authorization level of the requesting user. When you define a management policy workflow, you must determine whether permissions are necessary at each of the five locations.

The locations where permissions may be required are:

  1. On the service connection point. The service connection point permissions determine whether a user is assigned a management role within the CLM deployment. For example, if a user must initiate requests for other users, the user is assigned the CLM Enroll permission at the service connection point.

  2. On the profile template object. The profile template permissions determine whether a user can read the contents of the profile template (to execute management policy workflows within the profile template) or receive certificates based on the management policies within the profile template. If a user is required to enroll certificates based on the profile template, the user must be assigned the CLM Enroll permission on the profile template.

  3. Users or groups. Users or groups assigned a management role within the CLM environment must have permissions assigned on the user or group objects that they will manage within the environment. For example, if you wish to enable a manager to recover certificates issued to members of the EFS Users group, you must assign the manager or a group containing the manager the CLM Recover permission on the EFS Users group object.

  4. Certificate templates. The user or group that submits enrollment and renewal requests to the certification authority must be assigned the Enroll and Renew permissions on all certificate templates within a profile template.

  5. Within a management policy. A user or group must be assigned a management role within the management policy. For example, if a user is tasked with approving enrollment requests, you must assign the user the ability to approve enrollment requests within the Enroll management policy.

When assigning CLM permissions, keep the following tips in mind:

Assign permissions to universal or global groups. CLM only enumerates and evaluates universal and global groups when determining if a user is assigned a management role within the CLM environment. Domain local groups and local groups are not evaluated. In addition, if you have a multiple domain environment, you cannot assign permissions to domain local groups for certificate template and profile template objects. These objects exist in the Configuration naming context and are available at all domain controllers in the forest. A domain local group assignment would only be recognized by domain controllers in the forest root domain.

Ensure that matching permissions are assigned on the service connection point (SCP) and groups that are managed within CLM. If users or groups must manage users within CLM, they must be assigned CLM extended permissions at both the SCP (to designate their role as a manager allowed access to the CLM management portal), and on the user or group object (to designate who they can manage).

Verify all permission assignment locations. When you are troubleshooting a permission assignment problem, be sure to look at all permission assignment locations. Omission of a required permission assignment at any of the five locations will result in the failure of the management profile workflow.

Verify all group memberships. Many of the permission assignments will depend on nested groups. If a group membership within the nesting is not defined correctly, the user’s access token will not include the group membership and will thus be missing a permission assignment.

References and Related Reading

Microsoft Certificate Lifecycle Manager Technical White Paper

Microsoft Certificate Lifecycle Manager Quick Start Guide

Microsoft Certificate Lifecycle Manager Partner Listing