Le 22/10/2015 19:44, Olivier a écrit :

Hi Clément,

yep, I know that and it works. But the problem is that this is the only client where I get this behaviour with ldapsearch and I'd like to uderstand why.

The real problem I have behind, is that I saw that to have user authentication over ldap working, I have DESACTIVATE TLS for ldap queries : even for a very internal machine, I really don't want to leave the configuration like that.

Here is what makes it work :

nsswitch.conf : passwd: files ldap

/etc/ldap.conf ... #ssl start_tls #tls_cacertdir /etc/openldap/cacerts ...

I can't leave things like this.

There should be no link between you GSSAPI problem and the StartTLS option. You can indeed try to use StartTLS in ldapsearch to see if your SSL configuration is correct, in this case, use -x to bypass the SASL authentication.

Then you need to import the CA which signed your LDAP server certificate on your clients to let them verify the certificate when requesting the LDAP with StartTLS.

Thanks Dan,

2015-10-22 20:54 GMT+02:00 Dan White dwhite@cafedemocracy.org:

On 10/22/15 17:59 +0200, Olivier wrote:

...

Hello everyone,

authentication over ldap doesn't work on one of my linux box. Trying to query the ldap server from this machine with ldapsearch, I get this :

$ ldapsearch -ZZZ -h ldap1.example:389 -D uid=olivier,dc=example,dc=fr -b dc=example,dc=fr -W Enter LDAP Password: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No credentials cache found)

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 ?

...

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.

I don'use such a mechanism (nor kerberos) and I don't remember that I

...

configured any such a thing.

Any idea to desactivate the attempt to use GSSAPI to authenticate ?

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 ?

-- Olivier

-- Dan White

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