Hi Dagobert, I checked out the logs on our LDAP server and to me it looks quite similar. At least it looks like all the information from the client has been submitted to the server.
Log output from LDAP server for session for server that does not work: [root@fr4p-gen-inf-ldp002 slapd-fr4p-gen-inf-ldp002]# grep 5338229 access [07/Nov/2016:17:09:10 +0100] conn=5338229 fd=162 slot=162 connection from 10.161.28.4 to 10.161.28.6 [07/Nov/2016:17:09:10 +0100] conn=5338229 op=0 BIND dn="uid=puser,ou=people,dc=syniverse,dc=com" method=128 version=3 [07/Nov/2016:17:09:10 +0100] conn=5338229 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=puser,ou=people,dc=syniverse,dc=com" [07/Nov/2016:17:09:10 +0100] conn=5338229 op=1 SRCH base="ou=sudoers,dc=syniverse,dc=com" scope=2 filter="(&(objectClass=sudoRole)(cn=defaults))" attrs=ALL [07/Nov/2016:17:09:10 +0100] conn=5338229 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [07/Nov/2016:17:09:10 +0100] conn=5338229 op=2 SRCH base="ou=sudoers,dc=syniverse,dc=com" scope=2 filter="(&(objectClass=sudoRole)(|(sudoUser=g701806)(sudoUser=%#40347)(sudoUser=%global_sysadmin)(sudoUser=%chs_sysadmin_prod)(sudoUser=%chs_dba_prod)(sudoUser=%#50000)(sudoUser=%#50191)(sudoUser=%#50203)(sudoUser=ALL)))" attrs=ALL [07/Nov/2016:17:09:10 +0100] conn=5338229 op=2 RESULT err=0 tag=101 nentries=14 etime=0 notes=U [07/Nov/2016:17:09:10 +0100] conn=5338229 op=3 SRCH base="ou=sudoers,dc=syniverse,dc=com" scope=2 filter="(&(objectClass=sudoRole)(sudoUser=*)(sudoUser=+*))" attrs=ALL [07/Nov/2016:17:09:10 +0100] conn=5338229 op=3 RESULT err=0 tag=101 nentries=0 etime=0 notes=U [07/Nov/2016:17:09:10 +0100] conn=5338229 op=-1 fd=162 closed - B1 Log output from LDAP server for session for server that does work: [root@fr4p-gen-inf-ldp001 slapd-fr4p-gen-inf-ldp001]# grep 3086148 access [07/Nov/2016:17:10:21 +0100] conn=3086148 fd=97 slot=97 connection from 10.161.28.4 to 10.161.28.5 [07/Nov/2016:17:10:21 +0100] conn=3086148 op=0 BIND dn="uid=puser,ou=people,dc=syniverse,dc=com" method=128 version=3 [07/Nov/2016:17:10:21 +0100] conn=3086148 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=puser,ou=people,dc=syniverse,dc=com" [07/Nov/2016:17:10:21 +0100] conn=3086148 op=1 SRCH base="ou=sudoers,dc=syniverse,dc=com" scope=2 filter="(&(objectClass=sudoRole)(cn=defaults))" attrs=ALL [07/Nov/2016:17:10:21 +0100] conn=3086148 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [07/Nov/2016:17:10:21 +0100] conn=3086148 op=2 SRCH base="ou=sudoers,dc=syniverse,dc=com" scope=2 filter="(&(objectClass=sudoRole)(|(sudoUser=g701806)(sudoUser=%g701806)(sudoUser=%#40347)(sudoUser=%global_sysadmin)(sudoUser=%chs_dba_prod)(sudoUser=%chs_sysadmin_prod)(sudoUser=%ic_opsadm_prod)(sudoUser=%chs_opsadmin_prod)(sudoUser=%comm_opsadmin_prod)(sudoUser=%#50000)(sudoUser=%#50203)(sudoUser=%#50191)(sudoUser=%#50463)(sudoUser=%#50518)(sudoUser=%#50544)(sudoUser=ALL)))" attrs=ALL [07/Nov/2016:17:10:21 +0100] conn=3086148 op=2 RESULT err=0 tag=101 nentries=17 etime=0 notes=U [07/Nov/2016:17:10:21 +0100] conn=3086148 op=3 SRCH base="ou=sudoers,dc=syniverse,dc=com" scope=2 filter="(&(objectClass=sudoRole)(sudoUser=*)(sudoUser=+*))" attrs=ALL [07/Nov/2016:17:10:21 +0100] conn=3086148 op=3 RESULT err=0 tag=101 nentries=0 etime=0 notes=U [07/Nov/2016:17:10:21 +0100] conn=3086148 op=4 UNBIND [07/Nov/2016:17:10:21 +0100] conn=3086148 op=4 fd=97 closed - U1 Regards, Stefan -----Ursprüngliche Nachricht----- Von: Dagobert Michelsen [mailto:[email protected]] Gesendet: Montag, 7. November 2016 15:06 An: Stefan Maass <[email protected]> Cc: [email protected]; [email protected] Betreff: Re: issue with sudo_ldap Hi Stefan, Am 07.11.2016 um 14:56 schrieb Stefan Maass <[email protected]>: > Thanks for your reply! > > I had seen the entry in the change log that you have mentioned below and I > have tried using the -g switch as well, but it did not change anything. It > just added one line into the output of the debug log other than that it does > nothing and I am still not allowed to sudo as I was in the former sudo > version. > > Nov 7 13:37:36 sudo[158099] will restore signal 13 on exec Nov 7 > 13:37:36 sudo[158099] settings: runas_group=global_sysadmin Nov 7 > 13:37:36 sudo[158099] settings: progname=sudo Nov 7 13:37:36 > sudo[158099] settings: network_addrs=10.161.120.147/255.255.254.0 > 10.161.146.18/255.255.255.0 10.161.146.26/255.255.255.0 Nov 7 > 13:37:36 sudo[158099] settings: plugin_dir=/opt/csw/libexec/sudo/ Nov > 7 13:37:36 sudo[158099] policy plugin returns 0 > > It looks like it does not find the policy in LDAP that matches the right to > switch user. Maybe you can enable request logging on your LDAP server and see how the SEARCH request looks like? > The other changes that have been done in regards of LDAP don't say much to me > for now so I am not sure if they could be responsible for what I am facing. Apart from that I would expect an upstream issue as nothing has changed regarding the build perspective for OpenCSW. Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896
