SupportConsoleDevelopersStart a trialContact

Chapter 11. Managing Certificate System Users and Groups

This chapter explains how to set up authorization for access to the administrative, agent services, and end-entities pages.

11.1. About authorization

Authorization is the process of allowing access to certain tasks associated with the Certificate System. Access can be limited to allow certain tasks to certain areas of the subsystem for certain users or groups and different tasks to different users and groups.

Note

The ACLs associated with each group discussed in this section must not be modified.

Users are specific to the subsystem in which they are created. Each subsystem has its own set of users independent of any other subsystem installed. The users are placed in groups, which can be predefined or user-created. Privileges are assigned to a group through access control lists (ACLs). There are ACLs associated with areas in the administrative console, agent services interface, and end-entities page that perform an authorization check before allowing an operation to proceed. Access control instructions (ACIs) in each of the ACLs are created that specifically allow or deny possible operations for that ACL to specified users, groups, or IP addresses.

The ACLs contain a default set of ACIs for the default groups that are created. These ACIs can be modified to change the privileges of predefined groups or to assign privileges to newly-created groups.

Authorization goes through the following process:

  1. The users authenticate to the interface using either the Certificate System user ID and password or a certificate.
  2. The server authenticates the user either by matching the user ID and password with the one stored in the database or by checking the certificate against one stored in the database. With certificate-based authentication, the server also checks that the certificate is valid and finds the group membership of the user by associating the DN of the certificate with a user and checking the user entry. With password-based authentication, the server checks the password against the user ID and then finds the group membership of the user by associating that user ID with the user ID contained in the group.
  3. When the user tries to perform an operation, the authorization mechanism compares the user ID of the user, the group in which the user belongs, or the IP address of the user to the ACLs set for that user, group, or IP address. If an ACL exists that allows that operation, then the operation proceeds.

11.2. Default groups

The privileges of a user are determined by its group (role) membership. A user can be assigned to three groups (roles):

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

11.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 11.1. Security domain user roles
RoleDescription

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 SubCA, 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 SubCA certificates approved automatically during configuration. Alternatively, a security domain administrator can restrict this right if necessary.

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

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

11.2.4. Enterprise Groups

Important

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.

11.3. Managing users and groups for a CA, OCSP, KRA, 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, KRA, and TKS - use the Java administrative console to manage groups and users. The TPS has web-based admin services, and users and groups are configured through its web service page.

11.3.1. Managing groups

11.3.1.1. Creating a new group

  1. Log into the administrative console. 

    # pkiconsole -d nssdb -n 'optional client cert nickname' https://server.example.com:8443/subsystem_type
    Note

    pkiconsole is being deprecated and will be replaced by a new browser-based UI in a future major release. Although pkiconsole will continue to be available until the replacement UI is released, we encourage using the command line equivalent of pkiconsole at this time, as the pki CLI will continue to be supported and improved upon even when the new browser-based UI becomes available in the future.

  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.

    user4

    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 11.4.3.1, “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.

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

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

11.3.2.1. Creating role users

After you have installed the Certificate System, only the bootstrap user created during the setup exists. In order to create additional role users, you can use the command line or the console. In this section, it is assumed that you have already created the CA admin user (e.g. )jgenie and the CA agent user (e.g. jsmith) by following 7.12 "Create PKI role users" in the Planning, Installation and Deployment Guide (Common Criteria Edition).

Note

For security and audit reasons, create individual accounts for Certificate System users and administrators.

11.3.2.1.1. Enrolling for a user certificate

A role user must possess a personal certificate for authentication purposes. The following procedure describes how a user enrolls for a certificate.

  1. As the user, create a certificate request, which you will then send to a CA agent:

    • If a Key Recovery Authority (KRA) exists in your Certificate System environment: 

      # CRMFPopClient -d /home/example-user/certs_db -p password -n "CN=user_name" -q POP_SUCCESS -b kra.transport -w "AES KeyWrap/Wrapped" -v -o ~/user_name.req -oaep

Initializing security database: /home/example-user/certs_db
archival option enabled
Loading transport certificate
Parsing subject DN
RDN: CN=user_name
Generating key pair: temporary: false
Keypair private key id: 2eb823eea69e01f0892345dd7d7603be5b9ad2ec
Using key wrap algorithm: AES KeyWrap/Wrapped
Creating certificate request
Creating signer
Creating POP
Creating CRMF request
Storing CRMF request into /home/example-user/certs_db/user_name.req
Storing CRMF request key id into /home/example-user/certs_db/user_name.req.keyId

      This command stores the Certificate Signing Request (CSR) in the CRMF format in the ~/user_name.req file. Send the CSR request file to a CA agent.

    • If no Key Recovery Authority (KRA) exists in your Certificate System environment: 

      # PKCS10Client -d /home/example-user/certs_db -p password -n "CN=user_name" -o ~/user_name.req

PKCS10Client: Certificate request written into /home/example-user/certs_db/user_name.req
PKCS10Client: PKCS#10 request key id written into /home/example-user/certs_db/user_name.req.keyId
"

      This command stores the CSR in pkcs10 format in the ~/user_name.req file. Send the CSR request file to a CA agent.

  2. As the CA agent, create an enrollment request using the received CSR file as the input:

    1. Create the ~/cmc.role_crmf.cfg file with the following content: 

      #numRequests: Total number of PKCS10 requests or CRMF requests.
numRequests=1

#input: full path for the PKCS10 request or CRMF request,
#the content must be in Base-64 encoded format
#Multiple files are supported. They must be separated by a space.
input=~/user_name.req

#output: full path for the CMC request in binary format
output=~/cmc.role_crmf.req

#tokenname: name of token where agent signing cert can be found (default is internal)
tokenname=internal

#nickname: nickname for agent certificate which will be used
#to sign the CMC full request.
nickname=jsmith - CA Agent for Example.com

#dbdir: directory for cert9.db, key4.db and pkcs11.txt
dbdir=/home/jsmith/certs_db

#password: password for cert9.db which stores the agent
#certificate
password=password

#format: request format, either pkcs10 or crmf
format=crmf

      Set the parameters based on your environment and the CSR format used in the previous step.

    2. Pass the previously created configuration file to the CMCRequest utility to create the CMC request: 

      # CMCRequest ~/cmc.role_crmf.cfg

  3. As the CA agent jsmith, submit a CMC (Certificate Management over CMS) request:

    1. Create the ~/HttpClient_role_crmf.cfg file with the following content: 

      # #host: host name for the http server
host=server.example.com

#port: CA port number
port=8443

#secure: true for secure connection, false for nonsecure connection
secure=true

#input: full path for the enrollment request, the content must be in binary format
input=~/cmc.role_crmf.req

#output: full path for the response in binary format
output=~/cmc.role_crmf.resp

#tokenname: name of token where SSL client authentication cert can be found (default is internal)
#This parameter will be ignored if secure=false
tokenname=internal

#dbdir: directory for cert9.db, key4.db and pkcs11.txt
#This parameter will be ignored if secure=false
dbdir=/home/jsmith/certs_db

#clientmode: true for client authentication, false for no client authentication
#This parameter will be ignored if secure=false
clientmode=true

#password: password for cert9.db
#This parameter will be ignored if secure=false and clientauth=false
password=password

#nickname: nickname for client certificate
#This parameter will be ignored if clientmode=false
nickname=jsmith - CA Agent for Example.com

#servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert

      Set the parameters based on your environment.

    2. Submit the request to the CA: 

      # HttpClient ~/HttpClient_role_crmf.cfg

Total number of bytes read = 3776
after SSLSocket created, thread token is Internal Key Storage Token
client cert is not null
handshake happened
writing to socket
Total number of bytes read = 2523
MIIJ1wYJKoZIhvcNAQcCoIIJyDCCCcQCAQMxDzANBglghkgBZQMEAgEFADAxBggr
...
The response in data format is stored in ~/cmc.role_crmf.resp

    3. Verify the result: 

      # CMCResponse -i ~/cmc.role_crmf.resp

Certificates:
    Certificate:
    	Data:
        	Version:  v3
        	Serial Number: 0xF9D290B
        	Signature Algorithm: SHA512withEC - 1.2.840.10045.4.3.4
        	Issuer: CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA
        	Validity:
            	Not Before: Friday, January 26, 2024 12:50:37 AM PST America/Los_Angeles
            	Not  After: Wednesday, July 24, 2024 12:50:37 AM PDT America/Los_Angeles
        	Subject: CN=user_name
...
Number of controls is 1
Control #0: CMCStatusInfoV2
   OID: {1 3 6 1 5 5 7 7 25}
   BodyList: 1
   Status: SUCCESS

    4. If the issuance is successful, retrieve the newly issued .crt certificate file: 

      # pki -d /home/jsmith/certs_db -c password -p 8443 -n 'jsmith - CA Agent for Example.com' ca-cert-export 0xF9D290B --output-file ~/user.crt

      The CA agent jsmith then sends the certificate to the requesting user.

  4. As the requesting user, import the certificate received from the CA agent jsmith into the own <user home directory>/certs_db/ database: 

    # certutil -d ~/certs_db -A -t "u,u,u" -n "user_name" -i ~/user.crt
11.3.2.1.2. Creating users using the command line

To create a user using the command line:

  1. As a CA administrator (e.g. jgenie), add a user account. For example, to add the user_name user to the CA: 

    # pki -d /home/jgenie/certs_db -c password -n caadmin ca-user-add user_name --fullName "Example User"

----------------------
Added user "user_name"
----------------------
User ID: user_name
Full name: Example User

    This command uses the CA admin user to add a new account.

  2. Optionally, as a CA administrator (e.g. jgenie), add a user to a group. For example, to add the user_name user to the Certificate Manager Agents group: 

    # pki -d /home/jgenie/certs_db -c password -n "caadmin" ca-user-membership-add user_name "Certificate Manager Agents"

------------------------------------------------
Added membership in "Certificate Manager Agents"
------------------------------------------------
  Group: Certificate Manager Agents

  3. As a CA administrator, add the certificate to the user record:

    1. Add the certificate using its serial number or certificate file to the user account in the Certificate System database. For example, for the user_name user: 

      # pki -d /home/jgenie/certs_db/ -c password -n jgenie ca-user-cert-add user_name --input ~/user.crt

      OR 

      # pki -d /home/jgenie/certs_db/ -c password -n jgenie ca-user-cert-add user_name --serial 0xF9D290B

----------------------------------------------------------------------------------------------------------------------
Added certificate "2;261957899;CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA;CN=user_name"
----------------------------------------------------------------------------------------------------------------------
  Cert ID: 2;261957899;CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA;CN=user_name
  Version: 2
  Serial Number: 0xf9d290b
  Issuer: CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA
  Subject: CN=user_name

    2. Verify that the certificate is added to the user record. For example, to list certificates that contain the user_name user in the certificate’s subject: 

      # pki -d /home/jgenie/certs_db/ -c password -n jgenie ca-user-cert-find user_name

-----------------
1 entries matched
-----------------
  Cert ID: 2;261957899;CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA;CN=user_name
  Version: 2
  Serial Number: 0xf9d290b
  Issuer: CN=CA Signing Certificate,OU=rhcs10-ECC-SubCA,O=Example-rhcs10-ECC-RootCA
  Subject: CN=user_name
----------------------------
Number of entries returned 1
----------------------------
11.3.2.1.3. Creating users using the console

To create a user using the PKI Console:

  1. Log into the administrative console. 

    # pkiconsole -d nssdb -n 'optional client cert nickname' https://server.example.com:8443/subsystem_type
    Note

    pkiconsole is being deprecated and will be replaced by a new browser-based UI in a future major release. Although pkiconsole will continue to be available until the replacement UI is released, we encourage using the command line equivalent of pkiconsole at this time, as the pki CLI will continue to be supported and improved upon even when the new browser-based UI becomes available in the future.

  2. In the Configuration tab, select Users and Groups. Click Add.

  3. Fill in the information in the Edit User Information dialog.

    user2

    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. Add the user’s certificate.

    1. Request a user certificate through the CA end-entities service page.
    2. If auto-enrollment is not configured for the user profile, then approve the certificate request.
    3. Copy the content of user.crt (result from Section 11.3.2.1.1, “Enrolling for a user certificate”) to the clipboard.
    4. Select the new user entry, and click Certificates.
    5. Click Import, and paste in the base-64 encoded certificate.

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

11.3.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 bootstrap 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. For details, see Section 5.4, “Renewing certificates”.

  2. Add the renewed user certificate to the user entry in the internal LDAP database.

    1. Open the console for the subsystem. 

      # pkiconsole -d nssdb -n 'optional client cert nickname' https://server.example.com:admin_port/subsystem_type
      Note

      pkiconsole is being deprecated and will be replaced by a new browser-based UI in a future major release. Although pkiconsole will continue to be available until the replacement UI is released, we encourage using the command line equivalent of pkiconsole at this time, as the pki CLI will continue to be supported and improved upon even when the new browser-based UI becomes available in the future.

    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.

11.3.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 deletion when prompted.

  • Alternatively, you can delete a system user by running the following in the CLI as an administrator: 

    # pki -d /home/jgenie/certs_db -c password -n caadmin ca-user-del user_name
------------------------
Deleted user "user_name"
------------------------

11.4. Configuring access control for users

Authorization is the mechanism that checks whether a user is allowed to perform an operation. Authorization points are defined in certain groups of operations that require an authorization check.

11.4.1. About access control

Access control lists (ACLs) are the mechanisms that specify the authorization to server operations. An ACL exists for each set of operations where an authorization check occurs. Additional operations can be added to a ACL.

The ACL contains access control instructions (ACIs) which specifically allow or deny operations, such as read or modify. The ACI also contains an evaluator expression. The default implementation of ACLs specifies only users, groups, and IP addresses as possible evaluator types. Each ACI in an ACL specifies whether access is allowed or denied, what the specific operator is being allowed or denied, and which users, groups, or IP addresses are being allowed or denied to perform the operation.

The privileges of Certificate System users are changed by changing the access control lists (ACL) that are associated with the group in which the user is a member, for the users themselves, or for the IP address of the user. New groups are assigned access control by adding that group to the access control lists. For example, a new group for administrators who are only authorized to view logs, LogAdmins, can be added to the ACLs relevant to logs to allow read or modify access to this group. If this group is not added to any other ACLs, members of this group only have access to the logs.

The access for a user, group, or IP address is changed by editing the ACI entries in the ACLs. In the ACL interface, each ACI is shown on a line of its own. In this interface window, the ACI has the following syntax: 

allow|deny (operation) user|group|IP="name"
Note

The IP address can be an IPv4 or IPv6 address. An IPv4 address must be in the format n.n.n.n or n.n.n.n,m.m.m.m. For example, 128.21.39.40 or 128.21.39.40,255.255.255.00. An IPv6 address uses a 128-bit namespace, with the IPv6 address separated by colons and the netmask separated by periods. For example, 0:0:0:0:0:0:13.1.68.3, FF01::43, 0:0:0:0:0:0:13.1.68.3,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0, and FF01::43,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF00:0000.

For example, the following is an ACI that allows administrators to perform read operations: 

allow (read) group="Administrators"

An ACI can have more than one operation or action configured. The operations are separated with a comma with no space on either side. For example: 

allow (read,modify) group="Administrators"

An ACI can have more than one group, user, or IP address by separating them with two pipe symbols (||) with a space on either side. For example: 

allow (read) group="Administrators" || group="Auditors"

The administrative console can create or modify ACIs. The interface sets whether to allow or deny the operation in the Allow and Deny field, sets which operations are possible in the Operations field, and then lists the groups, users, or IP addresses being granted or denied access in the Syntax field.

An ACI can either allow or deny an operation for the specified group, user ID, or IP address. Generally, ACIs do not need to be created to deny access. If there are no allow ACIs that include a user ID, group, or IP address, then the group, user ID, or IP address is denied access.

Note

If a user is not explicitly allowed access to any of the operations for a resource, then this user is considered denied; he does not specifically need to be denied access.

For example, user JohnB is a member of the Administrators group. If an ACL has only the following ACL, JohnB is denied any access since he does not match any of the allow ACIs: 

Allow (read,modify) group="Auditors" || user="BrianC"

There usually is no need to include a deny statement. Some situations can arise, however, when it is useful to specify one. For example, JohnB, a member of the Administrators group, has just been fired. It may be necessary to deny access specifically to JohnB if the user cannot be deleted immediately. Another situation is that a user, BrianC, is an administrator, but he should not have the ability to change some resource. Since the Administrators group must access this resource, BrianC can be specifically denied access by creating an ACI that denies this user access.

The allowed rights are the operations which the ACI controls, either by allowing or denying permission to perform the operation. The actions that can be set for an ACL vary depending on the ACL and subsystem. Two common operations that can be defined are read and modify.

The syntax field of the ACI editor sets the evaluator for the expression. The evaluator can specify group, name, and IP address (both IPv4 and IPv6 addresses). These are specified along with the name of the entity set as equals (=) or does not equal (!=).

The syntax to include a group in the ACL is group="groupname". The syntax to exclude a group is group!="groupname", which allows any group except for the group named. For example: 

group="Administrators" || group!="Auditors"

It is also possible to use regular expressions to specify the group, such as using wildcard characters like an asterisk (*). For example: 

group="* Managers"

The syntax to include a user in the ACL is user="userID". The syntax to exclude the user is user!="userID", which allows any user ID except for the user ID named. For example: 

user="BobC" || user!="JaneK"

To specify all users, provide the value anybody. For example: 

user="anybody"

It is also possible to use regular expressions to specify the user names, such as using wildcard characters like an asterisk (*). For example: 

user="*johnson"

The syntax to include an IP address in the ACL is ipaddress="ipaddress". The syntax to exclude an ID address from the ACL is ipaddress!="ipaddress". An IP address is specified using its numeric value; DNS values are not permitted. For example: 

ipaddress="12.33.45.99"
ipaddress!="23.99.09.88"

The IP address can be an IPv4 address, as shown above, or IPv6 address. An IPv4 address has the format n.n.n.n or n.n.n.n,m.m.m.m with the netmask. An IPv6 address uses a 128-bit namespace, with the IPv6 address separated by colons and the netmask separated by periods. For example: 

ipaddress="0:0:0:0:0:0:13.1.68.3"

It is also possible to use regular expressions to specify the IP address, such as using wildcard characters like an asterisk (*). For example: 

ipaddress="12.33.45.*"

It is possible to create a string with more than one value by separating each value with two pipe characters (||) with a space on either side. For example: 

user="BobC" || group="Auditors" || group="Administrators"

11.4.2. Changing the access control settings for the subsystem

For instruction on how to configure this feature by editing the CS.cfg file, see 9.2.3.13 Changing the Access Control Settings for the Subsystem in the Planning, Installation and Deployment Guide (Common Criteria Edition).

11.4.3. Adding ACLs

ACLs are stored in the internal database and can only be modified in the administrative console.

To add a new ACL:

  1. Log into the administrative console.

    Note

    pkiconsole is being deprecated and will be replaced by a new browser-based UI in a future major release. Although pkiconsole will continue to be available until the replacement UI is released, we encourage using the command line equivalent of pkiconsole at this time, as the pki CLI will continue to be supported and improved upon even when the new browser-based UI becomes available in the future.

  2. Select Access Control List.

    acl
  3. Click Add to open the Access Control Editor.

  4. Fill the Resource name and Available rights fields.

    acl add

  5. To add an access control instruction (ACI), click Add, and supply the ACI information.

    acl2
    • Select the allow or deny radio button from the Access field to allow or deny the operation to the groups, users, or IP addresses specified. For more information about allowing or denying access, see Section 11.4.1, “About access control”.
    • Set the rights. The available options are read and modify. To select both, hold the Ctrl or Shift button while selecting the entries.
    • Specify the user, group, or IP address that will be granted or denied access in the Syntax field. See Section 11.4.1, “About access control” for details on syntax.
  6. Click OK to return to the Access Control Editor window.
  7. Click OK to store the ACI.

11.4.3.1. Editing ACLs

ACLs are stored in the internal database and can only be modified in the administrative console.

To edit the existing ACLs:

  1. Log into the administrative console.

    Note

    pkiconsole is being deprecated and will be replaced by a new browser-based UI in a future major release. Although pkiconsole will continue to be available until the replacement UI is released, we encourage using the command line equivalent of pkiconsole at this time, as the pki CLI will continue to be supported and improved upon even when the new browser-based UI becomes available in the future.

  2. Select Access Control List in the left navigation menu.

    acl

  3. Select the ACL to edit from the list, and click Edit.

    The ACL opens in the Access Control Editor window.

    acl1

  4. To add an ACI, click Add, and supply the ACI information.

    To edit an ACI, select the ACI from the list in the ACI entries text area of the ACL Editor window. Click Edit.

    acl2
    1. Select the allow or deny radio button from the Access field to allow or deny the operation to the groups, users, or IP addresses specified. For more information about allowing or denying access, see Section 11.4.1, “About access control”.
    2. Set the rights for the access control. The options are read and modify. To set both, use the Ctrl or Shift buttons.
    3. Specify the user, group, or IP address that will be granted or denied access in the Syntax field. See Section 11.4.1, “About access control” for details on syntax.
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.