Hi Dagobert, Digging a little deeper it looks like there is an issue with the sudoHost part. I have enabled debugging in /etc/opt/csw/ldap.conf and the result shows that it does not recognize any of the netgroups. Even if we added the one host that I am testing on explicitely it does not recognize it. We have played around with that a bit and as the sudo manpage that "Negated sudoHost entries are only supported by version 1.8.18 or higher.", we have created a negated sudoHost entry in LDAP which did not have any effect. So it looks like every sudoHost entry is being negated in general. Here is the output of the debugged sudo command to switch to a specific user and then "sudo -l" which shows that it does not find any sudoHost entry matching. This output is from when we had the specific host am1p-gen-chs-app001 negated, but it looks exactly the same if it is not negated.
pts/1|root@am1p-gen-chs-app001:/etc/opt/csw# sudo su - g706553 sudo: LDAP Config Summary sudo: =================== sudo: host am1p-gen-inf-ldp001.am1.syniverse.com,am1p-gen-inf-ldp002.am1.syniverse.com,fr4p-gen-inf-ldp001.fr4.syniverse.com,fr4p-gen-inf-ldp002.fr4.syniverse.com sudo: port -1 sudo: ldap_version 3 sudo: sudoers_base ou=sudoers,dc=syniverse,dc=com sudo: search_filter (objectClass=sudoRole) sudo: netgroup_base (NONE: will use nsswitch) sudo: netgroup_search_filter (objectClass=nisNetgroup) sudo: binddn uid=puser,ou=people,dc=syniverse,dc=com sudo: bindpw sudo: ssl start_tls sudo: tls_cacertdir /etc/opt/csw/ssl/certs sudo: =================== sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_cacertdir -> /etc/opt/csw/ssl/certs sudo: ldap_init(am1p-gen-inf-ldp001.am1.syniverse.com,am1p-gen-inf-ldp002.am1.syniverse.com,fr4p-gen-inf-ldp001.fr4.syniverse.com,fr4p-gen-inf-ldp002.fr4.syniverse.com, 389) sudo: ldap_set_option: ldap_version -> 3 sudo: start_tls specified but LDAP libs do not support ldap_start_tls_s() or ldap_start_tls_s_np() sudo: ldap_simple_bind_s() ok sudo: Looking for cn=defaults: (&(objectClass=sudoRole)(cn=defaults)) sudo: found:cn=defaults,ou=SUDOers,dc=syniverse,dc=com sudo: ldap sudoOption: 'ignore_dot' sudo: ldap sudoOption: '!mail_no_user' sudo: ldap sudoOption: 'log_host' sudo: ldap sudoOption: 'logfile=/var/log/sudolog' sudo: ldap sudoOption: '!syslog' sudo: ldap sudoOption: 'timestamp_timeout=10' sudo: ldap sudoOption: '!authenticate' sudo: ldap sudoOption: 'ignore_dot' sudo: ldap sudoOption: '!mail_no_user' sudo: ldap sudoOption: 'log_host' sudo: ldap sudoOption: 'logfile=/var/log/sudolog' sudo: ldap sudoOption: '!syslog' sudo: ldap sudoOption: 'timestamp_timeout=10' sudo: ldap sudoOption: '!authenticate' sudo: ldap search '(&(objectClass=sudoRole)(|(sudoUser=root)(sudoUser=%root)(sudoUser=%#0)(sudoUser=%other)(sudoUser=%bin)(sudoUser=%sys)(sudoUser=%adm)(sudoUser=%uucp)(sudoUser=%mail)(sudoUser=%tty)(sudoUser=%lp)(sudoUser=%nuucp)(sudoUser=%daemon)(sudoUser=%#1)(sudoUser=%#2)(sudoUser=%#3)(sudoUser=%#4)(sudoUser=%#5)(sudoUser=%#6)(sudoUser=%#7)(sudoUser=%#8)(sudoUser=%#9)(sudoUser=%#12)(sudoUser=ALL)))' sudo: searching from base 'ou=sudoers,dc=syniverse,dc=com' sudo: adding search result sudo: result now has 0 entries sudo: ldap search '(&(objectClass=sudoRole)(sudoUser=*)(sudoUser=+*))' sudo: searching from base 'ou=sudoers,dc=syniverse,dc=com' sudo: adding search result sudo: result now has 0 entries sudo: searching LDAP for sudoers entries sudo: done with LDAP searches sudo: user_matches=false sudo: host_matches=false sudo: sudo_ldap_lookup(0)=0x02 sudo: removing reusable search result bash.ori-3.2$ sudo -l sudo: LDAP Config Summary sudo: =================== sudo: host am1p-gen-inf-ldp001.am1.syniverse.com,am1p-gen-inf-ldp002.am1.syniverse.com,fr4p-gen-inf-ldp001.fr4.syniverse.com,fr4p-gen-inf-ldp002.fr4.syniverse.com sudo: port -1 sudo: ldap_version 3 sudo: sudoers_base ou=sudoers,dc=syniverse,dc=com sudo: search_filter (objectClass=sudoRole) sudo: netgroup_base (NONE: will use nsswitch) sudo: netgroup_search_filter (objectClass=nisNetgroup) sudo: binddn uid=puser,ou=people,dc=syniverse,dc=com sudo: bindpw sudo: ssl start_tls sudo: tls_cacertdir /etc/opt/csw/ssl/certs sudo: =================== sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_cacertdir -> /etc/opt/csw/ssl/certs sudo: ldap_init(am1p-gen-inf-ldp001.am1.syniverse.com,am1p-gen-inf-ldp002.am1.syniverse.com,fr4p-gen-inf-ldp001.fr4.syniverse.com,fr4p-gen-inf-ldp002.fr4.syniverse.com, 389) sudo: ldap_set_option: ldap_version -> 3 sudo: start_tls specified but LDAP libs do not support ldap_start_tls_s() or ldap_start_tls_s_np() sudo: ldap_simple_bind_s() ok sudo: Looking for cn=defaults: (&(objectClass=sudoRole)(cn=defaults)) sudo: found:cn=defaults,ou=SUDOers,dc=syniverse,dc=com sudo: ldap sudoOption: 'ignore_dot' sudo: ldap sudoOption: '!mail_no_user' sudo: ldap sudoOption: 'log_host' sudo: ldap sudoOption: 'logfile=/var/log/sudolog' sudo: ldap sudoOption: '!syslog' sudo: ldap sudoOption: 'timestamp_timeout=10' sudo: ldap sudoOption: '!authenticate' sudo: ldap sudoOption: 'ignore_dot' sudo: ldap sudoOption: '!mail_no_user' sudo: ldap sudoOption: 'log_host' sudo: ldap sudoOption: 'logfile=/var/log/sudolog' sudo: ldap sudoOption: '!syslog' sudo: ldap sudoOption: 'timestamp_timeout=10' sudo: ldap sudoOption: '!authenticate' sudo: ldap search '(&(objectClass=sudoRole)(|(sudoUser=g706553)(sudoUser=%g706553)(sudoUser=%#50168)(sudoUser=%prod)(sudoUser=%chs_ind_cust_ops_prod)(sudoUser=%chs_na_cust_ops_prod)(sudoUser=%chs_eu_cust_ops_prod)(sudoUser=%dch_ops_level2_prod)(sudoUser=%#11)(sudoUser=%#50207)(sudoUser=%#50206)(sudoUser=%#50202)(sudoUser=%#50570)(sudoUser=ALL)))' sudo: searching from base 'ou=sudoers,dc=syniverse,dc=com' sudo: adding search result sudo: ldap sudoHost '+hosts_chs_ind_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_ind_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_na_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_na_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_eu_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_eu_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_eu_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_eu_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_eu_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_eu_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_eu_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_eu_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_na_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_chs_eu_cust_ops_prod' ... not sudo: ldap sudoHost '+hosts_dch_ops_level2_prod_dchops' ... not sudo: ldap sudoHost 'am1p-gen-chs-app001' ... not sudo: result now has 0 entries sudo: ldap search '(&(objectClass=sudoRole)(sudoUser=*)(sudoUser=+*))' sudo: searching from base 'ou=sudoers,dc=syniverse,dc=com' sudo: adding search result sudo: result now has 0 entries sudo: perform search for pwflag 54 sudo: done with LDAP searches sudo: user_matches=true sudo: host_matches=false sudo: sudo_ldap_lookup(54)=0x84 Sorry, user g706553 may not run sudo on am1p-gen-chs-app001. Thanks and Regards, Stefan -----Ursprüngliche Nachricht----- Von: Stefan Maass Gesendet: Montag, 7. November 2016 14:57 An: 'Dagobert Michelsen' <[email protected]> Cc: [email protected]; '[email protected]' <[email protected]> Betreff: AW: issue with sudo_ldap Hi Dagobert, 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. 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. Regards, Stefan -----Ursprüngliche Nachricht----- Von: Dagobert Michelsen [mailto:[email protected]] Gesendet: Montag, 7. November 2016 13:10 An: Stefan Maass <[email protected]> Cc: [email protected] Betreff: Re: issue with sudo_ldap Hi Stefan, Am 07.11.2016 um 11:52 schrieb Stefan Maass <[email protected]>: > It looks like we ran into a new issue and I hope you are the right person to > contact. At least I can see that the package (I think) is involved has been > packaged by you. > > I have recently done an upgrade of a few packages including sudo and > sudo_ldap on a few nodes. The former versions were as follows: > > CSWsudo à VERSION: 1.8.16,REV=2016.03.18 > CSWsudo-ldap à VERSION: 1.8.16,REV=2016.03.18 > > The new versions are: > > CSWsudo à VERSION: 1.8.18,REV=2016.09.21 > CSWsudo-ldap à VERSION: 1.8.18,REV=2016.09.21 > > Interestingly on the servers with the older version and also on the servers > with the newer version the command /opt/csw/bin/pkgutil --version > CSWsudo-ldap shows 2.6.7. So it looks like it is in fact the same package. pkgutil —version shows the version of pkgutil. Try > dam@unstable10s [unstable10s]:/home/dam > pkgutil -c sudo sudo_ldap > You're not root and didn't set -W, using home dir. > => Fetching new catalog and descriptions > (file:///export/mirror/opencsw-official/unstable/sparc/5.10) if available ... > ==> 3948 packages loaded from > /home/dam/.pkgutil/catalog._export_mirror_opencsw-official_unstable_sparc_5.10 > package installed catalog > CSWsudo 1.8.18p1,REV=2016.10.28 SAME > The issue that we have is that since I have upgraded the sudo packages LDAP > users are not able anymore to use sudo as it seems that the information from > the LDAP server is not received. > > This example output is from a server where sudo works: > > pts/23|root@fr4u-gen-chs-app001:/root# sudo su - g701806 > sudo: start_tls specified but LDAP libs do not support ldap_start_tls_s() or > ldap_start_tls_s_np() > Oracle Corporation SunOS 5.10 Generic Patch January 2005 > LOGIN NAME: g701806 > ORACLE DATABASE: chdev > Clearing House profile executed. > development environment for server fr4u-gen-chs-app001 set! > fr4u-gen-chs-app001:DEVELOP\&chdev\&/ldap/home/g701806: sudo su - > sudo: start_tls specified but LDAP libs do not support ldap_start_tls_s() or > ldap_start_tls_s_np() > Oracle Corporation SunOS 5.10 Generic Patch January 2005 > pts/23|root@fr4u-gen-chs-app001:/root# ^D > fr4u-gen-chs-app001:DEVELOP\&chdev\&/ldap/home/g701806: sudo -l > sudo: start_tls specified but LDAP libs do not support > ldap_start_tls_s() or ldap_start_tls_s_np() Matching Defaults entries for > g701806 on fr4u-gen-chs-app001: > loglinelen=0, logfile=/var/adm/sudolog, ignore_dot, !mail_no_user, > log_host, logfile=/var/log/sudolog, !syslog, > timestamp_timeout=10, !authenticate > > User g701806 may run the following commands on fr4u-gen-chs-app001: > (root) ALL > > This example output is from a server where sudo does not work: > > pts/5|root@fr4u-gen-chs-app002:/var/log# sudo su - g701806 > sudo: start_tls specified but LDAP libs do not support ldap_start_tls_s() or > ldap_start_tls_s_np() > Oracle Corporation SunOS 5.10 Generic Patch January 2005 > LOGIN NAME: g701806 > ORACLE DATABASE: chdev > Clearing House profile executed. > development environment for server fr4u-gen-chs-app002 set! > fr4u-gen-chs-app002:DEVELOP\&chdev\&/ldap/home/g701806: sudo su - > sudo: start_tls specified but LDAP libs do not support > ldap_start_tls_s() or ldap_start_tls_s_np() > g701806 is not allowed to run sudo on fr4u-gen-chs-app002. This incident > will be reported. > fr4u-gen-chs-app002:DEVELOP\&chdev\&/ldap/home/g701806: sudo -l > sudo: start_tls specified but LDAP libs do not support > ldap_start_tls_s() or ldap_start_tls_s_np() Sorry, user g701806 may not run > sudo on fr4u-gen-chs-app002. > > I am not sure if this output helps, but I have added a line to sudo.conf to > debug sudo. So here is what appears in the sudo_debug log when I execute the > command “sudo su –“ on the server where sudo works: > > Nov 7 11:13:42 sudo[535884] settings: progname=sudo Nov 7 11:13:42 > sudo[535884] settings: network_addrs=10.161.120.146/255.255.254.0 > 10.161.146.17/255.255.255.0 10.161.146.25/255.255.255.0 Nov 7 > 11:13:42 sudo[535884] settings: plugin_dir=/opt/csw/libexec/sudo/ Nov > 7 11:13:43 sudo[535884] policy plugin returns 1 Nov 7 11:13:43 > sudo[535884] settings: progname=sudo Nov 7 11:13:43 sudo[535884] > settings: network_addrs=10.161.120.146/255.255.254.0 > 10.161.146.17/255.255.255.0 10.161.146.25/255.255.255.0 Nov 7 11:13:43 > sudo[535884] settings: plugin_dir=/opt/csw/libexec/sudo/ Nov 7 11:13:43 > sudo[535884] command info from plugin: > Nov 7 11:13:43 sudo[535884] 0: command=/usr/bin/su > Nov 7 11:13:43 sudo[535884] 1: runas_uid=0 > Nov 7 11:13:43 sudo[535884] 2: runas_gid=0 > Nov 7 11:13:43 sudo[535884] 3: runas_groups=0,1,2,3,4,5,6,7,8,9,12 > Nov 7 11:13:43 sudo[535884] 4: closefrom=3 > Nov 7 11:13:43 sudo[535884] 5: set_utmp=true > Nov 7 11:13:43 sudo[535884] 6: umask=022 > Nov 7 11:13:43 sudo[535884] executed /usr/bin/su, pid 535901 Nov 7 > 11:13:43 sudo[535884] sudo_ev_add_v1: adding event 44628 to base 4b4d0 > Nov 7 11:13:43 sudo[535884] sudo_ev_add_v1: adding event 44668 to > base 4b4d0 Nov 7 11:13:43 sudo[535884] signal pipe fd 7 Nov 7 > 11:13:43 sudo[535884] backchannel fd 9 Nov 7 11:13:43 sudo[535901] > exec /usr/bin/su [su -] Nov 7 11:13:43 sudo[535884] > sudo_ev_scan_impl: 1 fds ready Nov 7 11:13:43 sudo[535884] failed to > read child status: EOF Nov 7 11:13:43 sudo[535884] sudo_ev_del_v1: > removing event 44668 from base 4b4d0 > > And here is the output from the server where sudo does not work: > > Nov 7 11:12:02 sudo[152587] will restore signal 13 on exec Nov 7 > 11:12:02 sudo[152587] settings: progname=sudo Nov 7 11:12:02 > sudo[152587] 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 > 11:12:02 sudo[152587] settings: plugin_dir=/opt/csw/libexec/sudo/ Nov > 7 11:12:02 sudo[152587] policy plugin returns 0 Maybe a look in the Changelog helps: https://www.sudo.ws/changes.html * plugins/sudoers/ldap.c, plugins/sudoers/sssd.c: Fix matching when no sudoRunAsUser is present in a sudoRole. If only a sudoRunAsGroup is present, match on the invoking user if the -g option was specified and the group matched. If no sudoRunAsGroup is present and the -g option was specified, allow it if it matches the passwd gid of the runas user. This matches the behavior of the sudoers backend. [e1a52c34da5e] There are also a few other changes, I suggest you take a look and make sure you didn’t hit one of these before digging in further. You may also wanto to cc: sudo-users@: https://www.sudo.ws/mailman/listinfo/sudo-users 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
