Hi Dan, many thanks : with your guidance, I found where the problem came from, and I think it's almost fixed (not fully though).
Ok : the situation is that I use layer between my machines and the ldap server (aka : sssd). The sssd package depends on sasl libraries : that's why it is installed on my boxes even if I don't usally use it. The first thing is that I don't understand is : why the same command "ldapsearch -ZZZ -h ldaphost ..." works fine on redhat 6 and failed on redhat 5 (only works with '-x' on redhat5. I've noted your agurment that this is the default behaviour). Anyway, I saw where my authentication problem came from : On redhat5 I need to tell nsswitch NOT to use sssd to get SUDOER database bcause this is not supported before redhat6. So my nswitch.conf looks like this : # cat /etc/nsswitch.conf sudoers: ldap passwd: files sss shadow: files sss group: files sss ... So I had to configure /etc/ldap.conf to include all relevant information for talking with the ldap server and get the sudoer db from ldap. The problem is that I have not found which option I should use in ldap.conf to say NOT to use sasl when binding the ldap directory (aka the equivalent of '-x'). I have found two workarounds to make it work alyhough, but those methods are not good to me : 1/ First method is to remove those two lines : ssl start_tls tls_cacertdir /etc/openldap/cacerts from /etc/ldap.conf -> ok, it works but now the user password circulate in clear over the sudo processe. 2/ second method is to configure a proxy "binddn" in /etc/ldap.conf. when I do that, it appears that then I can I leave "starttls" in the file, sasl is not called over the sudo process and it works. The problem : to make it work I need to declare the "bindpw" in /etc/ldap.conf and I don't like that at all. (BTW, I have not bee able to make it work with a disctinct /etc/ldap.secret) Ok question : is there an option that I could install in /etc/ldap.conf to telle NOT to use sasl (aka : equivalent of '-x' for ldapsearch). Hope the issue/diag is clear, If there is no other way, I suspect that I could try to create x509 certificates for my redhat5 machines and bind using an "external" SASL mecanism. But I beleive that with this method the ACL configuration on the server side can quickly become a nightmare. Any thougt, guidance ? Thanks, --- Olivier 2015-10-23 23:45 GMT+02:00 Dan White <[email protected]>: > On 10/23/15 23:31 +0200, Olivier wrote: > >> 2015-10-22 20:54 GMT+02:00 Dan White <[email protected]>: >> >>> Without including a '-x' option on the command line, you are directing >>> ldapsearch to perform a SASL authenticated bind. See the ldapsearch >>> manpage. >>> >> >> I use SASL in certain circumstances (aka: EXTERNAL), but not GSSAPI and >> find strange that this particular machine (I mean the client) even tries >> it. >> >> Do you know why ldapsearch tries to authenticate using GSSAPI ? >> > > Because your local cyrus sasl library determined it was the best option, > because it was not provided with a specific mechanism to use (-Y). > > In this case, ldapsearch deferred the underlying authentication exchange >>> to libsasl2, which has determined that GSSAPI is the most appropriate >>> SASL >>> mechanism to use, likely because the ldap server is offering it. You can >>> use '-Y' to specify a preferred sasl mechanism, if that is your >>> intention. >>> >> >> Is there any way to configure the server not to serve GSSAPI mechanism ? I >> have not fount any parameter that could deal with that on the server side. >> > > Yes. Configure a sasl slapd.conf file, and specify an explicit 'mech_list' > which excludes GSSAPI. See: > > http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/options.php > > You can remove the GSSAPI libsasl2 shared library from your system, but >>> that would simply mask the problem. >>> >> >> Mmm... Thanks for this idea, but again, this is GSSAPI that I don't want >> to >> use, not SASL. >> >> Is there any documentation that describes the dialog between the client >> and >> the server before they agree an a particular mechanism ? >> > > SASL authentication is based on a server-offers - client-chooses model. The > server offers all available mechanisms to the client, which then chooses > the most appropriate mechanism to use based on which mechanisms it has > available. You can explicitly set the mechanism with the '-Y' option, or > via a SASL_MECH user-only option (see ldap.conf(5)). > > See section 5.2 of RFC 4513 for further detail. > > -- > Dan White >
