Search

14.2. Default Groups

download PDF
A user's privileges are determined by the group (role) membership of the user. There are three groups (roles) that a user can be assigned to:
  • Administrators. This group is given full access to all of the tasks available in the administrative interface.
  • Agents. This group is given full access to all of the tasks available in the agent services interface.
  • Auditors. This group is given access to view the signed audit logs. This group does not have any other privileges.
There is a fourth role that is exclusively created for communication between subsystems. Administrators should never assign a real user to such a role:
  • Enterprise administrators. Each subsystem instance is automatically assigned a subsystem-specific role as an enterprise administrator when it is joined to a security domain during configuration. These roles automatically provide trusted relationships among subsystems in the security domain, so that each subsystem can efficiently carry out interactions with other subsystems.

14.2.1. Administrators

Administrators have permissions to perform all administrative tasks. A user is designated or identified as being an administrator by being added to the Administrators group for the group. Every member of that group has administrative privileges for that instance of Certificate System.
At least one administrator must be defined for each Certificate System instance, but there is no limit to the number of administrators an instance can have. The first administrator entry is created when the instance is configured.
Administrators are authenticated with a simple bind using their Certificate System user ID and password.
Table 14.1. Security Domain User Roles
Role Description
Security Domain Administrators
  • Add and modify users in the security domain's user and group database.
  • Manage the shared trust policies.
  • Manage the access controls on the domain services.
By default, the CA administrator of the CA hosting the domain is assigned as the security domain administrator.
Enterprise CA Administrators
  • Automatically approve any sub-CA, server, and subsystem certificate from any CA in the domain.
  • Register and unregister CA subsystem information in the security domain.
Enterprise KRA Administrators
  • Automatically approve any transport, storage, server, and subsystem certificate from any CA in the domain.
  • Register and unregister KRA subsystem information in the security domain.
  • Push KRA connector information to any CA.
Enterprise OCSP Administrators
  • Automatically approve any OCSP, server, and subsystem certificate from any CA in the domain.
  • Register and unregister OCSP subsystem information in the security domain.
  • Push CRL publishing information to any CA.
Enterprise TKS Administrators
  • Automatically approve any server and subsystem certificate from any CA in the domain.
  • Register and unregister TKS subsystem information in the security domain.
Enterprise TPS Administrators
  • Automatically approve any server and subsystem certificate from any CA in the domain.
  • Register and unregister TPS subsystem information in the security domain.
As necessary, the security domain administrator can manage access controls on the security domain and on the individual subsystems. For example, the security domain administrator can restrict access so that only finance department KRA administrators can set up finance department KRAs.
Enterprise subsystem administrators are given enough privileges to perform operations on the subsystems in the domain. For example, an enterprise CA administrator has the privileges to have sub-CA certificates approved automatically during configuration. Alternatively, a security domain administrator can restrict this right if necessary.

14.2.2. Auditors

An auditor can view the signed audit logs and is created to audit the operation of the system. The auditor cannot administer the server in any way.
An auditor is created by adding a user to the Auditors group and storing the auditor's certificate in the user entry. The auditor's certificate is used to encrypt the private key of the key pair used to sign the audit log.
The Auditors group is set when the subsystem is configured. No auditors are assigned to this group during configuration.
Auditors are authenticated into the administrative console with a simple bind using their UID and password. Once authenticated, auditors can only view the audit logs. They cannot edit other parts of the system.

14.2.3. Agents

Agents are users who have been assigned end-entity certificate and key-management privileges. Agents can access the agent services interface.
Agents are created by assigning a user to the appropriate subsystem agent group and identifying certificates that the agents must use for SSL client authentication to the subsystem for it to service requests from the agents. Each subsystem has its own agent group:
  • The Certificate Manager Agents group.
  • The Key Recovery Authority Agents group.
  • The Online Certificate Status Manager Agents group.
  • The Token Key Service Agents group.
  • The Token Processing System Agents group.
Each Certificate System subsystem has its own agents with roles defined by the subsystem. Each subsystem must have at least one agent, but there is no limit to the number of agents a subsystem can have.
Certificate System identifies and authenticates a user with agent privileges by checking the user's SSL client certificate in its internal database.

14.2.4. Enterprise Groups

Note

No real user should ever be assigned to this group.
During subsystem configuration, every subsystem instance is joined to a security domain. Each subsystem instance is automatically assigned a subsystem-specific role as an enterprise administrator. These roles automatically provide trusted relationships among subsystems in the security domain, so that each subsystem can efficiently carry out interactions with other subsystems. For example, this allows OCSPs to push CRL publishing publishing information to all CAs in the domain, KRAs to push KRA connector information, and CAs to approve certificates generated within the CA automatically.
Enterprise subsystem administrators are given enough privileges to perform operations on the subsystems in the domain. Each subsystem has its own security domain role:
  • Enterprise CA Administrators
  • Enterprise KRA Administrators
  • Enterprise OCSP Administrators
  • Enterprise TKS Administrators
  • Enterprise TPS Administrators
Additionally, there is a Security Domain Administrators group for the CA instance which manages the security domain, access control, users, and trust relationships within the domain.
Each subsystem administrator authenticates to the other subsystems using SSL client authentication with the subsystem certificate issued during configuration by the security domain CA.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.