Chapter 15. Exploring RHEL Identity Management in a controlled environment


15.1. Accessing the IdM Web UI in a PoC setup

Learn how to log in to the IdM Web UI with a password for the first time.

Procedure

  1. Type the URL of the IdM server or replica into the browser address bar:

    https://replica.idm.example.com
    Copy to Clipboard Toggle word wrap

    This opens the IdM Web UI login screen in your browser.

    Screenshot of the IdM Web UI accessed within a web browser displaying a "Username" field and a "Password" field. There is a blue "Log in" button below and to the right of those two fields.

  2. On the Web UI login screen, enter the admin in to the Login field. Enter Secret123 in to the Password field.

    A Screenshot of the IdM Web UI with the "Username" field filled in with "admin" and the "Password" field displays several black circles obfuscating the password by replacing the characters tat were typed in.

  3. Click Log in.

    After the successful login, you can start configuring the IdM server.

Learn how to use the IdM Web UI to add an IdM user and set the IdM user password.

Procedure

  1. Log in to the IdM Web UI as IdM admin. For details, see Accessing the IdM Web UI in a PoC setup.
  2. Go to Users Active Users tab.
  3. Click the + Add icon.
  4. Optional: In the User login field, add a login name, for example idmuser01.

    If you leave it empty, the IdM server creates the login name in the following pattern: The first letter of the first name and the surname. The whole login name can have up to 32 characters.

  5. Enter First name and Last name of the new user, for example Alice and Acme.
  6. Optional: In the Password and Verify password fields, enter the user password and confirm it, ensuring they both match.

    This is an initial, temporary password. The user will be asked to reset the password at the first login.

  7. Click the Add button.

    At this point, you can see the user account in the Active Users table.

    If you click on the user name, you can edit advanced settings, such as adding a phone number, address, or occupation.

Automating user management with Ansible is more efficient than using the Web UI approach described in Adding an IdM user using an Ansible playbook in a PoC setup.

Learn how to use a single Ansible playbook to add multiple IdM users. Because of Ansible idempotence, if any of the users already exists in IdM, the script skips them.

Prerequisites

  • You are logged in to controller.idm.example.com as the ansible user.

Procedure

  1. In your ~/MyPlaybooks directory, create an add-multiple-users.yml Ansible playbook file with the data of the users whose presence you want to ensure in IdM, for example:

    ---
    - name: Playbook to handle users
      hosts: ipaserver
    
      tasks:
      - name: Create user idm_users
        freeipa.ansible_freeipa.ipauser:
          ipaadmin_password: Secret123
          users:
          - name: idmuser01
            first: Alice
            last: Acme
            password: "Password123"
          - name: idmuser03
            first: Bob
            last: Acme
            password: "RedHat123&"
    Copy to Clipboard Toggle word wrap

    You must use the following options to add a user:

    • name: the login name
    • first: the first name string
    • last: the last name string

    The rest is optional.

    You can see the full list of available user options in the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-user.md Markdown file.

  2. [Optional] Clear the SSSD cache to improve the performance of the ansible-playbook command:

    $ sudo sss_cache -E
    Copy to Clipboard Toggle word wrap
    [sudo] password for ansible:
    Copy to Clipboard Toggle word wrap
  3. Run the playbook:

    $ ansible-playbook -i inventory add-multiple-users.yml
    Copy to Clipboard Toggle word wrap

Next steps

  1. Log into the IdM Web UI as idmuser01:

    1. Use "Password123", the temporary password configured by the Ansible script above, as idmuser01 password.
    2. Set a new password.
  2. Repeat for idmuser03.

15.4. Host-based access control rules in IdM

Host-based access control (HBAC) rules define which users or user groups can access which hosts or host groups by using which services or services in a service group. As a system administrator, you can use HBAC rules to achieve the following goals:

  • Limit access to a specified system in your domain to members of a specific user group.
  • Allow only a specific service to be used to access systems in your domain.

By default, IdM is configured with a default HBAC rule named allow_all, which means universal access to every host for every user via every relevant service in the entire IdM domain.

You can fine-tune access to different hosts by replacing the default allow_all rule with your own set of HBAC rules. For centralized and simplified access control management, you can apply HBAC rules to user groups, host groups, or service groups instead of individual users, hosts, or services.

Learn how to use the Identity Management (IdM) Web UI to define a host-based access rule (HBAC) rule to allow a set of RHEL IdM users to access IdM clients using the SSH protocol. The example below describes how to:

  • Enable the IdM user idmuser01 to access an IdM client client.idm.example.com remotely by using the SSH protocol.
  • Disable the IdM user idmuser03 from using the SSH protocol to access the IdM client client.idm.example.com.

Prerequisites

Procedure

  1. Create and customize the allow_remote_access rule:

    1. Navigate to Policy > Host Based Access Control > HBAC Rules and then click Add. Set allow_remote_access as the name of the rule and click Add and Edit.
    2. In the Who section, verify that Specified Users and Groups is selected, and then click Add. Select the idmuser01 user, and then click > to move the user to the Prospective column. Click Add.
    3. In the Accessing section, verify that Specified Hosts and Groups is selected, and then click Add. Select the client.idm.example.com machine and click > to move it to the Prospective column. Click Add.
    4. In the Via Service section, verify that Specified Services and Groups is selected, and then click Add. Select the ftp, sshd, and vsftpd services from the Available column and click > to move them to the Prospective column. Click Add.
    5. Return to the HBAC rules list by clicking HBAC Rules at the top of the window.
  2. For security reasons, modify the allow_all rule so that only IdM admins have universal access to every host via every relevant service in the entire IdM domain:

    1. Navigate to Policy > Host Based Access Control > HBAC Rules.
    2. Click the allow_all rule.
    3. In the Who section, verify that Specified Users and Groups is selected, and then click Add. Select the admins group, and then click > to move it to the Prospective column. Click Add.

Verification

  1. Navigate to Policy > Host Based Access Control > HBAC Test. Select the parameters of the test according to the following table:

    Expand
    ListSelect

    WHO

    idmuser03

    ACCESSING

    client.idm.example.com

    VIA SERVICE

    sshd

    RULES

    allow_remote_access

  2. On the Run Test tab, click Run Test to run the simulation. On the right side of the Run Test tab, the console shows an ACCESS DENIED message because the idmuser03 user is not a member of the HBAC rule.
  3. Now select the test parameters according to the following table:

    Expand
    ListSelect

    WHO

    idmuser01

    ACCESSING

    client.idm.example.com

    VIA SERVICE

    sshd

    RULES

    allow_remote_access

  4. On the Run Test tab, click Run Test to run the simulation. On the right side of the Run Test tab, the console shows an ACCESS GRANTED message because the idmuser01 user is a member of the HBAC rule.
  5. Open a terminal and log in to the client machine as the idmuser03 user. The connection fails because the user is not a member of the rule:

    $ ssh idmuser03@client
    Connection closed by 172.25.250.11 port 22
    Copy to Clipboard Toggle word wrap
  6. Try to log in to the client machine as the idmuser01 user. The connection is successful because the user is a member of the rule:

    $ ssh idmuser01@client
    ...output omitted...
    [idmuser01@client /]$*
    Copy to Clipboard Toggle word wrap

Automating host-based access control configuration with Ansible is more efficient than using the Web UI approach described in Enabling an IdM user to manage IdM groups and group membership using the IdM Web UI in the PoC setup.

Learn how to ensure the presence of a host-based access control (HBAC) rule in Identity Management (IdM) using an Ansible playbook. The example below describes how to:

  • Enable the IdM user idmuser01 to access an IdM client client.idm.example.com remotely by using the SSH protocol.
  • Disable the IdM user idmuser03 from using the SSH protocol to access the IdM client client.idm.example.com.

Prerequisites

Procedure

  1. In your ~/MyPlaybooks/ directory, create an ensure-new-hbacrule-present.yml Ansible playbook file with the content below that defines the desired HBAC policy:

    ---
    - name: Playbook to handle hbacrules
      hosts: ipaserver
    
      tasks:
      # Ensure idmuser01 can access client.idm.example.com via the sshd service
      - freeipa.ansible_freeipa.ipahbacrule:
          ipaadmin_password: Secret123
          name: allow_remote_access
          user: idmuser01
          host: client.idm.example.com
          hbacsvc:
          - sshd
          state: present
      # Ensure allow_all rule is modified so that only admins are members
      - freeipa.ansible_freeipa.ipahbacrule:
          ipaadmin_password: Secret123
          name: allow_all
          group: admins
          usercat: ""
    Copy to Clipboard Toggle word wrap

    If an HBAC rule already exists and you are only modifying it, you must set the action option to member. Otherwise the playbook fails. In the example, the Ensure allow_all rule is modified so that only admins are members task modifies the allow_all built-in rule, and therefore, requires action: member.

    Tip

    To avoid writing your HBAC-related playbooks from scratch, you can copy and modify the sample playbooks in the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/playbooks/hbacrule/ directory.

  2. Run the playbook:

    $ ansible-playbook -i inventory ensure-new-hbacrule-present.yml
    Copy to Clipboard Toggle word wrap

Verification

  1. Navigate to Policy > Host Based Access Control > HBAC Test. Select the parameters of the test according to the following table:

    Expand
    ListSelect

    WHO

    idmuser03

    ACCESSING

    client.idm.example.com

    VIA SERVICE

    sshd

    RULES

    allow_remote_access

  2. On the Run Test tab, click Run Test to run the simulation. On the right side of the Run Test tab, the console shows an ACCESS DENIED message because the idmuser03 user is not a member of the HBAC rule.
  3. Now select the test parameters according to the following table:

    Expand
    ListSelect

    WHO

    idmuser01

    ACCESSING

    client.idm.example.com

    VIA SERVICE

    sshd

    RULES

    allow_remote_access

  4. On the Run Test tab, click Run Test to run the simulation. On the right side of the Run Test tab, the console shows an ACCESS GRANTED message because the idmuser01 user is a member of the HBAC rule.
  5. Open a terminal and log in to the client machine as the idmuser03 user. The connection fails because the user is not a member of the rule:

    $ ssh idmuser03@client
    (idmuser03@client) Password: RedHat123&
    Connection closed by 172.25.250.11 port 22
    Copy to Clipboard Toggle word wrap
  6. Try to log in to the client machine as the idmuser01 user. The connection is successful because the user is a member of the rule:

    $ ssh idmuser01@client
    (idmuser01@client) Password: Password123
    ...output omitted...
    [idmuser01@client /]$*
    Copy to Clipboard Toggle word wrap

15.7. Role-based access control in RHEL IdM

Learn more about role-based access control (RBAC) in Identity Management (IdM). RBAC is a security feature that restricts access to authorized users. You can define roles with specific permissions and then assign those roles to users.

Role-based access control is composed of three parts:

  • Permissions grant the right to perform a specific task such as adding or deleting users, modifying a group, and enabling read-access.
  • Privileges combine permissions, for example all the permissions needed to add a new user.
  • Roles grant a set of privileges to users, user groups, hosts or host groups.

The built-in Group Administrators privilege in RHEL Identity Management (IdM) contains the following permissions:

  • Add Groups
  • Modify External Group Membership
  • Modify Group Membership
  • Modify Groups
  • Remove Groups

Learn how to use the IdM Web UI to assign a role that grants the Group Administrator privilege to the IdM user idmuser01. As a result, idmuser01 can add the idmuser03 to the built-in editors group.

Prerequisites

Procedure

  1. Log in as IdM admin to the IdM Web UI.
  2. Create the groupadmin role:

    1. Navigate to IPA Server > Role-Based Access Control > Roles and then click Add.
    2. In the Role name field, enter groupadmin. In the Description field, enter Group Administrator. Click Add and Edit.
  3. Add the idmuser01 user to the role:

    1. On the Role: groupadmin page, ensure that you are on the Users tab, and click Add.
    2. In the Add users into role 'groupadmin' window, check the box next to idmuser01 and click > to move the user from the Available to the Prospective column.
    3. Click Add.
  4. Add the Group Administrators privilege to the role:

    1. On the Role: groupadmin page, ensure that you are on the Privileges tab, and click Add.
    2. In the Add role 'groupadmin' into privileges window, check the box next to Group Administrators and click > to move the user from the Available to the Prospective column.
    3. Click Add.

Verification

  1. Verify that idmuser01 is assigned to the groupadmin role:

    1. In the IdM Web UI, navigate as IdM admin to Identity > Users.
    2. Click idmuser01.
    3. Click Roles.

      You can see that groupadmin is listed among the roles.

  2. Verify that idmuser01 can assign group membership to idmuser03:

    1. Log in to the IdM Web UI as idmuser01.
    2. Navigate to Identity > Users.
    3. Click idmuser03.
    4. Click User Groups.
    5. Click Add.
    6. Select the editors group and then click > to move it to the Prospective column. Click Add.

      In the user profile, you can now see that idmuser03 is a member of the editors group.

Additional resources

Automating role-based access control configuration with Ansible is more efficient than using the Web UI approach described in Enabling an IdM user to manage IdM groups and group membership using the IdM Web UI in the PoC setup.

Learn how to use the role ansible-freeipa module in an Ansible playbook to assign a role that grants the IdM user idmuser01 the same Group Administrator privilege as configured using the Web UI method. As a result, idmuser01 can add the idmuser03 to the built-in editors group.

Prerequisites

Procedure

  1. In your ~/MyPlaybooks/ directory, create an assign-group-administrator-privilege-to-idmuser01.yml Ansible playbook file with the content below that defines the desired RBAC policy:

    ---
    - name: Make idmuser01 a member of an RBAC role that contains the Group Administrators privilege
      hosts: ipaserver
    
      tasks:
      - name: Create the groupadmin role
        freeipa.ansible_freeipa.iparole:
          ipaadmin_password: Secret123
          name: groupadmin
          user:
          - idmuser01
          privilege:
          - Group Administrators
          state: present
    Copy to Clipboard Toggle word wrap

    You can see the full list of available options in the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-role.md file.

  2. Run the playbook:

    $ ansible-playbook -i inventory assign-group-administrator-privilege-to-idmuser01.yml
    Copy to Clipboard Toggle word wrap

Verification

  1. Verify that idmuser01 is assigned to the groupadmin role:

    1. In the IdM Web UI, navigate as IdM admin to Identity > Users.
    2. Click idmuser01.
    3. Click Roles.

      You can see that groupadmin is listed among the roles.

  2. Verify that idmuser01 can assign group membership to idmuser03:

    1. Log in to the IdM Web UI as idmuser01.
    2. Navigate to Identity > Users.
    3. Click idmuser03.
    4. Click User Groups.
    5. Click Add.
    6. Select the editors group and then click > to move it to the Prospective column. Click Add.

      In the user profile, you can now see that idmuser03 is a member of the editors group.

15.10. Sudo access on an IdM client

System administrators can grant sudo access to allow non-root users to execute administrative commands that are normally reserved for the root user. Consequently, when users need to perform an administrative command normally reserved for the root user, they precede that command with sudo. After entering their password, the command is executed as if they were the root user. To execute a sudo command as another user or group, such as a database service account, you can configure a RunAs alias for a sudo rule.

If a Red Hat Enterprise Linux (RHEL) host is enrolled as an Identity Management (IdM) client, you can specify sudo rules defining which IdM users can perform which commands on the host in the following ways:

  • Locally in the /etc/sudoers file
  • Centrally in IdM

You can create a central sudo rule for an IdM client using the command line (CLI) and the IdM Web UI.

You can also configure password-less authentication for sudo using the Generic Security Service Application Programming Interface (GSSAPI), the native way for UNIX-based operating systems to access and authenticate Kerberos services. You can use the pam_sss_gss.so Pluggable Authentication Module (PAM) to invoke GSSAPI authentication via the SSSD service, allowing users to authenticate to the sudo command with a valid Kerberos ticket.

In Identity Management (IdM), you can grant sudo access for a specific command to an IdM user account on a specific IdM host. First, add a sudo command and then create a sudo rule for one or more commands.

Complete this procedure to create the idmuser01_reboot sudo rule to grant the idmuser01 account the permission to run the /usr/sbin/reboot command on the client.idm.example.com machine, or client.

Prerequisites

  • You are logged in to the IdM Web UI as admin.
  • You have created a user account for idmuser01 in IdM and unlocked the account by creating a password for the user. For details on adding a new IdM user using the command line, see Adding users using the command line.
  • No local idmuser01 account is present on the client host. The idmuser01 user is not listed in the local /etc/passwd file.
  • The client.idm.example.com host exists in IdM.

Procedure

  1. Add the /usr/sbin/reboot command to the IdM database of sudo commands:

    1. Navigate to Policy Sudo Sudo Commands.
    2. Click Add in the upper right corner to open the Add sudo command dialog box.
    3. Enter the command you want the user to be able to perform using sudo: /usr/sbin/reboot.

    4. Click Add.
  2. Use the new sudo command entry to create a sudo rule to allow idmuser01 to reboot the client machine:

    1. Navigate to Policy Sudo Sudo rules.
    2. Click Add in the upper right corner to open the Add sudo rule dialog box.
    3. Enter the name of the sudo rule: idmuser01_reboot.
    4. Click Add and Edit.
    5. Specify the user:

      1. In the Who section, check the Specified Users and Groups radio button.
      2. In the User category the rule applies to subsection, click Add to open the Add users into sudo rule "idmuser01_reboot" dialog box.
      3. In the Add users into sudo rule "idmuser01_reboot" dialog box in the Available column, check the idmuser01 checkbox, and move it to the Prospective column.
      4. Click Add.
    6. Specify the host:

      1. In the Access this host section, check the Specified Hosts and Groups radio button.
      2. In the Host category this rule applies to subsection, click Add to open the Add hosts into sudo rule "idmuser01_reboot" dialog box.
      3. In the Add hosts into sudo rule "idmuser01_reboot" dialog box in the Available column, check the client.idm.example.com checkbox, and move it to the Prospective column.
      4. Click Add.
    7. Specify the commands:

      1. In the Command category the rule applies to subsection of the Run Commands section, check the Specified Commands and Groups radio button.
      2. In the Sudo Allow Commands subsection, click Add to open the Add allow sudo commands into sudo rule "idmuser01_reboot" dialog box.
      3. In the Add allow sudo commands into sudo rule "idmuser01_reboot" dialog box in the Available column, check the /usr/sbin/reboot checkbox, and move it to the Prospective column.
      4. Click Add to return to the idm_sudo_reboot page.

      Figure 15.1. Adding IdM sudo rule

    8. Click Save in the top left corner.

      The new rule is enabled by default.

    Note

    Propagating the changes from the server to the client can take a few minutes.

Verification

  1. Log in to client as idmuser01.
  2. Reboot the machine using sudo. Enter the password for idmuser01 when prompted:

    $ sudo /usr/sbin/reboot
    [sudo] password for idmuser01:
    Copy to Clipboard Toggle word wrap

If the sudo rule is configured correctly, the machine reboots.

Learn how to use a single Ansible playbook to grant sudo access for a specific command to an IdM user account on a specific IdM host.First, add a sudo command and then create a sudo rule for one or more commands.

Complete this procedure to create the idmuser01_reboot sudo rule to grant the idmuser01 account the permission to run the /usr/sbin/reboot command on the client.idm.example.com machine, or client.

Prerequisites

  • You are logged in to controller.idm.example.com as the ansible user.

Procedure

  1. In your ~/MyPlaybooks directory, create an add-sudo-rule.yml Ansible playbook file with the parameters of the sudo rule, for example:

    ---
    - name: Playbook to handle SUDO rules
      hosts: ipaserver
      tasks:
      - name: Add reboot to sudo commands
        freeipa.ansible_freeipa.ipasudocmd:
          ipaadmin_password: Secret123
          name: /usr/sbin/reboot
          state: present
      - name: Create a sudo rule idmuser01_reboot
        freeipa.ansible_freeipa.ipasudorule:
          name: idmuser01_reboot
          ipaadmin_password: Secret123
      - name: Modify the idmuser01_reboot sudo rule by adding reboot command and idmuser01
        freeipa.ansible_freeipa.ipasudorule:
          ipaadmin_password: Secret123
          name: idmuser01_reboot
          allow_sudocmd:
            - /usr/sbin/reboot
          user:
            - idmuser01
          action: member
    Copy to Clipboard Toggle word wrap

    If a sudo rule already exists and you are only modifying it, you must set the action option to member. Otherwise the playbook fails. In the example, the Modify the idmuser01_reboot sudo rule by adding reboot command and idmuser01 task modifies the rule that the Create a sudo rule idmuser01_reboot task created previously, and therefore, requires action: member.

    You can see the full list of available options in the /usr/share/ansible/collections/ansible_collections/freeipa/ansible_freeipa/README-sudocmd.md and …​/README-sudorule.md files.

  2. Run the playbook:

    $ ansible-playbook -i inventory add-sudo-rule.yml
    Copy to Clipboard Toggle word wrap

Verification

  1. Log in to client as idmuser01.
  2. Reboot the machine using sudo. Enter the password for idmuser01 when prompted:

    $ sudo /usr/sbin/reboot
    [sudo] password for idmuser01:
    Copy to Clipboard Toggle word wrap

If the sudo rule is configured correctly, the machine reboots.

Back to top
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. Explore our recent updates.

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.

Theme

© 2025 Red Hat