[Freeipa-users] Sudo privilege inheritance in FreeIPA (3.0.x branch)

[sysadmin ofdoom]

Note:     sudo rule "testSudo" fails when using user group. But succeeds
when using a directly defined user.
        sudo rule "sudo-1" fails when user defined directly, but hosts are
defined with host group.

The behaviour that I'm observing is: sudo rules are not functioning any
time the user or host are not defined directly in the sudo rule. And yes I
have set the nisdomainname.

My
Failing config:
====================
[root at freeipaserver ~]# ipa user-show
User login: aaaa
  User login: aaaa
  First name: bbbb
  Last name: bbbb
  Home directory: /home/aaaa
  Login shell: /bin/bash
  Email address: aaaa at example.com
  UID: 591700000
  GID: 591700000
  Account disabled: False
  Password: True
  Member of groups: ipausers, ug1-sudo
  Indirect Member of Sudo rule: sudo-1, testSudo
  Indirect Member of HBAC rule: hbac1
  Kerberos keys available: True

[root at freeipaserver ~]# ipa sudorule-show
Rule name: sudo-1
  Rule name: sudo-1
  Description: Sudo privilege policy for HG1
  Enabled: TRUE
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  User Groups: ug1-sudo
  Host Groups: hg1

[root at freeipaserver ~]# ipa sudorule-show
Rule name: testSudo
  Rule name: testSudo
  Enabled: TRUE
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  User Groups: ug1-sudo
  Hosts: ipaclient.city.state.example.com

[root at freeipaserver ~]# ipa hostgroup-show
Host-group: hg1
  Host-group: hg1
  Description: Host group 1 - Contains non hardened hosts
  Member hosts: ipaclient.city.state.example.com
  Member of Sudo rule: sudo-1
  Member of HBAC rule: hbac1


Working Config:
===================

[root at freeipaserver~]# ipa user-show
User login: aaaa
  User login: aaaa
  First name: bbbb
  Last name: bbbb
  Home directory: /home/aaaa
  Login shell: /bin/bash
  Email address: aaaa at charter.com
  UID: 591700000
  GID: 591700000
  Account disabled: False
  Password: True
  Member of groups: ipausers, ug1-sudo
  Member of Sudo rule: testSudo
  Indirect Member of Sudo rule: sudo-1
  Indirect Member of HBAC rule: hbac1
  Kerberos keys available: True

[root at freeipaserver ~]# ipa sudorule-show
Rule name: testSudo
  Rule name: testSudo
  Enabled: TRUE
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  Users: aaaa
  Hosts: ipaclient.city.state.example.com





On Wed, Jan 27, 2016 at 09:36:13AM -0700, sysadmin ofdoom wrote:
> I am trying to implement FreeIPA in a larger environment. Due to the
> complexity of the environment I've been constructing a user group structure
> such that i have groups at the following levels:
>
> project --> project_at_site --> project_site_vendor

I'm not sure the order of the hierarchy is correct, can you show an
example with ipa group-show?

>
> HBAC rules are defined at the lowest level (vendor at site) and associated
> with a host group at the same level.
>
> Each of the above user group levels will have a corresponding sudo group.
> (Used to provide a vendor access to servers  the vendor supports at a
> specific site at a moments notice)
>
> HBAC rules are propagating up the chain correctly.
>
> When a user is added to a top level group (e.g. project or project-sudo)
> the indirect membership shows up for both Sudo and HBAC rules.
>
> The problem is that I can't get the sudo privileges to work when the user
> shows indirect membership for the sudo rule. If i make the user a direct
> member of the sudo rule, i can use sudo.
>
> As I've looked at debug logs, i was able to see that the query used when i
> was identical when i was successful at using sudo and when i i got denied.
> The difference is  the failure would have a message like
> [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [
> user example com]  The successes returned 2 rules.
>
> The only change made between the success and failure was making the user a
> direct member of the sudo rule where the failure was an indirect member.
>
> Thanks for any help!

sudo uses the list of groups as returned by initgroups()/getgrouplist(),
so if the user is a member of that group (as reported by id $user), then
the sudo rule should match.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160204/97033789/attachment.htm>