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
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/sudoersfile - Centrally in IdM
You can create a central sudo rule for an IdM client using the command line interface (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.
Additional resources
- See Managing sudo access.
8.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/passwdfile.
Procedure
Retrieve a Kerberos ticket as the IdM
admin.[root@idmclient ~]# kinit adminAdd the
/usr/sbin/rebootcommand to the IdM database ofsudocommands:[root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot ------------------------------------- Added Sudo Command "/usr/sbin/reboot" ------------------------------------- Sudo Command: /usr/sbin/rebootCreate a
sudorule named idm_user_reboot:[root@idmclient ~]# ipa sudorule-add idm_user_reboot --------------------------------- Added Sudo Rule "idm_user_reboot" --------------------------------- Rule name: idm_user_reboot Enabled: TRUEAdd the
/usr/sbin/rebootcommand 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 -------------------------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 -------------------------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 -------------------------Optionally, define the validity of the idm_user_reboot rule:
To define the time at which a
sudorule starts to be valid, use theipa sudorule-mod sudo_rule_namecommand with the--setattr sudonotbefore=DATEoption. 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=20251231123400ZTo define the time at which a sudo rule stops being valid, use the
--setattr sudonotafter=DATEoption. 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
Propagating the changes from the server to the client can take a few minutes.
Verification steps
- Log in to the idmclient host as the idm_user account.
Display which
sudorules 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
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:
8.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:
- Add the AD users or groups to a non-POSIX external IdM group.
- 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.
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
adminKerberos 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/passwdfile.
Procedure
Create the ad_users group that contains the ad_users_external group with the administrator@ad-domain member:
- 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.
Create the ad_users_external group and indicate that it contains members from outside the IdM domain by adding the
--externaloption:[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 mapNoteEnsure that the external group that you specify here is an AD security group with a
globaloruniversalgroup 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 isdomain local.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: 129600004Add 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 -------------------------The AD user must be identified by a fully-qualified name, such as
DOMAIN\user_nameoruser_name@DOMAIN. The AD identity is then mapped to the AD SID for the user. The same applies to adding AD groups.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 -------------------------
Grant the members of ad_users the permission to run
/usr/sbin/rebooton the idmclient host:Add the
/usr/sbin/rebootcommand to the IdM database ofsudocommands:[root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot ------------------------------------- Added Sudo Command "/usr/sbin/reboot" ------------------------------------- Sudo Command: /usr/sbin/rebootCreate a
sudorule named ad_users_reboot:[root@idmclient ~]# ipa sudorule-add ad_users_reboot --------------------------------- Added Sudo Rule "ad_users_reboot" --------------------------------- Rule name: ad_users_reboot Enabled: TrueAdd the
/usr/sbin/rebootcommand 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 -------------------------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 -------------------------Add the
ad_usersgroup 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 -------------------------
Propagating the changes from the server to the client can take a few minutes.
Verification steps
Log in to the idmclient host as administrator@ad-domain.com, an indirect member of the
ad_usersgroup:$ ssh administrator@ad-domain.com@ipaclient Password:Optionally, display the
sudocommands thatadministrator@ad-domain.comis 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
Reboot the machine using
sudo. Enter the password foradministrator@ad-domain.comwhen prompted:[administrator@ad-domain.com@idmclient ~]$ sudo /usr/sbin/reboot [sudo] password for administrator@ad-domain.com:
8.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_userin IdM and unlocked the account by creating a password for the user. For details on adding a new IdM user using the command-line interface, see Adding users using the command line. -
No local
idm_useraccount is present on theidmclienthost. Theidm_useruser is not listed in the local/etc/passwdfile.
Procedure
Add the
/usr/sbin/rebootcommand to the IdM database ofsudocommands:- Navigate to Policy → Sudo → Sudo Commands.
- Click Add in the upper right corner to open the Add sudo command dialog box.
Enter the command you want the user to be able to perform using
sudo:/usr/sbin/reboot.Figure 8.1. Adding IdM sudo command

- Click Add.
Use the new
sudocommand entry to create a sudo rule to allow idm_user to reboot the idmclient machine:- Navigate to Policy → Sudo → Sudo rules.
- Click Add in the upper right corner to open the Add sudo rule dialog box.
-
Enter the name of the
sudorule: idm_user_reboot. - Click Add and Edit.
Specify the user:
- In the Who section, check the Specified Users and Groups radio button.
- In the User category the rule applies to subsection, click Add to open the Add users into sudo rule "idm_user_reboot" dialog box.
- 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.
- Click Add.
Specify the host:
- In the Access this host section, check the Specified Hosts and Groups radio button.
- In the Host category this rule applies to subsection, click Add to open the Add hosts into sudo rule "idm_user_reboot" dialog box.
- 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.
- Click Add.
Specify the commands:
- In the Command category the rule applies to subsection of the Run Commands section, check the Specified Commands and Groups radio button.
- In the Sudo Allow Commands subsection, click Add to open the Add allow sudo commands into sudo rule "idm_user_reboot" dialog box.
-
In the Add allow sudo commands into sudo rule "idm_user_reboot" dialog box in the Available column, check the
/usr/sbin/rebootcheckbox, and move it to the Prospective column. - Click Add to return to the idm_sudo_reboot page.
Figure 8.2. Adding IdM sudo rule

- Click Save in the top left corner.
The new rule is enabled by default.
Propagating the changes from the server to the client can take a few minutes.
Verification steps
-
Log in to
idmclientasidm_user. Reboot the machine using
sudo. Enter the password foridm_userwhen prompted:$ sudo /usr/sbin/reboot [sudo] password for idm_user:
If the sudo rule is configured correctly, the machine reboots.
8.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_userin 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_useraccount is present on theidmclienthost. Theidm_useruser is not listed in the local/etc/passwdfile. -
You have a custom application named
third-party-appinstalled on theidmclienthost. -
The
reportcommand for thethird-party-appapplication is installed in the/opt/third-party-app/bin/reportdirectory. -
You have created a local service account named
thirdpartyappto execute commands for thethird-party-appapplication.
Procedure
Retrieve a Kerberos ticket as the IdM
admin.[root@idmclient ~]# kinit adminAdd the
/opt/third-party-app/bin/reportcommand to the IdM database ofsudocommands:[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/reportCreate a
sudorule namedrun_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: TRUEUse the
--users=<user>option to specify the RunAs user for thesudorule-add-runasusercommand:[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 -------------------------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.Add the
/opt/third-party-app/bin/reportcommand to therun_third-party-app_reportrule:[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 -------------------------Apply the
run_third-party-app_reportrule to the IdMidmclienthost:[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 -------------------------Add the
idm_useraccount to therun_third-party-app_reportrule:[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
Propagating the changes from the server to the client can take a few minutes.
Verification steps
-
Log in to the
idmclienthost as theidm_useraccount. Test the new sudo rule:
Display which
sudorules theidm_useraccount 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
Run the
reportcommand as thethirdpartyappservice 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.
8.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_userin 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_useraccount is present on theidmclienthost. Theidm_useruser is not listed in the local/etc/passwdfile. -
You have a custom application named
third-party-appinstalled on theidmclienthost. -
The
reportcommand for thethird-party-appapplication is installed in the/opt/third-party-app/bin/reportdirectory. -
You have created a local service account named
thirdpartyappto execute commands for thethird-party-appapplication.
Procedure
Add the
/opt/third-party-app/bin/reportcommand to the IdM database ofsudocommands:- Navigate to Policy → Sudo → Sudo Commands.
- Click Add in the upper right corner to open the Add sudo command dialog box.
Enter the command:
/opt/third-party-app/bin/report.
- Click Add.
Use the new
sudocommand entry to create the newsudorule:- Navigate to Policy → Sudo → Sudo rules.
- Click Add in the upper right corner to open the Add sudo rule dialog box.
Enter the name of the
sudorule: run_third-party-app_report.
- Click Add and Edit.
Specify the user:
- In the Who section, check the Specified Users and Groups radio button.
- 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.
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.

- Click Add.
Specify the host:
- In the Access this host section, check the Specified Hosts and Groups radio button.
- 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.
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.

- Click Add.
Specify the commands:
- In the Command category the rule applies to subsection of the Run Commands section, check the Specified Commands and Groups radio button.
- 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.
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/reportcheckbox, and move it to the Prospective column.
- Click Add to return to the run_third-party-app_report page.
Specify the RunAs user:
- In the As Whom section, check the Specified Users and Groups radio button.
- In the RunAs Users subsection, click Add to open the Add RunAs users into sudo rule "run_third-party-app_report" dialog box.
In the Add RunAs users into sudo rule "run_third-party-app_report" dialog box, enter the
thirdpartyappservice account in the External box and move it to the Prospective column.
- Click Add to return to the run_third-party-app_report page.
- Click Save in the top left corner.
The new rule is enabled by default.
Figure 8.3. Details of the sudo rule

Propagating the changes from the server to the client can take a few minutes.
Verification steps
-
Log in to the
idmclienthost as theidm_useraccount. Test the new sudo rule:
Display which
sudorules theidm_useraccount 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
Run the
reportcommand as thethirdpartyappservice 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.
8.7. Enabling GSSAPI authentication for sudo on an IdM client
The following procedure describes enabling 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
sudorule for an IdM user that applies to an IdM host. For this example, you have created theidm_user_rebootsudorule to grant theidm_useraccount the permission to run the/usr/sbin/rebootcommand on theidmclienthost. -
You need
rootprivileges to modify the/etc/sssd/sssd.conffile and PAM files in the/etc/pam.d/directory.
Procedure
-
Open the
/etc/sssd/sssd.confconfiguration file. Add the following entry to the
[domain/<domain_name>]section.[domain/<domain_name>] pam_gssapi_services = sudo, sudo-i
-
Save and close the
/etc/sssd/sssd.conffile. Restart the SSSD service to load the configuration changes.
[root@idmclient ~]# systemctl restart sssdIf you are running RHEL 9.2 or later:
[Optional] Determine if you have selected the
sssdauthselectprofile:# authselect current Profile ID: sssdThe output says that the
sssdauthselectprofile is selected.If the
sssdauthselectprofile is selected, enable GSSAPI authentication:# authselect enable-feature with-gssapiIf the
sssdauthselectprofile is not selected, select it and enable GSSAPI authentication:# authselect select sssd with-gssapi
If you are running RHEL 9.1 or earlier:
-
Open the
/etc/pam.d/sudoPAM configuration file. Add the following entry as the first line of the
authsection in the/etc/pam.d/sudofile.#%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-
Save and close the
/etc/pam.d/sudofile.
-
Open the
Verification steps
Log into the host as the
idm_useraccount.[root@idm-client ~]# ssh -l idm_user@idm.example.com localhost idm_user@idm.example.com's password:Verify that you have a ticket-granting ticket as the
idm_useraccount.[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
(Optional) If you do not have Kerberos credentials for the
idm_useraccount, 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:
Reboot the machine using
sudo, without specifying a password.[idm_user@idmclient ~]$ sudo /usr/sbin/reboot
Additional resources
- The GSSAPI entry in the IdM terminology listing
- Granting sudo access to an IdM user on an IdM client using IdM Web UI
- Granting sudo access to an IdM user on an IdM client using the CLI
-
pam_sss_gss (8)man page -
sssd.conf (5)man page
8.8. Enabling GSSAPI authentication and enforcing Kerberos authentication indicators for sudo on an IdM client
The following procedure describes enabling 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. Additionally, only users who have logged in with a smart card will authenticate to those commands with their Kerberos ticket.
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.
Prerequisites
-
You have created a
sudorule for an IdM user that applies to an IdM host. For this example, you have created theidm_user_rebootsudorule to grant theidm_useraccount the permission to run the/usr/sbin/rebootcommand on theidmclienthost. -
You have configured smart card authentication for the
idmclienthost. -
You need
rootprivileges to modify the/etc/sssd/sssd.conffile and PAM files in the/etc/pam.d/directory.
Procedure
-
Open the
/etc/sssd/sssd.confconfiguration file. 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
-
Save and close the
/etc/sssd/sssd.conffile. Restart the SSSD service to load the configuration changes.
[root@idmclient ~]# systemctl restart sssd-
Open the
/etc/pam.d/sudoPAM configuration file. Add the following entry as the first line of the
authsection in the/etc/pam.d/sudofile.#%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-
Save and close the
/etc/pam.d/sudofile. -
Open the
/etc/pam.d/sudo-iPAM configuration file. Add the following entry as the first line of the
authsection in the/etc/pam.d/sudo-ifile.#%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-
Save and close the
/etc/pam.d/sudo-ifile.
Verification steps
Log into the host as the
idm_useraccount and authenticate with a smart card.[root@idmclient ~]# ssh -l idm_user@idm.example.com localhost PIN for smart_cardVerify 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
Display which
sudorules theidm_useraccount 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
Reboot the machine using
sudo, without specifying a password.[idm_user@idmclient ~]$ sudo /usr/sbin/reboot
Additional resources
- SSSD options controlling GSSAPI authentication for PAM services
- The GSSAPI entry in the IdM terminology listing
- Configuring Identity Management for smart card authentication
- Kerberos authentication indicators
- Granting sudo access to an IdM user on an IdM client using IdM Web UI
- Granting sudo access to an IdM user on an IdM client using the CLI.
-
pam_sss_gss (8)man page -
sssd.conf (5)man page
8.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.soPAM 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:
-
otpfor two-factor authentication -
radiusfor RADIUS authentication -
pkinitfor PKINIT, smart card, or certificate authentication -
hardenedfor hardened passwords
-
- pam_gssapi_check_upn
-
This option is enabled and set to
trueby default. If this option is enabled, the SSSD service requires that the user name matches the Kerberos credentials. Iffalse, thepam_sss_gss.soPAM 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
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.comdomain -
Enable GSSAPI authentication for the
sudoandsudo -iservices. -
Require certificate or smart card authentication authenticators for the
sudocommand. -
Require one-time password authentication authenticators for the
sudo -icommand. - Enforce matching user names and Kerberos principals.
-
Enable GSSAPI authentication for the
- For the
ad.example.comdomain -
Enable GSSAPI authentication only for the
sudoservice. - Do not enforce matching user names and principals.
-
Enable GSSAPI authentication only for the
[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 ...
Additional resources
8.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
-
You have enabled GSSAPI authentication for the
sudoservice. See Enabling GSSAPI authentication for sudo on an IdM client. -
You need
rootprivileges to modify the/etc/sssd/sssd.conffile and PAM files in the/etc/pam.d/directory.
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
In this situation, add the hostname directly to
[domain_realm]section in the/etc/krb5.confKerberos configuration file:[idm-user@idm-client ~]$ cat /etc/krb5.conf ... [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM server.example.com = EXAMPLE.COMIf you see the following error, you do not have any Kerberos credentials:
No Kerberos credentials available
In this situation, retrieve Kerberos credentials with the
kinitutility or authenticate with SSSD:[idm-user@idm-client ~]$ kinit idm-user@IDM.EXAMPLE.COM Password for idm-user@idm.example.com:
If you see either of the following errors in the
/var/log/sssd/sssd_pam.loglog 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>].
In this situation, verify that you authenticated with SSSD, or consider disabling the
pam_gssapi_check_upnoption in the/etc/sssd/sssd.conffile:[idm-user@idm-client ~]$ cat /etc/sssd/sssd.conf ... pam_gssapi_check_upn = falseFor additional troubleshooting, you can enable debugging output for the
pam_sss_gss.soPAM module.Add the
debugoption at the end of allpam_sss_gss.soentries in PAM files, such as/etc/pam.d/sudoand/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[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 sudoTry to authenticate with the
pam_sss_gss.somodule 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
8.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
You have configured your Ansible control node to meet the following requirements:
- You are using Ansible version 2.14 or later.
-
You have installed the
ansible-freeipapackage on the Ansible controller. - The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
-
The example assumes that the secret.yml Ansible vault stores your
ipaadmin_password.
- You have ensured the presence of 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 interface, see link: Adding users using the command line.
-
No local idm_user account exists on idmclient. The idm_user user is not listed in the
/etc/passwdfile on idmclient.
Procedure
Create an inventory file, for example
inventory.file, and defineipaserversin it:[ipaservers] server.idm.example.com
Add one or more
sudocommands:Create an
ensure-reboot-sudocmd-is-present.ymlAnsible playbook that ensures the presence of the/usr/sbin/rebootcommand in the IdM database ofsudocommands. To simplify this step, you can copy and modify the example in the/usr/share/doc/ansible-freeipa/playbooks/sudocmd/ensure-sudocmd-is-present.ymlfile:--- - 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: presentRun 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
Create a
sudorule that references the commands:Create an
ensure-sudorule-for-idmuser-on-idmclient-is-present.ymlAnsible playbook that uses thesudocommand 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.ymlfile:--- - 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: presentRun 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
Verification steps
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.
- Log in to idmclient as idm_user.
Reboot the machine using
sudo. Enter the password for idm_user when prompted:$ sudo /usr/sbin/reboot [sudo] password for idm_user:
If sudo is configured correctly, the machine reboots.
Additional resources
-
See the
README-sudocmd.md,README-sudocmdgroup.md, andREADME-sudorule.mdfiles in the/usr/share/doc/ansible-freeipa/directory.