[Freeipa-users] sudo rules user and host group bugs?

Tovey, Mark MTovey at go2uti.com
Mon Jul 15 18:00:19 UTC 2013



    Did anyone find a solution for this?  I am having the same experience.

ipa sudorule-show my_sudo_rule
  Rule name: my_sudo_rule
  Enabled: TRUE
  Command category: all
  User Groups: ugroup1, ugroup2, ugroup3
  Host Groups: hgroup1

ipa hostgroup-show hgroup1
  Host-group: hgroup1
  Description: Test host group
  Member hosts: server1.my_domain.com, server2.my_domain.com,
                server3.my_domain.com, server4.my_domain.com
  Member of HBAC rule: hbac_rule1
  Member of Sudo rule: my_sudo_rule

    Only when I add the hosts directly into the sudo rule instead of indirectly through a host group does the sudo rule work.

    Thanks,
    -Mark



On Jun 5, 2013, at 1:47 PM, KodaK wrote:

Sorry, for some reason gmail makes me forget about "reply all."

On Wed, Jun 5, 2013 at 2:45 PM, Dmitri Pal <dpal redhat com<mailto:dpal redhat com>> wrote:
On 06/05/2013 11:20 AM, KodaK wrote:
I know this has been discussed before, but I didn't see anything with a cursory search.

There are bugs when using user and host groups with sudo rules.  I have to split out my users and hosts into individual entries.  I'm running ipa 3.0.0-26 on RHEL.

All I really want to know is if this is fixed upstream.


I am not sure I recall a bug you are referring to. A quick scan against the open tickets does not reveal anything like what you describe.
Can you provide the description of the issue or point to the earlier thread on the matter?


I'm going off of memory on seeing the previous bug.  It very well could be a false memory.

I have a rule like this:

[jebalicki mo0033802 ~]$ ipa sudorule-show esolutions-sandbox-root-access
  Rule name: esolutions-sandbox-root-access
  Enabled: TRUE
  Users: slfries, awellard
  Hosts: slnessbxl01.unix.magellanhealth.com
  Sudo Allow Commands: /bin/su -

This works.  However, if I change the rule to use hostgroups instead of listing the hosts individually the rule will not work.

The groups still exist and look like this:

[jebalicki mo0033802 ~]$ ipa hostgroup-show esolutions-sandbox-hosts
  Host-group: esolutions-sandbox-hosts
  Description: esolutions sandbox hosts
  Member hosts: slnessbxl01.unix.magellanhealth.com
  Member of HBAC rule: esolutions-sandbox-access

[jebalicki mo0033802 ~]$ ipa group-show esolutions
  Group name: esolutions
  Description: esolutions group
  GID: 1115600250
  Member users: awellard, slfries
  Member of HBAC rule: esolutions-sandbox-access

Client machine is pretty much default-out-of-the-box IRT IPA configuration, here's the installer output (installs during kickstart):

[root slnessbxl01 ~]# cat ks-post.log
Discovery was successful!
Hostname: slnessbxl01.unix.magellanhealth.com
Realm: UNIX.MAGELLANHEALTH.COM
DNS Domain: UNIX.MAGELLANHEALTH.COM
IPA Server: slpidml01.unix.magellanhealth.com
BaseDN: dc=unix,dc=magellanhealth,dc=com


Synchronizing time with KDC...

Enrolled in IPA realm UNIX.MAGELLANHEALTH.COM
Created /etc/ipa/default.conf
New SSSD config will be created.
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm UNIX.MAGELLANHEALTH.COM
Warning: Hostname (slnessbxl01.unix.magellanhealth.com) not found in DNS
DNS server record set to: slnessbxl01.unix.magellanhealth.com -> 10.200.12.104
SSSD enabled
NTP enabled
Client configuration complete.

[root slnessbxl01 ~]# rpm -qa | grep ipa
python-iniparse-0.3.1-2.1.el6.noarch
libipa_hbac-python-1.8.0-32.el6.x86_64
libipa_hbac-1.8.0-32.el6.x86_64
ipa-client-2.2.0-16.el6.x86_64
ipa-python-2.2.0-16.el6.x86_64
[root slnessbxl01 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
[root slnessbxl01 ~]#

Troubleshooting:

Can you confirm that the output of the following commands:
1. $ domainname
* does it match your domain?
2. $ hostname
* does match match your fqdn?
3. $ getent netgroup esolutions-sandbox-hosts
* does this list your host?
4. Does /etc/nsswitch.conf contain the line: "netgroup:   files sss"?


Another important Sudo Troubleshooting step is to edit: /etc/sudo-ldap.conf (or /etc/ldap.conf, depending on what version of RHEL/Sudo you're running):

At the top, add the line: sudoers_debug 2

Then try another sudo command. sudo -l for example.

This should result in a long list of search criteria and status.  The last few lines should indicate where any matches occurred.

"Keeping your head in the cloud"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
JR Aquino

Senior Information Security Specialist, Technical Operations
T: +1 805 690 3478 | F: +1 805 879 3730 | M: +1 805 717 0365
GIAC Certified Exploit Researcher and Advanced Penetration Tester |
GIAC WebApplication Penetration Tester | GIAC Certified Incident Handler
JR Aquino citrix com<mailto:JR Aquino citrix com>

[cid:image002.jpg at 01CD4A37.5451DC00]



Powering mobile workstyles and cloud services


________________________________________________________________
Mark Tovey - UNIX Engineer | Service Strategy & Design
UTi<http://www.go2uti.com/> | 400 SW Sixth Ave, Suite 1100 | Portland | Oregon | 97204 | USA
MTovey at go2uti.com<mailto:MTovey at go2uti.com> | O / C +1 503 953-1389 | Skype: mark.tovey2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130715/e614775a/attachment.htm>


More information about the Freeipa-users mailing list