Search results for "starttls" - openldap-technical

RE: LDAPS Support

by Maucci, Cyrille

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.

7 years

Re: Secure replication

by Quanah Gibson-Mount

--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>

8 years, 1 month

cn=config (MMR) replication causes ldapsearch -ZZ to hang on RHEL 6.7

by Frank Crow

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

9 years, 2 months

Re: syncrepl without cleartext password.

by Christian Kratzer

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/

9 years, 7 months

Re: [EXT] RE: ldap proxy

by Quanah Gibson-Mount

--On Wednesday, February 26, 2025 4:30 PM -0800 Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > You told it to use simple binds, not SASL. Here's an example ldapsearch using a SASL/EXTERNAL bind setting all parameters via the command line. ldapsearch -Y EXTERNAL -o tls_cacert=/etc/ssl/certs/myca.pem -o tls_cert=/home/joe/mycert.pem -o tls_key=/home/joe/mycert.key -H ldaps://host.domain.com OR if using starttls: ldapsearch -ZZ -Y EXTERNAL -o tls_cacert=/etc/ssl/certs/myca.pem -o tls_cert=/home/joe/mycert.pem -o tls_key=/home/joe/mycert.key -H ldap://host.domain.com --Quanah

3 months, 1 week

Re: TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure

by Siddharth Jain

is it necessary to specify both TLS_CACERT and TLS_CACERTDIR ? or can the full path to ca cert be specified in TLS_CACERT? what does this mean? 16.2.2.1. TLS_CACERT <filename> This is equivalent to the server's TLSCACertificateFile option. As noted in the TLS Configuration<https://www.openldap.org/doc/admin24/tls.html#TLS%20Configuration> section, a client typically may need to know about more CAs than a server, but otherwise the same considerations apply. 16.2.2.2. TLS_CACERTDIR <path> This is equivalent to the server's TLSCACertificatePath option. The specified directory must be managed with the OpenSSL c_rehash utility as well. If using Mozilla NSS, <path> may contain a cert/key database. ________________________________ From: Howard Chu <hyc(a)symas.com> Sent: Friday, October 2, 2020 10:27 PM To: Siddharth Jain <siddjain(a)live.com>; openldap-technical(a)openldap.org <openldap-technical(a)openldap.org> Subject: Re: TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure Quanah Gibson-Mount wrote: > > > --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:// Also, TLS_CERT/TLS_KEY are user-only directives. Re-read the ldap.conf(5) manpage. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 years, 8 months

Re: Dovecot can't connect to openldap over starttls

by info＠gwarband.de

Am 2017-03-21 20:36, schrieb Dieter Klünter: > Am Mon, 20 Mar 2017 19:16:49 +0100 > schrieb info(a)gwarband.de: > >>> Am 2017-03-20 16:18, schrieb Dan White: >>>> On 03/20/17 16:06 +0100, info(a)gwarband.de wrote: >>>>> I don't have any idea how to set a higher debug level to dovecot. >>>>> In my opinion I have the highest. So I can't deliver a greater >>>>> log. >>>> >>>> I recommend consulting Dovecot's advice on how to run a debugger, >>>> or dig >>>> into the code which calls libldap. >> >>> There isn't too much to "debug" in Dovecot's TLS implementation, >>> it's not doing anything fancy asides from calling the >>> ldap_start_tls_s. >>> >>> I am not sure what debugging you could try further. >>> >>> Aki >> >> This was the answer of the dovecot mailing list. >> Maybe it would be possible that people from this mailinglist >> communicate directly with the dovecot mailinglist to find the >> soulution together and easier. > > You may test and debug by means of OpenSSL s_client(1). The starttls > and protocol options might provide some insight. > > -Dieter I have found with the dovecot mailinglist the soulution. It was a permission problem because dovecot can't access the *.crt with the rights of a subgroup. Thanks. Tobias

8 years, 2 months

Re: olcTLSVerifyClient: demand not taking effect

by Philip Guenther

On Tue, 13 Mar 2012, Peter Wood wrote: > Also I tried all variations of olcTLSVerifyClient: [demand|hard|true] with > the same result. olcTLSVerifyClient: <level> Specifies what checks to perform on client certificates in an incoming TLS session, if any. <...> Note the "if any" part. That config option says, "If the client negotiates TLS, whether because it's connecting via an ldaps connection or used the StartTLS operation on an ldap connection, then this is the requirements regarding client certificates." If the client connects via ldap (or ldapi) and doesn't use the StartTLS operation, then the olcTLSVerifyClient setting HAS NO EFFECT. If you want the server to reject authentication requests that don't use TLS, then you need to look at the olcSecurity setting. To quote the manpage: olcSecurity: <factors> Specify a set of security strength factors (separated by white space) to require (see olcSaslSecprops's minssf option for a description of security strength factors). The directive may be specified globally and/or per-database. ssf=<n> specifies the overall security strength factor. transport=<n> specifies the transport security strength factor. tls=<n> specifies the TLS security strength factor. sasl=<n> specifies the SASL security strength factor. update_ssf=<n> specifies the overall security strength factor to require for directory updates. update_transport=<n> specifies the transport security strength factor to require for directory updates. update_tls=<n> specifies the TLS security strength factor to require for directory updates. update_sasl=<n> specifies the SASL security strength factor to require for directory updates. simple_bind=<n> specifies the security strength factor required for simple username/password authentication. Note that the transport factor is measure of security provided by the underlying transport, e.g. ldapi:// (and eventually IPSEC). It is not normally used. Philip Guenther

13 years, 2 months

Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)

by Dieter Kluenter

Quanah Gibson-Mount <quanah(a)symas.com> writes: > This is expected to be the final testing call for 2.4.45, with an > anticipated release, depending on feedback, during the week of > 2017/05/29. > > For this testing call, we particularly need folks to test OpenLDAP > with startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series > and with the 1.1 series). There is currenly nothing in the test suite > that covers encrypted connections (Although it's on my todo list). To > build against OpenSSL 1.1 may also require cyrus-sasl HEAD out of the > cyrus-sasl GIT repository, depending on your build options as the > current cyrus-sasl release does not support the OpenSSL 1.1 series. > It can be found at <https://github.com/cyrusimap/cyrus-sasl>. If you > build with GSSAPI and use Heimdal, you will also need the Heimdal > 7.1.0 or later release (as that is where OpenSSL 1.1 support was > added). It can be obtained from <http://h5l.org/>. [...] All tests succeeded, source built against openssl-1.0.2j, startTLS. ldaps and sasl EXTERNAL showed no failures. ldapwhoami -Y EXTERNAL -Z -H ldap://localhost:9007 SASL/EXTERNAL authentication started SASL username: cn=Dieter Kluenter,ou=Partner,o=AVCI,c=DE SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de ldapwhoami -Y EXTERNAL -H ldaps://localhost:9008 SASL/EXTERNAL authentication started SASL username: cn=Dieter Kluenter,ou=Partner,o=AVCI,c=DE SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

8 years

Re: ssf Security Question

by William Brown

On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote: > William Brown wrote: > > Just want to point out there are some security risks with ssf > > settings. > > I have documented these here: > > > > https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht > > ml > > Nice writeup. I always considered SSF values to be naive and somewhat > overrated. People expect too much when looking at these numbers - > especially regarding the "strength" of cryptographic algorithms which > changes over time anyway with new cryptanalysis results coming up. > > Personally I always try to implement a TLS-is-must policy and prefer > LDAPS (with correct protocol and ciphersuites configured) over > LDAP/StartTLS to avoid this kind of pre-TLS leakage. > Yes, I deliberately ignore "LDAPS is deprecated". ;-] I agree. If only there was a standards working group that could deprecate startTLS in favour of TLS .... :) > > Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse > to > accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which > is > IMO also somewhat questionable. Yes, I really agree. While a plain text port exists, data leaks are possible. We should really improve this situation, where we have TLS for all data to prevent these mistakes. I think a big part of the issue is that GSSAPI forces the encryption layer, and can't work via an already encrypted channel. The people I know involved in this space are really resistant to changing this due to the "kerberos centric" nature of the products. > > Ciao, Michael. > -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane

7 years, 6 months

openldap-technical search results for query "starttls"