Export (0) Print
Expand All

Security Best Practices for CLM 2007

Microsoft® Identity Lifecycle Manager "2" Certificate Management Service (ILM CMS) integrates with several core Windows components and applications, including Microsoft SQL Server, Internet Information Services (IIS), and certification authorities (CAs). Because of this integration, we recommend that you take steps to secure your ILM CMS environment.

The following topics describe how to make your ILM CMS environment more secure:

Enable SSL Protection on the CLM Web Site

When you install ILM CMS, the installation process configures the CLM Web site to prevent anonymous access. The installation process also configures the CLM Web site to allow access only to authorized users. With the exception of domain administrators, users have only limited permissions in ILM CMS, unless you assign additional permission to users manually.

noteNote
After you configure ILM CMS for the first time, you must manually enable any functionality that requires anonymous access, such as kiosk unblock.

Be default, the HTTP transport for the CLM Web site does not use Secure Sockets Layer (SSL) protection. You must enable SSL protection manually after you install and configure ILM CMS. We recommend that you protect the virtual directory for the CLM Web site with 128-bit SSL encryption.

Enable Administrators to Audit the CLM 2007 Registry Keys

To enhance system integrity and track system changes, we recommend that you enable administrators to audit the ILM CMS registry keys on the CLM server. The ILM CMS registry keys hold important information about the ILM CMS configuration. This includes the following information:

  • Installation details

    For example, the version, language, installation date, and product identifier for ILM CMS.

  • Log file details

  • Agent account passwords that are protected by Data Protection API (DPAPI)

  • Installation folder locations

To enable auditing of CLM 2007 registry keys

  1. To open Registry Editor, click Start, click Run, type regedit, and then click OK.

  2. Expand HKEY_LOCAL_MACHINE\Software\Microsoft\, and then select the CLM key.

  3. On the Edit menu, click Permissions.

  4. In the Permissions dialog box, click Advanced.

  5. Click the Auditing tab, and then click Add.

  6. In the Select User, Computer, or Group dialog box, type the name of a user or click Advanced to search for a user, and then click OK.

  7. In the Auditing Entry dialog box, under Access, select the types of access that you want to audit, and then click OK.

    noteNote
    At a minimum, we recommend that you enable auditing for both successful and failed Set Value access attempts by the Everyone group. If you enable auditing for Everyone, ILM CMS collects audit information for all users.

  8. To apply your changes, on the Auditing tab, click OK, and then click OK in the Permissions dialog box.

Manage the CLM Agent Accounts

ILM CMS uses the CLM agent accounts for its core administrative operations, such as updating tables in the CLM database. Because these accounts have a high level of administrative rights, we recommend that you use the following best practices when you manage the CLM agent accounts:

  • Run the CLM Configuration Wizard to update the CLM agent accounts.

    ILM CMS stores the CLM agent account passwords in the Windows registry on the CLM server. The registry keys are protected by DPAPI. If you must change a CLM agent password or change which account is used as a CLM agent, we recommend that you run the CLM Configuration Wizard. For more information about running the CLM Configuration Wizard, see Installing and Configuring CLM 2007 on a Server (http://go.microsoft.com/fwlink/?LinkId=88419).

  • Use the default ACL settings on the CLM agent account passwords.

    We recommend that you do not modify the default access control lists (ACLs) for the registry keys that contain the CLM agent passwords. The CLM Configuration Wizard explicitly sets permissions to the password registry keys and prevents the keys from inheriting permissions. The following table shows the default permission assignments.

     

    User or group Default permission assignment

    CLM application pool user account

    Read permission

    Administrators group

    Full Control permission

Plan Your Permissions Strategy

When you evaluate deployment of ILM CMS, we recommend that you plan your permissions strategy carefully. In addition, we recommend that you examine and verify your permissions and user rights settings regularly to enhance the security of the environment in which ILM CMS operates.

Use a common naming pattern for CLM extended permissions

We recommend that you use a common naming pattern for all groups to which you assign CLM extended permissions. For example, prefix the group names with clm-perm.

Use separate accounts for profile template administration

Although certificate managers administer profile templates in ILM CMS, administrators can also administer profile templates. Because it is a general best practice to isolate management functions, we recommend that you use separate accounts for profile template administration and general CLM Web site administration, such as running reports.

We also recommend that you limit the number of users in your organization who can manage profile templates. The following table shows the permissions that a certificate manager must have in your organization.

 

Location Permission assignment

Service connection point

Read permission

CLM Audit extended permission

Target user or group

None

Profile template object (in Active Directory)

Read permission

Write permission

Certificate template

None

Profile template (on the CLM Web site)

None

Profile templates container (in Active Directory)

Read permission

Create Child Objects permission

Implement a certificate registration model

When you plan your ILM CMS deployment, we recommend that you record all of the CLM permissions you want to configure. One way to organize your permissions strategy is to use the ILM CMS certificate registration models to categorize your ILM CMS workflows.

ILM CMS provides three broad registration models that you can implement: self-service, delegated, and centralized. An organization can implement one or all of these registration models in one environment. implements different certificate registration models by requiring different validation processes for each certificate registration and marking each certificate with a specific extension, depending on its assurance level.

Self-service registration model

In the self-service registration model, a user can use the Manage My Info view of the CLM Web site to request a change to a certificate or personal identification number (PIN). You can configure whether another user must approve the request before it is completed. You must configure whether self-service is enabled and whether a user must approve the request for every management policy in a profile template. The following table shows the permissions that a user must have to complete a self-service request.

 

Location Permission assignment

Service connection point

None

Target user or group

NA

Profile template object (in Active Directory)

Read permission

CLM Enroll extended permission

Certificate template

Read permission

CLM Enroll extended permission (This permission is required only if the user will complete the request, which occurs when you have not assigned an approver in the management policy.)

Profile template (on the CLM Web site)

You must enable self-service in the management policy.

Profile templates container (in Active Directory)

None

The following table shows the permissions that an approver must have to approve a self-service request.

 

Location Permission assignment

Service connection point

Read permission

CLM Audit extended permission

Target user or group

None

Profile template object (in Active Directory)

Read permission

Certificate template

None

Profile template (on the CLM Web site)

In the management policy, you must designate the user as an approver.

Profile templates container (in Active Directory)

None

Delegated registration model

In the delegated registration model, someone other than the user initiates registration. Then, the user provides a supplied, one-time password to complete registration. The person who initiates registration is called an initiator. The following table shows the permissions that an initiator must have to request certificates on behalf of other users.

 

Location Permission assignment

Service connection point

Read permission

The relevant extended permission for the operation they will initiate, for example, CLM Request Enroll, CLM Request Recover.

Target user or group

Read permission

The extended permission for the operation that the user will initiate, for example, CLM Request Enroll or CLM Request Recover.

Profile template object (in Active Directory)

Read permission

Certificate template

None

Profile template (on the CLM Web site)

In the management policy, you must designate the user as an initiator.

Profile templates container (in Active Directory)

None

The following table shows the permissions that an approver must have to approve a request made on behalf of another user.

noteNote
The approver permissions in the following table are the same as the permissions required for an approver completing a self-service request.

 

Location Permission assignment

Service connection point

Read permission

CLM Audit extended permission

Target user or group

None

Profile template object (in Active Directory)

Read permission

Certificate template

None

Profile template (on the CLM Web site)

In the management policy, you must designate the user as an approver.

Profile templates container (in Active Directory)

None

Centralized registration model

In the centralized registration model, certificate managers enroll users for certificates. The following table shows the permissions that an enrollment agent must have to enroll users for certificates.

 

Location Permission assignment

Service connection point

Read permission

CLM Enrollment Agent extended permission

Target user or group

None

Profile template object (in Active Directory)

Read permission

Certificate template

Read permission

CLM Enroll extended permission

Profile template (on the CLM Web site)

In the management policy, you must designate the user as an enrollment agent.

Profile templates container (in Active Directory)

None

Limit CLM agent account permissions

We recommend that you limit the permissions and user rights that you assign to the CLM agent accounts to only those that are necessary for ILM CMS to function correctly. We also recommend that you do not use the CLM agent accounts for other programs or uses. The following table shows the permissions and user rights that each CLM agent account must have.

 

Acccount Permission assignment

CLM Agent

  • Allow logon locally user right on the CLM server

  • Issue and Manage Certificates permission on the CA

  • Read and Write permission on the system Temp Folder (C:\Windows\Temp)

Key Recovery Agent

  • Allow logon locally user right on the CLM server

  • Membership in the Administrators local group

  • CLM Enroll permission on the Key Recovery Agent certificate template, or on the custom certificate template, if you use one

  • Read and Write permission on the System Temp Folder (C:\Windows\Temp)

Authorization Agent

  • Membership in the Pre-Windows 2000 Compatible Access domain group

  • Generate security audits user right on the CLM server

CA Manager Agent

  • Manage CA permission on the CA

Make the Certificate Templates More Secure

ILM CMS uses certificate templates to determine which users can perform key certificate enrollment and recovery operations. We recommend that you use the following best practices to make the certificate templates more secure:

  • Restrict enrollment for the EnrollmentAgent and KeyRecoveryAgent certificate templates.

    We recommend that you restrict enrollment for the EnrollmentAgent and KeyRecoveryAgent certificate templates to allow only the CLM agent accounts to enroll certificates based on those certificate templates. If you use a custom certificate template for the CLM Agent signing certificate, also restrict enrollment for that certificate template. You might have to grant authenticated users the CLM Request Enroll extended permission on the CLM Agent's signing certificate template if you are using the default User certificate template to issue users certificates.

  • Use at least one additional certificate for the Key Recovery Agent.

    Before or after you deploy ILM CMS, we recommend that you issue at least one additional Key Recovery Agent certificate outside of the ILM CMS environment. Doing so allows you to recover archived private keys if a catastrophic failure of ILM CMS or the CA occurs. If you do issue additional Key Recovery Agent certificates, you must configure key recovery on your CAs so that the number of recovery agents matches the number of Key Recovery Agent certificates that you issued.

  • Use a custom, version 2 certificate template for the CLM Agent certificate template.

    The default User certificate template includes the Encrypting File System (EFS) and Secure E-mail application policies, which ILM CMS does not require. We recommend that you duplicate the default User certificate template, remove the EFS and Secure E-mail application policies, and then assign the custom certificate template to the CLM Agent.

    noteNote
    ILM CMS uses the default User certificate for encryption purposes, even if the Public Key Usage List does not specify key encipherment. You can view the Public Key Usage List by right-clicking a certificate template, and then clicking Properties. The list is under Other Information.

Make SQL Server More Secure

Because ILM CMS uses Microsoft SQL Server™ as its central database, we recommend that you carefully secure SQL Server access accounts, passwords, and authentication methods.

Use Integrated Windows authentication

Although ILM CMS supports both SQL authentication and Integrated Windows authentication, we recommend that you use Integrated Windows authentication. In Integrated Windows authentication, Windows authenticates the user and sends the success to SQL Server, and the user name and password for the SQL user account are not sent in the network.

Use the CLM Configuration Wizard to set initial passwords

If you use SQL authentication, we recommend that you use the CLM Configuration Wizard to set your initial password to the CLMUser account. You can also use the CLM Configuration Wizard to change the password, if the user does not have access to the SQL server as a database administrator.

During installation, ILM CMS randomizes the initial password that you assign to the CLMExternal account. You must use the SQL Enterprise Manager console to change that password.

Preserve the default SQL Server access settings

We recommend that you preserve the default SQL Server access settings for the CLM database. The following table shows the default access settings.

CLM database default access settings

SQL Role dbo (SA) CLMUser CLMExternal

db_accessadmin

db_backupoperator

db_datareader

db_datawriter

db_ddladmin

db_denydatareader

db_denydatawriter

db_owner

Yes

db_securityadmin

CLMApp

Yes

CLMExternalApi

Yes

public

Yes

Yes

Yes

Define the Firewall Settings

We recommend that you define the firewall settings that ILM CMS requires for each ILM CMS component. Although these settings are configured by default in ILM CMS, we recommend that you regularly verify your firewall settings to ensure that they are configured correctly. The following table shows the required firewall settings

Required firewall settings

Object Source Destination Port Rule

Active Directory

NA

NA

53 (udp)

88 (tcp/udp)

389 (tcp)

445 (tcp)

3268 (tcp)

NA

Certificate managers

All

CLM

443 (tcp)

Permit

Certificate managers

All

Active Directory

88 (tcp/udp)

Permit

Certificate managers users

All

CLM

443 (tcp)

Permit

Certificate managers and users

All

Active Directory

88 (tcp/udp)

Permit

CA

CLM

CA

135 (tcp)

Permit

CA

CLM

CA

7680 (configurable based on DCOM settings)

Permit

SMTP

CLM

SMTP

25 (tcp)

Permit

SQL

CLM/CA

SQL

1433 (tcp)

Permit

SQL

CLM/CA

SQL

1434 (udp)

Permit

Addition Resources

For more information about security best practices for ILM CMS, see the following resources:

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft