13.4. Managing Users and Groups for a CA, OCSP, DRM, or TKS

Many of the operations that users can perform are dictated by the groups that they belong to; for instance, agents for the CA manage certificates and profiles, while administrators manage CA server configuration.
Four subsystems — the CA, OCSP, DRM, and TKS — use the Java administrative console to manage groups and users. The other two — the RA and TPS — have web-based admin services, and users and groups are configured through their web services pages.

13.4.1. Managing Groups

13.4.1.1. Creating a New Group

  1. Log into the administrative console. 
    pkiconsole https://server.example.com:admin_port/subsystem_type
  2. Select Users and Groups from the navigation menu on the left.
  3. Select the Groups tab.
  4. Click Edit, and fill in the group information.
    It is only possible to add users who already exist in the internal database.
  5. Edit the ACLs to grant the group privileges. See Section 13.7.3, “Editing ACLs” for more information. If no ACIs are added to the ACLs for the group, the group will have no access permissions to any part of Certificate System.

13.4.1.2. Changing Members in a Group

Members can be added or deleted from all groups. The group for administrators must have at least one user entry.
  1. Log into the administrative console.
  2. Select Users and Groups from the navigation tree on the left.
  3. Click the Groups tab.
  4. Select the group from the list of names, and click Edit.
  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. Select the users to add from the dialog box, and click OK.

13.4.2. Managing Users (Administrators, Agents, and Auditors)

The users for each subsystem are maintained separately. Just because a person is an administrator in one subsystem does not mean that person has any rights (or even a user entry) for another subsystem. Users can be configured and, with their user certificates, trusted as agents, administrators, or auditors for a subsystem.

13.4.2.1. Creating Users

  1. Log into the administrative console. 
    pkiconsole https://server.example.com:admin_port/subsystem_type
  2. In the Configuration tab, select Users and Groups. Click Add.
  3. Fill in the information in the Edit User Information dialog.
    Most of the information is standard user information, such as the user's name, email address, and password. This window also contains a field called User State, which can contain any string, which is used to add additional information about the user; most basically, this field can show whether this is an active user.
  4. Select the group to which the user will belong. The user's group membership determines what privileges the user has. Assign agents, administrators, and auditors to the appropriate subsystem group.
  5. Store the user's certificate.
    1. Request a user certificate through the CA or RA end-entities service pages.
    2. If auto-enrollment is not configured for the user profile, then approve the certificate request.
    3. Retrieve the certificate using the URL provided in the notification email, and copy the base-64 encoded certificate to a local file or to the clipboard.
    4. Select the new user entry, and click Certificates.
    5. Click Import, and paste in the base-64 encoded certificate.

13.4.2.2. Changing a Certificate System User's Certificate

  1. Log into the administrative console.
  2. Select Users and Groups.
  3. Select the user to edit from the list of user IDs, and click Certificates.
  4. Click Import to add the new certificate.
  5. In the Import Certificate window, paste the new certificate in the text area. Include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines.

13.4.2.3. Renewing Administrator, Agent, and Auditor User Certificates

There are two methods of renewing a certificate. Regenerating the certificate takes its original key and its original profile and request, and recreates an identical key with a new validity period and expiration date. Re-keying a certificate resubmits the initial certificate request to the original profile, but generates a new key pair. Administrator certificates can be renewed by being re-keyed.
Each subsystem has a default administrative user that was created at the time the subsystem was created. A new certificate can be requested for this user before their original one expires, using one of the default renewal profiles.
Certificates for administrative users can be renewed directly in the end user enrollment forms, using the serial number of the original certificate.
  1. Renew the admin user certificates in the CA's end users forms, as described in Section 4.8.2, “Certificate-Based Renewal”. This must be the same CA as first issued the certificate (or a clone of it).
    Agent certificates can be renewed by using the certificate-based renewal form in the end entities page. Self-renew user SSL client certificate. This form recognizes and updates the certificate stored in the browser's certificate store directly.

    TIP

    It is also possible to renew the certificate using certutil, as described in Section 15.3.3, “Renewing Certificates Using certutil”. Rather than using the certificate stored in a browser to initiate renewal, certutil uses an input file with the original key.
  2. Add the renewed user certificate to the user entry in the internal LDAP database.
    1. Open the console for the subsystem. 
      pkiconsole https://server.example.com:admin_port/subsystem_type
    2. Configuration | Users and Groups | Users | admin | Certificates | Import
    3. In the Configuration tab, select Users and Groups.
    4. In the Users tab, double-click the user entry with the renewed certificate, and click Certificates.
    5. Click Import, and paste in the base-64 encoded certificate.
    This can also be done by using ldapmodify to add the renewed certification directly to the user entry in the internal LDAP database, by replacing the userCertificate attribute in the user entry, such as uid=admin,ou=people,dc=subsystem-base-DN.

13.4.2.4. Deleting a Certificate System User

Users can be deleted from the internal database. Deleting a user from the internal database deletes that user from all groups to which the user belongs. To remove the user from specific groups, modify the group membership.
Delete a privileged user from the internal database by doing the following:
  1. Log into the administrative console.
  2. Select Users and Groups from the navigation menu on the left.
  3. Select the user from the list of user IDs, and click Delete.
  4. Confirm the delete when prompted.

13.4.3. Preventing Users from Belonging to Multiple Roles

Each group is configured to perform one of three roles: administrator, agent, or auditor. There may be multiple groups in the same role, but there are only those three roles for users of a subsystem.
In many security contexts, it is critical for users to belong to only one type of role (even if they belong to multiple groups). An auditor, for example, should never belong to an administrator or agent group. By default, Certificate System allows users to belong to multiple roles, but this behavior can be restricted by disabling multi-roles and by setting the list of roles which are controlled by the multi-roles setting.
  1. Stop the instance. 
    service instance_name stop
    Always stop a subsystem before editing the subsystem configuration files.
  2. Open the CS.cfg file. 
    vim /var/lib/instance_name/conf/CS.conf
  3. Add or edit the multiroles.enable parameter to set whether to allow users to belong to multiple roles. For security, disable multi-roles by setting the value to false. 
    multiroles.enable=false
  4. Add or edit the list of default roles in Certificate System that are affected by the multi-roles setting. If multi-roles is disabled and a user belongs to one of the roles listed in the multiroles.false.groupEnforceList parameter, then the user cannot be added to any group for any of the other roles in the list. 
    multiroles.false.groupEnforceList=Administrators,Auditors,Trusted Managers,Certificate Manager Agents,Registration Manager Agents,Data Recovery Manager Agents,Online Certificate Status Manager Agents,Token Key Service Manager Agents,Enterprise CA Administrators,Enterprise KRA Adminstrators,Enterprise OCSP Administrators,Enterprise RA Administrators,Enterprise TKS Administrators,Enterprise TPS Administrators,Security Domain Administrators,Subsystem Group
  5. Start the instance. 
    service instance_name start