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.
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.siroe.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.
You can also configure the Certificate Manager and Registration Manager to check the revocation status of an agent's certificate the server receives during SSL client authentication; you cannot configure the Data Recovery Manager to check the revocation status of its agents' certificates. The configuration file includes 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).
auths.revocationChecking.bufferSize=5
auths.revocationChecking.ca=ca
auths.revocationChecking.enabled=true
auths.revocationChecking.unknownStateInterval=0
auths.revocationChecking.validityInterval=120
auths.revocationChecking.ra=ra
auths.revocationChecking.kra=kra
Table 7.1 Configuration parameters for checking the revocation status of agents' certificates
Open the configuration file in a text editor; to locate the file, see "Locating the Configuration File".
Locate the parameters mentioned above and edit their values as appropriate.
Save your changes, and close the configuration file.
Start the CMS instance; see "Starting Certificate Management System".
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.)
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 for 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. 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).
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, user ID, email address, and phone number.
To add the information to the internal database of a CMS instance:
In the navigation tree, select Users and Groups.
The Users tab appears on the right pane.
The Select User Type window appears.
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 "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; see "Logging In to 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.
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. 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.
Setting up Agents Using the Manual 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.
Access the end-entity interface.
In the Enrollment tab, under Browser, select Manual.
In the enrollment form that appears, enter sample data and submit the request.
Next, access the Certificate Manager Agent Services interface.
Click List Requests.
In the page that displays, select the "Show pending requests", and click Find.
In the list of certificate signing requests that displays, select the request you submitted.
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.
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.
In the navigation tree, click Users and Groups.
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.
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.
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 Users tab appears.
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 is 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.
The Import Certificate window appears.
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.
The certificate information appears.
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 Content".
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 Registration Manager as a Trusted Manager
Setting Up a Certificate Manager as a Trusted Manager
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".
Similarly, The request-approval form for Registration Manager's signing certificate request includes a checkbox labeled "This certificate is for 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 2. Create a User Entry for the Registration Manager
Step 3. Copy the Registration Manager's Certificate to the Internal Database
Step 5. Configure Registration Manager's 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 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.
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.
You are returned to the Users tab. The Registration Manager you just added appears 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 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 Content".
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, select Registration Manager.
The General Settings tab appears in the right pane.
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.
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>
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.
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
Step 5. Configure Certificate Manager's Connector Settings
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 Users tab appears in the right pane.
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 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".
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, select Certificate Manager.
In the "List of connectors" select Data Recovery Manager Connector and click Edit.
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.
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:
If you need details about individual fields, see "Setting Up Privileged Users".
To change a privileged user's certificate:
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".
In the Group Name list, select the group you want to change, and click Edit.
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.
When prompted, confirm your action.
If you click OK, the user entry is deleted from the internal database.
Previous
