[Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Dmitri Pal]

On 10/17/2012 03:05 PM, Macklin, Jason wrote:
> Yes Dmitri, this is the user I'm doing the tests with on that client.  Though I would expect this user to have sudo capabilities on this host he does not.  I first came across the idea that maybe domainname/nisdomainname/dnsdomainname did not match and that was causing the problem.  I have since fixed all of those to match my system domain which is the same domain that the client was enrolled with and it did not change any of the sudo behaviors for this user.  I currently have no specific HBAC rule configured besides the "wide open" rule.  Do I need one more specific for allowing users to run sudo?

No. It should just work then. It definitely connects and matches the
Admin rule but not the other rules so I was not sure if you are testing
the right rule on the right machine with the right user.

We can start dealing with the problems step by step.
We know Admin rule works.
If you add all hosts to a hostgroup and use it in the Admin rule instead
of just all would it continue to work?
Then you can start removing hosts from the group one by one.

After testing with group you can replace the group with individual host
and see whether it works and so on.
May be there is a bug somewhere but so far we have not narrowed it done
well enough.

I am traveling next day so I hope someone else will pickup the thread.

>
> -----Original Message-----
> From: Dmitri Pal [mailto:dpal at redhat.com] 
> Sent: Wednesday, October 17, 2012 2:57 PM
> To: Macklin, Jason {DASB~Branford}
> Cc: JR.Aquino at citrix.com; freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level.
>
> On 10/17/2012 01:05 PM, Macklin, Jason wrote:
>> Thanks guys!  Adding the "-b" did make a world of difference though it still doesn't make anything too obvious... at least to me.
>>
>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com"
>> SASL/GSSAPI authentication started
>> SASL username: admin at DBR.ROCHE.COM
>> SASL SSF: 56
>> SASL data security layer installed.
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <ou=SUDOers,dc=dbr,dc=roche,dc=com> with scope subtree # 
>> filter: (objectclass=*) # requesting: ALL #
>>
>> # sudoers, dbr.roche.com
>> dn: ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: extensibleObject
>> ou: sudoers
>>
>> # test4, sudoers, dbr.roche.com
>> dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: asteinfeld
>> sudoHost: dbduwdu062.dbr.roche.com
>> sudoHost: +tempsudo
>> sudoCommand: ALL
>> cn: test4
> This means that user "asteinfeld" should be allowed to execute any command on host "dbduwdu062.dbr.roche.com" or any host that is a member of the "tempsudo" host group.
> Is this the user you making tests with?
>
> Keep in mind the other general per-requisits: If you use netgroups the domain should be correct and the netgroups should be configured.
> Also HBAC should allow this user to authenticate via sudo on this host.
> AFAIR your HBAC is now wide open but when you start changing things to narrow access you need to make HBAC rules for SUDO too. 
>> # switch, sudoers, dbr.roche.com
>> dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: oyilmaz
>> sudoHost: dbdusdu071.dbr.roche.com
>> sudoCommand: /bin/su
>> cn: switch
> This rule allows "oyilmaz" to execute one command "/bin/su" on host "dbdusdu071.dbr.roche.com"
>> # jing144, sudoers, dbr.roche.com
>> dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: jli
>> sudoHost: dbduvdu144.dbr.roche.com
>> sudoCommand: ALL
>> cn: jing144
> I hope you can now deduce the meaning of this one :-)
>
>> # Admin, sudoers, dbr.roche.com
>> dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com
>> objectClass: sudoRole
>> sudoUser: jmacklin
>> sudoUser: mrini
>> sudoUser: cgajare
>> sudoUser: parnold
>> sudoUser: hhebert
>> sudoUser: ckuecherer
>> sudoUser: gferreri
>> sudoHost: ALL
>> sudoCommand: ALL
>> cn: Admin
> given users ALL commands on any host.
>
>> # search result
>> search: 4
>> result: 0 Success
>>
>> # numResponses: 6
>> # numEntries: 5
>>
>> I really appreciate all of the help!
>>
>> Cheers,
>> Jason
>>
> So with this knowledge can you try different combinations of users and hosts and provide the results?
> You might want to remove the Admin for now to get it out of picture.
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/