Privileged users are users who are designated to perform privileged operations on Netscape Certificate Management System (CMS); these operations are privileged because no one else can perform them. You assign privileged-user status to a user by storing the user's login information in the internal database of Certificate Management System, associating the user's login information with a personal certificate (if the user is an agent or a trusted manager), and granting access permissions to various CMS resources by adding the user to appropriate groups.
Groups and Their Privileges
Setting Up Privileged Users
Changing Privileged-User Information
Deleting a Privileged User
Agents are users (people) who manage the request queues for the Certificate Manager, Registration Manager, and Data Recovery Manager. For details, see "Agents".
Trusted managers are CMS subsystems that are connected to other subsystems and that are trusted to perform certain activities for them. For example, you might set up a Registration Manager to screen end-entity certificate requests for a Certificate Manager. Because the Certificate Manager trusts the Registration Manager, it approves all certificate requests received from this Registration Manager. For details, see "Trusted Managers".
Administrators are users who have been assigned CMS administration privileges--permission to access the CMS window and perform all the system administration tasks defined there. You assign these privileges to users by adding them to the internal database and assigning membership in a group called Administrators that Certificate Management System creates during installation.
For each CMS instance, the server must have at least one administrator. You can also have more than one individual administering the server.
Agents are users who have been assigned end-entity certificate- and key-management privileges. Certificate Management System defines three agent roles, one for each of its subsystems: Certificate Manager agents, Registration Manager agents, and Data Recovery Manager agents.
List certificates
Search for certificates
Revoke end-entity certificates
Manually update certificates and CRLs stored in a publishing directory
Manage key archival and retrieval requests
Figure 7.1 Agents use the HTML forms-based interface called Agent Services
To make a user an agent for a subsystem, one of the things you must do is store the user's client (personal) certificate information in the internal database of the subsystem. For example, if you set up an agent for a Certificate Manager, you store the agent's client certificate in the internal database of that Certificate Manager. Then, when the subsystem receives a request from the agent, it uses this certificate to verify the authenticity of the request before servicing it. For details on how the subsystem verifies the authenticity of a request from an agent, see "Authentication of Agents".
If the CA's certificate is listed but untrusted, follow the instructions in "Installing a New CA Certificate in the Certificate Database" and change the setting to trusted.
The following general guidelines explain how a user can get a client certificate from a public CA and how you can copy that certificate (in base-64 encoded form) to the internal database of the appropriate subsystem:
When the user receives the certificate from the public CA, the user imports the certificate into the web browser that he or she will use to access the subsystem. It is a good idea to ask the user to inform you that the certificate has been installed.
Ask the user to send you the certificate information sent by the public CA. In the information that you receive, locate the user's certificate in base-64 encoded form.
You can also get the user's certificate from the public CA that issued it. Access the public CA site, search for the user's certificate, and locate the certificate in base-64 encoded form. Copy the base-64 encoded certificate, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text file.
You can also get the user's certificate from the public CA that issued it. Access the public CA site, search for the user's certificate, and locate the certificate in base-64 encoded form.
The copied information should look similar to the following example: -----BEGIN CERTIFICATE----- MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRzY2FwZSBDb21td W5pY2F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5M DIyMzE5MDAwMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQ LEwZQZW9wbGUxFzAVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0e TEjMCEGCSqGSIb3DbndgJARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANL ADBIAkEAoYiYgthgtbbnjfngjnjgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBA QDAgCAMA0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeL mD4CP4xzmKdvQ6IqD2q8DBs9lRQu9JYg129oaCLpZfMNTPnMc3WPKO2pWZWUm7waHEtdbo9vSpbJk XTM/2GhWbsO5vLdeOxrPGxihkHgV/vmqCl4HW7AorqGgyfygbhgthgutrhryj -----END CERTIFICATE-----
The copied information should look similar to the following example:
-----BEGIN CERTIFICATE-----
MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRzY2FwZSBDb21td W5pY2F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5M DIyMzE5MDAwMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQ LEwZQZW9wbGUxFzAVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0e TEjMCEGCSqGSIb3DbndgJARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANL ADBIAkEAoYiYgthgtbbnjfngjnjgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBA QDAgCAMA0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeL mD4CP4xzmKdvQ6IqD2q8DBs9lRQu9JYg129oaCLpZfMNTPnMc3WPKO2pWZWUm7waHEtdbo9vSpbJk XTM/2GhWbsO5vLdeOxrPGxihkHgV/vmqCl4HW7AorqGgyfygbhgthgutrhryj
-----END CERTIFICATE-----
When you copy the certificate, be sure to include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines.
The following general instructions explain how a user can get a client certificate from Certificate Management System and how you can copy that certificate (in base-64 encoded form) to the internal database of a subsystem:
Depending on how your Certificate Management System is configured for certificate issuance, one of the following events happen:
If Certificate Management System is configured for automated certification and the request passes authentication and policy checks, the server automatically issues the client certificate to the user.
After the user imports the certificate into the web browser, you need to copy the certificate (in base-64 encoded form) in order to be able to add it to a subsystem's internal database.
Go to the Certificate Management System home page for end entities (by default, it is called End Entity Registration Services).
The default URL for this page is in this form: http://<host_name>:<end_entity_HTTP_port> or https://<host_name>:<end_entity_HTTPS_port> In both cases, the <host_name> must be in this form: <machine_name>.<your_domain>.<domain> For example, the URL may look like this: https://testCA.netscape.com Click the Retrieval tab.
The default URL for this page is in this form:
http://<host_name>:<end_entity_HTTP_port> or
https://<host_name>:<end_entity_HTTPS_port>
In both cases, the <host_name> must be in this form: <machine_name>.<your_domain>.<domain>
For example, the URL may look like this: https://testCA.netscape.com
In the left frame, click either the List Certificates or Search For Certificates link, and search for the user's certificate.
In the page listing the results of your search, click the Details button (next to the corresponding user's entry) to see detailed information about the certificate.
Scroll down to the section named "Installing This Certificate in a Client," which contains the user's certificate in base-64 encoded form.
Copy the base-64 encoded certificate, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text file.
Trusted managers are those CMS subsystems that are connected to other CMS subsystems and that are trusted to perform specific functions for them. In other words, a trusted manager acts as a front end to the subsystem that trusts it, performing specific functions, depending on the subsystem to which it is connected. You establish this trust between the two subsystems by configuring them to function in certain way.
In Certificate Management System, the Registration Manager or Certificate Manager can function as a trusted manager; the Data Recovery Manager cannot function as a trusted manager. You can configure
For example, as illustrated in the figure below, you might deploy one or more Registration Managers to process, approve, and forward certificate signing requests to a Certificate Manager. A Registration Manager to delegate its end-entity interactions to a trusted Registration Manager, for reasons of localizability (proximity to end entities), customizability, and scalability; the Registration Manager trusts the Registration Manager and services all certificate requests sent by this Registration Manager.
For example, as illustrated in the figure below, you might deploy one or more Registration Managers to process, approve, and forward certificate signing requests to a Certificate Manager.
For example, as illustrated in the figure below, you might deploy one or more Registration Managers to forward requests to another Registration Manager in a Registration Manager chain. (The Registration Manager passing the request acts as the client and the one receiving the request acts as the server.) A Data Recovery Manager to delegate its end-entity interactions to a trusted Certificate Manager or Registration Manager for security reasons; the Data Recovery Manager trusts the Certificate Manager or Registration Manager and services all key archival and recovery requests initiated by this subsystem.
For example, as illustrated in the figure below, you might deploy one or more Registration Managers to forward requests to another Registration Manager in a Registration Manager chain. (The Registration Manager passing the request acts as the client and the one receiving the request acts as the server.)
For example, as illustrated in figure below, you might deploy one or more Certificate Managers or Registration Managers to send key archival or recovery requests to a Data Recovery Manager.
Certificate Management System supports proprietary HTTPS connectors for linking CMS subsystems. You can use these connectors to make the following connections:
Registration Manager to Registration Manager
Registration Manager to Data Recovery Manager
Certificate Manager to Data Recovery Manager
Figure 7.2 Connectivity service between a trusted Registration Manager and other subsystems Keep in mind that a trusted manager does not take on the main functions of the subsystem that trusts it. For example, if a Registration Manager is connected to a Certificate Manager, the Registration Manager has no authority to issue (sign) certificates or CRLs. It receives end-entity requests, authenticates them, and forwards them to the Certificate Manager for signing. After receiving a response from the Certificate Manager, it notifies the end entity of the results.
Figure 7.2 Connectivity service between a trusted Registration Manager and other subsystems
Similarly, a Certificate Manager or Registration Manager connected to a Data Recovery Manager has no authority to archive and recover end users' encryption private keys.
You can configure a subsystem to trust one or more managers. You do this by adding these managers as privileged users to the internal database of that subsystem, assigning them memberships in the appropriate group, and identifying the certificates the managers must use for SSL client authentication to the subsystem they report to. For information about adding a trusted manager, see "Setting Up Trusted Managers".
By default, a Registration Manager that has been set up to function as a trusted manager uses its signing certificate for SSL client authentication to the subsystem that trusts it. For information on this certificate, see "Signing Key Pair and Certificate". Similarly, a Certificate Manager that has been set up to function as a trusted manager uses its SSL server certificate for SSL client authentication to the subsystem that trusts it. For information on this certificate, see "SSL Server Key Pair and Certificate".
If the CA's certificate is listed but untrusted, follow the instructions in "Changing the Trust Settings of a CA Certificate" and change the trust setting to trusted.
Groups for Agents
Group for Trusted Managers
During installation, Certificate Management System automatically creates a group called Administrators and adds a user to this group; the server sets the name of this user to the certificate administrator ID (of the CMS administrator) you specified during installation. If you don't remember this name, see the installation worksheet you completed in preparation for installing the system. For example, if you specified admin as the user ID for the CMS administrator, the name of the user in the Administrators group will be admin.
Depending on the components you installed, create one or more privileged users and add them to the appropriate groups. It is recommended that you add at least one more user to the Administrators group. For instructions on creating privileged users and adding them to one or more groups, see "Setting Up Privileged Users".
Depending on the subsystems you chose to install, Certificate Management System automatically creates a combination of the following groups in a CMS instance:
Registration Manager Agents group, if you have installed the Registration Manager
Data Recovery Manager Agents group, if you have installed the Data Recovery Manager
When the Certificate Manager is installed, a group called Certificate Manager Agents is automatically created in its internal database. After installation, this group has a single user entry--when you get the first agent certificate from the Certificate Manager, the server automatically adds the initial administrator as the agent and stores a copy of the agent certificate against that user entry. The user ID for this agent user is the same as the certificate administrator ID (as specified during installation).
When the Registration Manager is installed, a group called Registration Manager Agents is automatically created in its internal database. By default, this group has no entries.
When the Data Recovery Manager is installed, a group called Data Recovery Manager Agents is automatically created in its internal database. By default, this group has no entries.
When the Certificate Manager, Registration Manager, or Data Recovery Manager is installed, a group called Trusted Managers is automatically created in its internal database. By default, this group has no entries.
Setting Up Agents
Setting Up Trusted Managers
You need at least one administrator for each instance of Certificate Management System. To understand the role of an administrator, see "Administrators".
Step 2. Add the Information to the Internal Database
Note the user's corporate information, such as name, email address, and phone number.
To add the information to the internal database of a CMS instance:
Click Users and Groups.
The Users tab appears. Click Add.
The Users tab appears.
The Edit User Information window appears. Specify information as appropriate:
The Edit User Information window appears.
User ID. Type a user ID or login name for the user. The ID can be an alphanumeric string of up to 255 characters. Give this ID to the user. The user is required to enter this ID in the login screen of the CMS window; see "Accessing the CMS Window".
Full name. Type the user's full name. The user never sees this. This field is to help you keep track of your users. The name can be an alphanumeric string of up to 255 characters. Password. Type a password of up to eight characters for the user. Give this password to the user. The user is required to enter this password in the login screen of the CMS window; see "Accessing the CMS Window".
Confirm password. Retype the password exactly as you typed it in the Password field. Email. Type the user's complete email address. The user never sees this. This field is to help you contact the user, if the need arises. Phone. Type the user's phone number. The user never sees this. This field is to help you contact the user, if the need arises. Group. Select Administrators; for more information about this group, see "Group for Administrators". When you set up a user, you can add him or her to only one group. To add the user to another group, see "Changing Members in a Group".
Click OK.
You are returned to the Users tab. The administrator you just added will be displayed in the list of users. Click Refresh to view the updated configuration.
You are returned to the Users tab. The administrator you just added will be displayed in the list of users.
You need an agent for each subsystem installed in a given CMS instance. To understand the role of an agent, see "Agents". This section explains how to add agents to a CMS instance manually. To import users with agent-level privileges from a Netscape Certificate Server version 1.0x database, see "Appendix A, Migrating from Certificate Server" in the Netscape Certificate Management System Deployment and Installation Guide.
Step 3. Store the Agent's SSL Client Certificate in the Internal Database
Step 4. Check the Certificate Database for the CA Certificate
Before adding an agent to the internal database of a CMS instance:
Make sure the user has one or more client certificates that are currently valid; the certificate must not have expired, been revoked, or been signed by an untrusted authority. If the user does not own a client certificate, either issue the user a certificate or ask the user to get a certificate. For details, see "Agent's Certificate for SSL Client Authentication".
Identify the certificate that the user must use for SSL client authentication to Certificate Management System. You can identify more than one certificate if you want.
Copy this certificate, in base-64 encoded format, to a text file.
The Edit User Information window appears. Specify information as appropriate.
The information you enter here is to help you keep track of your agent users; the user never sees or uses it. The server relies solely on the agent's client certificate (which you will add next) for authentication. User ID. Type the user ID or login name. The ID can be an alphanumeric string of up to 255 characters. Full name. Type the user's full name. The name can be an alphanumeric string of up to 255 characters. Password. You can choose to leave this field blank. Confirm password. You can choose to leave this field blank. Email. Type the user's complete email address. Phone. Type the user's phone number. Group. Choose the appropriate agent group; for more information about this group, see "Groups for Agents". When you set up a user, you can add her or him to only one group. To add the user to another group, see "Changing Members in a Group".
The information you enter here is to help you keep track of your agent users; the user never sees or uses it. The server relies solely on the agent's client certificate (which you will add next) for authentication.
You are returned to the Users tab. The agent you just added will be displayed in the list of users.
Otherwise, save your changes.
You can add the certificate to the internal database later, following the instructions provided in "Changing a Privileged User's Certificate".
To store a copy of an agent's SSL client certificate in the internal database:
The Manage User Certificates window appears. Click Import.
The Manage User Certificates window appears.
The Import Certificate window appears. Click inside the text area, and paste the user's certificate in base-64 encoded form.
The Import Certificate window appears.
Be sure to include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines. Click OK.
Be sure to include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines.
You are returned to the Manage User Certificates window. The certificate you imported should now be listed in this window. To view the certificate you imported, select it and click View.
You are returned to the Manage User Certificates window. The certificate you imported should now be listed in this window.
The certificate information appears. Click Done.
The certificate information appears.
You are returned to the Users tab. Click Refresh to view the updated configuration.
You are returned to the Users tab.
The CA that signed the agent's SSL client certificate must be trusted by the subsystem that services requests from the agent. Make sure that this CA's certificate exists in the subsystem's certificate database (internal or external) and that it is trusted. To check whether the CA's certificate exists in your subsystem's certificate database, follow the instructions in "Viewing the Certificate Database Contents".
You can set up a Registration Manager or Certificate Manager to function as a trusted manager to another CMS instance. This section explains how to do this.
Setting Up a Certificate Manager as a Trusted Manager
You can set up a remote Registration Manager to function as a trusted manager to a Certificate Manager, Registration Manager, or Data Recovery Manager. The setup process involves the following steps:
Step 2. Create a User Entry for the Registration Manager
Step 3. Copy the Registration Manager's Certificate to the Internal Database
Step 5. Configure the Connector Settings
Before setting up a Registration Manager to function as a trusted manager to another CMS subsystem:
Make sure that the Registration Manager has the certificate you want it to use for SSL client authentication to the subsystem that will trust it; by default, the Registration Manager uses its signing certificate for this purpose. The certificate must be currently valid; the certificate must not have expired, been revoked, or been signed by an authority untrusted by the subsystem. For details, see "Trusted Manager's Certificate for SSL Client Authentication".
Locate the certificate in base-64 encoded format. Copy the certificate, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text file.
Identify the subsystem--Certificate Manager, Registration Manager, or Data Recovery Manager--to which you want to connect the Registration Managers. Note details, such as the host name and port number of that subsystem.
If you are planning to connect the Registration Manager to a Certificate Manager, you should keep this in mind: during the installation of a Registration Manager, you generated a signing certificate for the Registration Manager. If you requested the signing certificate from a Certificate Manager, you were given an opportunity to add the Registration Manager as a trusted manager to that Certificate Manager's database. If you chose this option, then the Registration Manager is already set up to function as a trusted manager to that Certificate Manager--in this case, you are not required to go through these steps.
In this step, you create a privileged-user entry for the Registration Manager in the internal database of the subsystem. As a part of creating this entry, you also add the user entry to the Trusted Managers group in order to give the entry access privileges to the agent port of the subsystem.
The information you enter here is to help you keep track of the Registration Manager; the subsystem never uses it. The subsystem relies solely on the Registration Manager's SSL client certificate (which you will add in Step 3) for authentication. User ID. Type the Registration Manager's instance ID (or any other ID that will help you identify the Registration Manager in the list of privileged users). The ID can be an alphanumeric string of up to 255 characters. Full name. Type the full host name of the Registration Manager. The host name can be an alphanumeric string of up to 255 characters. It must be in this form: <machine_name>.<your_domain>.<domain> Password. Leave this field blank. Confirm password. Leave this field blank. Email. Leave this field blank. Phone. Leave this field blank. Group. Select Trusted Managers; for more information about this group, see "Group for Trusted Managers".
The information you enter here is to help you keep track of the Registration Manager; the subsystem never uses it. The subsystem relies solely on the Registration Manager's SSL client certificate (which you will add in Step 3) for authentication.
You are returned to the Users tab. The Registration Manager you just added is displayed in the list of users.
Otherwise, skip to Step 5. You can add the certificate later, following the instructions in "Changing a Privileged User's Certificate".
In this step, you add a copy of the Registration Manager's SSL client authentication certificate to the internal database of the subsystem and associate the certificate with the user entry you created in Step 2.
The Import Certificate window appears. Click inside the text area, and paste the Registration Manager's certificate in base-64 encoded form.
The certificate information appears. Verify that the certificate you added is the correct one. Click Done.
The certificate information appears. Verify that the certificate you added is the correct one.
The issuer of the Registration Manager's certificate that you added in Step 3 must be trusted by the subsystem that services certificate requests approved by the Registration Manager. Make sure that this CA's certificate exists in the subsystem's certificate database (internal) and that it is trusted. To check whether the CA's certificate exists in the subsystem's certificate database, follow the instructions in "Viewing the Certificate Database Contents".
In this step, you configure the connector settings of the Registration Manager. This enables the Registration Manager to utilize the proprietary HTTPS connectors to communicate with the subsystem (following successful SSL client authentication).
In the navigation tree, click Registration Manager.
The General Settings tab appears. Click the Connectors tab.
The General Settings tab appears.
In the "List of connectors" select the connector:
If you are connecting the Registration Manager to another Registration Manager, select Registration Manager Connector and click Edit.
If you are connecting the Registration Manager to a Data Recovery Manager, select Data Recovery Manager Connector and click Edit.
For the purposes of completing these instructions, let us assume you selected Certificate Manager Connector.
The Edit Connector dialog box appears.
Click Remote, and enter the appropriate information:
Host name. Type the full host name of the subsystem that trusts this Registration Manager; in this case, it would be the host name of the Certificate Manager. The Registration Manager uses this name to locate the Certificate Manager. The format for the host name must be as follows: <machine_name>.<your_domain>.<domain> Port number. Type the number of the TCP/IP port at which the Certificate Manager will listen to requests from the trusted Registration Manager. The default port designated for communication between a trusted Registration Manager and a subsystem is the agent's port. See "Agent Port".
<machine_name>.<your_domain>.<domain>
The sample screen above shows how to connect the Registration Manager to a Certificate Manager running on a host called nolan-nt.mcom.com listening for HTTPS requests on port 888. Click OK.
The sample screen above shows how to connect the Registration Manager to a Certificate Manager running on a host called nolan-nt.mcom.com listening for HTTPS requests on port 888.
You are returned to the Connectors tab. To save your changes, click Save.
You are returned to the Connectors tab.
The CMS configuration is modified. If the changes you made require you to restart the server, you will be prompted accordingly. In that case, stop and restart the server.
You can set up a Certificate Manager to function as a trusted manager to a remote Data Recovery Manager. The setup process involves the following steps:
Step 2. Create a User Entry for the Certificate Manager
Step 3. Copy the Certificate Manager's Certificate to the Internal Database
Before setting up a Certificate Manager to function as a trusted manager to a Data Recovery Manager:
Make sure that the Certificate Manager has the certificate you want it to use for SSL client authentication to the Data Recovery Manager that will trust it; by default, the Certificate Manager uses its SSL server certificate for this purpose. The certificate must be currently valid; the certificate must not have expired, been revoked, or been signed by an authority untrusted by the subsystem. For details, see "Trusted Manager's Certificate for SSL Client Authentication".
Identify the Data Recovery Manager to which you want to connect the Certificate Manager. Note details, such as the host name and port number of that Data Recovery Manager.
In this step, you create a privileged-user entry for the Certificate Manager in the internal database of the Data Recovery Manager. As a part of creating this entry, you also add the user entry to the Trusted Managers group in order to give the entry access privileges to the agent port of the Data Recovery Manager.
The information you enter here is to help you keep track of the Certificate Manager; the Data Recovery Manager never uses it. The Data Recovery Manager relies solely on the Certificate Manager's SSL server certificate (which you will add in Step 3) for authentication. User ID. Type the Certificate Manager's instance ID (or any other ID that will help you identify the Certificate Manager in the list of privileged users). The ID can be an alphanumeric string of up to 255 characters. Full name. Type the full host name of the Certificate Manager. The host name can be an alphanumeric string of up to 255 characters. It must be in this form: <machine_name>.<your_domain>.<domain> Password. Leave this field blank. Confirm password. Leave this field blank. Email. Leave this field blank. Phone. Leave this field blank. Group. Select Trusted Managers; for more information about this group, see "Group for Trusted Managers".
The information you enter here is to help you keep track of the Certificate Manager; the Data Recovery Manager never uses it. The Data Recovery Manager relies solely on the Certificate Manager's SSL server certificate (which you will add in Step 3) for authentication.
You are returned to the Users tab. The Certificate Manager you just added is displayed in the list of users.
In this step, you add the Certificate Manager's SSL server certificate to the internal database of the Data Recovery Manager and associate the certificate with the user entry you created in Step 2.
The Import Certificate window appears. Click inside the text area, and paste the Certificate Manager's certificate in base-64 encoded form.
The issuer of the Certificate Manager's certificate that you added in Step 3 must be trusted by the Data Recovery Manager that services the key archival requests initiated by the Certificate Manager. Make sure that this CA's certificate exists in the Data Recovery Manager's certificate database (internal) and that it is trusted. To check whether the CA's certificate exists in the Data Recovery Manager's certificate database, follow the instructions in "Viewing the Certificate Database Contents".
In this step you configure the connector settings of the Certificate Manager. This enables the Certificate Manager to utilize the proprietary HTTPS connectors to communicate with the Data Recovery Manager (following successful SSL client authentication).
In the navigation tree, click Certificate Manager.
In the "List of connectors" select Data Recovery Manager Connector and click Edit.
The Edit Connector dialog box appears. Click the Enable checkbox to the enable the connector configuration.
Host name. Type the full host name of the Data Recovery Manager that trusts this Certificate Manager. The Certificate Manager uses this name to locate the Data Recovery Manager. The format for the host name must be as follows: <machine_name>.<your_domain>.<domain> Port number. Type the number of the TCP/IP port at which the Data Recovery Manager will listen to requests from the trusted Certificate Manager. The port designated for communication between a trusted Certificate Manager and a Data Recovery Manager is the agent port. See "Agent Port".
The sample screen above shows how to connect the Certificate Manager to a Data Recovery Manager running on a host called nolan- nt.netscape.com listening for HTTPS requests at port 8100. Click OK.
The sample screen above shows how to connect the Certificate Manager to a Data Recovery Manager running on a host called nolan- nt.netscape.com listening for HTTPS requests at port 8100.
To add or remove certificates of a privileged user, see "Changing a Privileged User's Certificate".
To change the group membership or access permissions of a privileged user, see "Changing Members in a Group".
To change a privileged user's login information:
The Users tab appears. In the User ID list, select the user you want to edit, and click Edit.
The Edit User Information window appears. Make the appropriate modifications.
If you need details about individual fields, see "Setting Up Privileged Users". Click OK.
If you need details about individual fields, see "Setting Up Privileged Users".
To change a privileged user's certificate:
The Users tab appears. In the User ID list, select the user whose certificate information you want to change, and click Certificates.
The Manage User Certificate window appears. Take the appropriate action:
The Manage User Certificate window appears.
To delete a certificate, select the certificate and click Delete.
To add a new certificate for this user to the internal database, click Import. In the Import Certificate window that appears, paste the new certificate in the text area. Be sure to paste the entire base-64 encoded block, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines. For details on getting the user's certificate, see "Agent's Certificate for SSL Client Authentication".
You can add or remove members from all groups. Keep in mind that the group for administrators must have at least one user entry. For details, see "Groups and Their Privileges".
The Users tab appears. Click the Groups tab.
In the Group Name list, select the group you want to change, and click Edit.
The Edit Group Information window appears. Make the appropriate changes:
The Edit Group Information window appears.
To remove a user from the group, select the user and click Delete.
To add users, click Add User. In the User Selection window that appears, select the users you want to add and click OK. You are returned to the Edit Group Information window.
You are returned to the Groups tab. Click Refresh to view the updated configuration.
You are returned to the Groups tab.
The Users tab appears. In the User ID list, select the user you want to delete, and click Edit.
The Edit User Information window appears. Check the Membership area to see whether the user belongs to any of the groups.
Remove the user from these groups by clicking the Groups tab and following the instructions in "Changing Members in a Group".
Select the user again and click Delete.
When prompted, confirm the deletion.
The user entry is deleted from the internal database. Click Refresh to view the updated configuration.
The user entry is deleted from the internal database.
Previous
