Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 20. Granting sudo access to an IdM user on an IdM client

Learn more about granting sudo access to users in Identity Management.

20.1. 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) 8 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.

In RHEL 8.4 and later, 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.

20.2. Granting sudo access to an IdM user on an IdM client using the CLI

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.

For example, complete this procedure to create the idm_user_reboot sudo rule to grant the idm_user account the permission to run the /usr/sbin/reboot command on the idmclient machine.

Prerequisites

  • You are logged in as IdM administrator.
  • You have created a user account for idm_user in IdM and unlocked the account by creating a password for the user. For details on adding a new IdM user using the CLI, see Adding users using the command line.
  • No local idm_user account is present on the idmclient host. The idm_user user is not listed in the local /etc/passwd file.

Procedure

  1. Retrieve a Kerberos ticket as the IdM admin. 

    [root@idmclient ~]# kinit admin
    Copy to Clipboard

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

    [root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot
-------------------------------------
Added Sudo Command "/usr/sbin/reboot"
-------------------------------------
  Sudo Command: /usr/sbin/reboot
    Copy to Clipboard

  3. Create a sudo rule named idm_user_reboot: 

    [root@idmclient ~]# ipa sudorule-add idm_user_reboot
---------------------------------
Added Sudo Rule "idm_user_reboot"
---------------------------------
  Rule name: idm_user_reboot
  Enabled: TRUE
    Copy to Clipboard

  4. Add the /usr/sbin/reboot command to the idm_user_reboot rule: 

    [root@idmclient ~]# ipa sudorule-add-allow-command idm_user_reboot --sudocmds '/usr/sbin/reboot'
  Rule name: idm_user_reboot
  Enabled: TRUE
  Sudo Allow Commands: /usr/sbin/reboot
-------------------------
Number of members added 1
-------------------------
    Copy to Clipboard

  5. Apply the idm_user_reboot rule to the IdM idmclient host: 

    [root@idmclient ~]# ipa sudorule-add-host idm_user_reboot --hosts idmclient.idm.example.com
Rule name: idm_user_reboot
Enabled: TRUE
Hosts: idmclient.idm.example.com
Sudo Allow Commands: /usr/sbin/reboot
-------------------------
Number of members added 1
-------------------------
    Copy to Clipboard

  6. Add the idm_user account to the idm_user_reboot rule: 

    [root@idmclient ~]# ipa sudorule-add-user idm_user_reboot --users idm_user
Rule name: idm_user_reboot
Enabled: TRUE
Users: idm_user
Hosts: idmclient.idm.example.com
Sudo Allow Commands: /usr/sbin/reboot
-------------------------
Number of members added 1
-------------------------
    Copy to Clipboard

  7. Optional: Define the validity of the idm_user_reboot rule:

    1. To define the time at which a sudo rule starts to be valid, use the ipa sudorule-mod sudo_rule_name command with the --setattr sudonotbefore=DATE option. The DATE value must follow the yyyymmddHHMMSSZ format, with seconds specified explicitly. For example, to set the start of the validity of the idm_user_reboot rule to 31 December 2025 12:34:00, enter: 

      [root@idmclient ~]# ipa sudorule-mod idm_user_reboot --setattr sudonotbefore=20251231123400Z
      Copy to Clipboard

    2. To define the time at which a sudo rule stops being valid, use the --setattr sudonotafter=DATE option. For example, to set the end of the idm_user_reboot rule validity to 31 December 2026 12:34:00, enter: 

      [root@idmclient ~]# ipa sudorule-mod idm_user_reboot --setattr sudonotafter=20261231123400Z
      Copy to Clipboard
Note

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

Verification

  1. Log in to the idmclient host as the idm_user account.

  2. Display which sudo rules the idm_user account is allowed to perform. 

    [idm_user@idmclient ~]$ sudo -l
Matching Defaults entries for idm_user on idmclient:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
    env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
    env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
    env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
    env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User idm_user may run the following commands on idmclient:
    (root) /usr/sbin/reboot
    Copy to Clipboard

  3. Reboot the machine using sudo. Enter the password for idm_user when prompted: 

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot
[sudo] password for idm_user:
    Copy to Clipboard

20.3. Granting sudo access to an AD user on an IdM client using the CLI

Identity Management (IdM) system administrators can use IdM user groups to set access permissions, host-based access control, sudo rules, and other controls on IdM users. IdM user groups grant and restrict access to IdM domain resources.

You can add both Active Directory (AD) users and AD groups to IdM user groups. To do that:

  1. Add the AD users or groups to a non-POSIX external IdM group.
  2. Add the non-POSIX external IdM group to an IdM POSIX group.

You can then manage the privileges of the AD users by managing the privileges of the POSIX group. For example, you can grant sudo access for a specific command to an IdM POSIX user group on a specific IdM host.

It is also possible to add AD user groups as members to IdM external groups. This might make it easier to define policies for Windows users, by keeping the user and group management within the single AD realm.

Important

Do not use ID overrides of AD users for SUDO rules in IdM. ID overrides of AD users represent only POSIX attributes of AD users, not AD users themselves.

You can add ID overrides as group members. However, you can only use this functionality to manage IdM resources in the IdM API. The possibility to add ID overrides as group members is not extended to POSIX environments and you therefore cannot use it for membership in sudo or host-based access control (HBAC) rules.

Follow this procedure to create the ad_users_reboot sudo rule to grant the administrator@ad-domain.com AD user the permission to run the /usr/sbin/reboot command on the idmclient IdM host, which is normally reserved for the root user. administrator@ad-domain.com is a member of the ad_users_external non-POSIX group, which is, in turn, a member of the ad_users POSIX group.

Prerequisites

  • You have obtained the IdM admin Kerberos ticket-granting ticket (TGT).
  • A cross-forest trust exists between the IdM domain and the ad-domain.com AD domain.
  • No local administrator account is present on the idmclient host: the administrator user is not listed in the local /etc/passwd file.

Procedure

  1. Create the ad_users group that contains the ad_users_external group with the administrator@ad-domain member:

    1. Optional: Create or select a corresponding group in the AD domain to use to manage AD users in the IdM realm. You can use multiple AD groups and add them to different groups on the IdM side.

    2. Create the ad_users_external group and indicate that it contains members from outside the IdM domain by adding the --external option: 

      [root@ipaserver ~]# ipa group-add --desc='AD users external map' ad_users_external --external
-------------------------------
Added group "ad_users_external"
-------------------------------
  Group name: ad_users_external
  Description: AD users external map
      Copy to Clipboard
      Note

      Ensure that the external group that you specify here is an AD security group with a global or universal group scope as defined in the Active Directory security groups document. For example, the Domain users or Domain admins AD security groups cannot be used because their group scope is domain local.

    3. Create the ad_users group: 

      [root@ipaserver ~]# ipa group-add --desc='AD users' ad_users
----------------------
Added group "ad_users"
----------------------
  Group name: ad_users
  Description: AD users
  GID: 129600004
      Copy to Clipboard

    4. Add the administrator@ad-domain.com AD user to ad_users_external as an external member: 

      [root@ipaserver ~]# ipa group-add-member ad_users_external --external "administrator@ad-domain.com"
 [member user]:
 [member group]:
  Group name: ad_users_external
  Description: AD users external map
  External member: S-1-5-21-3655990580-1375374850-1633065477-513
-------------------------
Number of members added 1
-------------------------
      Copy to Clipboard

      The AD user must be identified by a fully-qualified name, such as DOMAIN\user_name or user_name@DOMAIN. The AD identity is then mapped to the AD SID for the user. The same applies to adding AD groups.

    5. Add ad_users_external to ad_users as a member: 

      [root@ipaserver ~]# ipa group-add-member ad_users --groups ad_users_external
  Group name: ad_users
  Description: AD users
  GID: 129600004
  Member groups: ad_users_external
-------------------------
Number of members added 1
-------------------------
      Copy to Clipboard

  2. Grant the members of ad_users the permission to run /usr/sbin/reboot on the idmclient host:

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

      [root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot
-------------------------------------
Added Sudo Command "/usr/sbin/reboot"
-------------------------------------
  Sudo Command: /usr/sbin/reboot
      Copy to Clipboard

    2. Create a sudo rule named ad_users_reboot: 

      [root@idmclient ~]# ipa sudorule-add ad_users_reboot
---------------------------------
Added Sudo Rule "ad_users_reboot"
---------------------------------
  Rule name: ad_users_reboot
  Enabled: True
      Copy to Clipboard

    3. Add the /usr/sbin/reboot command to the ad_users_reboot rule: 

      [root@idmclient ~]# ipa sudorule-add-allow-command ad_users_reboot --sudocmds '/usr/sbin/reboot'
  Rule name: ad_users_reboot
  Enabled: True
  Sudo Allow Commands: /usr/sbin/reboot
-------------------------
Number of members added 1
-------------------------
      Copy to Clipboard

    4. Apply the ad_users_reboot rule to the IdM idmclient host: 

      [root@idmclient ~]# ipa sudorule-add-host ad_users_reboot --hosts idmclient.idm.example.com
Rule name: ad_users_reboot
Enabled: True
Hosts: idmclient.idm.example.com
Sudo Allow Commands: /usr/sbin/reboot
-------------------------
Number of members added 1
-------------------------
      Copy to Clipboard

    5. Add the ad_users group to the ad_users_reboot rule: 

      [root@idmclient ~]# ipa sudorule-add-user ad_users_reboot --groups ad_users
Rule name: ad_users_reboot
Enabled: TRUE
User Groups: ad_users
Hosts: idmclient.idm.example.com
Sudo Allow Commands: /usr/sbin/reboot
-------------------------
Number of members added 1
-------------------------
      Copy to Clipboard
Note

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

Verification

  1. Log in to the idmclient host as administrator@ad-domain.com, an indirect member of the ad_users group: 

    $ ssh administrator@ad-domain.com@ipaclient
Password:
    Copy to Clipboard

  2. Optional: Display the sudo commands that administrator@ad-domain.com is allowed to execute: 

    [administrator@ad-domain.com@idmclient ~]$ sudo -l
Matching Defaults entries for administrator@ad-domain.com on idmclient:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
    env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
    env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
    env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
    env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User administrator@ad-domain.com may run the following commands on idmclient:
    (root) /usr/sbin/reboot
    Copy to Clipboard

  3. Reboot the machine using sudo. Enter the password for administrator@ad-domain.com when prompted: 

    [administrator@ad-domain.com@idmclient ~]$ sudo /usr/sbin/reboot
[sudo] password for administrator@ad-domain.com:
    Copy to Clipboard

20.4. Granting sudo access to an IdM user on an IdM client using the IdM Web UI

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 idm_user_reboot sudo rule to grant the idm_user account the permission to run the /usr/sbin/reboot command on the idmclient machine.

Prerequisites

  • You are logged in as IdM administrator.
  • You have created a user account for idm_user 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 idm_user account is present on the idmclient host. The idm_user user is not listed in the local /etc/passwd file.

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 idm_user to reboot the idmclient 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: idm_user_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 Users section, click Add to open the Add users into sudo rule "idm_user_reboot" dialog box.
      3. In the Available column, check the idm_user checkbox, and click the arrow to 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 Hosts section, click Add to open the Add hosts into sudo rule "idm_user_reboot" dialog box.
      3. In Available column, check the idmclient.idm.example.com checkbox, and click the arrow to move it to the Prospective column.
      4. Click Add.

    7. Specify the commands:

      1. In the Run Commands section, check the Specified Commands and Groups radio button.
      2. In the Sudo Allow Commands section, click Add to open the Add allow sudo commands into sudo rule "idm_user_reboot" dialog box.
      3. In the Available column, check the /usr/sbin/reboot checkbox, and click the arrow to move it to the Prospective column.
      4. Click Add to return to the idm_sudo_reboot page.
    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 idmclient as idm_user.

  2. Reboot the machine using sudo. Enter the password for idm_user when prompted: 

    $ sudo /usr/sbin/reboot
[sudo] password for idm_user:
    Copy to Clipboard

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

20.5. Creating a sudo rule on the CLI that runs a command as a service account on an IdM client

In IdM, you can configure a sudo rule with a RunAs alias to run a sudo command as another user or group. For example, you might have an IdM client that hosts a database application, and you need to run commands as the local service account that corresponds to that application.

Use this example to create a sudo rule on the command line called run_third-party-app_report to allow the idm_user account to run the /opt/third-party-app/bin/report command as the thirdpartyapp service account on the idmclient host.

Prerequisites

  • You are logged in as IdM administrator.
  • You have created a user account for idm_user in IdM and unlocked the account by creating a password for the user. For details on adding a new IdM user using the CLI, see Adding users using the command line.
  • No local idm_user account is present on the idmclient host. The idm_user user is not listed in the local /etc/passwd file.
  • You have a custom application named third-party-app installed on the idmclient host.
  • The report command for the third-party-app application is installed in the /opt/third-party-app/bin/report directory.
  • You have created a local service account named thirdpartyapp to execute commands for the third-party-app application.

Procedure

  1. Retrieve a Kerberos ticket as the IdM admin. 

    [root@idmclient ~]# kinit admin
    Copy to Clipboard

  2. Add the /opt/third-party-app/bin/report command to the IdM database of sudo commands: 

    [root@idmclient ~]# ipa sudocmd-add /opt/third-party-app/bin/report
----------------------------------------------------
Added Sudo Command "/opt/third-party-app/bin/report"
----------------------------------------------------
  Sudo Command: /opt/third-party-app/bin/report
    Copy to Clipboard

  3. Create a sudo rule named run_third-party-app_report: 

    [root@idmclient ~]# ipa sudorule-add run_third-party-app_report
--------------------------------------------
Added Sudo Rule "run_third-party-app_report"
--------------------------------------------
  Rule name: run_third-party-app_report
  Enabled: TRUE
    Copy to Clipboard

  4. Use the --users=<user> option to specify the RunAs user for the sudorule-add-runasuser command: 

    [root@idmclient ~]# ipa sudorule-add-runasuser run_third-party-app_report --users=thirdpartyapp
  Rule name: run_third-party-app_report
  Enabled: TRUE
  RunAs External User: thirdpartyapp
-------------------------
Number of members added 1
-------------------------
    Copy to Clipboard

    The user (or group specified with the --groups=* option) can be external to IdM, such as a local service account or an Active Directory user. Do not add a % prefix for group names.

  5. Add the /opt/third-party-app/bin/report command to the run_third-party-app_report rule: 

    [root@idmclient ~]# ipa sudorule-add-allow-command run_third-party-app_report --sudocmds '/opt/third-party-app/bin/report'
Rule name: run_third-party-app_report
Enabled: TRUE
Sudo Allow Commands: /opt/third-party-app/bin/report
RunAs External User: thirdpartyapp
-------------------------
Number of members added 1
-------------------------
    Copy to Clipboard

  6. Apply the run_third-party-app_report rule to the IdM idmclient host: 

    [root@idmclient ~]# ipa sudorule-add-host run_third-party-app_report --hosts idmclient.idm.example.com
Rule name: run_third-party-app_report
Enabled: TRUE
Hosts: idmclient.idm.example.com
Sudo Allow Commands: /opt/third-party-app/bin/report
RunAs External User: thirdpartyapp
-------------------------
Number of members added 1
-------------------------
    Copy to Clipboard

  7. Add the idm_user account to the run_third-party-app_report rule: 

    [root@idmclient ~]# ipa sudorule-add-user run_third-party-app_report --users idm_user
Rule name: run_third-party-app_report
Enabled: TRUE
Users: idm_user
Hosts: idmclient.idm.example.com
Sudo Allow Commands: /opt/third-party-app/bin/report
RunAs External User: thirdpartyapp
-------------------------
Number of members added 1
    Copy to Clipboard
Note

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

Verification

  1. Log in to the idmclient host as the idm_user account.

  2. Test the new sudo rule:

    1. Display which sudo rules the idm_user account is allowed to perform. 

      [idm_user@idmclient ~]$ sudo -l
Matching Defaults entries for idm_user@idm.example.com on idmclient:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
    env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
    env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
    env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
    env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User idm_user@idm.example.com may run the following commands on idmclient:
    (thirdpartyapp) /opt/third-party-app/bin/report
      Copy to Clipboard

    2. Run the report command as the thirdpartyapp service account. 

      [idm_user@idmclient ~]$ sudo -u thirdpartyapp /opt/third-party-app/bin/report
[sudo] password for idm_user@idm.example.com:
Executing report...
Report successful.
      Copy to Clipboard

20.6. Creating a sudo rule in the IdM WebUI that runs a command as a service account on an IdM client

In IdM, you can configure a sudo rule with a RunAs alias to run a sudo command as another user or group. For example, you might have an IdM client that hosts a database application, and you need to run commands as the local service account that corresponds to that application.

Use this example to create a sudo rule in the IdM WebUI called run_third-party-app_report to allow the idm_user account to run the /opt/third-party-app/bin/report command as the thirdpartyapp service account on the idmclient host.

Prerequisites

  • You are logged in as IdM administrator.
  • You have created a user account for idm_user in IdM and unlocked the account by creating a password for the user. For details on adding a new IdM user using the CLI, see Adding users using the command line.
  • No local idm_user account is present on the idmclient host. The idm_user user is not listed in the local /etc/passwd file.
  • You have a custom application named third-party-app installed on the idmclient host.
  • The report command for the third-party-app application is installed in the /opt/third-party-app/bin/report directory.
  • You have created a local service account named thirdpartyapp to execute commands for the third-party-app application.

Procedure

  1. Add the /opt/third-party-app/bin/report 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: /opt/third-party-app/bin/report.
    4. Click Add.

  2. Use the new sudo command entry to create the new sudo rule:

    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: run_third-party-app_report.
    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 section, click Add to open the Add users into sudo rule "run_third-party-app_report" dialog box.
      3. In the Available column, check the idm_user 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 Hosts section, click Add to open the Add hosts into sudo rule "run_third-party-app_report" dialog box.
      3. In the Available column, check the idmclient.idm.example.com checkbox, and move it to the Prospective column.
      4. Click Add.

    7. Specify the commands:

      1. In the Run Commands section, check the Specified Commands and Groups radio button.
      2. In the Sudo Allow Commands section, click Add to open the Add allow sudo commands into sudo rule "run_third-party-app_report" dialog box.
      3. In the Available column, check the /opt/third-party-app/bin/report checkbox, and move it to the Prospective column.
      4. Click Add to return to the run_third-party-app_report page.

    8. Specify the RunAs user:

      1. In the As Whom section, check the Specified Users and Groups radio button.
      2. In the RunAs Users section, click Add to open the Add RunAs users into sudo rule "run_third-party-app_report" dialog box.
      3. Enter the thirdpartyapp service account in the External box and move it to the Prospective column.
      4. Click Add to return to the run_third-party-app_report page.
    9. 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 the idmclient host as the idm_user account.

  2. Test the new sudo rule:

    1. Display which sudo rules the idm_user account is allowed to perform. 

      [idm_user@idmclient ~]$ sudo -l
Matching Defaults entries for idm_user@idm.example.com on idmclient:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
    env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
    env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
    env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
    env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User idm_user@idm.example.com may run the following commands on idmclient:
    (thirdpartyapp) /opt/third-party-app/bin/report
      Copy to Clipboard

    2. Run the report command as the thirdpartyapp service account. 

      [idm_user@idmclient ~]$ sudo -u thirdpartyapp /opt/third-party-app/bin/report
[sudo] password for idm_user@idm.example.com:
Executing report...
Report successful.
      Copy to Clipboard

20.7. Enabling GSSAPI authentication for sudo on an IdM client

Enable Generic Security Service Application Program Interface (GSSAPI) authentication on an IdM client for the sudo and sudo -i commands via the pam_sss_gss.so PAM module. With this configuration, IdM users can authenticate to the sudo command with their Kerberos ticket.

Prerequisites

  • You have created a sudo rule for an IdM user that applies to an IdM host. For this example, you have created the idm_user_reboot sudo rule to grant the idm_user account the permission to run the /usr/sbin/reboot command on the idmclient host.
  • The idmclient host is running RHEL 8.4 or later.
  • You need root privileges to modify the /etc/sssd/sssd.conf file and PAM files in the /etc/pam.d/ directory.

Procedure

  1. Open the /etc/sssd/sssd.conf configuration file.

  2. Add the following entry to the [domain/<domain_name>] section. 

    [domain/<domain_name>]
pam_gssapi_services = sudo, sudo-i
    Copy to Clipboard
  3. Save and close the /etc/sssd/sssd.conf file.

  4. Restart the SSSD service to load the configuration changes. 

    [root@idmclient ~]# systemctl restart sssd
    Copy to Clipboard

  5. On RHEL 8.8 or later:

    1. Optional: Determine if you have selected the sssd authselect profile: 

      # authselect current
Profile ID: sssd
      Copy to Clipboard

    2. If the sssd authselect profile is selected, enable GSSAPI authentication: 

      # authselect enable-feature with-gssapi
      Copy to Clipboard

    3. If the sssd authselect profile is not selected, select it and enable GSSAPI authentication: 

      # authselect select sssd with-gssapi
      Copy to Clipboard

  6. On RHEL 8.7 or earlier:

    1. Open the /etc/pam.d/sudo PAM configuration file.

    2. Add the following entry as the first line of the auth section in the /etc/pam.d/sudo file. 

      #%PAM-1.0
auth sufficient pam_sss_gss.so
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    include      system-auth
      Copy to Clipboard
    3. Save and close the /etc/pam.d/sudo file.

Verification

  1. Log into the host as the idm_user account. 

    [root@idm-client ~]# ssh -l idm_user@idm.example.com localhost
idm_user@idm.example.com's password:
    Copy to Clipboard

  2. Verify that you have a ticket-granting ticket as the idm_user account. 

    [idmuser@idmclient ~]$ klist
Ticket cache: KCM:1366201107
Default principal: idm_user@IDM.EXAMPLE.COM

Valid starting       Expires              Service principal
01/08/2021 09:11:48  01/08/2021 19:11:48  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
	renew until 01/15/2021 09:11:44
    Copy to Clipboard

  3. Optional: If you do not have Kerberos credentials for the idm_user account, delete your current Kerberos credentials and request the correct ones. 

    [idm_user@idmclient ~]$ kdestroy -A

[idm_user@idmclient ~]$ kinit idm_user@IDM.EXAMPLE.COM
Password for idm_user@idm.example.com:
    Copy to Clipboard

  4. Reboot the machine using sudo, without specifying a password. 

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot
    Copy to Clipboard

20.8. Enabling GSSAPI authentication and enforcing Kerberos authentication indicators for sudo on an IdM client

You can enable Generic Security Service Application Program Interface (GSSAPI) authentication on an Identity Management (IdM) client for PAM-enabled services such as sudo and sudo -i via the pam_sss_gss.so PAM module. Additionally, you can enable only users who have logged in with a smart card to authenticate to those services with their Kerberos ticket.

Note

You can use this procedure as a template to configure GSSAPI authentication with SSSD for other PAM-aware services, and further restrict access to only those users that have a specific authentication indicator attached to their Kerberos ticket.

However, using authentication indicators to restrict access has currently two limitations:

  • Only deployments based on MIT Kerberos support authentication indicators. These deployments include, for example, RHEL IdM, FreeIPA in Fedora, and Samba AD DC in Fedora.
  • Authentication indicators are removed from Kerberos tickets at the realm boundary.

Therefore, if you, for example, want to restrict sudo access by using pam_gssapi_indicators_map = sudo:pkinit, you can only apply this restriction to users stored in IdM LDAP. Tickets issued to users stored elsewhere, such as those stored in Active Directory, currently cannot satisfy the pam_gssapi_indicators_map = sudo:pkinit condition.

Prerequisites

  • You have created a sudo rule for an IdM user that applies to an IdM host. For this example, you have created the idm_user_reboot sudo rule to grant the idm_user account the permission to run the /usr/sbin/reboot command on the idmclient host.
  • You have configured smart card authentication for the idmclient host.
  • The idmclient host is running RHEL 8.4 or later.
  • You need root privileges to modify the /etc/sssd/sssd.conf file and PAM files in the /etc/pam.d/ directory.

Procedure

  1. Open the /etc/sssd/sssd.conf configuration file.

  2. Add the following entries to the [domain/<idm_domain_name>] section. 

    [domain/<idm_domain_name>]
pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo:pkinit, sudo-i:pkinit
    Copy to Clipboard
  3. Save and close the /etc/sssd/sssd.conf file.

  4. Restart the SSSD service to load the configuration changes. 

    [root@idmclient ~]# systemctl restart sssd
    Copy to Clipboard

  5. On RHEL 8.8 or later:

    1. Determine if you have selected the sssd authselect profile: 

      # authselect current
Profile ID: sssd
      Copy to Clipboard

    2. Optional: Select the sssd authselect profile: 

      # authselect select sssd
      Copy to Clipboard

    3. Enable GSSAPI authentication: 

      # authselect enable-feature with-gssapi
      Copy to Clipboard

    4. Configure the system to authenticate only users with smart cards: 

      # authselect with-smartcard-required
      Copy to Clipboard

  6. On RHEL 8.7 or earlier:

    1. Open the /etc/pam.d/sudo PAM configuration file.

    2. Add the following entry as the first line of the auth section in the /etc/pam.d/sudo file. 

      #%PAM-1.0
auth sufficient pam_sss_gss.so
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    include      system-auth
      Copy to Clipboard
    3. Save and close the /etc/pam.d/sudo file.
    4. Open the /etc/pam.d/sudo-i PAM configuration file.

    5. Add the following entry as the first line of the auth section in the /etc/pam.d/sudo-i file. 

      #%PAM-1.0
auth sufficient pam_sss_gss.so
auth       include      sudo
account    include      sudo
password   include      sudo
session    optional     pam_keyinit.so force revoke
session    include      sudo
      Copy to Clipboard
    6. Save and close the /etc/pam.d/sudo-i file.

Verification

  1. Log into the host as the idm_user account and authenticate with a smart card. 

    [root@idmclient ~]# ssh -l idm_user@idm.example.com localhost
PIN for smart_card
    Copy to Clipboard

  2. Verify that you have a ticket-granting ticket as the smart card user. 

    [idm_user@idmclient ~]$ klist
Ticket cache: KEYRING:persistent:1358900015:krb_cache_TObtNMd
Default principal: idm_user@IDM.EXAMPLE.COM

Valid starting       Expires              Service principal
02/15/2021 16:29:48  02/16/2021 02:29:48  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
	renew until 02/22/2021 16:29:44
    Copy to Clipboard

  3. Display which sudo rules the idm_user account is allowed to perform. 

    [idm_user@idmclient ~]$ sudo -l
Matching Defaults entries for idmuser on idmclient:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
    env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
    env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
    env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
    env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User idm_user may run the following commands on idmclient:
    (root) /usr/sbin/reboot
    Copy to Clipboard

  4. Reboot the machine using sudo, without specifying a password. 

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot
    Copy to Clipboard

20.9. SSSD options controlling GSSAPI authentication for PAM services

You can use the following options for the /etc/sssd/sssd.conf configuration file to adjust the GSSAPI configuration within the SSSD service.

pam_gssapi_services
GSSAPI authentication with SSSD is disabled by default. You can use this option to specify a comma-separated list of PAM services that are allowed to try GSSAPI authentication using the pam_sss_gss.so PAM module. To explicitly disable GSSAPI authentication, set this option to -.
pam_gssapi_indicators_map

This option only applies to Identity Management (IdM) domains. Use this option to list Kerberos authentication indicators that are required to grant PAM access to a service. Pairs must be in the format <PAM_service>:_<required_authentication_indicator>_.

Valid authentication indicators are:

  • otp for two-factor authentication
  • radius for RADIUS authentication
  • pkinit for PKINIT, smart card, or certificate authentication
  • hardened for hardened passwords
pam_gssapi_check_upn
This option is enabled and set to true by default. If this option is enabled, the SSSD service requires that the user name matches the Kerberos credentials. If false, the pam_sss_gss.so PAM module authenticates every user that is able to obtain the required service ticket.

Examples

The following options enable Kerberos authentication for the sudo and sudo-i services, requires that sudo users authenticated with a one-time password, and user names must match the Kerberos principal. Because these settings are in the [pam] section, they apply to all domains: 

[pam]
pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo:otp
pam_gssapi_check_upn = true
Copy to Clipboard

You can also set these options in individual [domain] sections to overwrite any global values in the [pam] section. The following options apply different GSSAPI settings to each domain:

For the idm.example.com domain
  • Enable GSSAPI authentication for the sudo and sudo -i services.
  • Require certificate or smart card authentication authenticators for the sudo command.
  • Require one-time password authentication authenticators for the sudo -i command.
  • Enforce matching user names and Kerberos principals.
For the ad.example.com domain
  • Enable GSSAPI authentication only for the sudo service.
  • Do not enforce matching user names and principals. 
[domain/idm.example.com]
pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo:pkinit, sudo-i:otp
pam_gssapi_check_upn = true
...

[domain/ad.example.com]
pam_gssapi_services = sudo
pam_gssapi_check_upn = false
...
Copy to Clipboard

20.10. Troubleshooting GSSAPI authentication for sudo

If you are unable to authenticate to the sudo service with a Kerberos ticket from IdM, use the following scenarios to troubleshoot your configuration.

Prerequisites

Procedure

  • If you see the following error, the Kerberos service might not able to resolve the correct realm for the service ticket based on the host name: 

    Server not found in Kerberos database
    Copy to Clipboard

    In this situation, add the hostname directly to [domain_realm] section in the /etc/krb5.conf Kerberos configuration file: 

    [idm-user@idm-client ~]$ cat /etc/krb5.conf
...

[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM
 server.example.com = EXAMPLE.COM
    Copy to Clipboard

  • If you see the following error, you do not have any Kerberos credentials: 

    No Kerberos credentials available
    Copy to Clipboard

    In this situation, retrieve Kerberos credentials with the kinit utility or authenticate with SSSD: 

    [idm-user@idm-client ~]$ kinit idm-user@IDM.EXAMPLE.COM
Password for idm-user@idm.example.com:
    Copy to Clipboard

  • If you see either of the following errors in the /var/log/sssd/sssd_pam.log log file, the Kerberos credentials do not match the username of the user currently logged in: 

    User with UPN [<UPN>] was not found.

UPN [<UPN>] does not match target user [<username>].
    Copy to Clipboard

    In this situation, verify that you authenticated with SSSD, or consider disabling the pam_gssapi_check_upn option in the /etc/sssd/sssd.conf file: 

    [idm-user@idm-client ~]$ cat /etc/sssd/sssd.conf
...

pam_gssapi_check_upn = false
    Copy to Clipboard

  • For additional troubleshooting, you can enable debugging output for the pam_sss_gss.so PAM module.

    • Add the debug option at the end of all pam_sss_gss.so entries in PAM files, such as /etc/pam.d/sudo and /etc/pam.d/sudo-i: 

      [root@idm-client ~]# cat /etc/pam.d/sudo
#%PAM-1.0
auth       sufficient   pam_sss_gss.so   debug
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    include      system-auth
      Copy to Clipboard 
      [root@idm-client ~]# cat /etc/pam.d/sudo-i
#%PAM-1.0
auth       sufficient   pam_sss_gss.so   debug
auth       include      sudo
account    include      sudo
password   include      sudo
session    optional     pam_keyinit.so force revoke
session    include      sudo
      Copy to Clipboard

    • Try to authenticate with the pam_sss_gss.so module and review the console output. In this example, the user did not have any Kerberos credentials. 

      [idm-user@idm-client ~]$ sudo ls -l /etc/sssd/sssd.conf
pam_sss_gss: Initializing GSSAPI authentication with SSSD
pam_sss_gss: Switching euid from 0 to 1366201107
pam_sss_gss: Trying to establish security context
pam_sss_gss: SSSD User name: idm-user@idm.example.com
pam_sss_gss: User domain: idm.example.com
pam_sss_gss: User principal:
pam_sss_gss: Target name: host@idm.example.com
pam_sss_gss: Using ccache: KCM:
pam_sss_gss: Acquiring credentials, principal name will be derived
pam_sss_gss: Unable to read credentials from [KCM:] [maj:0xd0000, min:0x96c73ac3]
pam_sss_gss: GSSAPI: Unspecified GSS failure.  Minor code may provide more information
pam_sss_gss: GSSAPI: No credentials cache found
pam_sss_gss: Switching euid from 1366200907 to 0
pam_sss_gss: System error [5]: Input/output error
      Copy to Clipboard

20.11. Using an Ansible playbook to ensure sudo access for an IdM user on an IdM client

In Identity Management (IdM), you can ensure sudo access to a specific command is granted to an IdM user account on a specific IdM host.

Complete this procedure to ensure a sudo rule named idm_user_reboot exists. The rule grants idm_user the permission to run the /usr/sbin/reboot command on the idmclient machine.

Prerequisites

Procedure

  1. Create an inventory file, for example inventory.file, and define ipaservers in it: 

    [ipaservers]
server.idm.example.com
    Copy to Clipboard

  2. Add one or more sudo commands:

    1. Create an ensure-reboot-sudocmd-is-present.yml Ansible playbook that ensures the presence of the /usr/sbin/reboot command in the IdM database of sudo commands. To simplify this step, you can copy and modify the example in the /usr/share/doc/ansible-freeipa/playbooks/sudocmd/ensure-sudocmd-is-present.yml file: 

      ---
- name: Playbook to manage sudo command
  hosts: ipaserver

  vars_files:
  - /home/user_name/MyPlaybooks/secret.yml
  tasks:
  # Ensure sudo command is present
  - ipasudocmd:
      ipaadmin_password: "{{ ipaadmin_password }}"
      name: /usr/sbin/reboot
      state: present
      Copy to Clipboard

    2. Run the playbook: 

      $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-reboot-sudocmd-is-present.yml
      Copy to Clipboard

  3. Create a sudo rule that references the commands:

    1. Create an ensure-sudorule-for-idmuser-on-idmclient-is-present.yml Ansible playbook that uses the sudo command entry to ensure the presence of a sudo rule. The sudo rule allows idm_user to reboot the idmclient machine. To simplify this step, you can copy and modify the example in the /usr/share/doc/ansible-freeipa/playbooks/sudorule/ensure-sudorule-is-present.yml file: 

      ---
- name: Tests
  hosts: ipaserver

  vars_files:
  - /home/user_name/MyPlaybooks/secret.yml
  tasks:
  # Ensure a sudorule is present granting idm_user the permission to run /usr/sbin/reboot on idmclient
  - ipasudorule:
      ipaadmin_password: "{{ ipaadmin_password }}"
      name: idm_user_reboot
      description: A test sudo rule.
      allow_sudocmd: /usr/sbin/reboot
      host: idmclient.idm.example.com
      user: idm_user
      state: present
      Copy to Clipboard

    2. Run the playbook: 

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-sudorule-for-idmuser-on-idmclient-is-present.yml
      Copy to Clipboard

Verification

Test that the sudo rule whose presence you have ensured on the IdM server works on idmclient by verifying that idm_user can reboot idmclient using sudo. Note that it can take a few minutes for the changes made on the server to take effect on the client.

  1. Log in to idmclient as idm_user.

  2. Reboot the machine using sudo. Enter the password for idm_user when prompted: 

    $ sudo /usr/sbin/reboot
[sudo] password for idm_user:
    Copy to Clipboard

If sudo is configured correctly, the machine reboots.

Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat