Discussion:
I don't want to use GSSAPI !?
(too old to reply)
Olivier
2015-10-22 15:59:16 UTC
Permalink
Raw Message
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)

Do you know why ldapsearch tries to authenticate using GSSAPI ?

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 ?

(note: the ldap client is a linux redhat5)

Thanks,

---
Olivier
Clément OUDOT
2015-10-22 16:09:34 UTC
Permalink
Raw Message
Content preview: Le 22/10/2015 17:59, Olivier a écrit : > Hello everyone,
Post by Olivier
authentication over ldap doesn't work on one of my linux box. Trying >
$ 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) > > Do you
know why ldapsearch tries to authenticate using GSSAPI ? > > 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
? > > (note: the ldap client is a linux redhat5) [...]

Content analysis details: (-0.1 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.8 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[193.248.50.71 listed in dnsbl.sorbs.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
1.0 PLING_QUERY Subject has exclamation mark and question mark
X-BeenThere: openldap-***@openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP Technical Discussion list <openldap-technical.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-technical/>
List-Post: <mailto:openldap-***@openldap.org>
List-Help: <mailto:openldap-technical-***@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=subscribe>
Errors-To: openldap-technical-***@openldap.org
Sender: "openldap-technical" <openldap-technical-***@openldap.org>
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: Le 22/10/2015 17:59, Olivier a écrit : > Hello everyone,
Post by Olivier
authentication over ldap doesn't work on one of my linux box. Trying >
$ 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) > > Do you
know why ldapsearch tries to authenticate using GSSAPI ? > > 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
? > > (note: the ldap client is a linux redhat5) [...]

Content analysis details: (-0.1 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.8 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[193.248.50.71 listed in dnsbl.sorbs.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
1.0 PLING_QUERY Subject has exclamation mark and question mark
Post by Olivier
Hello everyone,
authentication over ldap doesn't work on one of my linux box. Trying
$ ldapsearch -ZZZ -h ldap1.example:389 -D
uid=olivier,dc=example,dc=fr -b dc=example,dc=fr -W
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
Unspecified GSS failure. Minor code may provide more information (No
credentials cache found)
Do you know why ldapsearch tries to authenticate using GSSAPI ?
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 ?
(note: the ldap client is a linux redhat5)
Hi Olivier,

use -x for simple authentication.
--
Clément OUDOT
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
Olivier
2015-10-22 17:44:29 UTC
Permalink
Raw Message
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.

---
Olivier
Post by Clément OUDOT
Post by Olivier
Hello everyone,
authentication over ldap doesn't work on one of my linux box. Trying to
$ ldapsearch -ZZZ -h ldap1.example:389 -D uid=olivier,dc=example,dc=fr
-b dc=example,dc=fr -W
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)
Do you know why ldapsearch tries to authenticate using GSSAPI ?
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 ?
(note: the ldap client is a linux redhat5)
Hi Olivier,
use -x for simple authentication.
--
Clément OUDOT
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
Clément OUDOT
2015-10-23 08:25:12 UTC
Permalink
Raw Message
Content preview: 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. > [...]

Content analysis details: (-0.1 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.8 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[193.248.50.71 listed in dnsbl.sorbs.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
1.0 PLING_QUERY Subject has exclamation mark and question mark
Cc: "openldap-***@openldap.org" <openldap-***@openldap.org>
X-BeenThere: openldap-***@openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP Technical Discussion list <openldap-technical.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-technical/>
List-Post: <mailto:openldap-***@openldap.org>
List-Help: <mailto:openldap-technical-***@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=subscribe>
Errors-To: openldap-technical-***@openldap.org
Sender: "openldap-technical" <openldap-technical-***@openldap.org>
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: 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. > [...]

Content analysis details: (-0.1 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.8 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[193.248.50.71 listed in dnsbl.sorbs.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
1.0 PLING_QUERY Subject has exclamation mark and question mark
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.
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.
--
Clément OUDOT
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
Dan White
2015-10-22 18:54:59 UTC
Permalink
Raw Message
Content preview: On 10/22/15 17:59 +0200, Olivier wrote: >Hello everyone, >
Post by Olivier
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) [...]

Content analysis details: (-1.6 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[67.217.151.180 listed in list.dnswl.org]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
1.0 PLING_QUERY Subject has exclamation mark and question mark
Post by Olivier
Hello everyone,
authentication over ldap doesn't work on one of my linux box. Trying to
$ ldapsearch -ZZZ -h ldap1.example:389 -D uid=olivier,dc=example,dc=fr -b
dc=example,dc=fr -W
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.
Post by Olivier
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.
Post by Olivier
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.
--
Dan White
Olivier
2015-10-23 21:31:47 UTC
Permalink
Raw Message
Thanks Dan,
Post by Dan White
Post by Olivier
Hello everyone,
authentication over ldap doesn't work on one of my linux box. Trying to
$ ldapsearch -ZZZ -h ldap1.example:389 -D uid=olivier,dc=example,dc=fr -b
dc=example,dc=fr -W
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 ?
Post by Dan White
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.
Post by Dan White
I don'use such a mechanism (nor kerberos) and I don't remember that I
Post by Olivier
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
Post by Dan White
--
Dan White
Dan White
2015-10-23 21:45:27 UTC
Permalink
Raw Message
Content preview: On 10/23/15 23:31 +0200, Olivier wrote: >2015-10-22 20:54
GMT+02:00 Dan White <***@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 ? [...]

Content analysis details: (-1.6 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[67.217.151.180 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: cafedemocracy.org]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
1.0 PLING_QUERY Subject has exclamation mark and question mark
Post by Olivier
Post by Dan White
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).
Post by Olivier
Post by Dan White
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
Post by Olivier
Post by Dan White
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
Olivier
2015-10-26 14:49:27 UTC
Permalink
Raw Message
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
Post by Dan White
Post by Olivier
Post by Dan White
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
Post by Olivier
Post by Dan White
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'
http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/options.php
You can remove the GSSAPI libsasl2 shared library from your system, but
Post by Olivier
Post by Dan White
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
Dan White
2015-10-26 15:10:21 UTC
Permalink
Raw Message
Content preview: On 10/26/15 15:49 +0100, Olivier wrote: >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 >...
[...]

Content analysis details: (-1.6 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[67.217.151.180 listed in list.dnswl.org]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
1.0 PLING_QUERY Subject has exclamation mark and question mark
# cat /etc/nsswitch.conf
sudoers: ldap
passwd: files sss
shadow: files sss
group: files sss
...
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').
There is no such option.

Consult the documentation for your pam ldap module. If you're using PADL,
consider using nss-pam-ldapd, or nssov (which is distributed with
OpenLDAP).
--
Dan White
Loading...