Security Best Practices for CLM 2007

Article
10/05/2010

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
Enable Administrators to Audit the CLM 2007 Registry Keys
Manage the CLM Agent Accounts
Plan Your Permissions Strategy
Make the Certificate Templates More Secure
Make SQL Server More Secure
Define the Firewall Settings

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.

Note

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

To open Registry Editor, click Start, click Run, type regedit, and then click OK.
Expand HKEY_LOCAL_MACHINE\Software\Microsoft\, and then select the CLM key.
On the Edit menu, click Permissions.
In the Permissions dialog box, click Advanced.
Click the Auditing tab, and then click Add.
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.
In the Auditing Entry dialog box, under Access, select the types of access that you want to audit, and then click OK.

Note

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.
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 (https://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

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.

Note

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.

Note

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:

Improving Web Application Security: Threats and Countermeasures (https://go.microsoft.com/fwlink/?LinkId=90680)
SQL Server Best Practices (https://go.microsoft.com/fwlink/?LinkId=90681)
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication (https://go.microsoft.com/fwlink/?LinkId=90682)