Red Hat CERTIFICATE SYSTEM 7.3 - ADMINISTRATION Administration Manual page 415

• The Data Recovery Manager 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.
17.1.2.4. Enterprise Groups
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, DRMs 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 DRM 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.
17.1.2.5. Trusted Managers
One subsystem can allow another subsystem to communicate over its agent port and perform certain
functions for that subsystem by forming a trust between the two. The subsystem that is trusted is
called a trusted manager.
NOTE
These trust relationships are unnecessary since all interacting subsystems are within the
same security domain, and the security domain automatically creates similar relationships.
Default Groups
393