uri_gr1(a)tut.by wrote:
> On attempt to auth via ldap next error appear:
> conn=0 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037"
This means that the LDAP client is sending a StartTLS extended operation
to establish an encrypted LDAP connection but the OpenLDAP server is not
built with TLS support or not correctly configured for that.
So depending on your security requirements you should try to configure
the clients without requesting StartTLS or fix the OpenLDAP
installation/configuration to support that.
See also: http://www.openldap.org/faq/data/cache/185.html
Ciao, Michael.
--On Tuesday, December 31, 2019 10:44 AM -0500 Peter Sui <peters(a)qnext.com>
wrote:
> if I run:
> ldapsearch -h ldap.forumsys.com -p 636 -b "" -s base "(objectClass=*)" -D
> "cn=read-only-admin,dc=example,dc=com" -w password -Z
It is not valid to combine startTLS with port 636. Also, you should update
your options to match modern standards.
Example against ldaps:///
ldapsearch -H ldaps://ldap.forumsys.com:636
as opposed to
ldapsearch -h ldap.forumsys.com -p 636
Example against ldap:///
ldapsearch -H ldap://ldap.forumsys.com:389
as opposed to
ldapsearch -h ldap.forumsys.com -p 389
I would note that the -Z(Z) options are for startTLS (generally against
port 389). It is not valid to mix startTLS with ldaps:// URIs. You've not
provided any useful information about your setup, so it's not possible to
give you much help past that.
As for your SASL question, as documented in the ldapsearch man page, you
provide the SASL Mech as a parameter to the -Y option. For example:
ldapsearch -Y GSSAPI -H ldap://ldap.forumsys.com:389
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
On 3/30/22 19:28, Stefan Kania wrote:
> That's what can be found in the FAQ on openldap.org:
> https://www.openldap.org/faq/data/cache/605.html
> I would trust this more then any rumors on any stackxxxx page ;)
But in this case it's the other way round. The text in the FAQ-O-MATIC
is outdated (and cannot be changed I presume).
In the mean-time the IETF position of this had changed. But nobody
updates any LDAP-related IETF standards anymore.
Personally I'm recommending LDAPS over StartTLS ext.op. since ever.
Ciao, Michael.
--On Friday, June 06, 2014 4:41 PM -0700 Andrei Cipu
<andrei.cipu(a)yahoo.com> wrote:
> Hi all,
>
> I'm using openldap-2.4.31 compiled with gnutls25 on Rapsbmc (pre-compiled
> by the distribution) and I'm trying to make ldap+StartTls work with
> ldapsearch (simple ldap:// works like a charm).
Get a current version of OpenLDAP, and use openssl, not gnutls.
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
--On Saturday, October 3, 2020 12:36 AM +0000 Siddharth Jain
<siddjain(a)live.com> wrote:
>
> But ldapsearch throws an error:
>
>
> $ ldapsearch -d 1 -x -H ldaps://ldap.foo.com:636 ... -ZZ
This is not valid.
Either you:
(a) use ldap:// with -ZZ (startTLS)
OR
(b) use ldaps://
Both will result in a TLS secured connection if successful
But you absolutely CANNOT combine startTLS + ldaps://
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Am Sun, 26 Feb 2012 11:49:14 +0100
schrieb Daniel Pocock <daniel(a)pocock.com.au>:
>
>
>
> Is there some way to ensure that a client who connects on port 389 can
> do nothing without StartTLS?
>
> Or is it necessary to just disable port 389 and only listen for
> ldaps:/// ?
read on TLS OPTIONS in
man ldap.conf(5) and man slapd.conf(5)
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
Buchan Milne skrev, on 30-01-2008 10:57:
>>> It seems that no matter what you select here, if the port is
>>> 389, it does STARTTLS:
>>>
>>> Jan 29 17:59:16 seaknight slapd[840]: conn=0 fd=15 ACCEPT from
>>> IP=127.0.0.1:53243 (IP=0.0.0.0:389)
>>> Jan 29 17:59:16 seaknight slapd[840]: conn=0 op=0 STARTTLS
>>> Jan 29 17:59:16 seaknight slapd[840]: conn=0 op=0 RESULT oid=
>>> err=0 text= Jan 29 17:59:16 seaknight slapd[840]: conn=0
>>> fd=15 TLS established tls_ssf=256 ssf=256
>> This is encouraging - I guess you are not using the same version of
>> slapd as I am? (I'm using 2.4.7, which apparently has a bug with
>> STARTTLS, at least in Debian it does).
>
> I don't use Debian, and on production platforms I don't use the packages
> supplied by the distro, but the rebuilds (which are available at
> http://staff.telkomsa.net/packages/) of the Mandriva package, for which I am
> the maintainer. The output in my reply was from my Mandriva 2008.0 x86_64,
> running the 2.3.38 package supplied with the distro. I will try and test the
> 2.4.7 packages sometime later today.
FWIW your rhl5 src rpm rebuilt on Fedora FC6 has no problems with ldaps,
ldap starttls or ldapi; it does everything perfectly normally -
otherwise I'd have reacted negatively far sooner.
[...]
Best,
--Tonni
--
Tony Earnshaw
Email: tonni at hetnet dot nl
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.
--
Clément OUDOT
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
--On Thursday, September 24, 2020 9:51 PM +0530 Shaheena Kazi
<shaheena.kazi(a)gmail.com> wrote:
> But when I run /opt/openssl/bin/openssl s_client -connect
> localhost:389, I get the output as below:
> root@xxxxxxxxx# /opt/openssl/bin/openssl s_client -connect localhost:389
You have to issue an LDAP startTLS, which you failed to do.
I.e.,
openssl s_client -connect localhost:389 -starttls ldap
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
On 3/31/22 08:11, Ulrich Windl wrote:
> I think the point was that you can bind even when not having started TLS before.
>
> I don't know whether this can prevent it:
> olcSecurity: ssf=0 update_ssf=128 simple_bind=64
You can prevent the bind operation to succeed but the clear-text
password was already revealed to network sniffers. Be aware of that.
This does not mean that you shouldn't use this security setting. It's
useful because it makes misconfigured systems, only supporting StartTLS
ext.op., fail early during integration tests - hopefully before real
passwords are used.
Ciao, Michael.