<div dir="ltr">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@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: <a href="mailto:aaaa@example.com">aaaa@example.com</a> 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@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@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: <a href="http://ipaclient.city.state.example.com">ipaclient.city.state.example.com</a> [root@freeipaserver ~]# ipa hostgroup-show Host-group: hg1 Host-group: hg1 Description: Host group 1 - Contains non hardened hosts Member hosts: <a href="http://ipaclient.city.state.example.com">ipaclient.city.state.example.com</a> Member of Sudo rule: sudo-1 Member of HBAC rule: hbac1 Working Config: =================== [root@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: <a href="mailto:aaaa@charter.com">aaaa@charter.com</a> 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@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: <a href="http://ipaclient.city.state.example.com">ipaclient.city.state.example.com</a> <pre> 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.</pre></div>