Rajnesh Kumar Siwal wrote:
The details are as follows :-
[root@ipa1 ~]# cat /etc/redhat-release
CentOS release 6.3 (Final)

[root@ipa1 ~]# rpm -qa|grep -i ipa

[root@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.


On Mon, Feb 4, 2013 at 7:59 PM, Rob Crittenden <rcrit...@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.


On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal
<rajnesh.si...@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>)

I disabled that allow_all rule, now it is fine.

On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal
<rajnesh.si...@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.si...@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
        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 ?

Rajnesh Kumar Siwal

Rajnesh Kumar Siwal

Rajnesh Kumar Siwal

Freeipa-users mailing list

Reply via email to