Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
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 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
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 ? 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) [Success] 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 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 -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
Restarting IPA removed the rule that was deleted manually through GUI . It looks like a bug the IPA Webui was not able to delete the sudo rule cn: All Except Shell On Mon, Feb 4, 2013 at 3:54 PM, Rajnesh Kumar Siwal rajnesh.si...@gmail.com 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 ? 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) [Success] 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 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 -- Regards, Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
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.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) [Success] 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 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
The details are as follows :- [root@ipa1 ~]# cat /etc/redhat-release CentOS release 6.3 (Final) [root@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@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. One thing, the Server is in Migration Mode . The users have yet to login into the Migration Page and get their credentials created. [root@ipa1 ~]# ipa config-show Maximum username length: 32 Home directory base: /home Default shell: /bin/bash Default users group: ipausers Default e-mail domain: chargepoint.com Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: TRUE Certificate Subject base: O=MYCOMPANY.DMZ Password Expiration Notification (days): 15 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: guest_u:s0 We have migrated the Users/Groups from the OpenLDAP Server (after disabling compat-mode) using schema RFC 2307. I am not yet aable to migrate sudo roles so will be creating them manually. 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. rob 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) [Success] 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 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 -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule
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 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@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 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. rob 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) [Success] 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 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
