[Freeipa-users] sudo rule working even after the user has been removed from the sudo rule

[Rob Crittenden]

Rajnesh Kumar Siwal wrote:
> The details are as follows :-
> [root at ipa1 ~]# cat /etc/redhat-release
> CentOS release 6.3 (Final)
>
> [root at ipa1 ~]# rpm -qa|grep -i ipa
> ipa-server-2.2.0-17.el6_3.1.x86_64
> libipa_hbac-python-1.8.0-32.el6.x86_64
> ipa-pki-ca-theme-9.0.3-7.el6.noarch
> ipa-python-2.2.0-17.el6_3.1.x86_64
> device-mapper-multipath-libs-0.4.9-56.el6_3.1.x86_64
> libipa_hbac-1.8.0-32.el6.x86_64
> python-iniparse-0.3.1-2.1.el6.noarch
> ipa-client-2.2.0-17.el6_3.1.x86_64
> ipa-server-selinux-2.2.0-17.el6_3.1.x86_64
> ipa-pki-common-theme-9.0.3-7.el6.noarch
> ipa-admintools-2.2.0-17.el6_3.1.x86_64
> device-mapper-multipath-0.4.9-56.el6_3.1.x86_64
>
> [root at ipa1 ~]# uname -a
> Linux ipa1.chargepoint.dmz 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec
> 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> As of now this is a standalone server being run (No replication till now)
> We have been interacting with the Web Interface only.

The ou=sudoers entry in LDAP is a virtual entry managed by the compat 
plugin. It should detect deletes and remove them from its view. If you 
restart the dirsrv service does the entry go away?

>
> One thing, the Server is in "Migration Mode" .
> The users have yet to login into the Migration Page and get their
> credentials created.

Migration mode has no impact on sudo.

> I am not yet aable to migrate sudo roles so will be creating them manually.

There currently no way to import existing sudo rules.

rob
>
>
> On Mon, Feb 4, 2013 at 7:59 PM, Rob Crittenden <rcritten at redhat.com> wrote:
>> Rajnesh Kumar Siwal wrote:
>>>
>>> I deleted the following entry from the IPA WebUI "All Except Shell"
>>> (Sudo Role) but ldapsearch still fetches it (Effectively sudo works
>>> after the deletion of the rule) :-
>>>
>>> dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com
>>> objectClass: sudoRole
>>> sudoUser: %ctsadmin
>>> sudoHost: ALL
>>> sudoCommand: ALL
>>> sudoRunAsUser: ALL
>>> sudoOption: !authenticate
>>> cn: All Except Shell
>>>
>>> Is it present in cache somewhere ?
>>
>>
>> I think we need more information on your configuration, distribution, exact
>> package version(s) and what you've done.
>>
>> rob
>>
>>
>>>
>>> On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal
>>> <rajnesh.siwal at gmail.com> wrote:
>>>>
>>>> Looking into the sssd logs, I came to know there there was one more
>>>> rule allowing access:-
>>>> (Mon Feb  4 14:13:01 2013) [sssd[be[chargepoint.dmz]]]
>>>> [hbac_get_category] (5): Category is set to 'all'.
>>>> (Mon Feb  4 14:13:01 2013) [sssd[be[chargepoint.dmz]]]
>>>> [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all]
>>>> (Mon Feb  4 14:13:01 2013) [sssd[be[chargepoint.dmz]]]
>>>> [be_pam_handler_callback] (4): Backend returned: (0, 0, <NULL>)
>>>> [Success]
>>>>
>>>> I disabled that allow_all rule, now it is fine.
>>>>
>>>> On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal
>>>> <rajnesh.siwal at gmail.com> wrote:
>>>>>
>>>>> Here is the outuput of ldapsearch :-
>>>>> dn: cn=Admins,ou=sudoers,dc=example,dc=com
>>>>> objectClass: sudoRole
>>>>> sudoUser: %ctsadmin
>>>>> sudoHost: ALL
>>>>> sudoCommand: ALL
>>>>> sudoRunAsUser: ALL
>>>>> cn: Admins
>>>>>
>>>>> The rule still says that the group ctsadmin is allowed (Which should
>>>>> not happen after I remove the ctsadmin group from sudo access)
>>>>> On the IPA Web Interface there is not sudo role attached to the  User
>>>>> "rsiwal" (Neither Direct nor Indirect).
>>>>> May be there is some bug.
>>>>>
>>>>>
>>>>> On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal
>>>>> <rajnesh.siwal at gmail.com> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have just created a setup for sudo on the IPA Server 2.2.
>>>>>> I modified nsswitch.conf to use ldap.
>>>>>> ldap.conf has been modified to fetch sudo users from the IPA Server.
>>>>>>
>>>>>> Now, th euser in group "admin" can do sudo.
>>>>>>         1. rsiwal being a user of group sudo can run all commands as
>>>>>> sudo (FINE)
>>>>>>         2. If I disable the rule "Admins" (that I admin group access to
>>>>>> sudo), the sudo still works for the user rsiwal (Which should not work
>>>>>> logically).
>>>>>>         3. Removed the group "Admins" (including rsiwal) from the Sudo
>>>>>> rule. The rule is still allowing user rsiwal to run "sudo su -". (It
>>>>>> should Fail)
>>>>>>
>>>>>> Is there some kind of caching being at the Server / client end ?
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Rajnesh Kumar Siwal
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Rajnesh Kumar Siwal
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Rajnesh Kumar Siwal
>>>
>>>
>>>
>>>
>>
>
>
>