Previous     Contents     Index     Next     
iPlanet Certificate Management System Installation and Setup Guide



Chapter 13   Managing Privileged Users and Groups


Privileged users are users who are designated to perform privileged operations on iPlanet 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.

This chapter describes the types of privileged users you need to set up for a CMS instance, what each user does, how Certificate Management System identifies these users, and how you create and manage these users. The chapter also describes what a group is and discusses the groups that Certificate Management System provides by default.

The chapter has the following sections:



Privileged-User Types and Responsibilities

After you install Certificate Management System, your first task is to set up privileged users. There are three types of privileged users: administrators, agents, and trusted managers.

  • Administrators are users (people) who manage server-specific tasks for the CMS maangers, the Certificate Manager, Registration Manager, Data Recovery Manager, and Online Certificate Status Manager. For details, see "Administrators".

  • Agents are users (people) who manage the request queues for the CMS managers. 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".

The role of a privileged user—whether administrator, agent, or trusted manager—is determined by the group to which the user belongs. This is explained in "Groups and Their Privileges".


Administrators

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.

During installation, Certificate Management System prompts you to provide information for creating the first user entry in the Administrators group. Following installation, therefore, this group has a single user entry. For more information about this group, see "Group for Administrators".

Certificate Management System authenticates users with administrator-level privileges based on its built-in authentication mechanism. This is explained in "Authentication of Administrators".


Agents

Agents are users who have been assigned end-entity certificate- and key-management privileges. Certificate Management System defines four agent roles, one for each of its subsystems: Certificate Manager agents, Registration Manager agents, Data Recovery Manager agents, and Online Certificate Status Manager agents.

Agents interact with the corresponding CMS manager to manage operations such as these:

  • List, approve, and reject pending certificate issuance and renewal requests

  • 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

  • Manually add CRLs to the Online Certificate Status Manager

  • See the list of OCSP requests processed by the Online Certificate Status Manager

For a complete list of agent tasks, see CMS Agent's Guide. To locate this guide, see "Where to Go for Related Information".

All agents perform their tasks through HTML forms-based interfaces. The HTML forms an agent uses to manage a specific subsystem are grouped together and named after the subsystem they represent. For example, the forms-based interface provided for the Certificate Manager is called Certificate Manager Agent Services (see Figure 13-1). For more information, see "Agent Services Interface".

Agents cannot access the CMS window and perform the tasks provided within the Netscape Console framework—unless they are given administrator privileges.

Figure 13-1    Agents use the HTML forms-based interface called Agent Services


Each subsystem installed in a CMS instance must have at least one agent. You can also have more than one individual managing agent services.

You create agents by adding them to the internal database of a CMS instance, assigning membership in the appropriate agent groups, and identifying certificates that the agents must use for SSL client authentication to the subsystem (for it to service requests from the agents). For information about agents' certificates, see "Agent's Certificate for SSL Client Authentication". For information on creating agents for a CMS instance, see "Setting Up Agents".

During installation, Certificate Management System automatically creates appropriate groups with agent privileges for the CMS managers installed; for example, if you install a Certificate Manager and a Data Recovery Manager in a CMS instance, you'll see two agent groups. For more information about these groups, see "Groups for Agents".

Certificate Management System authenticates users with agent-level privileges based on its built-in authentication mechanism. This is explained in "Authentication of Agents".


Agent's Certificate for SSL Client Authentication

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 user you want to set up as an agent does not own a client certificate, ask the user to get one. Depending on your company's PKI policy, the user could get the client certificate from either an internally deployed CA or any public CA.

Keep in mind that the CA that signs your agents' certificates must be trusted by the subsystem that processes requests sent by these agents; for example, if your subsystems are set up not to trust public CAs, your agents should not get their certificates signed by public CAs. Make sure that the CA's certificate exists in the subsystem's certificate or trust database and that the certificate is valid and trusted. To check whether or not the CA's certificate exists in a subsystem's trust database, follow the instructions in "Viewing the Certificate Database Content".


Getting an Agent's Certificate from a Public CA
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:

  1. The user sends a client certificate request to the public CA from the client machine that he or she will use to access the subsystem from the Agent Services interface. It is important that the user generate and submit this request from the machine she or he will use later to access the subsystem, because part of this request process generates a private key on the local machine. Alternatively, if location independence is required, the user can use a hardware token, such as a smart card, to generate and store the key pair (and the certificate when the user receives it from the public CA).

  2. 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.

  3. 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.

  4. Copy the base-64 encoded certificate, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text file.

    The copied information should look similar to the following example:

    -----BEGIN CERTIFICATE-----

    MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pYF
    0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDAw
    MnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFzA
    VBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3DbndgJ
    ARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAoYiYgthgtbbnjfngjn
    jgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEj

    -----END CERTIFICATE-----

  5. Save the text file and use it to store a copy of the certificate in a subsystem's internal database (see "Step 3. Store the Agent's SSL Client Certificate in the Internal Database").


Getting an Agent's Certificate from Certificate Management System
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:

  1. The user sends a client certificate request to Certificate Management System from the client machine that he or she will use to access the subsystem from the Agent Services interface. It is important that the user generate and submit this request from the machine he or she will use later to access the subsystem, because part of this request process generates a private key on the local machine. Alternatively, if location independence is required, the user can also use a hardware token, such as a smart card, to generate and store the key pair (and the certificate when the user receives it from the public CA).

  2. 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 manual certification, an issuing agent must process the request and approve it for issuance. Once the request is approved, the server issues the client certificate to the user.

    • 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.

  3. When the user receives the certificate, the user must import 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.

  4. 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.

To copy an agent's certificate:

  1. Open a web browser window.

  2. 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.siroe.com

  3. Click the Retrieval tab.

  4. In the left frame, click either the List Certificates or Search For Certificates link, and search for the user's certificate.

  5. 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.

  6. Scroll down to the section named "Installing This Certificate in a Client," which contains the user's certificate in base-64 encoded form.

  7. Copy the base-64 encoded certificate, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines, to a text file.

    The copied information should look similar to the following example:

    -----BEGIN CERTIFICATE-----

    MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBCMSAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pY2
    F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDA
    wMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFz
    AVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3Dbndg
    JARYUc3Vwcml5YUBuZXRzY2FwZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAoYiYgthgtbbnjfngj
    njgnagwJjAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAMA0GCSq

    -----END CERTIFICATE-----

  8. Save the text file and use it to store a copy of the certificate in a subsystem's internal database (see "Step 3. Store the Agent's SSL Client Certificate in the Internal Database").


Revocation Status Checking of Agent Certificates

You can configure a Certificate Manager and Registration Manager to check the revocation status of an agent's certificate the server receives during SSL client authentication. You can configure a Data Recovery Manager (or Online Certificate Status Manager) to check the revocation status of its agents' certificates only if you have deployed an OCSP responder and have issued agent certificates with Authority Information Access extension pointing to the OCSP responder. For information about adding Authority Information Access extension to certificates, see "Configuring Policy Rules for a Subsystem". For information about setting up an OCSP responder, see Chapter 21 "Setting Up an OCSP Responder."


Note The CMS configuration file (CMS.cfg) includes a parameter named jss.ocspcheck.enable, which enables you to specify whether a CMS manager should use Online Certificate Status Protocol (OCSP) to verify the revocation status of the certificate it receives as a part of SSL client or server authentication (from clients or servers it makes connections with). If you change the value of this parameter to true, the CMS manager reads the Authority Information Access extension in the certificate and verifies the revocation status of the certificate from the OCSP responder specified in the extension.


The configuration files of both Certificate Manager and Registration Manager include parameters that enable you to specify whether the server should do the revocation checking and if it should, at what interval. Note that the revocation-status verification works for only those agent certificates that have been issued by the Certificate Manager (and not by any third-party CAs).

The configuration parameters pertaining to this feature of the Certificate Manager are as follows:

auths.revocationChecking.bufferSize=5
auths.revocationChecking.ca=ca
auths.revocationChecking.enabled=true
auths.revocationChecking.unknownStateInterval=0
auths.revocationChecking.validityInterval=120

The configuration parameters pertaining to this feature of the Registration Manager are as follows:

auths.revocationChecking.bufferSize=5
auths.revocationChecking.enabled=true
auths.revocationChecking.ra=ra
auths.revocationChecking.unknownStateInterval=0
auths.revocationChecking.validityInterval=120

If you have a Data Recovery Manager installed in the same instance, in addition to the above lines, you'll also notice this line:

auths.revocationChecking.kra=kra

Table 13-1 provides details for the above mentioned parameters.


Table 13-1    Configuration parameters for checking the revocation status of agents' certificates  

Parameter name

Description

revocationChecking.bufferSize  

Specifies the total number of last-checked certificates the server should maintain in its cache. For example, if you configure the buffer size to be 2, the server retains the last two certificates it checked in its cache. By default, the server caches the last 5 certificates.  

revocationChecking.<subsystem>  

Specifies the name of the CMS instance. <subsystem> indicates whether the subsystem is a Certificate Manager (ca) or Registration Manager (ra). You must not change the default values.  

revocationChecking.enabled  

Specifies whether revocation checking is to be is enabled or disabled. To enable the feature, enter true; to disable the feature, enter false. By default, the feature is enabled.  

revocationChecking.
unknownStateInterval  

The default interval is o seconds.  

revocationChecking.
validityInterval  

Specifies how long, in seconds, the cached certificates are considered valid. Be judicious when choosing the interval, especially when configuring a Registration Manager. For example, if you configure the validity period to be 60 seconds, the server discards the certificates in its cache every minute and attempts to retrieve them from their source—the Certificate Manager uses its internal database to retrieve and verify the revocation status of the certificates, whereas the Registration Manager retrieves certificates from its own internal database and then requests the Certificate Manager for the revocation status of these certificates.

The default validity period is 120 seconds (2 minutes).  

To configure a Certificate Manager or Registration Manager to verify the revocation status of its agents' certificates:

  1. Stop the CMS instance; see "Stopping Certificate Management System".

  2. Go to this directory: <server_root>/cert-<instance_id>/config

  3. Open the configuration file (CMS.cfg) in a text editor.

  4. Locate the parameters mentioned above and edit their values as appropriate.

  5. Save your changes, and close the configuration file.

  6. Start the CMS instance; see "Starting Certificate Management System".


Trusted Managers

Trusted managers are those CMS subsystems or managers 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.


Subsystems That Can Function as Trusted Managers

In Certificate Management System, the Registration Manager and Certificate Manager can function as a trusted manager; the Data Recovery Manager and Online Certificate Status Manager cannot function as a trusted manager.

You can configure a Certificate Manager to delegate its end-entity interactions to a trusted Registration Manager, for reasons of localizability (proximity to end entities), customizability, and CA scalability; the Certificate Manager trusts the Registration Manager and signs all certificate signing 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.

You can configure 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 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.)

You can configure 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 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.


Connectors for Linking Trusted Managers

Certificate Management System supports proprietary HTTPS connectors for linking CMS subsystems. You can use these connectors to make the following connections:

  • Registration Manager to Certificate Manager

  • Registration Manager to Registration Manager

  • Registration Manager to Data Recovery Manager

  • Certificate Manager to Data Recovery Manager

  • Certificate Manager to Certificate Manager (in a cloned-CA setup, which is explained in "Cloning a Certificate Manager")

Figure 13-2 illustrates how a trusted Registration Manager communicates with a Certificate Manager.

Figure 13-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.

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".

During installation, Certificate Management System automatically creates a group with trusted manager privileges. For more information about this group, see "Group for Trusted Managers".


Trusted Manager's Certificate for SSL Client Authentication

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".

When you set up a trusted manager for a CMS subsystem, it is important to know which CA has issued the certificate the trusted manager will use for SSL client authentication to the subsystem. The certificate must be issued by a CA that the subsystem trusts. For example, when you set up a trusted Registration Manager for a subsystem, it is important to know which CA has issued the Registration Manager's signing certificate. The certificate must be issued by a CA that the subsystem trusts. If the subsystem is a Certificate Manager, the certificate must be issued by either the Certificate Manager itself or a CA that the Certificate Manager trusts. Similarly, if the Registration Manager is connected to a Data Recovery Manager, the signing certificate must be issued by the CA that the Data Recovery Manager trusts.

The issuer of a Registration Manager's signing certificate is the CA from which you requested the certificate when you installed the Registration Manager. If you have renewed the certificate since installation, the issuer is the CA from which you requested the renewed certificate. Check the signing certificate for its issuer's name; see "Viewing the Certificate Database Content". You can also find this information by looking at the installation worksheet you completed in preparation for installing the system.

Once you learn the issuer's name, verify that this CA's certificate exists in the subsystem's trust database and that the certificate is trusted. To check whether the CA's certificate exists in the subsystem's trust database, follow the instructions in "Viewing the Certificate Database Content".



Groups and Their Privileges

In Certificate Management System, a group refers to a collection of privileged users—administrators, agents, or trusted Registration Managers. Each group has predetermined privileges, based on its access control. All users belonging to a group automatically inherit the privileges of that group.

When you installed Certificate Management System, it automatically created the following groups for the subsystems you installed:

These default groups are created in the internal database of the appropriate CMS instance. They can help you set up your privileged users quickly and easily.

You can add new privileged users to these groups; see "Setting Up Privileged Users". You cannot delete or change the group names. Also, don't change the internal database in which the groups are stored.


Group for Administrators

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 (see ("Administrator"). 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.

Keep in mind that the Administrators group must always contain at least one user entry. This means you can delete the entry that was created in this group during installation, provided you add another user to the group.

After installation, be sure to do the following:

  1. Log in to the CMS window with the administrator ID and password specified during installation.

  2. 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".


Groups for Agents

Depending on the subsystems you chose to install, Certificate Management System automatically creates a combination of the following groups for a CMS instance:

  • Certificate Manager Agents group, if you have installed the Certificate Manager

  • Registration Manager Agents group, if you have installed the Registration Manager

  • Data Recovery Manager Agents group, if you have installed the Data Recovery Manager

  • Online Certificate Status Manager Agents group, if you have installed the Online Certificate Status Manager


Group for Certificate Manager Agents

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 (see "Stage 3. Enrolling for Administrator/Agent Certificate"), 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.

The Certificate Manager Agents group has access rights to agent-specific resources of the Certificate Manager; that is, privileged users you add to this group automatically inherit access rights to the agent port of the Certificate Manager. For information on ports, see "CMS Ports".

After installation, you should add to this group the privileged users to whom you want to assign Certificate Manager agent privileges. All agents who belong to the Certificate Manager Agents group can access the Certificate Manager Agent Services interface; see "Certificate Manager Agent Services".

For an agent to be able to carry on SSL client-authenticated communication with a Certificate Manager, you need to do additional configurations. See "Setting Up Agents".


Group for Registration Manager Agents

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.

The Registration Manager Agents group has access rights to agent-specific resources of the Registration Manager; that is, privileged users you add to this group automatically inherit access rights to the agent ports of the Registration Manager. For information on ports, see "CMS Ports".

After installation, you should add to this group the privileged users to whom you want to assign Registration Manager agent privileges. All agents who belong to the Registration Manager Agents group can access the Registration Manager Agent Services interface; see "Registration Manager Agent Services"

For an agent to be able to do SSL client-authenticated communication with a Registration Manager, you need to do additional configurations. See "Setting Up Agents".


Group for Data Recovery Manager Agents

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. Note that if the Data Recovery Manager is colocated with a Certificate Manager, following installation, this group has a single user entry—when you get the very 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).

The Data Recovery Manager Agents group has access rights to agent-specific resources of the Data Recovery Manager; that is, privileged users you add to this group automatically inherit access rights to the agent ports of the Data Recovery Manager. For information on ports, see "CMS Ports".

After installation, you should add to this group the privileged users to whom you want to assign Data Recovery Manager agent privileges. All agents who belong to the Data Recovery Manager Agents group can access the Data Recovery Manager Agent Services interface; see "Data Recovery Manager Agent Services"

For an agent to be able to carry on SSL client-authenticated communication with a Data Recovery Manager, you need to do additional configurations. See "Setting Up Agents".


Group for Online Certificate Status Manager Agents

When the Online Certificate Status Manager is installed, a group called Online Certificate Status Manager Agents is automatically created in its internal database. By default, this group has no entries.

The Online Certificate Status Manager Agents group has access rights to agent-specific resources of the Online Certificate Status Manager; that is, privileged users you add to this group automatically inherit access rights to the agent ports of the Online Certificate Status Manager. For information on ports, see "CMS Ports".

After installation, you should add to this group the privileged users to whom you want to assign Online Certificate Status Manager agent privileges. All agents who belong to the Online Certificate Status Manager Agents group can access the Online Certificate Status Manager Agent Services interface; see "Online Certificate Status Manager Agent Services Interface"

For an agent to be able to do SSL client-authenticated communication with a Online Certificate Status Manager, you need to do additional configurations. See "Setting Up Agents".


Group for Trusted Managers

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.

The Trusted Managers group has access rights to the corresponding agent gateway; that is, the subsystems you add to this group automatically inherit access rights to the agent port of the corresponding Certificate Manager, Registration Manager, or Data Recovery Manager. For information on ports, see "CMS Ports".

After installation, you should add to this group the subsystems that you want to function as trusted managers. All subsystems that belong to the Trusted Managers group can carry on SSL client-authenticated communication with the subsystem that trusts them and receive responses back.

For a Registration Manager to be able to do SSL client-authenticated communication with a subsystem, you need to do additional configurations. See "Setting Up Trusted Managers".



Setting Up Privileged Users


Setting up privileged users for a CMS instance involves adding the appropriate user information to the internal database of that instance. You can set up any number of privileged users for a CMS instance. If the user is a person (that is, an administrator or agent), you can put that user into as many groups as you like.

This section describes the following tasks:


Setting Up Administrators

You need at least one administrator for each instance of Certificate Management System. To understand the role of an administrator, see "Administrators".

To set up an administrator follow these steps:


Step 1. Find the Required Information

Note the user's corporate information, such as name, user ID, email address, and phone number.


Step 2. Add the Information to the Internal Database

To add the information to the internal database of a CMS instance:

  1. Log in to the CMS window (see "Logging In to the CMS Window").

  2. In the navigation tree, select Users and Groups.

    The Users tab appears on the right pane.

  3. Click Add.

    The Select User Type window appears.

  4. Select Administrator and click OK.

    The Edit User Information window appears.

  5. Specify information as appropriate:

    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 "Logging In to 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.

    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; 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".

  6. Click OK.

    You are returned to the Users tab. The administrator you just added will be displayed in the list of users.

  7. Click Refresh to view the updated configuration.


Setting Up Agents

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.

You can set up agents for a CMS instance in two ways:


Setting up Agents Using the Automated Process

Certificate Management System automates the process of setting up agents if agents request their certificate using the manual enrollment form. The automated process is built into the request-approval form (the page that displays the pending request) in the Agent Services interface and it enables the person who has both Certificate Manager agent and Administrator privileges to create new agents for a CMS instance—that is, the Certificate Manager agent who approves new agents' certificate requests must belong to both Certificate Manager Agents and Administrators groups in the internal database of the Certificate Manager.

The request-approval form includes a checkbox labeled "This certificate is for a <subsystem> agent", where <subsystem> indicates Certificate Manager, Registration Manager, or Data Recovery Manager. Selecting the checkbox indicates that the user who has requested the certificate should be made an agent for the specified subsystem. Selecting the checkbox also requires the Certificate Manager agent to specify a user ID for the new agent.

If the Certificate Manager agent approves the certificate request with the checkbox selected and user ID specified, the server automatically adds the user as an agent to its internal database, copies the user's client certificate to the database, and associates the certificate with the new user's entry.

If you want to test this feature, follow these steps:

  1. Open a web browser window.

  2. Access the end-entity interface.

  3. In the Enrollment tab, under Browser, select Manual.

  4. In the enrollment form that appears, enter sample data and submit the request.

  5. Next, access the Certificate Manager Agent Services interface.

  6. Click List Requests.

  7. In the page that displays, select the "Show pending requests", and click Find.

  8. In the list of certificate signing requests that displays, select the request you submitted.

  9. In the request approval form for user enrollment requests, verify the request. If required, adjust some of the parameters such as the subject name and validity period.

  10. Next, check the box labeled "This certificate is for a Certificate Manager agent", specify a user ID for the new agent, and approve the certificate request.

    The Certificate Manager processes the requests, issues the certificate to the user, automatically adds the user as an agent to its user and group database, copies the user's client certificate to the database, and associates the certificate with the new user's entry.

  11. To verify, log in to the CMS window for the Certificate Manager.

  12. In the navigation tree, click Users and Groups.

  13. In the list of users, you should find the user ID you specified for the new agent. To view the certificate issued to the new agent, select the user ID and click Certificates.


Setting up Agents Using the Manual Process

Typically, you add agents to a CMS instance by manually creating a privileged-user entry for the agent in the corresponding subsystem's user and group database and then add the agent's certificate to the database.

Setting up an agent involves the following steps:


Step 1. Find the Required Information
Before adding an agent to the internal database of a CMS instance:

  • Note the user's corporate information, such as name, login ID, password, email address, and phone number.

  • 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.


Step 2. Add the Information to the Internal Database
To add the information to the internal database of a CMS instance:

  1. Log in to the CMS window (see "Logging In to the CMS Window").

  2. In the navigation tree, select Users and Groups.

    The Users tab appears.

  3. Click Add.

    The Select User Type window appears.

  4. Select Agent and click OK.

    The Edit User Information window appears.

  5. 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.

    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".

  6. Click OK.

    You are returned to the Users tab. The agent you just added is displayed in the list of users.

What you do next depends on whether you have the agent's certificate:


Step 3. Store the Agent's SSL Client Certificate in the Internal Database
To store a copy of an agent's SSL client certificate in the internal database:

  1. In the Users tab, click Certificates.

    The Manage User Certificates window appears.

  2. Click Import.

    The Import Certificate window appears.

  3. Click inside the text area, and paste the user's certificate in base-64 encoded form.

    Be sure to include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines.

  4. Click OK.

    You are returned to the Manage User Certificates window. The certificate you imported should now be listed in this window.

  5. To view the certificate you imported, select it and click View.

    The certificate information appears.

  6. Click Done.

    You are returned to the Users tab.

  7. Click Refresh to view the updated configuration.


Step 4. Check the Certificate Database for the CA Certificate
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 Content".


Setting Up Trusted Managers

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.

To understand the role of a trusted manager in your PKI, see "Trusted Managers".


Setting up Trusted Managers Using the Automated Process

Certificate Management System automates the process of setting up trusted managers. The automated process is built into the request-approval form (the page that displays the pending request) in the Agent Services interface and it enables the person who has both Certificate Manager agent and Administrator privileges to create new trusted managers for a CMS instance—that is, the Certificate Manager agent who approves the subsystems' certificate requests must belong to both the Certificate Manager Agents and Administrators groups in the user and group database of the Certificate Manager. For more information about these groups, see "Groups and Their Privileges".

  • The request-approval form for Certificate Manager's SSL server certificate request includes a checkbox labeled "This certificate is for a Trusted Manager."

  • Similarly, The request-approval form for Registration Manager's signing certificate request includes a checkbox labeled "This certificate is for a Trusted Manager."

If selected, the checkbox indicates that the subsystem that has requested the certificate must be made a trusted manager. Selecting the checkbox also requires the agent to specify an ID for the subsystem that will be set up as a trusted manager.

If the Certificate Manager agent approves the certificate request with the checkbox selected and user ID specified, the server automatically adds the subsystem as a new privileged user to its user and group database, adds the user to the Trusted Managers group, copies the corresponding certificate to the database, and associates the certificate with the new user's entry.

Note that for a Certificate Manager to add the Registration Manager this way, the Certificate Manager agent who approves the Registration Manager signing certificate request must belong to both the Certificate Manager Agents and Administrators groups in the internal database of the Certificate Manager. For more information about these groups, see "Groups and Their Privileges".


Setting Up a Registration Manager as a Trusted Manager

You can set up a remote Registration Manager to function as a trusted manager to a Certificate Manager, another Registration Manager, or a Data Recovery Manager.


Step 1. Find the Required Information
Before setting up a Registration Manager to function as a trusted manager to another CMS subsystem:

  • Note identifying information, such as the instance ID and host name of the Registration Manager.

  • 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 Manager. 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, 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.


Step 2. Create a User Entry for the Registration Manager
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.

To create a user entry with appropriate access privileges for a Registration Manager:

  1. Log in to the CMS window for the subsystem (see "Logging In to the CMS Window"). For the purposes of completing these instructions, let us assume that the subsystem is a Certificate Manager.

  2. In the navigation tree, select Users and Groups.

    The Users tab appears.

  3. Click Add.

    The Select User Type window appears.

  4. Select Trusted Manager and click OK.

    The Edit User Information window appears.

  5. Specify information as appropriate.

    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.

    Host 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 the <machine_name>.<your_domain>.<domain> form.

    Group. Select Trusted Managers; for more information about this group, see "Group for Trusted Managers".

  6. Click OK.

    You are returned to the Users tab. The Registration Manager you just added appears in the list of users.

What you do next depends on whether you have the Registration Manager's SSL client certificate:


Step 3. Copy the Registration Manager's Certificate to the Internal Database
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.

To store the Registration Manager's SSL client certificate in the internal database of the subsystem:

  1. In the Users tab, select the user entry you just added for the Registration Manager and click Certificates.

    The Manage User Certificates window appears.

  2. Click Import.

    The Import Certificate window appears.

  3. Click inside the text area, and paste the Registration Manager's certificate in base-64 encoded form.

    Be sure to include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines.

  4. Click OK.

    You are returned to the Manage User Certificates window. The certificate you imported should now be listed in this window.

  5. To view the certificate you imported, select it and click View.

    The certificate information appears. Verify that the certificate you added is the correct one.

  6. Click Done.

    You are returned to the Users tab.


Step 4. Check the Certificate Database for the CA Certificate
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 Content".


Step 5. Configure Registration Manager's Connector Settings
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).

  1. Log in to the CMS window for the Registration Manager (see "Logging In to the CMS Window").

  2. In the navigation tree, select Registration Manager.

    The General Settings tab appears in the right pane.

  3. Select the Connectors tab.

  4. In the "List of connectors" select the connector:

    • If you are connecting the Registration Manager to a Certificate Manager, select Certificate Manager Connector and click Edit.

    • 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.

  5. Select the Enable checkbox to enable the connector configuration.

  6. Select Remote, and enter the appropriate information:

    Host. 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. 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".

    Timeout. Connection timeout. By default, it is 30 seconds.

    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.

  7. Click OK.

    You are returned to the Connectors tab.

  8. To save your changes, click Save.

    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.


Setting Up a Certificate Manager as a Trusted Manager

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 1. Find the Required Information
Before setting up a Certificate Manager to function as a trusted manager to a Data Recovery Manager:

  • Note identifying information, such as the instance ID and host name of the Certificate 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".

  • 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 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.


Step 2. Create a User Entry for the Certificate 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.

To create a user entry with appropriate access privileges for a Certificate Manager:

  1. Log in to the CMS window for the Data Recovery Manager (see "Logging In to the CMS Window").

  2. In the navigation tree, select Users and Groups.

    The Users tab appears in the right pane.

  3. Click Add.

    The Select User Type window appears.

  4. Select Trusted Manager and click OK.

    The Edit User Information window appears.

  5. Specify information as appropriate.

    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.

    Host name. Type the fully qualified 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>

    Group. Select Trusted Managers; for more information about this group, see "Group for Trusted Managers".

  6. Click OK.

    You are returned to the Users tab. The Certificate Manager you just added is displayed in the list of users.

What you do next depends on whether you have the Certificate Manager's SSL server certificate:


Step 3. Copy the Certificate Manager's Certificate to the Internal Database
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.

To store the Certificate Manager's SSL server certificate in the internal database of the subsystem:

  1. In the Users tab, select the user entry you just added for the Certificate Manager and click Certificates.

    The Manage User Certificates window appears.

  2. Click Import.

    The Import Certificate window appears.

  3. Click inside the text area, and paste the Certificate Manager's certificate in base-64 encoded form.

    Be sure to include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines.

  4. Click OK.

    You are returned to the Manage User Certificates window. The certificate you imported should now be listed in this window.

  5. To view the certificate you imported, select it and click View.

    The certificate information appears. Verify that the certificate you added is the correct one.

  6. Click Done.

    You are returned to the Users tab.


Step 4. Check the Certificate Database for the CA Certificate
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 Content".


Step 5. Configure Certificate Manager's Connector Settings
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).

Note that during the installation of a Data Recovery Manager, you were prompted to specify the host name and port number of the Certificate Manager to which the Data Recovery Manager will be connected. If you specified this information, you are not required to go through this step. However, it is recommended that you verify the connector setting and make sure that the information you entered during installation is correct.

  1. Log in to the CMS window for the Certificate Manager (see "Logging In to the CMS Window").

  2. In the navigation tree, select Certificate Manager.

    The General Settings tab appears in the right pane.

  3. Select the Connectors tab.

  4. In the "List of connectors" select Data Recovery Manager Connector and click Edit.

    The Edit Connector dialog box appears.

  5. Select the Enable checkbox to the enable the connector configuration.

  6. Select Remote, and enter the appropriate information:

    Host. 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 in the <machine_name>.<your_domain>.<domain> form.

    Port. 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".

    Timeout. Connection timeout. By default, it is 30 seconds.

    The sample screen above shows how to connect the Certificate Manager to a Data Recovery Manager running on a host called testKRA.siroe.com listening for HTTPS requests at port 8000.

  7. Click OK.

    You are returned to the Connectors tab.

  8. To save your changes, click Save.

    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.



Changing Privileged-User Information

You can change privileged-user information in several ways:


Changing a Privileged User's Login Information

To change a privileged user's login information:

  1. Log in to the CMS window (see "Logging In to the CMS Window").

  2. In the navigation tree, select Users and Groups.

    The Users tab appears in the right pane.

  3. In the User ID list, select the user you want to edit, and click Edit.

    The Edit User Information window appears.

  4. Make the appropriate modifications.

    If you need details about individual fields, see "Setting Up Privileged Users".

  5. Click OK.

    You are returned to the Users tab.

  6. Click Refresh to view the updated configuration.


Changing a Privileged User's Certificate

To change a privileged user's certificate:

  1. Log in to the CMS window (see "Logging In to the CMS Window").

  2. In the navigation tree, select Users and Groups.

    The Users tab appears in the right pane.

  3. In the User ID list, select the user whose certificate information you want to change, and click Certificates.

    The Manage User Certificate window appears.

  4. Take the appropriate action:

    • To view a certificate, select the certificate and click View.

    • 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".

  5. Click Done.

    You are returned to the Users tab.

  6. Click Refresh to view the updated configuration.


Changing Members in a Group

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".

To change a group's members:

  1. Log in to the CMS window (see "Logging In to the CMS Window").

  2. In the navigation tree, select Users and Groups.

    The Users tab appears in the right pane.

  3. Click the Groups tab.

  4. In the Group Name list, select the group you want to change, and click Edit.

    The Edit Group Information window appears.

  5. Make the appropriate changes:

    • To change the group description, type a new description in the "Group description" field.

    • 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.

  6. Click OK when you are done with the changes.

    You are returned to the Groups tab.

  7. Click Refresh to view the updated configuration.



Deleting a Privileged User

You can delete privileged users from the internal database. Deleting a user from the internal database deletes that user from all groups to which the user belongs. If you want to delete a user from specific groups, you should modify the appropriate groups; for details, see "Changing Members in a Group".

To delete a privileged user from the internal database:

  1. Log in to the CMS window (see "Logging In to the CMS Window").

  2. In the navigation tree, select Users and Groups.

    The Users tab appears in the right pane.

  3. In the User ID list, select the user you want to delete, and click Delete.

  4. When prompted, confirm your action.

    If you click OK, the user entry is deleted from the internal database.

  5. Click Refresh to view the updated configuration.


Previous     Contents     Index     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated April 02, 2001