Troubleshooting CLM 2007
Microsoft® Identity Lifecycle Manager "2" Certificate Management Service (ILM CMS) is an identity-assurance management system that maximizes the trust and flexibility associated with digital certificates and smart cards. You can use this document to troubleshoot problems you might encounter when you use ILM CMS.
The following topics provide troubleshooting solutions:
Introduction to Troubleshooting CLM 2007
A-Z List of Problem Topics for CLM 2007
Things to Check Before Troubleshooting CLM 2007
Quick Fixes for CLM 2007
Troubleshooting CLM 2007 Problems
Troubleshooting CLM 2007 Performance Problems
Troubleshooting CLM 2007 Security Problems
Troubleshooting CLM 2007 Using Advanced Techniques and Tools
Troubleshooting CLM 2007 Language and Localization Issues
Additional Resources
Introduction to Troubleshooting CLM 2007
The topics in this section describe when and how to use this document to troubleshoot ILM CMS.
When to use this document
Use this document in the following situations:
When a ILM CMS management policy workflow does not behave as expected.
When users cannot connect to the CLM Web site.
Users are also known as certificate subscribers.
When ILM CMS configuration fails or causes errors.
Do not use this document to learn how to perform operational tasks, such as configuring a profile template or modifying a management policy workflow. For information about how to perform operations tasks, see Using the CLM 2007 Web site (https://go.microsoft.com/fwlink/?LinkId=89761).
This document assumes that you have a basic understanding of how to use ILM CMS and why your organization uses it to manage software certificates and smart cards. You should also have a thorough understanding of how your organization deploys and manages ILM CMS. This includes an understanding of the mechanisms that your organization uses to configure and manage ILM CMS settings.
How to use this document
To give you flexibility in how you solve problems using ILM CMS, this document organizes troubleshooting information in various ways, and with varying amount of detail, as you can see in the following list:
A-Z List of Problem Topics for CLM 2007
Lists problem topics alphabetically. Use this list to find a problem topic quickly.
Things to Check Before Troubleshooting CLM 2007
Provides a list of tasks and settings to check before you troubleshoot a problem. Read this topic before you read a problem topic to ensure that your system is set up properly for troubleshooting.
Quick Fixes for CLM 2007
Provides quick solutions for the most common ILM CMS problems. Read this topic if the problem persists after you complete the tasks in Things to Check Before Troubleshooting CLM 2007.
Troubleshooting CLM 2007 Problems
Provides links to step-by-step diagnostic procedures and solutions that might help you identify and solve ILM CMS problems.
Troubleshooting CLM 2007 Performance Problems
Provides information for resolving performance problems.
Troubleshooting CLM 2007 Security Problems
Provides information for resolving security problems.
Troubleshooting CLM 2007 Using Advanced Techniques and Tools
Describes how to configure your servers and computers for advanced troubleshooting. Read this topic if you cannot find a solution in the other troubleshooting topics, and if you are ready to begin advanced troubleshooting and diagnostics, such as trace logging.
Additional Resources
Provides links to related documentation.
A-Z List of Problem Topics for CLM 2007
You can use the following topics to troubleshoot ILM CMS problems:
Certificate-based authentication problems
Certificate managers cannot access the management view of the CLM Web site
Certificate managers cannot manage profile templates
Certificate managers in some domains cannot view CLM 2007 management functions
Certificate Subject policy module
Change passwords for the SQL Server access accounts
Change the CLM agent account passwords
CLM 2007 cannot connect to the CLM database
CLM 2007 issues certificates to users but does not record them in the CLM database
CLM administrators cannot delegate administration for profile templates
Configure SQL Server security settings
Enable trace logging for the CA modules
Enable trace logging for Certificate Lifecycle Manager 2007 Client
Enable trace logging for document printing
Enable trace logging for online updates
Enable trace logging for the CLM Configuration Wizard
Enable trace logging for the CLM server components
Enable trace logging for the CLM Service
Installing Certificate Lifecycle Manager 2007 Client fails because of hardware or software incompatibility on the CLM client
Installing CLM 2007 fails because of hardware or software incompatibility on the CLM server
Integrated Windows authentication problems
Internet Explorer does not load the CLM Web site
Management policy workflow fails in CLM 2007
Non-CLM Certificate Requests policy module
Smart card field mappings printed incorrectly
SMIME Capabilities policy module
Solving CLM database password problems
Subject Alternative Name policy module
The CLM Web site is slow to display user information and available operations
The CLM Web site is slow to return records from the CLM database
The user running the CLM Configuration Wizard does not have the required group membership
Users are prompted to install ActiveX controls each time they open the CLM Web site
Users cannot approve requests
Users cannot complete requests
Users cannot complete self-service requests
Users cannot enroll for certificates on behalf of other users
Users cannot execute requests
Users cannot initiate requests
Users in some domains cannot access the CLM Web site
Things to Check Before Troubleshooting CLM 2007
Before you begin troubleshooting, verify that your system is configured correctly and that ILM CMS is set up and running properly.
Do the following:
Make sure you have administrative rights on the computer that you are troubleshooting
Install all critical updates and security updates for Windows
Update all your software, including non-Microsoft software
Restart the computer if you are running a server operating system
Make sure you have administrative rights on the computer that you are troubleshooting
You cannot modify Certificate Lifecycle Manager 2007 Client settings unless you are a member of the Administrators group on the computer that you are troubleshooting.
To make sure that you are a member of the Administrators group
Click Start, right-click My Computer, and then click Manage.
In the console tree, double-click Local Users and Groups, and then click Groups.
In the details pane, double-click Administrators, and then verify that your account name (or a group in which your account is a member) appears in the Members list.
You can also tell if you have the appropriate administrative rights to configure ILM CMS by opening Certification Authority in Control Panel. If you do not have administrative rights, all the controls in the Certification Authority console appear dimmed and a warning message tells you that you must be an administrator to change any settings.
Important
You must be a member of the Domain Admins group to troubleshoot most ILM CMS settings, including the CLM agent accounts, the service connection point, and CA modules. You must be a member of the Enterprise Admins group to troubleshoot and configure profile templates.
Install all critical updates and security updates for Windows
Some updates might be required for ILM CMS to function properly.
To ensure that you have all critical updates and security updates
- Click Start, point to All Programs, click Windows Update, and then follow the instructions that appear on your screen.
Update all your software, including non-Microsoft software
ILM CMS might not function correctly with some programs unless you update the programs with the most recent service pack or software update. Newer versions of many programs, such as antivirus programs, automatically configure ILM CMS, which might solve some problems.
Restart the computer if you are running a server operating system
If you are running any Windows Server 2003 operating system, and you started ILM CMS after you started another program, you must restart your computer. ILM CMS might not be able to track the state of traffic for a program, if you start ILM CMS after you start another program.
Quick Fixes for CLM 2007
The following topics provide quick solutions to problems that you might have when you use ILM CMS:
Bulk Smart Card Issuance Tool returns non-descriptive error when issuing smart card containing a user certificate
Installing CLM 2007 fails because of hardware or software incompatibility on the CLM server
The user running the CLM Configuration Wizard does not have the required group membership
Create database fails when running the CLM configuration wizard
Installing Certificate Lifecycle Manager 2007 Client fails because of hardware or software incompatibility on the client
The configuration wizard fails when configuring the CA Exit Module
You can use this information to solve problems in the same way that you use a frequently asked questions (FAQ) topic to find answers to common questions. Read this topic before you begin any advanced troubleshooting.
Bulk Smart Card Issuance Tool returns non-descriptive error when issuing smart card
If you have configured your registry settings to not allow BaseCSP private key import, you may get the following error when issuing a smart card using the bulk smart card issuance tool:
"Exception from HRESULT: 0x80001600"
This error should read:
"The current settings of Base CSP provider do not allow for private key import"
Installing CLM 2007 fails because of hardware or software incompatibility on the CLM server
If your server hardware does not meet the ILM CMS minimum requirements, the CLM Installation Wizard displays an error message that names the specific component that does not meet the requirements.
Installation most often fails for the following reasons:
You did not install the Microsoft .NET Framework 2.0.
You did not install Internet Information Services (IIS) 6.0.
You do not have at least 40 gigabytes (GB) of hard disk space on the CLM server.
You do not have at least 1,024 megabytes (MB) of RAM on the CLM server.
You are not running Microsoft® Windows Server® 2003, Enterprise Edition or Microsoft® Windows Server® 2003, Datacenter Edition on the CLM server.
For more information about the hardware and software requirements for the CLM server, see Installing and Configuring Certificate Lifecycle Manager 2007 on a Server (https://go.microsoft.com/fwlink/?LinkId=88419), and then check the hardware specifications for each CLM server that you use to ensure that it meets the minimum requirements.
The user running the CLM Configuration Wizard does not have the required group membership
You must run the CLM Configuration Wizard as a user account that is a member of the following groups:
The local Administrators group on the CLM server
The Enterprise Admins group for the domain where the profile templates container is created during configuration
The Domain Admins group for the domain where the service connection point and CLM agent accounts are created during configuration
Create database fails when running the CLM Configuration Wizard
If you receive an error in the CLM configuration wizard during database creation, the cause may be a conflict with the SQL Server collation. The CLM configuration wizard has a dependency that the default collation of the SQL Server is Case Insensitive, as CLM does not support SQL Case Sensitive collations.
CLM officially supports the SQL collation of SQL_Latin1_General_CP1_CI_AS. Verify that the default SQL collation matches the supported collation.
Installing Certificate Lifecycle Manager 2007 Client fails because of hardware or software incompatibility on the CLM client
If the CLM client does not meet the CLM minimum requirements, the CLM Installation Wizard displays an error message that names the specific component that does not meet the requirements.
Installation failures are most often the result of the CLM client not running the required operating system. You can install Certificate Lifecycle Manager 2007 Client only on a computer running Windows XP Service Pack 2.
For more information about hardware and software requirements, see Installing and Configuring Certificate Lifecycle Manager 2007 Client (https://go.microsoft.com/fwlink/?LinkId=88422). Also, check the hardware specifications for each of the computers on which you want to install Certificate Lifecycle Manager 2007 Client to ensure that they meet the minimum requirements.
The configuration wizard fails when configuring the CA Exit Module
In an environment where the CA and CLM are installed on the same machine, and the CA has one or more special characters (! " # % & ’ ( ) * + , / : ; < = > ? [ \ ] ^ ` { | } ), the configuration wizard will be unable to configure the exit module. In this case, even though the CA and CLM are on the same machine, you must manually configure the exit module as you would if the CA were on a remote machine. For more information, see Configure the Exit Module in the CLM 2007 Help.
Troubleshooting CLM 2007 Problems
The following topics provide detailed information about troubleshooting ILM CMS problems:
Solving SQL Server problems
Solving request problems
Solving management policy workflow problems
Solving CLM Web site access problems
Solving CLM agent accounts authentication problems
Solving policy module problems
Solving SQL Server problems
The topics in this section discuss problems that you might have when you use SQL Server and ILM CMS.
ILM CMS is integrated with SQL Server and uses it as its central data store. If ILM CMS encounters a problem when it connects with SQL Server, it does not store completed certificate requests in the CLM database, which can cause management policies to fail.
From the following list, choose the problem that best describes your situation, and then complete the procedures to solve the problem:
CLM 2007 cannot connect to the CLM database
Solving CLM database password problems
CLM 2007 issues certificates to users but does not record them in the CLM database
CLM 2007 cannot connect to the CLM database
The connection to the CLM database is defined by a connection string in the properties of the exit module. The following code sample is from the Web.config file:
Connect Timeout=15;Data Source=SQLDNSName;User ID=CLMUser;Integrated Security=False;Persist Security Info=True;Password=P@sswOrd;Initial Catalog=CLM;
The connection string contains detailed information about how the certification authority connects to the server running the CLM database. Table 1 shows the values in the connection string.
Table 1 CLM database connection string values
Value | Description |
---|---|
Connect Timeout |
Specifies that a connection attempt should time out after 15 seconds. |
Data Source |
Replaces the SQLDNSName placeholder with the DNS name of the server running SQL Server. If you run SQL Server on a local computer, you can use (local) to reference the local SQL Server installation. |
User ID |
Specifies the name of the SQL Server account that you use to authenticate the connection between the exit module and the database. |
Integrated Security |
Specifies whether Integrated Windows authentication should be used. |
Persist Security Info |
Specifies that security information is persistent after the connection to the database is established. |
Password |
Specifies the password that is assigned to the CLMUser account in SQL Server. |
Initial Catalog |
Specifies the name of the CLM database. |
Note
Separate all entries in the connection string with semicolons.
By default, the connection string is stored in the CLM2.Exit registry value on the CA server in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CANAME\ExitModules.
The registry value is protected by Data Protection API (DPAPI) and is referenced in the Web.config file of ILM CMS. In the Web.config file, the following line is referenced:
<add key="CLM.DataAccess.ConnectionString" value=
"protected:Registry,DPAPI;value:HKLM\SOFTWARE\Microsoft\CLM\CertSvc\Enterprise\Config\WebUser\,DBConnectionString" />
Important
If you have to troubleshoot problems with the exit module connection string, or if you have to change which database the ILM CMS connects to temporarily, you can comment out the existing CLM.DataAccess.ConnectionString Web.config entry, and replace value=”value”
with the plaintext connection string.
If you use an incorrect password or SQL DNS name in the connection string, you must edit the connection string to reflect the correct password or DNS name. If you do not know the original password, you might have to use Enterprise Manager in SQL Server to reset the password on the CLMUser account.
To manage the CLM database connection string
Log on to the CLM server with an account that is a member of the Domain Admins group.
Click Start, point to All Programs, point to Microsoft Certificate Lifecycle Manager, and then click Configuration Wizard.
In Configuration Wizard, click Database, and then enter the database connection information.
Click Summary, review your configuration changes, and then click Configure.
Important
You must use the CLM Configuration Wizard if you want to change the value in the connection string for the password for the user account used to connect to the CLM database. Changing the value in the connection string does not change the actual password for the user account. For information about how to change SQL passwords, see Solving CLM database password problems and Change passwords for the SQL Server access accounts.
Solving CLM database password problems
Most SQL access problems are caused by password synchronization problems between SQL Server and ILM CMSor the CA. If your passwords are not synchronized, you must reset the password in SQL Server, ILM CMS, and the CA.
Important
When you edit the connection string in the Certification Authority console, the password appears as plaintext. The actual registry value that stores the connection string is protected by DPAPI.
Important
To reset the password in the connection string, you must run the CLM Configuration Wizard to enter all settings, and then reset the CLMUser account password. You must edit the connection string with a user account that has the Manage CA permission at the CA.
To change the password that a user account uses to connect to the CLM database
Log on the server running SQL Server as the SQL Server database administrator.
Click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager.
Important
You can only use Enterprise Manager to change the password for this user if you use SQL Server Authentication. If you use Integrated Windows authentication, change the password for the user in Group Policy.
In the console tree, expand Microsoft SQL Servers, expand SQL Server Group, expand (local) (Windows NT), expand Security, and then click Logins.
In the details pane, right-click the user account that you use to connect the CLM database, and then click Properties.
In Password, type a new password, and then click OK, and then close Enterprise Manager.
Click Start, point to All Programs, point to Microsoft Certificate Lifecycle Manager, and then click Configuration Wizard.
In Configuration Wizard, click Database, and then enter the database connection information.
Click Summary, review your configuration changes, and then click Configure.
To close the CLM Configuration Wizard, click Finish.
Click Start, point to Administrative Tools, and then click Certification Authority.
In the console tree, right-click the CA, and then click Properties.
In the Properties dialog box, click the Exit Module tab.
Under Exit modules, select Certificate Lifecycle Manager Exit Module, and then click Properties.
In the Configuration Properties dialog box, update the value for the CLM database password to the password that you created in step 5 of this procedure, and then click OK.
In the Properties dialog box, click OK.
Close the Certification Authority console, and then perform an enrollment request to test the database connection.
CLM 2007 issues certificates to users but does not record them in the CLM database
If there is an error in the connection string for the exit module, the workflow might issue a certificate to the user, but fail to record the certificate in the CLM database. This failure prevents you from further managing the profile template in ILM CMS. A member of the Enterprise Admins group must install the CLM Enterprise exit module on the certification authority computer. The exit module reads information from the issued certificate, and then writes the certificate information into the CLM database.
Note
If ILM CMS encounters an error during an internal request, it might return an error message to the user about the failure to write the request to the CLM database. An example of an internal request is when a user tries to access the CLM Web site. If ILM CMS encounters an error during an external request, the error might be recorded in the log file only if you have enabled trace logging. For more information about how to enable trace logging for ILM CMS, see Troubleshooting CLM 2007 Using Advanced Techniques and Tools.
If ILM CMS returns an error in the connection string for the exit module, you must edit the connection string.
To edit the connection string for the exit module
Log on to the CA as an administrator with the Manage CA permission.
Click Start, point to Administrative Tools, and then click Certification Authority.
In the console tree, right-click the CA, and then click Properties.
In the Properties dialog box, click the Exit Module tab.
Under Exit modules, select Certificate Lifecycle Manager Exit Module, and then click Properties.
In the Configuration Properties dialog box, update the value for the CLM database password to the password that you created in step 5 of the procedure, and then click OK.
In the Properties dialog box, click OK.
Close the Certification Authority console, and then perform an enrollment request to test the database connection.
Solving request problems
The topics in this section discuss problems that you might have when you use requests in ILM CMS.
From the following list, choose the problem that best describes your situation, and then complete the procedures to solve the problem:
Certificate managers cannot access the management view of the CLM Web site
Certificate managers cannot manage profile templates
CLM administrators cannot delegate administration for profile templates
Users cannot complete self-service requests
Users cannot initiate requests
Users cannot approve requests
Users cannot execute requests
Users cannot complete requests
Users cannot enroll for certificates on behalf of other users
Unable to access smart card during enrollment with "Unknown card" error on Windows 2000 computer
Certificate managers cannot access the management view of the CLM Web site
To access the management view of the CLM Web site, a user or group must have at least one extended permission. If a user or group cannot access the management view, but should be able to, review your ILM CMS deployment plan and administration policy to see which extended permissions are missing for that user or group. Table 2 to shows the purpose of each extended permission.
Table 2 CLM extended permissions and assignment locations
Extended permission | Description |
---|---|
CLM Audit |
Enables an administrator to generate and display CLM profile templates, define management policies in a profile template, and generate ILM CMS reports. |
CLM Enroll |
Enables an administrator to specify the workflow and the data that ILM CMS collects when it issues certificates using the profile template. Note This extended permission only applies to profile templates. |
CLM Enrollment Agent |
Enables a user or group to request certificates on behalf of another user. The subject of the issued certificate contains the name of the target user, but not the name of the requestor. The enrollment is performed by the Enrollment Agent account on behalf of the user making the request, not by the user or group that is assigned the CLM Enrollment Agent permission. Note Although the Active Directory extended permission is not implemented in ILM CMS, the enrollment agent role in the CLM Web site is functional. |
CLM Request Enroll |
Enables a user to initiate, execute, or complete an enrollment request. |
CLM Request Recover |
Enables a user to initiate encryption key recovery from the CA. The recovery is performed by the Key Recovery Agent account on behalf of the user requesting the operation, not by the user or group that is assigned the CLM Request Recover permission. |
CLM Request Renew |
Enables a user to initiate, execute, or complete a renewal request. The renewal request replaces a user's certificate that will expire soon with a new certificate that has a new validity period. |
CLM Request Revoke |
Enables a user to revoke a certificate before it expires. This might be necessary, if a user’s computer or smart card is compromised or stolen. |
CLM Request Unblock Smart Card |
Enables a certificate manager or administrator to reset a user's personal identification number (PIN) for a smart card. This enables key material on a smart card to be reestablished. Note This permission applies to both Unblock and Offline Unblock policies. |
Certificate managers cannot manage profile templates
By default, only members of the Enterprise Admins group are assigned the necessary permissions to create and manage profile templates.
Note
In an environment that has multiple domains, members of the Domain Admins group for the forest root domain can create and manage profile templates only if you created the service connection point in that domain.
Table 3 shows the permission assignments.
Table 3 Profile template delegation permission assignments
Location | Permission assignment |
---|---|
Profile templates container |
Full Control permission on the container and all child objects. |
Service connection point |
Read permission and the CLM Audit extended permission. |
Note
You can assign any of the CLM extended permissions to the delegated user, but the CLM Audit permission provides the lowest level of privilege.
CLM administrators cannot delegate administration for profile templates
You can delegate profile template administration to users who are not administrators. By default, only members of the Enterprise Admins group are assigned the necessary permissions to create and manage profile templates.
Note
In an environment that has multiple domains, members of the Domain Admins group for the forest root domain can create and manage profile templates only if you created the service connection point in that domain.
Table 4 shows the permission assignments.
Table 4 Profile template delegation permission assignments
Location | Permission assignment |
---|---|
Profile templates container |
Full Control permission on the container and all child objects. |
Service connection point |
Read permission and the CLM Audit extended permission. |
Note
You can assign any of the CLM extended permissions to the delegated user, but the CLM Audit permission provides the lowest level of privilege.
Users cannot complete self-service requests
The user who is referenced in the subject of the issued certificate performs the self-service request. When you implement self-service in a management policy workflow, the user initiates, executes, and completes the request. The workflow requires the interaction of other security principals only if the workflow requires one or more approvals.
Important
You do not have to designate the user as a security principal who can initiate the request when you implement self-service requests.
Table 5 shows the permission assignments.
Table 5 Initiation request permission assignments
Location | Permission Assignment |
---|---|
Service connect point |
Read permission. |
Profile template object |
Read permission and the CLM Enroll extended permission. If the user does not have the CLM Enroll extended permission, any enrollment or renewal request fails. |
Certificate template |
Read permission and the CLM Request Enroll extended permission on all certificate templates included in the profile template. In addition, the certificate template must be available at the certification authority designated in the profile template. |
In a management policy |
You must enable self-service requests in the Workflow: General Settings section for management policies on the CLM Web site. |
Users cannot initiate requests
A user or group that is allowed to initiate a request in a management policy initiates the request for another user. For example, an organization might want a user to phone Help Desk to unblock a smart card. You can designate a Help Desk operator to initiate requests on behalf of users who call the Help Desk. To allow a group of users to initiate requests on behalf of other users, you must assign that group Read permission and the CLM Request Unblock Smart Card extended permission at the service connection point.
Table 6 shows the permission assignments.
Table 6 Initiation request permission assignments
Location | Permission assignment |
---|---|
Service connect point |
Read permission and required CLM extended permissions. |
Profile template object |
|
Group that the user is a member of |
Read permission and the required CLM extended permissions. The group permission allows you to designate the users or group for which a certificate manager can initiate requests. For example, you can allow one certificate manager to initiate requests for the East division and another for the West division. |
In a management policy |
You must designate a user to be a principal in the Workflow: Initiate [RequestType] Requests section for the management policy, where [RequestType] represents the type of request. |
Users cannot approve requests
A user or group that is allowed to initiate a request in a management policy initiates the request for another user. For example, an organization might want a user to phone Help Desk to unblock a smart card. You can designate a Help Desk operator to initiate requests on behalf of users who call the Help Desk. To allow a group of users to initiate requests on behalf of other users, you must assign that group Read permission and the CLM Request Unblock Smart Card extended permission at the service connection point.
Table 7 shows the permission assignments.
Table 7 Approve request permission assignments
Location | Permission assignment |
---|---|
Service connect point |
Read permission and the required CLM extended permissions. |
Profile template object |
|
Group that the user is a member of |
Read permission and the required CLM extended permissions. The group permission allows you to designate the users or group for which a certificate manager can initiate requests. For example, you can allow one certificate manager to initiate requests for the East division and another for the West division. |
In a management policy |
You must designate a user to be a principal in the Workflow: Initiate [RequestType] Requests section, for the management policy, where [RequestType] represents the type of request. |
Users cannot execute requests
A user or group that is allowed to execute a request in a management policy executes the request for the user. You typically use this approach in a registration model where an enrollment agent acts on behalf of the user. For example, an organization might want to centralize the distribution of smart cards. The user who prints the smart card, and then installs the initial certificates on the smart card in a blocked state executes the request. These actions result in the issuance of the smart card certificates and the printing of the smart card.
Table 8 shows the permission assignments.
Table 8 Execute request permission assignments
Location | Permission assignment |
---|---|
Service connect point |
Read permission and required CLM extended permissions. |
Profile template object |
Read permission. If the execution results in certificate requests being submitted to the CA, then you must assign the CLM Enroll extended permission to the user. |
Group that the user is a member of |
Read permission and required CLM extended permissions. |
Certificate template |
Read permission and the CLM Request Enroll extended permission. |
In a management policy |
You must designate a user to be a principal in the Workflow: Initiate [RequestType] Requests section, for the management policy, where [RequestType] represents the type of request. |
Users cannot complete requests
If a workflow is initiated by a certificate manager, or a management policy requires approvals, the user might have to connect to the CLM Web site to complete the request and submit the request to the CA.
Table 9 shows the permission assignments.
Table 9 Execute request permission assignments
Location | Permission assignment |
---|---|
Service connect point |
Read permission. |
Profile template object |
Read permission and the CLM Enroll extended permission. |
Certificate template |
Read permission and the CLM Request Enroll extended permission on all certificate templates in the profile template. |
In a management policy |
A user who completes a request does not require specific assignments in the workflow. As the subject of the certificate, the user is able to complete the request. |
Note
If the user completes the request after another user grants approval or initiates the request, you typically implement one-time passwords, which provide a password to the user. After the user enters the password, he or she can complete the request.
Users cannot enroll for certificates on behalf of other users
When your organization implements an enrollment agent, the certificate manager requests a certificate on behalf of another user. During the management policy workflow, the certificate manager designates which user will get the certificate. ILM CMS places the name for that user in the subject of the certificate.
Table 10 shows the permission assignments.
Table 10 Enrollment request permission assignments
Location | Permission assignment |
---|---|
Service connect point |
CLM Enrollment Agent and CLM Request Enroll extended permissions. |
Profile template object |
Read permission and the CLM Enroll extended permissions. These permissions must be assigned to the users who will have enrollment requests performed for them and the users who will perform the enrollment requests. |
Group that contains the users for whom enrollment requests will be performed |
CLM Enrollment Agent and CLM Request Enroll permissions. |
Certificate template |
Read permission and the CLM Request Enroll extended permission on all certificate templates in the profile template. |
In a management policy |
You must designate a user as a principal in the Workflow: Initiate [RequestType] Requests section, for the management policy, where [RequestType] represents the type of request. |
Unable to access smart card during enrollment with "Unknown card" error on Windows 2000 computer
Some middleware will return the error "Unknown card" during enrollment on a Windows 2000 computer if the user does not have local administrator privileges. The following middleware versions require the user to have local administrator privileges:
AET SafeSign Identity Client version 2.3
Aladdin eToken Runtime Environment version 4.5
Gemplus GemSafe version 5.1
Solving management policy workflow problems
The topics in this section discuss problems that you might have when you use management policy workflow in ILM CMS.
Because a management policy workflow is very detailed, you might have to use advanced troubleshooting techniques and tools to determine the root cause or your management workflow problem. If you do not find a solution to the problem you have in the topics in this section, see Troubleshooting CLM 2007 Using Advanced Techniques and Tools for more information.
Management policy workflow fails in CLM 2007
You might experience the following problems when you define a workflow in a management policy:
Problems assigning permissions
The user might not be able to perform the operation if incorrect permissions are assigned at the one of the following locations:
At the service connection point
On a profile template object
On a group containing the user
On a certificate template
In a management policy
For more information on troubleshooting permission problems, see Solving request problems.
Problems defining workflow logic in a management policy
The workflow must meet specific requirements for approvals, execution, and data collection.
When you define a workflow in a management policy, the following problems are ones you are most likely to encounter:
Problems combining software and smart card certificates in a single profile template
Profile templates cannot support both software and smart card certificates. Two separate profile templates must be created: one for the software certificates and one for the smart card certificates.
Problems adding certificate templates
When you attempt to add a certificate template to the profile template, characters such as quotation marks (“) or apostrophes (‘), cause problems rendering the certificate template listing page. To solve this problem, you must rename the certificate templates in the Active Directory Sites and Services console.
Problems enabling data collection by a certificate manager
To enable data collection by a certificate manager, you must allow the certificate manager to participate in the workflow of the management policy. For example, if you want to enable self-service requests for a management policy, you must enable one or more approvals to allow a certificate manager to intervene in the workflow and collect data.
Problems configuring the number of active profile templates or smart cards
If you are deploying smart cards and wish to either duplicate smart cards or issue temporary smart cards, you must ensure that the number of active smart cards allowed is set to a value of 2 or more. If the number of active smart cards is set to a value of 1, then the issuance of the temporary smart card fails because it would result in two active smart cards.
Solving CLM Web site access problems
The topics in this section discuss problems that you might have when you access the CLM Web site in ILM CMS.
The CLM Web site is the central administration point for managing certificate requests and management policies. Users, certificate managers, and administrators might encounter problems accessing the CLM Web site.
From the following list, choose the problem that best describes your situation, and then complete the procedures to solve the problem:
Internet Explorer does not load the CLM Web site
Users are prompted to install ActiveX controls each time they open the CLM Web site
Users in some domains cannot access the CLM Web site
Certificate managers in some domains cannot view CLM 2007 management functions
Internet Explorer does not load the CLM Web site
On each computer from which you access the CLM Web site, you must add the CLM Web site to the Trusted Sites Web content security zone in Microsoft Internet Explorer®. Because the CLM Web site enforces the use of trusted sites, it does not function correctly if you do not add the CLM Web site to Trusted Sites.
To add the CLM Web site to Trusted Sites in Internet Explorer
Log on to the computer as an administrator.
In Internet Explorer, on the Tools menu, click Internet Options.
In Internet Options, click the Security tab, click Trusted Sites, and then click Sites.
In Trusted Sites, type the address of the CLM Web site, and then click Add.
Click Close, and then click OK.
Users are prompted to install ActiveX controls each time they open the CLM Web site
The default configuration for Trusted Sites prompts the user prior to loading controls that are not marked safe for scripting. Because Certificate Lifecycle Manager 2007 Client is not marked safe for scripting, you must enable Initialize and script ActiveX controls not marked as safe for scripting, if you do not want Internet Explorer to prompt users when a control loads.
To prevent Internet Explorer from prompting users for the client ActiveX control
Log on to the computer as an administrator.
In Internet Explorer, on the Tools menu, click Internet Options.
In Internet Options, click the Security tab, click Trusted Sites, and then click Custom Level.
In the Security Settings - Trusted Sites Zone dialog box, under Initialize and script ActiveX controls not marked as safe for scripting, select Enable, and then click OK.
Users in some domains cannot access the CLM Web site
To determine access to the CLM Web site, you must define permissions at the service connection point. When you run the CLM Configuration Wizard for the first time on a CLM server, the CLM Configuration Wizard proposes a location for the service connection point.
We recommend that you create the service connection point in the domain that hosts the user account of the person installing ILM CMS. Because the account you use to install ILM CMS must be a member of the Enterprise Admins group, this location is often the forest root domain.
You can implement the service connection point in any domain in the forest by changing the Lightweight Directory Access Protocol (LDAP) path. If you want to designate a custom LDAP path, we recommend that you create the path before you run the CLM Configuration Wizard.
Service connection point permissions
If a user, or a group that includes the user, has any CLM extended permissions, that user can access the management view of the CLM Web site. To access the user view of the CLM Web site, the user or group must be assigned Read permission on the service connection point.
Note
You must also assign permission on the Web folder to the Authenticated Users group. The default location for this folder is %ProgramFiles%\Microsoft Certificate Lifecycle Manager\Web.
In an environment that has multiple domains, you must ensure that users from domains other than the domain where the service connection point exists can access the service connection point. To accomplish this, use the following best practices:
Assign service connection point permissions to universal groups.
To allow access to the group, include global groups from each domain in the forest in the membership of the universal groups.
Assign Read permission to the Authenticated Users group.
You typically modify this default permission.
Do not assign service connection point permissions to domain local groups or local groups.
ILM CMS uses the membership of global and universal groups only when access permissions for a user are determined. ILM CMS does not use memberships in domain local groups.
Note
If you deploy multiple instances of ILM CMSin your organization, ensure that all instances point to the same service connection point so that you experience consistent authorization to ILM CMS.
Certificate managers in some domains cannot view CLM 2007 management functions
To determine access to the CLM Web site, you must define permissions at the service connection point. When you run the CLM Configuration Wizard for the first time on a CLM server, the CLM Configuration Wizard proposes a location for the service connection point.
We recommend that you create the service connection point in the domain that hosts the user account of the person installing ILM CMS. Because the account you use to install ILM CMS must be a member of the Enterprise Admins group, this location is often the forest root domain.
You can implement the service connection point in any domain in the forest by changing the LDAP path. If you want to designate a custom LDAP path, we recommend that you create the path before you run the CLM Configuration Wizard.
Service connection point permissions
If a user, or a group that includes the user, has any CLM extended permissions, that user can access the management view of the CLM Web site. To access the user view of the CLM Web site, the user or group must be assigned Read permission on the service connection point.
Note
You must also assign permission on the Web folder to the Authenticated Users group. The default location for this folder is %ProgramFiles%\Microsoft Certificate Lifecycle Manager\Web.
In an environment that has multiple domains, you must ensure that users from domains other than the domain where the service connection point exists can access the service connection point. To accomplish this, use the following best practices:
Assign service connection point permissions to universal groups.
To allow access to the group, include global groups from each domain in the forest in the membership of the universal groups.
Assign Read permission to the Authenticated Users group.
You typically modify this default permission.
Do not assign service connection point permissions to domain local groups or local groups.
ILM CMS uses the membership of global and universal groups only when access permissions for a user are determined. ILM CMS does not use memberships in domain local groups.
Note
If you deploy multiple instances of ILM CMSin your organization, ensure that all instances point to the same service connection point so that you experience consistent authorization to ILM CMS.
Solving CLM agent accounts authentication problems
The topics in this section discuss problems that you might have with authentication in ILM CMS.
From the following list, choose the problem that best describes your situation, and then complete the procedures to solve the problem:
Integrated Windows authentication problems
Certificate-based authentication problems
Integrated Windows authentication problems
Many organizations deploy ILM CMS using Integrated Windows authentication in IIS. Integrated Windows authentication authenticates users, and then sends their credentials automatically to ILM CMS.
For Integrated Windows authentication to succeed, you must use Kerberos authentication, not NTLM authentication. Only Kerberos authentication allows the clmWebPool account to impersonate the current user for transactions.
You can use Table 11 as a checklist to troubleshoot Integrated Windows authentication problems.
Table 11 Checklist for troubleshooting Integrated Windows authentication
Troubleshooting task | Description | |
---|---|---|
Attempt to use only Basic authentication with IIS. |
Determine if you can use Basic authentication by modifying IIS to allow only Basic authentication. If basic authentication works, determine what is preventing successful Kerberos authentication and causing the authentication to use NTLM authentication instead. Firewalls and service principal names (SPNs) that are assigned incorrectly to the CLM server commonly cause this problem. |
|
Check forest membership. |
Ensure that the user account and computer accounts are members of the forest that hosts ILM CMS. Alternatively, establish a cross-forest trust. Kerberos authentication requires that the user account and the computer account be part of Active Directory. |
|
Check client computer operating system compatibility. |
Verify that all computers on which you install the Certificate Lifecycle Manager 2007 Client are running Windows XP SP2. Windows XP SP2 supports Kerberos authentication, but Microsoft Windows ME and Microsoft Windows 98 do not. |
|
Check Trusted Sites in Group Policy or Internet Explorer. |
Verify that the DNS name for the CLM Web site is included in Trusted Sites in Internet Explorer. Only these security zones allow Integrated Windows authentication to succeed. If the DNS name of the CLM Web site is in the Internet zone, then add the DNS name to the Trusted Sites zone on the computer locally or by editing the Group Policy Object settings for the domain. In the Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, and then expand Internet Explorer. The Site to Zone Assignment list is listed in the details pane under Internet Control Panel\Security Page. |
|
Check the security zone assigned to the CLM Web site. |
Verify that the security zone you have selected for the CLM Web site supports Integrated Windows authentication. If someone in your organization changed the default security settings for an Internet Explorer security zone, Integrated Windows authentication might be disabled. |
|
Check whether the account that IIS uses for the CLM application pool is trusted for delegation. |
Verify that the clmWebPool account is trusted for delegation. In Active Directory, enable Advanced Features, view the properties of the user account in Users and Computers, and then verify that the account is trusted for delegation on the Delegation tab of the user account. In addition, the account must be trusted for delegation for any service. For information, see Allow a user to be trusted for delegation (https://go.microsoft.com/fwlink/?LinkId=89812). |
|
Check the SPN status of the account that IIS uses for the CLM application pool. |
Verify that the clmWebPool account has an SPN assigned. An SPN is required to allow the clmWebPool account to impersonate another user. (This is also true for the computer account on the CLM server.) You can verify the SPN assigned to the account by running the following command at the command prompt: The output of the command should return two SPNs:
If these SPNs do not exist or are not set, you must run the CLM Configuration Wizard again. |
Certificate-based authentication problems
You might want to implement certificate-based authentication for accessing the CLM Web site. Certificate-based authentication uses Kerberos authentication, which is also true for Integrated Windows authentication. If you want to use certificate-based authentication, you should ensure that Integrated Windows authentication works before you implement certificate-based authentication.
If Integrated Windows authentication works in your environment validate that your infrastructure supports certificate-based authentication.
You can use Table 12 as a checklist to troubleshoot certificate-based authentication problems.
Table 12 Checklist for troubleshooting certificate-based authentication problems
Task | |
---|---|
Verify that you have enabled Secure Sockets Layer (SSL) for the CLM Web site. If the CLM Web site is not enabled for SSL, you cannot use certificate-based authentication. Verify that you have enabled SSL |
|
Verify that you have enabled certificate-based authentication at the CLM Web site's virtual directory. You must enable or require certificate-based authentication. Verify that you have enabled certificate-based authentication |
|
Verify that you have enabled client certificate mapping. The client certificate mapping service reads the certificate subject alternate name for a user to determine the user principal name (UPN) for that user. Then, the mapping service looks up the UPN in the global catalog to determine the identity of the user. Verify that you have enabled client certificate mapping |
|
Verify that the certificate from the issuing CA is in the NTAuth store. Certificate-based authentication to a Web server requires that the issuing certificate from the CA is designated as an authorized CA for Integrated Windows authentication. Verify that the certificate for the issuing CA is in the NTAuth store |
|
Verify that you have included the UPN for the user in the Subject Alternate Name extension. The CLM Web site uses the UPN that is included in the certificate for a user to determine the identify of that user. If no UPN exists, the CLM Web site cannot identify the user. Verify that the UPN for a user is in the Subject Alternative Name extension |
|
Verify that all forms of authentication are disabled, except certificate-based authentication. If you have configured the CLM Web site to require certificate-based authentication, authentication fails when a user types a user name and password. Verify that you have disabled other forms of authentication |
Verify that you have enabled SSL
Certificate-based authentication is a mutual form of authentication. When a user presents a certificate to validate his or her identity, the Web server presents its SSL certificate to validate its identity. If you have not enabled the CLM Web site for SSL, certificate-based authentication does not occur.
To verify that you have enabled SSL
Log on to the CLM server with an account that is a member of the Domain Admins group.
Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
In the console tree, expand the local computer node, expand Web Sites, right-click the CLM Web site's virtual directory, and then click Properties.
In the Properties dialog box, click the Directory Security tab, and then click Edit under Secure communications.
In the Secure Communications dialog box, ensure that the Require secure channel (SSL) check box is selected, and then click OK.
If you want to require 128-bit encryption, select the Require 128-bit encryption check box.
Verify that you have enabled certificate-based authentication
In the CLM Web site's virtual directory Properties dialog box, you must enable or require certificate-based authentication.
To verify that you have enabled client-based authentication
Log on to the CLM server with an account that is a member of the Domain Admins group.
Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
In the console tree, expand the local computer node, expand Web Sites, right-click CLM Web site's virtual directory, and then click Properties.
In the Properties dialog box, click the Directory Security tab, and then click Edit under Secure communications.
In the Secure Communications dialog box, ensure that either Accept client certificates or Require client certificates is selected, and then click OK.
Verify that you have enabled client certificate mapping
The client certificate mapping service reads the certificate subject alternate name for a user to determine the UPN for that user. The service then looks up the UPN in the global catalog to determine the identity of the user.
To verify that you have enabled client certificate mapping
Log on to the CLM server with an account that is a member of the Domain Admins group.
Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
In the console tree, expand the local computer node, expand Web Sites, right-click the CLM Web site's virtual directory, and then click Properties.
In the Properties dialog box, click the Directory Security tab, and then click Edit under Secure communications.
In the Secure Communications dialog box, ensure that the Enable client certificate mapping check box is selected, and then click OK.
Verify that the certificate for the issuing CA is in the NTAuth store
Certificate-based authentication to a Web server requires you to designate the certificate for the issuing CA as an authorized CA for Integrated Windows authentication. By default, ILM CMS adds the certificate for an enterprise CA to the NTAuth store. You can use the Public Key Infrastructure (PKI) Health tool, Pkiview.msc, to verify that addition.
To verify that the certificate for the issuing CA is in the NTAuth store
Log on to the CLM server with an account that is a member of the Domain Admins group.
Install Windows Server 2003 Resource Kit Tools.
To download it, see Windows Server 2003 Resource Kit Tools (https://go.microsoft.com/fwlink/?LinkId=89763).
Note
Windows Server 2003 Resource Kit Tools requires Windows XP.
Click Start, click Run, type mmc, and then click OK.
On the File menu, click Add/Remove Snap-in.
In Add/Remove Snap-in, click Add.
In the Add Standalone Snap-in dialog box, select Enterprise PKI, and then click Add.
In Add/Remove Snap-in, click OK.
In the console tree, expand Enterprise PKI, and then click the name of the issuing CA.
In the details pane, review the CA Certificate to ensure that the value for status is OK.
Verify that the UPN for a user is in the Subject Alternate Name extension
The CLM Web site uses the UPN that ILM CMS includes in the certificate for a user to determine the identify of that user. If there is no UPN, the CLM Web site cannot identify the user.
To verify that the UPN for a user is in the Subject Alternative Name extension
Log on to the CA as an administrator with the Manage CA permission.
Click Start, point to Administrative Tools, and then click Certification Authority.
In the console tree, expand the CA, and then click Issued Certificates.
In the details pane, right-click a certificate that was issued for a specific user, point to All Tasks, and then click View Attributes/Extensions.
Click the Extensions tab, scroll through the available tags under Request Extensions, and then select Subject Alternative Name.
Verify that the Other Name value is a principal name.
Verify that you have disabled other forms of authentication
If certificate-based authentication fails, and you have enabled other forms of authentication, the user might see a log on dialog box that asks for credentials. If you have configured the CLM Web site to require certificate-based authentication, authentication fails when a user types a user name and password. You can disable all other forms of authentication by modifying the Directory Security authentication properties of the CLM Web site's virtual directory. You make the modifications in the IIS Manager console.
To verify that you have disabled other forms of authentication
Log on to the CLM server with an account that is a member of the Domain Admins group.
Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
In the console tree, expand the local computer node, expand Web Sites, right-click the CLM Web site's virtual directory, and then click Properties.
In the Properties dialog box, click the Directory Security tab, and then click Edit under Authentication and access control.
In the Authentication Methods dialog box, ensure that only Integrated Windows authentication is selected, and then click OK.
In the Properties dialog box, click OK.
Solving policy module problems
The topics in this section discuss problems that you might have with policy modules in ILM CMS.
From the following list, choose the problem that best describes your situation, and then complete the procedures to solve the problem:
Certificate Subject policy module
Subject Alternative Name policy module
SMIME Capabilities policy module
Non-CLM Certificate Requests policy module
Certificate Subject policy module
You might experience the following common problems when you configure the Certificate Subject policy module:
Problems determining the correct certificate template to associate with the policy module.
Problems determining the correct case when referencing an Active Directory or ILM CMS attribute.
Note
You can use the Adsiedit console to validate the spelling and case of an Active Directory attribute. Adsiedit is part of the Windows Support Tools and must be installed from the Windows CD in the Support\Tools folder. For ILM CMS attributes, you can view the CLM database tables in Enterprise Manager to determine the case and spelling.
- Problems referencing an attribute that is not populated for a user in ILM CMS or Active Directory.
Subject Alternative Name policy module
You might experience the following problems when you configure the Subject Alternative Name policy module:
Problems determining the correct certificate template to associate with the policy module.
Problems determining the correct case when referencing an Active Directory attribute.
Problems referencing values tied to Subject Alternative Name name entries when the name entry is configured to be omitted if the value is empty or not available.
Problems typing the correct object identifier associated with a name format other than RFC822 or DNSName.
Smart card field mappings printed incorrectly
When printing smart cards, if any of the print project field mappings map to a non-existent Active Directory field, the fields and values will print incorrectly. Verify that all the print project field mappings use valid Active Directory fields.
SMIME Capabilities policy module
You might experience the following problems when you configure the SMIME Capabilities policy module:
Problems determining the correct certificate template to associate with the policy module.
Problems determining what object identifier is associated with a specific SMIME encryption algorithm.
Problems determining the ASN.1 hex value for an algorithm parameter.
Problems separating multiple algorithms and parameters.
You must use semicolons (;) to separate them.
Non-CLM Certificate Requests policy module
You might experience the following problems when you configure the Non-CLM Certificate Requests policy module:
Problems determining the incorrect certificate template to associate with the policy module.
Mistakes in the connection string prevent the certificates issued by the CA from being written to the CLM database.
Problems determining the incorrect profile template to associate with the external certificate template.
A profile template defines the management policies that ILM CMS enables for the external certificates. For example, you might enable the Revoke and Recover policy for Encrypting File System (EFS) certificates and use auto-enrollment to deploy the certificates.
Problems configuring the maximum number of active certificates to a value of 1.
When the maximum number of active certificates value is set 1, a user cannot renew an existing certificate because the previous certificate and the renewed certificate would both be active. In addition, when the previous certificate expires, ILM CMS does not allow certificate renewal because the previous certificate is no longer valid.
Troubleshooting CLM 2007 Performance Problems
From the following list, choose the problem that best describes your situation, and then complete the procedures to solve the problem:
The CLM Web site is slow to return records from the CLM database
The CLM Web site is slow to display user information and available operations
The CLM Service is started but does not respond
The CLM Web site is slow to return records from the CLM database
The number of certificates and requests available in the management view of the CLM Web site grows as time passes. At some point, performance can suffer because of the number of records that queries and reports return.
The following options are available in the Web.config file to limit the number of certificates or requests that queries and reports return:
Limit the number of records returned by a query to the CLM database.
Limit the number of records returned by a report against the CLM database or Active Directory.
To limit the number of records returned by a query
Open the Web.config file with a text editor.
The default location for the Web.config file is %ProgramFiles%\Microsoft Certificate Lifecycle Manager\Web\Web.config.
Edit the CLM.MaxRecords key by changing the entry for
value
.For example, the following setting limits the number of certificates or requests in a query to the CLM database to 100 per transaction:
<add key="CLM.MaxRecords" value="100" />
To limit the number of records returned by a report
Open the Web.config file with a text editor.
The default location for the Web.config file is %ProgramFiles%\Microsoft Certificate Lifecycle Manager\Web\Web.config.
Edit the CLM.Report.MaxRecords key by changing the entry for
value
.For example, the following setting limits the number of certificates or requests included in a report to 500 records:
<add key="CLM.Report.MaxRecords" value=“500" />
When you have set both CLM.MaxRecords and CLM.Report.MaxRecords keys, the CLM.MaxRecords value can constrain the number of records returned by a report, if its value is less than the CLM.Report.MaxRecords value.
This constraint exists only when the report provides information from the CLM database, not from Active Directory. For example, if you produce a smart card inventory report, ILM CMS collects the data from the CLM database. CLM.MaxRecords constrains the report to 100 records. If the report only includes Active Directory information, then the CLM.Report.MaxRecords value of 500 records is enforced.
The CLM Web site is slow to display user information and available operations
When a certificate manager selects a user account for a management operation, by default, ILM CMS enumerates the following memberships:
All direct and nested group memberships of the certificate manager
All direct and nested group memberships of the user
Important
ILM CMS uses only global and universal group memberships, not domain local and local group memberships.
ILM CMS enumerates these memberships to identify the CLM extended permissions that are assigned to the certificate manager. ILM CMS uses extended permissions to determine what kind of operations a user can complete within ILM CMS.
Sometimes the display of the user and available ILM CMS operations is delayed for long periods. This can occur for the following reasons:
If the user has direct or nested membership in many global or universal groups
You must examine the discretionary access control list for each group to identify what CLM extended permissions ILM CMS has assigned directly to the certificate manager or to groups in which the certificate manager has membership.
If the user has membership in groups, or the security identifier (SID) history references groups, that ILM CMS cannot resolve
ILM CMS reports an exception, if it cannot resolve a group membership assigned to the user.
To prevent delays, you can configure the following options in the Web.config file:
Whether ILM CMS inspects permission assignments for a user, a group, or both a user and a group
Whether ILM CMS filters the list of groups that are searched for membership for both the certificate manager and the user
You set the CLM.RequestSecurity.Flags key in the Web.config file to configure what permission assignments to inspect on the user account. For example, to allow inspection of both user and group permission assignments, you use the following setting:
<add key="CLM.RequestSecurity.Flags" value="UseUser,UseGroups" />
To inspect only group permission assignments, you modify CLM.RequestSecurity.Flags to the use following setting:
<add key="CLM.RequestSecurity.Flags" value="UseGroups" />
If you enable ILM CMS to inspect groups that are assigned CLM extended permissions on the user group, you can define the CLM.RequestSecurity.Groups key to limit which group memberships ILM CMS inspects.
The CLM.RequestSecurity.Groups key lists all group names that ILM CMS inspects when the CLM Web site determines what operations are available to the certificate manager for the selected user. The list is a static list, which means that it does not update automatically, and each entry is separated by commas.
Note
Use a common naming pattern for all groups that are assigned CLM extended permissions on user or group objects. For example, prefix the group names with clm-perm, and then add all group names that have the clm-perm prefix. For example, if you want to inspect only permission assignments to the clm-perm-enroll, clm-perm-enrollagent, and clm-perm-revoke groups for all users when the CLM Web site determines what ILM CMS operations are available, you would use the following line in the Web.config file:
<add key="CLM.RequestSecurity.Groups" value="contoso\clm-perm-enroll,contoso\clm-perm-enrollagent,contoso\clm-perm-revoke" />
Note
The list of groups is typically much longer.
Use the following best practices when filtering groups in the Web.config file:
Review which groups are included in the filter list any time you add a new profile template.
You must add any new management groups that you use in the profile template to the Web.config file.
Use a standard naming format for all groups to which you assign CLM extended permissions on other groups.
Limit nesting in the CLM permission assignment groups.
Do not include a group name that does not exist in the list of filtered groups.
The CLM Service is started but does not respond
If the CLM service appears to have started successfully but does not respond in a normal manner, and you receive the error "Could not stop the Certificate Lifecycle Manager Service service on Local Computer" when you attempt to stop the service, the cause may be that the CLM Service Account is not a member of the local administrators group.
If you have manually configured the CLM Service Account, ensure that the account used is a member of the local administrators group.
-
Troubleshooting CLM 2007 Security Problems
From the following list, choose the problem that best describes your situation, and then complete the procedures to solve the problem:
Change the CLM agent account passwords
Configure SQL Server security settings
Change passwords for the SQL Server access accounts
Change the CLM agent account passwords
The Web.config file lists the CLM agent accounts and passwords that you configured when you used the CLM Configuration Wizard. The Windows registry uses Data Protection API (DPAPI) to protect user account passwords.
Note
The account that you designate as the Web Pool Agent account is not referenced in the Web.config file. CLM uses the account and password that you designate as the identity for the CLM application pool in the IIS configuration of the CLM server. The default account name for the CLM application pool is clmAppPool.
If you have to change which account ILM CMS uses as a CLM agent account, or if you have to change the password for a CLM agent account, you use the CLM Configuration Wizard.
To change the CLM agent account passwords
Log on to the CLM server with an account that is a member of the Domain Admins group.
Click Start, point to All Programs, point to Microsoft Certificate Lifecycle Manager, and then click Configuration Wizard.
On the Welcome to the Configuration Wizard page, and then click CLM Agent Accounts.
Because you have already configured the other ILM CMS components, you can click Agents to go directly to the page to modify the CLM agent accounts.
On the Agents - Microsoft CLM page, clear the Use the CLM default settings check box, and then click Custom Accounts.
In the Agents - Microsoft CLM dialog box, click the tab for the CLM agent that you want to modify.
On the AgentName tab, in the Password box, type a new password.
In the Confirm password box, retype the password.
Complete steps 5 through 7 for each CLM agent password that you want to modify, and then click OK.
On the Agents - Microsoft CLM page, click Summary.
On the Summary page, click Configure.
When you run the CLM Configuration Wizard, ILM CMS adds account information to the Web.config file (ILM CMS adds user names and pointers to the registry keys.) In addition, ILM CMS stores passwords, are protected with DPAPI, in the referenced registry keys.
Configure SQL Server security settings
By default, ILM CMS uses three distinct users and grants them access roles in the CLM database. Table 13 shows the CLM database user accounts.
Table 13 CLM database users
Database user account | Description |
---|---|
dbo |
Acts as the database owner. |
CLMUser |
Used for all CLM server connections to SQL Server. The CLMUser account can access public and ILM CMS data. |
CLMExternal |
Used for the CLM External API connections. |
Table 14 shows how the SQL Server roles that are assigned to the dbo, CLMUser, and CLMExternal database user accounts.
Table 14 CLM database roles
SQL role | dbo | 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 |
You must configure SQL Server access roles and permissions in Enterprise Manager.
To configure SQL Server security settings
Log on the server running SQL Server as the SQL Server database administrator.
Click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager.
In the console tree, expand Microsoft SQL Servers, expand SQL Server Group, expand, (local) Windows NT, expand Databases, and then expand CLMDatabaseName.
The default name for the CLM database is CLM.
In the console tree, click Users.
In the details pane, right-click the user that you want to configure, and then click Properties.
Under Database role membership, select the database roles that you want to permit for the user, deselect the database roles that you want to disallow, and then click OK.
Repeat steps 5 through 6 for each user that you want to configure.
Change passwords for the SQL Server access accounts
When a program must communicate with the CLM database, ILM CMS uses one of two SQL Server accounts to connect to the CLM database. Table 15 shows these database user accounts and their initial passwords.
Table 15 SQL Server accounts for integration with CLM 2007
Database user account | Description |
---|---|
CLMUser |
Used by the CLM server and the CA to connect to the CLM database. The initial password that ILM CMS assigns to the CLMUser account is assigned in the CLM Configuration Wizard. You can also use the CLM Configuration Wizard to change the password, if the user does not have database administrator access to SQL Server. |
CLMExternal |
Used by programs that implement CLM External API calls to populate the CLM database. For example, a custom program might allow ILM CMS to submit multiple certificate requests as external requests into the CLM database by making CLM External API calls. The initial password that ILM CMS assigns to the CLMExternal account is randomized during installation. |
Enterprise Manager stores and manages both of the SQL Server accounts. Enterprise Manager stores the accounts at each local SQL Server. You can modify them in the Logins container at Security\Logins. To reset the CLMExternal password, you must modify it in Enterprise Manager.
Important
You can only use Enterprise Manager to change the password for this user if you use SQL Server Authentication. If you use Integrated Windows authentication, change the password for the user in Group Policy.
To change the CLMExternal password
Log on to the server running SQL Server as the database administrator.
Click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager.
In the console tree, expand Microsoft SQL Servers, expand SQL Server Group, expand, (local) Windows NT, and then expand Security.
In the console tree, click Logins.
In the details pane, right click ServerName\CLMExternalUserName, and then click Properties.
To change the password for the user account that you use to connect to the CLM database
Log on the server running SQL Server as the SQL Server database administrator.
Click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager.
Important
You can only use Enterprise Manager to change the password for this user if you use SQL Server Authentication. If you use Integrated Windows authentication, change the password for the user in Group Policy.
In the console tree, expand Microsoft SQL Servers, expand SQL Server Group, expand (local) (Windows NT), expand Security, and then click Logins.
In the details pane, right-click the user account that ILM CMS uses to connect to the CLM database, and then click Properties.
In Password, type a new password, click OK, and then close Enterprise Manager.
Click Start, point to All Programs, point to Microsoft Certificate Lifecycle Manager, and then click Configuration Wizard.
In Configuration Wizard, click Database, and then enter the database connection information.
Click Summary, review your configuration changes, and then click Configure.
To close the CLM Configuration Wizard, click Finish.
Click Start, point to Administrative Tools, and then click Certification Authority.
In the console tree, right-click the CA, and then click Properties.
In the Properties dialog box, click the Exit Module tab.
Under Exit modules, select Certificate Lifecycle Manager Exit Module, and then click Properties.
In the Configuration Properties dialog box, update the value for the CLM database password to the password that you created in step 5, and then click OK.
In the Properties dialog box, click OK.
Close the Certification Authority console, and then perform an enrollment request to test the database connection.
Troubleshooting CLM 2007 Using Advanced Techniques and Tools
The following topics discuss advanced troubleshooting techniques for ILM CMS:
Enable trace logging for the CLM Service
Enable trace logging for the CLM server components
Enable trace logging for the CLM Configuration Wizard
Enable trace logging for the CA modules
Enable trace logging for document printing
Enable trace logging for Certificate Lifecycle Manager 2007 Client
Enable trace logging for online updates
Enable trace logging for the CLM Service
The Microsoft Certificate Lifecycle Manager 2007 Service (the CLM Service) is an optional component for a CLM server environment that is required to enable temporary smart cards, external certificates, automated renewals, and online updates.
To enable trace logging for the CLM Service
Log on to the CLM server as an administrator.
Locate the Microsoft.CLME2.Service.exe.config file.
The default location for this file is %ProgramFiles%\Microsoft Certificate Lifecycle Manager\Bin\.
Use a text editor to edit the
<system.diagnostics>
section of the Microsoft.CLME2.Service.exe.config file.Table 16 shows the available trace logging levels.
Table 16 Available trace logging levels
Value | Description |
---|---|
0 |
Disables all logging |
1 |
Enables logging error messages only |
3 |
Enables moderate logging |
4 |
Enables detailed logging of all events |
To enable trace logging, you edit the <system.diagnostics>
section of the Microsoft.CLME2.Service.exe.config file to set the values of each switch to the logging levels you want. The following example shows how to implement different levels of logging in Microsoft.CLME2.Service.exe.config:
<system.diagnostics>
<trace autoflush="true" indentsize="2" />
<switches>
<add name="Microsoft.CLME2.Service" value="1" />
<add name="Microsoft.CLME2.BusinessLayer.Worker" value="4" />
</switches>
</system.diagnostics>
Enable trace logging for the CLM server components
To enable trace logging for CLM server components, you edit the Web.config file. Table 17 shows the components for which you can enable trace logging.
Table 17 CLM server components that support trace logging
Component | Reason for enabling trace logging |
---|---|
Microsoft.Security.Principal |
To impersonate users |
Microsoft.Security.Principal.Logon |
To obtain the identities of users when they logon |
Microsoft.Security.Authorization |
To obtain authorization information |
Microsoft.Security.Authorization.Ldap |
To obtain directory attribute queries for the purpose of authorization |
Microsoft.DS |
To obtain directory-related lookups, searches, etc. |
Microsoft.Web.Authentication |
To trace custom authentication of users |
Microsoft.Web.Authentication.Config |
To trace custom authentication configuration settings set in the Web.config file |
Microsoft.CLME2.BusinessLayer |
To trace the general program logic |
Microsoft.CLME2.BusinessLayer.Authz |
To trace access control in the program |
Microsoft.CLME2.BusinessLayer.Principal |
To trace business layer custom authentication |
Microsoft.CLME2.BusinessLayer.SmartCard |
To trace smart card protocol messages between clients and servers |
Microsoft.CLME2.BusinessLayer.Worker |
To trace worker threads plugged into the CLM service |
Microsoft.CLME2.Common |
To trace which configuration settings are loaded from the Web.config file |
Microsoft.CLME2.DataAccess |
To trace what data is read and written to in the database |
Microsoft.CLME2.DataAccess.Ldap |
To trace what data is read and written to from the directory |
Microsoft.CLME2.PrintServer |
To trace when server side printing |
Microsoft.CLME2.Service |
To trace CLM service worker thread execution |
Enabling logging
To enable ILM CMS to sign for the CLM server components, you must edit the <listeners>
section of the Web.config file as follows:
Designate the listener that will capture tracing information.
Commonly, an organization implements the default listener Microsoft.EventLog.Listener.
Designate the log file where ILM CMS sends the trace log output.
For example, ILM CMS can send output to the Clm.txt file at C:\Temp\Clm.txt.
Important
You must assign full control of the folder containing the referenced log file to the Everyone group. In this example, the Everyone group must be assigned Full Control permissions to the C:\Temp folder.
The following code sample shows the Web.config file lines that you use to enable the default Microsoft.EventLog.Listerner, which stores the logging information in the Clm.txt file at C:\Temp\Clm.txt.
<system.diagnostics>
<trace autoflush="true" indentsize="2" >
<listeners>
<add name="Microsoft.EventLog.Listener" type="Microsoft.Diagnostics.SimpleTextWriterTraceListener, Microsoft.Configuration, Version=1.2.0.1, Culture=neutral, PublicKeyToken=a951996bdb7f9221, Custom=null" initializeData="c:\temp\clm.txt"/>
</listeners>
</trace>
Defining component logging levels
In the Web.config file, each trace logging for each CLM server component is either enabled or disabled in the <switches>
section. You define the level of logging on a component-by-component basis.
Table 18 shows the trace logging values that are available in the Web.config file.
Table 18 Trace logging values in the Web.config file
Value | Description |
---|---|
0 |
Disables all logging |
1 |
Enables only logging of error messages |
3 |
Enables moderate logging |
4 |
Enables detailed logging of all events |
The following code sample shows how to define moderate logging for all available components in the Web.config file:
<switches>
<add name="Microsoft.Security.Principal" value=“3” />
<add name="Microsoft.Security.Principal.Logon" value=“3” />
<add name="Microsoft.Security.Authorization" value=“3” />
<add name="Microsoft.Security.Authorization.Ldap" value=“3” />
<add name="Microsoft.DS" value=“3” />
<add name="Microsoft.Web.Authentication" value=“3” />
<add name="Microsoft.Web.Authentication.Config" value=“3” />
<add name="Microsoft.CLME2.BusinessLayer" value=“3” />
<add name="Microsoft.CLME2.BusinessLayer.Authz" value=“3” />
<add name="Microsoft.CLME2.BusinessLayer.SD" value=“3” />
<add name="Microsoft.CLME2.BusinessLayer.Principal" value=“3” />
<add name="Microsoft.CLME2.BusinessLayer.SmartCard" value=“3” />
<add name="Microsoft.CLME2.BusinessLayer.Skg" value=“3” />
<add name="Microsoft.CLME2.BusinessLayer.Events" value=“3” />
<add name="Microsoft.CLME2.BusinessLayer.Encryption" value=“3” />
<add name="Microsoft.CLME2.BusinessLayer.Caching" value=“3” />
<add name="Microsoft.CLME2.Common" value=“3” />
<add name="Microsoft.CLME2.DataAccess" value=“3” />
<add name="Microsoft.CLME2.DataAccess.Ldap" value=“3” />
<add name="MS.Southern.Common" value=“3” />
<add name="MS.Southern.Web" value=“3” />
</switches>
Enable trace logging for the CLM Configuration Wizard
When you configure the CLM server initially, ILM CMS implements trace logging. The CLM Configuration Wizard stores its trace log information in the Config.log file at %ProgramFiles%\Microsoft\CLM\Config.log.
When you have finished installing ILM CMS, we recommend that you review the trace log to ensure that no errors occurred.
Important
When you finish the review, delete the Config.log file which captures in plaintext any passwords that you entered when the CLM Configuration Wizard executed. The captured passwords include CLM agent account passwords and SQL account passwords.
You can change the level of tracing for the CLM Configuration Wizard by editing the Microsoft.CLME2.Config.exe.config file at %ProgramFiles%\Microsoft\CLM\Bin\Microsoft.CLME2.Config.exe.config, and then changing the switch values from the default value of 4. Table 19 shows the values you can use to configure trace logging.
Table 19 Trace logging levels for the CLM Configuration Wizard
Value | Description |
---|---|
0 |
Disables all logging |
1 |
Enables only logging of error messages |
3 |
Enables moderate logging |
4 |
Enables detailed logging of all events |
The following code sample shows the default contents of the Microsoft.CLME2.Config.exe.config file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<trace autoflush="true" indentsize="2" />
<switches>
<add name="Microsoft.Security.Authorization" value=“4” />
<add name="Microsoft.CLME2.Config" value=“4” />
<add name="Microsoft.DS" value=“4” />
<add name="Microsoft.CLME2.DataAccess" value=“4” />
<add name="Microsoft.CLME2.DataAccess.Ldap" value=“4” />
<add name="Microsoft.CLME2.BusinessLayer" value=“4” />
</switches>
</system.diagnostics>
</configuration>
Enable trace logging for the CA modules
To enable tracing for the CLM Enterprise exit module and the CLM policy module at a certification authority, you must edit the registry for each individual module. Enabling trace logging for the exit module and the policy module causes ILM CMS to write the error output to the ILM CMS log in Windows Event Viewer.
Table 20 shows where you must create string values in the registry to enable trace logging for a CA module.
Table 20 Locations for enabling trace logging for the policy and exit modules
CA module | Registry location |
---|---|
Policy module |
Add a string value named CLM2.Policy to the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CAName\PolicyModules Set the string value to the desired logging level listed in table 21, and then restart the CLM Service to apply the trace logging settings. |
Exit module |
Add a string value named Microsoft.CLME2.ExitModule in the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\CertSvc\Configuration\CAName\ExitModules Set the string value to the desired logging level listed in table 21, and then restart the CLM Service to apply the trace logging settings. |
Table 21 shows the trace logging levels that are available for the CA modules.
Table 21 CA module trace logging levels
Value | Description |
---|---|
Null |
Disables all logging |
Info |
Enables only information messages |
Warning |
Enables information and warning messages |
Error |
Enables information, warning, and error messages |
Verbose |
Enables all messages available for the module |
Enable trace logging for document printing
You use the ILM CMS document printing capabilities to print PIN letters and other documents as part of a management policy workflow. To enable tracing for the document printing operations, you must edit the Microsoft.CLM.PrintServer.exe.config file on the CLM server. The default location for this file is %ProgramFiles%\Microsoft\CLM\Bin\.
Table 22 shows the values that are available for logging levels in the Microsoft.CLM. PrintServer.exe.config file.
Table 22 Server trace logging levels for document printing
Value | Description |
---|---|
0 |
Disables all logging |
1 |
Enables logging error messages only |
3 |
Enables moderate logging |
4 |
Enables detailed logging of all events |
To enable trace logging, edit the <system.diagnostics>
section in the Microsoft.CLM.PrintServer.exe.config file so that the value of each switch is set to the desired logging level. The following code sample shows how you can configure trace logging in the PrintServer.exe.config file.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<trace autoflush="true" indentsize="2" />
<switches>
<add name="Microsoft.CLME2.PrintServer" value="3" />
</switches>
</system.diagnostics>
</configuration>
Enable trace logging for Certificate Lifecycle Manager 2007 Client
To enable trace logging for the Certificate Lifecycle Manager 2007 Client, you must edit the registry at a computer where the client is used. Trace logging captures the output from a computer running Certificate Lifecycle Manager 2007 Client to a specified file in the local file system. The level of output is based on a registry setting on the computer.
To define the logging level for Certificate Lifecycle Manager 2007 Client, you must create a DWORD registry value named Log Level in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CLM\v1.0\SmartCardClient registry key. Table 23 shows the DWORD data options.
Table 23 Possible DWORD values for the trace logging
Value | Description |
---|---|
0 |
Disable all logging |
1 |
Only enable Error logging messages |
3 |
Enable trace logging messages |
4 |
Enable debug level logging messages |
In addition to defining the logging level, you must also define a location and name for the log file. To define the log file, you create a string registry value named LogFileName in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CLM\v1.0\SmartCardClient registry key. Set the string value to the path and file name of the log file name, delimited with quotes. For example, you could set the log file name to Scclient.log and place it at this location: C:\Temp\Scclient.log.
HKLM \SOFTWARE\Microsoft\Clm\adk\TraceError\ 'C:\Program Files\Internet Explorer\iexplore.exe'=DWORD:1
HKLM \SOFTWARE\Microsoft\Clm\adk\TraceError\Folder\ ‘C:\Program Files\CLM Path\clmProfileUpdate.exe’ =[the path of the log file](for eample, c:\temp\client.log)
Enable trace logging for online updates
In ILM CMS, Online Update allows an organization to deploy updates to a profile template. You can determine if you have to update profile templates by comparing the version of the profile template deployed on the CLM client with the current version of the profile template, and with the configuration of the Online Update management policy.
To define the logging level for online updates, you must create a string registry value named TraceLevel in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CLM\v1.0\Agent registry key on the computer where you enabled the online update client. Table 23 shows the string data options.
Table 23 Possible trace logging values for online updates
Value | Description |
---|---|
None |
Disables all logging |
Warning |
Enables warning messages only |
Error |
Enables error logging messages |
Verbose |
Enables debug-level logging messages |
ILM CMS writes trace logging information to the Application log on the computer where trace logging is enabled.
Note
You install Online Update by enabling the Online Update component when you install Certificate Lifecycle Manager 2007 Client using the advanced installation option.
Troubleshooting CLM 2007 Language and Localization Issues
Some attribute names in User Search appear in English only.
Only the default attributes are localized into the current language setting automatically. Some displayed attributes are pre-defined in the web.config file and can be configured by the user.
To configure the language of displayed attributes in User Search
Open %programFiles%\Microsoft Certificate Lifecycle Manager\web\web.config for editing.
In the Custom Search Field section, in the key "Clm.UserSearch.DisplayColumn.ActiveDirectoryAttributes", do one of the following:
Modify an existing entry by replacing the display string. For example, replace {User!businessCategory[Business Category]!string} with {User!businessCategory[CustomString]!string}
Add a new entry using the format {User!adAttribute[DescriptNm1]!dataType}
User Search column headings do not appear, or appear in different languages, after changes to preferred Internet Explorer language.
Many language settings for CLM 2007 are stored as cookies in Internet Explorer. To ensure that all these settings appear in the new language, you must delete the previous cookies in Internet Explorer whenever you change languages. For more information about deleting cookies, see Help in Internet Explorer.
Additional Resources
For information about administering CLM, best practices, and known issues, see the following resources:
Using the CLM 2007 Web Site (https://go.microsoft.com/fwlink/?LinkId=89761)
Configuring Profile Templates (https://go.microsoft.com/fwlink/?LinkId=88441)
For general information about how ILM CMS works, see Technical Overview of CLM 2007 (https://go.microsoft.com/fwlink/?LinkId=89760)