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 <dwhite@cafedemocracy.org>:
On 10/23/15 23:31 +0200, Olivier wrote:
2015-10-22 20:54 GMT+02:00 Dan White <dwhite@cafedemocracy.org>:
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