Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Este conteúdo não está disponível no idioma selecionado.

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

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

8.1. Sudo access on an IdM client
Copiar o link

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.

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.

8.2. Granting sudo access to an IdM user on an IdM client using the CLI
Copiar o link

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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap

    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 Toggle word wrap
    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 Toggle word wrap

  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 Toggle word wrap

8.3. Granting sudo access to an AD user on an IdM client using the CLI
Copiar o link

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.

Note

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 Toggle word wrap
      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 Toggle word wrap

    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 Toggle word wrap

      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 Toggle word wrap

  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 Toggle word wrap

    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 Toggle word wrap

    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 Toggle word wrap

    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 Toggle word wrap

    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 Toggle word wrap
    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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap

8.4. Granting sudo access to an IdM user on an IdM client using the IdM Web UI
Copiar o link

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.

      A screenshot of a pop-up window labeled
      View larger image
      A screenshot of a pop-up window labeled
    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 User category the rule applies to subsection, click Add to open the Add users into sudo rule "idm_user_reboot" dialog box.
      3. In the Add users into sudo rule "idm_user_reboot" dialog box 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 Host category this rule applies to subsection, click Add to open the Add hosts into sudo rule "idm_user_reboot" dialog box.
      3. In the Add hosts into sudo rule "idm_user_reboot" dialog box 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 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 "idm_user_reboot" dialog box.
      3. In the Add allow sudo commands into sudo rule "idm_user_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 8.1. Adding IdM sudo rule

      A screenshot of an overview of the sudo rule that was added. There is a
      View larger image
      A screenshot of an overview of the sudo rule that was added. There is a

    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 Toggle word wrap

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

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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap

    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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap
    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 Toggle word wrap

    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 Toggle word wrap

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.

      A screenshot of a pop-up window labeled
      View larger image
      A screenshot of a pop-up window labeled
    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.

      A screenshot of a pop-up window labeled
      View larger image
      A screenshot of a pop-up window labeled
    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 "run_third-party-app_report" dialog box.

      3. In the Add users into sudo rule "run_third-party-app_report" dialog box in the Available column, check the idm_user checkbox, and move it to the Prospective column.

        A screenshot of a pop-up window labeled
        View larger image
        A screenshot of a pop-up window labeled
      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 "run_third-party-app_report" dialog box.

      3. In the Add hosts into sudo rule "run_third-party-app_report" dialog box in the Available column, check the idmclient.idm.example.com checkbox, and move it to the Prospective column.

        A screenshot of a pop-up window labeled
        View larger image
        A screenshot of a pop-up window labeled
      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 "run_third-party-app_report" dialog box.

      3. In the Add allow sudo commands into sudo rule "run_third-party-app_report" dialog box in the Available column, check the /opt/third-party-app/bin/report checkbox, and move it to the Prospective column.

        A screenshot of a pop-up window labeled
        View larger image
        A screenshot of a pop-up window labeled
      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 subsection, click Add to open the Add RunAs users into sudo rule "run_third-party-app_report" dialog box.

      3. In the Add RunAs users into sudo rule "run_third-party-app_report" dialog box, enter the thirdpartyapp service account in the External box and move it to the Prospective column.

        A screenshot of a dialog box where you can specify the
        View larger image
        A screenshot of a dialog box where you can specify the
      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.

      The following image shows the details of a sudo rule created in the IdM Web UI:

      A screenshot of an overview of the sudo rule that was added. The
      View larger image
      A screenshot of an overview of the sudo rule that was added. The
    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 Toggle word wrap

    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 Toggle word wrap

8.7. Enabling GSSAPI authentication for sudo on an IdM client
Copiar o link

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.
  • 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 Toggle word wrap
  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 Toggle word wrap

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

    # authselect current
Profile ID: sssd
    Copy to Clipboard Toggle word wrap

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

    # authselect enable-feature with-gssapi
    Copy to Clipboard Toggle word wrap

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

    # authselect select sssd with-gssapi
    Copy to Clipboard Toggle word wrap

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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap

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

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

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.
  • 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/<domain_name>] section. 

    [domain/<domain_name>]
pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo:pkinit, sudo-i:pkinit
    Copy to Clipboard Toggle word wrap
  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 Toggle word wrap

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

    # authselect current
Profile ID: sssd
    Copy to Clipboard Toggle word wrap

  6. Optional: Select the sssd authselect profile: 

    # authselect select sssd
    Copy to Clipboard Toggle word wrap

  7. Enable GSSAPI authentication: 

    # authselect enable-feature with-gssapi
    Copy to Clipboard Toggle word wrap

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

    # authselect with-smartcard-required
    Copy to Clipboard Toggle word wrap

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 Toggle word wrap

  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 Toggle word wrap

  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 Toggle word wrap

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

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

8.9. SSSD options controlling GSSAPI authentication for PAM services
Copiar o link

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.

8.9.1. SSSD GSSAPI configuration examples
Copiar o link

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 Toggle word wrap

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 Toggle word wrap

8.10. Troubleshooting GSSAPI authentication for sudo
Copiar o link

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 Toggle word wrap

    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 Toggle word wrap

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

    No Kerberos credentials available
    Copy to Clipboard Toggle word wrap

    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 Toggle word wrap

  • 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 Toggle word wrap

    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 Toggle word wrap

  • 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 Toggle word wrap 
      [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 Toggle word wrap

    • 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 Toggle word wrap
Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat