I setup LDAPS (yes, will be switching to ldap + StartTLS) and ran
intosomething odd and I'm really just looking for a bit of context.
Everything is working correctlyand I'm able to authenticate clients to
the ldap server, however when I runthe following ldapsearch I get an error:
jschaeffer@zipmaster07:~$ ldapsearch -LLL -v -D
cn=admin,dc=harmonywave,dc=com -W -H ldaps://baneling -b
uid=jschaeffer,ou=People,dc=harmonywave,dc=com
ldap_initialize( ldaps://baneling:636/??base )
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
And from the debug output:
531c7c0a ber_get_next on fd 12 failed errno=0 (Success)
531c7c0a conn=1000 op=1 do_unbind
531c7c0a connection_close: conn=1000 sd=12
531c7c18 slap_listener_activate(6):
531c7c18 >>> slap_listener(ldaps:///)
531c7c18 connection_get(12): got connid=1001
531c7c18 connection_read(12): checking for input on id=1001
531c7c18 connection_get(12): got connid=1001
531c7c18 connection_read(12): checking for input on id=1001
531c7c18 connection_read(12): unable to get TLS client DN, error=49 id=1001
531c7c18 connection_get(12): got connid=1001
531c7c18 connection_read(12): checking for input on id=1001
ber_get_next
531c7c18 ber_get_next on fd 12 failed errno=0 (Success)
531c7c18 connection_close: conn=1001 sd=12
If I use the FQDN for the URI then everything works fine and I get
results. I know DNS is working correctly, I can ping the server name
and it returns the FQDN and reverse DNS resolution also works. The
hostname and hostname -f commands work correctly on both client and server.
Was it never intended for ldap commands to resolve server names to their
FQDN? I'm also assuming that ldap + StartTLS would show the same behavior.
On 26/2/2012 1:39 μμ, Daniel Pocock wrote:
> I've looked at the TLS options and I have TLS running fine already. I
> notice the TLSCipherSuite option sets the cipher level within TLS, but
> it doesn't appear to guarantee that TLS is used.
I am not an expert on it, but I have found this solution:
http://www.openldap.org/lists/openldap-software/200707/msg00341.html on
the issue, although I haven't used it myself (but I am planning to).
I believe it does what you want.
If there is another solution, more straightforward, using simply
configuration directives, I don't know.
Best regards,
Nick
On Sep 3, 2011, at 6:00 PM, Nate Marks wrote:
> [root@ldap01 cacerts]# openssl s_client -CAfile /etc/pki/tls/certs/cacert.pem -connect 10.60.1.57:389
> CONNECTED(00000003)
> 4392:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
> [root@ldap01 cacerts]#
To use tls on the standard port you would need to submit the option -starttls xxx to openssl. Where xxx is the protocol.
But ldap as protocol is not supported. Even if it would, you could not type in anything useful.
--
Marco
Terry Gardner wrote:
> can the server be configured to reject all requests on that exception
> except for the StartTLS extended request in order to prevent clients from
> transmitting data in the clear?
Watch out for configuration directives 'security' and 'sasl-secprops'.
You might want to set TLSCipherSuite to avoid that a client uses a weak cipher
or crypto protocol.
But strictly speaking nothing prevents a misconfigured client to send
clear-text credentials over the wire. Rejecting processing them only gives a
strong hint that this is not the desired behaviour...
Ciao, Michael.
https://www.openldap.org/faq/data/cache/605.html
" ldaps:// is deprecated in favor of Start TLS [RFC2830]. OpenLDAP 2.0 supports both."
I understand it as OpenLDAP 2.1 and greater don't.
++Cyrille
-----Original Message-----
From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of web(a)tomjay.co.uk
Sent: Tuesday, June 05, 2018 4:36 AM
To: openldap-technical(a)openldap.org
Subject: LDAPS Support
Hello,
I'm under the impression that LDAPS (and not StartTLS) has been depreciated in OpenLDAP, but I can't find anything on the OpenLDAP website that says this. Is this the case, and is there a reference for it?
Thanks.
--On Saturday, May 06, 2017 1:56 AM +0000 "Real, Elizabeth (392K)"
<Elizabeth.Real(a)jpl.nasa.gov> wrote:
> The olcSyncRepl directive on both systems needs to go from:
>
> olcSyncRepl: rid=001 provider=ldap
>
> to:
>
> olcSyncRepl: rid=001 provider=ldaps
The use of "ldap://" does not mean that you have insecure replication. The
"ldaps" designation was developed to allow for SSL encrypted connections as
a part of LDAPv2, which did not have a formal design spec for allowing SSL
encryption. The LDAPv3 spec, which is what OpenLDAP 2.4 (and much earlier
version) implement, specifically has startTLS as a part of that
specification, which uses "ldap:///". I.e., ldaps is a bastardized hack
for LDAPv2. The proper way to do TLS encryption with LDAPv3 capable
servers such as OpenLDAP 2.[1-4+] is to use the startTLS extended operation
over a "ldap:///" URI.
In addition, there are other ways to have an encrypted connection between
an LDAP client and server without involving TLS at all, such as SASL/GSSAPI.
As Michael noted, you can, in addition to enabling TLS encryption between
the client and servers, use client cert authentication (SASL/EXTERNAL) so
as to remove the requirement for clear text credentials to be stored in the
olcSyncRepl attribute (if using simple binds). And again, the usage of
SASL/GSSAPI also precludes the neccessity of storing cleartext credentials
in the olcSyncRepl attribute.
As an aside, I would note that 2.4.40 is completely unsafe to use with
multimaster replication.
I would generally suggest forming a clear set of requirements for your
replication environment, and then asking how to implement them. Your
current question is too vague/general to really be answered well.
Hope that helps!
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
I'm trying to move my OpenLDAP MMR configuration from RHEL 6.5 (OpenLDAP
2.4.23) to RHEL 6.7 (OpenLDAP 2.4.40). On RHEL 6.5 it is working no with
no problems. On RHEL 6.7, the configuration causes "ldapsearch -ZZ" to
hang indefinitely.
The cn=config section in slapd.conf looks like this:
# sync provider configuration
overlay syncprov
syncprov-checkpoint 1 1
syncrepl rid=001
provider=ldap://server1
searchbase="cn=config"
filter="(|(objectClass=olcDatabaseConfig)(objectClass=olcOverlayConfig))"
bindmethod=sasl saslmech=EXTERNAL starttls=critical
tls_cert=/etc/openldap/csa-certs/config.crt
tls_key=/etc/openldap/csa-certs/config.key
tls_cacert=/etc/openldap/csa-certs/cacert.pem
tls_reqcert=demand
type=refreshAndPersist
retry="5 10 10 10 30 +"
timeout=1
syncrepl rid=002
provider=ldap://server2
searchbase="cn=config"
filter="(|(objectClass=olcDatabaseConfig)(objectClass=olcOverlayConfig))"
bindmethod=sasl saslmech=EXTERNAL starttls=critical
tls_cert=/etc/openldap/csa-certs/config.crt
tls_key=/etc/openldap/csa-certs/config.key
tls_cacert=/etc/openldap/csa-certs/cacert.pem
tls_reqcert=demand
type=refreshAndPersist
retry="5 10 10 10 30 +"
timeout=1
mirrormode on
If I comment out that section in slapd.conf then "ldapsearch -ZZ" works but
(obviously) I don't get cn=config replication.
Am I doing something wrong in the configuration? Is it a fluke that it is
working on 2.4.23 in the first place? Or does anyone know what may have
changed (or is more strict or whatever) in the 2.4.40 release?
Should I try to just remove RHEL's version of OpenLDAP and install the
latest from openldap.org instead?
Any assistance is highly appreciated!
Thanks,
--
Frank
Hi,
On Tue, 27 Oct 2015, Prakash Padadune wrote:
> I want to implement syncrepl without having cleartext password in the
> slapd.conf.
> How this can be achieved?
authenticate using client certificates and sasl_method = external
You will need the private key files on the clients though.
olcSyncrepl: {0}rid=001 provider=ldap://ldap1.foo.bar bindmethod=sasl saslmech=external keepalive=60:6:10 starttls=yes tls_cert="/etc/ssl/ce rts/server.cert" tls_key="/etc/ssl/certs/server.key" tls_cacert="/etc/ssl/certs/CA.cert" tls_reqcert=demand tls_crlcheck =none filter="(objectclass=*)" searchbase="dc=foo,dc=bar" scope=sub type=refreshAndPersist retry="60 10 300 +"
olcSyncrepl: {1}rid=002 provider=ldap://ldap2.foo.bar bindmethod=sasl saslmech=external keepalive=60:6:10 starttls=yes tls_cert="/etc/ssl/ce
rts/server.cert" tls_key="/etc/ssl/certs/server.key" tls_cacert="/etc/ssl/certs/CA.cert" tls_reqcert=demand tls_crlcheck =none filter="(objectclass=*)" searchbase="dc=foo,dc=bar" scope=sub type=refreshAndPersist retry="60 10 300 +"
then map your certificate identity to an entry in your tree that has appropriate permissions:
olcAuthzRegexp: {0}"cn=([^,]*)," "cn=$1,ou=servers,dc=foo,dc=bar"
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
