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
Re: [Freeipa-users] Sudo not working
That's got me closer now, as I'm at least getting an error message on stdout: [root@fs1 etc]# more nslcd.conf binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me [root@fs1 etc]# sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [root@fs1 ~]# So I'm off to figure out where my credentials are wrong. Thanks again, Rob, Stephen Pavel. Bret On Wed, Oct 31, 2012 at 2:39 PM, Rob Crittenden rcrit...@redhat.com wrote: Bret Wortman wrote: [root@fs1 etc]# more /etc/ldap.conf sudoers_debug: 1 [root@fs1 etc]# ls -l /etc/ldap.conf -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf Where should I see the extra output? I've had this set since last Friday and I'm not seeing any difference. Move the contents of /etc/nslcd.conf to this file and add ldap to sudoers in /etc/nsswitch.conf. rob On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: F17. I think you want /etc/ldap.conf then. The easiest way to be sure the right file is being used is to add sudoers_debug 1 to the file. This will present a lot of extra output so you'll know the file is being read. rob On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages. I'll try switching to SSS and see what that gets me. What distro is this? If it is RHEL 6.3 then put the configuration into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are working on getting them fixed). rob On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com** wrote: On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: I'm pretty certain there's a painfully simple solution to this that I'm not seeing, but my current configuration isn't picking up the freeipa sudoer rule that I've set. /etc/nsswitch.conf specifies: sudoers:files ldap /etc/nslcd.conf contains: binddn uid=sudo,cn=sysaccounts,cn=___** ___etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me The sssd_DOMAIN.log file contains this when I try to sudo: snip The SSSD logs aren't showing anything wrong because they have nothing to do with the execution of the SUDO rules in this situation. All the SSSD is doing is verifying the authentication (when sudo prompts you for your password). The problem with the rule is most likely happening inside SUDO itself. When you specify 'sudoers: files, ldap' in nsswitch.conf, it's telling SUDO to use its own internal LDAP driver to look up the rules. So you need to check sudo logs to see what's happening (probably you will need to enable debug logging in /etc/sudo.conf). Recent versions of SUDO (1.8.6 and later) have support for setting 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0
Re: [Freeipa-users] Sudo not working
To close the loop: I did the following to clear the credential problem. I suspect that I hadn't properly run kinit before doing these steps the first time: -sh-4.2$ kinit Password for br...@wedgeofli.me: -sh-4.2$ sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [sudo] password for bretw: bretw is not in the sudoers file. This incident will be reported. -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ ldapsearch ou=SUDOers,dc=wedgeofli,dc=me SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ ldapsearch -D uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password ou=SUDOers,dc=wedgeofli,dc=me ldap_bind: Invalid credentials (49) -sh-4.2$ ldappasswd -Y GSSAPI -S -h fs1.wedgeofli.meuid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me New password: Re-enter new password: SASL/GSSAPI authentication started SASL username: br...@wedgeofli.me SASL SSF: 56 SASL data security layer installed. -sh-4.2$ ldapsearch -D uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ sudo su - [sudo] password for bretw: [root@fs1 ~]# On Thu, Nov 1, 2012 at 7:58 AM, Bret Wortman bret.wort...@damascusgrp.comwrote: That's got me closer now, as I'm at least getting an error message on stdout: [root@fs1 etc]# more nslcd.conf binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me [root@fs1 etc]# sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [root@fs1 ~]# So I'm off to figure out where my credentials are wrong. Thanks again, Rob, Stephen Pavel. Bret On Wed, Oct 31, 2012 at 2:39 PM, Rob Crittenden rcrit...@redhat.comwrote: Bret Wortman wrote: [root@fs1 etc]# more /etc/ldap.conf sudoers_debug: 1 [root@fs1 etc]# ls -l /etc/ldap.conf -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf Where should I see the extra output? I've had this set since last Friday and I'm not seeing any difference. Move the contents of /etc/nslcd.conf to this file and add ldap to sudoers in /etc/nsswitch.conf. rob On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: F17. I think you want /etc/ldap.conf then. The easiest way to be sure the right file is being used is to add sudoers_debug 1 to the file. This will present a lot of extra output so you'll know the file is being read. rob On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages. I'll try switching to SSS and see what that gets me. What distro is this? If it is RHEL 6.3 then put the configuration into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are working on getting them fixed). rob On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com** wrote: On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: I'm pretty certain there's a painfully simple solution to this that I'm not seeing, but my current configuration isn't picking up the freeipa sudoer rule that I've set. /etc/nsswitch.conf specifies: sudoers:files ldap
Re: [Freeipa-users] Sudo not working
On 11/01/2012 08:26 AM, Bret Wortman wrote: To close the loop: I did the following to clear the credential problem. I suspect that I hadn't properly run kinit before doing these steps the first time: -sh-4.2$ kinit Password for br...@wedgeofli.me mailto:br...@wedgeofli.me: -sh-4.2$ sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [sudo] password for bretw: bretw is not in the sudoers file. This incident will be reported. This seems to suggest that it tries to use sudoers file instead of LDAP. -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 If you used kinit you then can use -Y GSSAPI to use kerberos credential for the authentication. -sh-4.2$ ldapsearch ou=SUDOers,dc=wedgeofli,dc=me SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ ldapsearch -D uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password ou=SUDOers,dc=wedgeofli,dc=me ldap_bind: Invalid credentials (49) -sh-4.2$ ldappasswd -Y GSSAPI -S -h fs1.wedgeofli.me http://fs1.wedgeofli.me uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me New password: Re-enter new password: SASL/GSSAPI authentication started SASL username: br...@wedgeofli.me mailto:br...@wedgeofli.me SASL SSF: 56 SASL data security layer installed. -sh-4.2$ ldapsearch -D uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ sudo su - [sudo] password for bretw: [root@fs1 ~]# On Thu, Nov 1, 2012 at 7:58 AM, Bret Wortman bret.wort...@damascusgrp.com mailto:bret.wort...@damascusgrp.com wrote: That's got me closer now, as I'm at least getting an error message on stdout: [root@fs1 etc]# more nslcd.conf binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me http://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me [root@fs1 etc]# sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [root@fs1 ~]# So I'm off to figure out where my credentials are wrong. Thanks again, Rob, Stephen Pavel. Bret On Wed, Oct 31, 2012 at 2:39 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: [root@fs1 etc]# more /etc/ldap.conf sudoers_debug: 1 [root@fs1 etc]# ls -l /etc/ldap.conf -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf Where should I see the extra output? I've had this set since last Friday and I'm not seeing any difference. Move the contents of /etc/nslcd.conf to this file and add ldap to sudoers in /etc/nsswitch.conf. rob On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: F17. I think you want /etc/ldap.conf then. The easiest way to be sure the right file is being used is to add sudoers_debug 1 to the file. This will present a lot of extra output so you'll know the file is being read. rob On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages.
Re: [Freeipa-users] Sudo not working
Bret Wortman wrote: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages. I'll try switching to SSS and see what that gets me. What distro is this? If it is RHEL 6.3 then put the configuration into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are working on getting them fixed). rob On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com wrote: On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: I'm pretty certain there's a painfully simple solution to this that I'm not seeing, but my current configuration isn't picking up the freeipa sudoer rule that I've set. /etc/nsswitch.conf specifies: sudoers:files ldap /etc/nslcd.conf contains: binddn uid=sudo,cn=sysaccounts,cn=__etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me The sssd_DOMAIN.log file contains this when I try to sudo: snip The SSSD logs aren't showing anything wrong because they have nothing to do with the execution of the SUDO rules in this situation. All the SSSD is doing is verifying the authentication (when sudo prompts you for your password). The problem with the rule is most likely happening inside SUDO itself. When you specify 'sudoers: files, ldap' in nsswitch.conf, it's telling SUDO to use its own internal LDAP driver to look up the rules. So you need to check sudo logs to see what's happening (probably you will need to enable debug logging in /etc/sudo.conf). Recent versions of SUDO (1.8.6 and later) have support for setting 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0 and later) for lookups (and caching) of sudo rules. -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo not working
F17. On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden rcrit...@redhat.com wrote: Bret Wortman wrote: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages. I'll try switching to SSS and see what that gets me. What distro is this? If it is RHEL 6.3 then put the configuration into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are working on getting them fixed). rob On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com wrote: On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: I'm pretty certain there's a painfully simple solution to this that I'm not seeing, but my current configuration isn't picking up the freeipa sudoer rule that I've set. /etc/nsswitch.conf specifies: sudoers:files ldap /etc/nslcd.conf contains: binddn uid=sudo,cn=sysaccounts,cn=__**etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me The sssd_DOMAIN.log file contains this when I try to sudo: snip The SSSD logs aren't showing anything wrong because they have nothing to do with the execution of the SUDO rules in this situation. All the SSSD is doing is verifying the authentication (when sudo prompts you for your password). The problem with the rule is most likely happening inside SUDO itself. When you specify 'sudoers: files, ldap' in nsswitch.conf, it's telling SUDO to use its own internal LDAP driver to look up the rules. So you need to check sudo logs to see what's happening (probably you will need to enable debug logging in /etc/sudo.conf). Recent versions of SUDO (1.8.6 and later) have support for setting 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0 and later) for lookups (and caching) of sudo rules. -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman __**_ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/**mailman/listinfo/freeipa-usershttps://www.redhat.com/mailman/listinfo/freeipa-users -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo not working
[root@fs1 etc]# more /etc/ldap.conf sudoers_debug: 1 [root@fs1 etc]# ls -l /etc/ldap.conf -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf Where should I see the extra output? I've had this set since last Friday and I'm not seeing any difference. On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden rcrit...@redhat.com wrote: Bret Wortman wrote: F17. I think you want /etc/ldap.conf then. The easiest way to be sure the right file is being used is to add sudoers_debug 1 to the file. This will present a lot of extra output so you'll know the file is being read. rob On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages. I'll try switching to SSS and see what that gets me. What distro is this? If it is RHEL 6.3 then put the configuration into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are working on getting them fixed). rob On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com wrote: On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: I'm pretty certain there's a painfully simple solution to this that I'm not seeing, but my current configuration isn't picking up the freeipa sudoer rule that I've set. /etc/nsswitch.conf specifies: sudoers:files ldap /etc/nslcd.conf contains: binddn uid=sudo,cn=sysaccounts,cn=___**_etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me The sssd_DOMAIN.log file contains this when I try to sudo: snip The SSSD logs aren't showing anything wrong because they have nothing to do with the execution of the SUDO rules in this situation. All the SSSD is doing is verifying the authentication (when sudo prompts you for your password). The problem with the rule is most likely happening inside SUDO itself. When you specify 'sudoers: files, ldap' in nsswitch.conf, it's telling SUDO to use its own internal LDAP driver to look up the rules. So you need to check sudo logs to see what's happening (probably you will need to enable debug logging in /etc/sudo.conf). Recent versions of SUDO (1.8.6 and later) have support for setting 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0 and later) for lookups (and caching) of sudo rules. -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman __**___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.**comFreeipa-users@redhat.com https://www.redhat.com/__**mailman/listinfo/freeipa-usershttps://www.redhat.com/__mailman/listinfo/freeipa-users https://www.redhat.com/**mailman/listinfo/freeipa-usershttps://www.redhat.com/mailman/listinfo/freeipa-users ** -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman __**_ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/**mailman/listinfo/freeipa-usershttps://www.redhat.com/mailman/listinfo/freeipa-users -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo not working
Bret Wortman wrote: [root@fs1 etc]# more /etc/ldap.conf sudoers_debug: 1 [root@fs1 etc]# ls -l /etc/ldap.conf -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf Where should I see the extra output? I've had this set since last Friday and I'm not seeing any difference. Move the contents of /etc/nslcd.conf to this file and add ldap to sudoers in /etc/nsswitch.conf. rob On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: F17. I think you want /etc/ldap.conf then. The easiest way to be sure the right file is being used is to add sudoers_debug 1 to the file. This will present a lot of extra output so you'll know the file is being read. rob On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages. I'll try switching to SSS and see what that gets me. What distro is this? If it is RHEL 6.3 then put the configuration into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are working on getting them fixed). rob On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com wrote: On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: I'm pretty certain there's a painfully simple solution to this that I'm not seeing, but my current configuration isn't picking up the freeipa sudoer rule that I've set. /etc/nsswitch.conf specifies: sudoers:files ldap /etc/nslcd.conf contains: binddn uid=sudo,cn=sysaccounts,cn=__etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me The sssd_DOMAIN.log file contains this when I try to sudo: snip The SSSD logs aren't showing anything wrong because they have nothing to do with the execution of the SUDO rules in this situation. All the SSSD is doing is verifying the authentication (when sudo prompts you for your password). The problem with the rule is most likely happening inside SUDO itself. When you specify 'sudoers: files, ldap' in nsswitch.conf, it's telling SUDO to use its own internal LDAP driver to look up the rules. So you need to check sudo logs to see what's happening (probably you will need to enable debug logging in /etc/sudo.conf). Recent versions of SUDO (1.8.6 and later) have support for setting 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0 and later) for lookups (and caching) of sudo rules. -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com mailto:Freeipa-users@redhat.__com mailto:Freeipa-users@redhat.com
