Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Automated sudo Configuration on IPA Clients
In Red Hat Enterprise Linux 6.6, the ipa-client-install script configures the sudo utility on IPA clients by default. FreeIPA sudo integration is a widely popular feature, which can, however, pose some configuration challenges. The integration is now seamless, and ipa-client-install leverages a newly added IPA provider in sssd.
Small demonstration of the feature:
# hostname
vm-086.idm.lab.bos.redhat.com
# ipa-server-install
# nisdomainname <--- NIS domain name is set, required for hosgroup based SUDO rules
idm.lab.bos.redhat.com
# tail /etc/nsswitch.conf
...
sudoers: files sss <--- sudoers is set to sssd
# grep services /etc/sssd/sssd.conf
services = nss, sudo, pam, ssh <--- sudo is an enabled service
Now we add SUDO rule targetted on a hostgroup containing vm-086.idm.lab.bos.redhat.com and user admin:
# kinit admin
# ipa hostgroup-add foo
# ipa hostgroup-add-member foo --hosts `hostname`
# ipa sudocmd-add /usr/bin/less
# ipa sudorule-add foo
# ipa sudorule-add-user foo --users admin
# ipa sudorule-add-host foo --hostgroups foo
# ipa sudorule-add-allow-command foo --sudocmds /usr/bin/less
# ipa sudorule-show foo
Rule name: foo
Enabled: TRUE
Users: admin
Host Groups: foo
Sudo Allow Commands: /usr/bin/less
Now we can try if sudo can read this rule through SSSD when we log as admin:
# su - admin
$ sudo -l
Matching Defaults entries for admin on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE
INPUTRC 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", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User admin may run the following commands on this host:
(root) /usr/bin/less
$ sudo /usr/bin/less /etc/shadow
[sudo] password for admin:
<--- opens the file
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2014-1383.html
Small demonstration of the feature: # hostname vm-086.idm.lab.bos.redhat.com # ipa-server-install # nisdomainname <--- NIS domain name is set, required for hosgroup based SUDO rules idm.lab.bos.redhat.com # tail /etc/nsswitch.conf ... sudoers: files sss <--- sudoers is set to sssd # grep services /etc/sssd/sssd.conf services = nss, sudo, pam, ssh <--- sudo is an enabled service Now we add SUDO rule targetted on a hostgroup containing vm-086.idm.lab.bos.redhat.com and user admin: # kinit admin # ipa hostgroup-add foo # ipa hostgroup-add-member foo --hosts `hostname` # ipa sudocmd-add /usr/bin/less # ipa sudorule-add foo # ipa sudorule-add-user foo --users admin # ipa sudorule-add-host foo --hostgroups foo # ipa sudorule-add-allow-command foo --sudocmds /usr/bin/less # ipa sudorule-show foo Rule name: foo Enabled: TRUE Users: admin Host Groups: foo Sudo Allow Commands: /usr/bin/less Now we can try if sudo can read this rule through SSSD when we log as admin: # su - admin $ sudo -l Matching Defaults entries for admin on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC 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", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User admin may run the following commands on this host: (root) /usr/bin/less $ sudo /usr/bin/less /etc/shadow [sudo] password for admin: <--- opens the file