Search results for "starttls" - openldap-technical

Re: TLS very strange behaviour

by Rich Megginson

On 10/10/2011 11:40 AM, Olivier wrote: > Hello, > > I have two ldap servers, my goal is to configure them > in multimaster mode with an sasl authentication based > on certificates. With the following configurations, that > works well : > > > ### slapd.conf for ldap1 : > > syncrepl rid=121 > provider=ldap://ldap2.example.fr > searchbase="dc=example,dc=fr" > schemachecking=on > type=refreshOnly > interval=00:00:00:05 > retry="10 +" > bindmethod=sasl > saslmech=external > authcid="cn=replicator,ou=system,dc=example,dc=fr" > authzid="dn:cn=replicator,ou=system,dc=example,dc=fr" > tls_cert=/etc/openldap/cacerts/syncrepl.crt > tls_key=/etc/openldap/cacerts/syncrepl.key > tls_reqcert=demand > > mirrormode on > > ### slapd.conf for ldap1 : > > syncrepl rid=121 > provider=ldap://ldap2.example.fr > searchbase="dc=example,dc=fr" > schemachecking=on > type=refreshOnly > interval=00:00:00:05 > retry="10 +" > bindmethod=sasl > saslmech=external > authcid="cn=replicator,ou=system,dc=example,dc=fr" > authzid="dn:cn=replicator,ou=system,dc=example,dc=fr" > tls_cert=/etc/openldap/cacerts/syncrepl.crt > tls_key=/etc/openldap/cacerts/syncrepl.key > tls_reqcert=demand > > mirrormode on > > # of course I have provided the CA certificate in both files. > TLSCACertificateFile /etc/openldap/cacerts/CA.crt > > # I also configured properly acl for "replicator" > # and have issued the right certificate > > -> No problem, it works. > > Now I also have configured certificates to be able to talk with the > servers on TLS : > > ### slapd.conf for ldap1 : > TLSCertificateFile /etc/openldap/cacerts/server1.crt > TLSCertificateKeyFile /etc/openldap/cacerts/server1.key > TLSCipherSuite HIGH > > ### slapd.conf for ldap2 : > TLSCertificateFile /etc/openldap/cacerts/server2.crt > TLSCertificateKeyFile /etc/openldap/cacerts/server2.key > TLSCipherSuite HIGH > > That also works perfectly ( ldapsearch with -ZZ responds properly ) > > I therefore decided to try to starttls for synchronisation. > > I added in syncrepl for ldap1 : > > ## ldap1 > > syncrepl > ... > starttls=yes > tls_cacert=/etc/openldap/cacerts/CA.crt > ... > > And the synchronizations worked well, TLS being started when ldap1 is client. > > I then added the starttls directive on server ldap2 and removed it > on server ldap1 : > > ## ldap2 > > syncrepl > ... > starttls=yes > tls_cacert=/etc/openldap/cacerts/CA.crt > ... > > The synchronization also worked well, TLS being started this time when > ldap2 is client. > > HERE IS THE PROBLEM : > > II tried to starttls in bothe syncrepl directives on both servers > ldap1 and ldap2, > here is what I get : > > ldap1 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync > ... > TLS: error: accept - force handshake failure: errno 11 - moznss error -12273 > TLS: can't accept: TLS error -12273:Unknown code ___P 15. > TLS: error: connect - force handshake failure: errno 0 - moznss error -12272 > TLS: can't connect: TLS error -12272:Unknown code ___P 16. > slap_client_connect: URI=ldap://ldap2.example.fr Warning, > ldap_start_tls failed (-11) > slap_client_connect: URI=ldap://ldap2.example.fr > ldap_sasl_interactive_bind_s failed (-6) > do_syncrepl: rid=121 rc -6 retrying > > ldap2 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync > ... > TLS: error: connect - force handshake failure: errno 0 - moznss error -12272 > TLS: can't connect: TLS error -12272:Unknown code ___P 16. > slap_client_connect: URI=ldap://ldap1.eaxample.fr:389 Warning, > ldap_start_tls failed (-11) > slap_client_connect: URI=ldap://ldap1.example.fr:389 > ldap_sasl_interactive_bind_s failed (-6) > do_syncrepl: rid=211 rc -6 retrying > TLS: error: accept - force handshake failure: errno 11 - moznss error -12273 > TLS: can't accept: TLS error -12273:Unknown code ___P 15. > > Any idea ? -12272 is SSL_ERROR_BAD_MAC_ALERT and -12273 is SSL_ERROR_BAD_MAC_READ I've seen this when the client and server do not have the same SSL certificate signature algorithm support. Is everything running on RHEL6 and/or Fedora 14 and later? > --- > Olivier >

13 years, 9 months

Re: require StartTLS

by Howard Chu

Dieter Klünter wrote: > Am Sun, 26 Feb 2012 12:39:26 +0100 > schrieb Daniel Pocock<daniel(a)pocock.com.au>: > >> >> >> On 26/02/12 12:15, Dieter Klünter wrote: >>> 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) >>> >> >> Thanks for the fast reply >> >> I'm not keen to rely on ldap.conf (client side config) - I want to >> enforce a preference for TLS from the server side, to avoid a >> situation where some application might be configured non-TLS by >> mistake. >> >> 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. > >> From man slapd.conf > TLSVerifyClient<level> > demand | hard | true > These keywords are all equivalent, for > compatibility reasons. The client certificate is > requested. If no certificate is provided, or a bad > certificate is provided, the session is immediately terminated. > > >> >> To make an analogy, in postfix, I require `plain' authentication: but >> the client is not allowed to try to authenticate until it has done >> StartTLS, because I never want a client to try sending a password >> over a channel that is not encrypted. > > Postfix is a LDAP client, thus all client configurations apply > according to man ldap.conf(5). Dieter, no. Josh Miller's post was correct. http://www.openldap.org/lists/openldap-technical/201202/msg00414.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

13 years, 4 months

Re: no contextCSN attribute on consumers

by cYuSeDfZfb cYuSeDfZfb

Hi Quanah, Thanks for the swift reponse! I think I do, yes, see, from consumer one: olcSyncrepl: {0}rid=202 provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" starttls=critical tls_reqcert=demand olcSyncrepl: {1}rid=201 provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" starttls=critical tls_reqcert=demand olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389 olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389 And the second consumer looks similar. Thanks again! On Mon, 12 Jun 2023 at 15:56, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Monday, June 12, 2023 3:23 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > Is there any explanation, why I would be unable to obtain these > > contextCSN attributes through an ldapsearch? > > Do you have the syncprov overlay instantiated on the database on the > consumers? > > --Quanah > > > >

2 years, 1 month

Re: Dovecot can't connect to openldap over starttls

by 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 -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

8 years, 3 months

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation

by Robert Heller

Will these spit out useful error messages? If I just get "TLS Negotiation failure" it is not going to be helpful. At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller > <heller(a)deepsoft.com> wrote: > > > > Slapd is reporting TLS Negotiation failure when SSSD tries to connect to > > it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess > > something is wrong with slapd's TLS configuration -- it is failing to do > > TLS Negotiation, either it is just not doing it or it is doing it wrong > > (somehow). Unless SSSD is not configured properly. > > You need to start with the following: > > >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > > to test startTLS > > and > > ldapwhoami -x -H ldaps://myhost:636 -D binddn -w > > to test without startTLS > > If you can get those to work, then you can move on to SSSD. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

7 years, 9 months

Re: SASL EXTERNAL, sasldb2 and authz-regexp

by Dieter Kluenter

Götz Reinicke - IT-Koordinator <goetz.reinicke(a)filmakademie.de> writes: > Hi folks, [...] > My consumer server should bind to the provider using sasl with the > saslmech external. (Red Hat 5.x, cyrus-sasl-2.1.22, openldap-2.3.43-3 ) > > I'v changed the slapd.conf files on both servers: > > consumer: > > syncrepl ... > bindmethod=sasl > saslmech=EXTERNAL > starttls=yes > > provider: > > authz-regexp > "dn=email=webmaster(a)filmakademie.de,cn=ldap2.filmakademie.de,ou=it > officenet,o=filmakademie baden-wuerttemberg > gmbh,l=ludwigbsburg,st=baden-wuerttemberg,c=de" > "cn=replicator,dc=filmakademie,dc=de" > > after restarting both servers I do get the error: > > <==slap_sasl2dn: Converted SASL name to <nothing> > SASL [conn=0] Error: unable to open Berkeley db /etc/sasldb2: No such > file or directory [...] I don't see a configuration for client certs, as an example I provide my slapd.conf syncrepl rid=042 provider=ldap://rubin.avci.de sizelimit=unlimited bindmethod=sasl saslmech=external starttls=yes tls_cert=/etc/openldap/certs/replicator.pem tls_key=/etc/openldap/certs/replicator-key.pem tls_cacert=/etc/openldap/certs/avciCA.pem tls_reqcert=demand searchbase="o=avci,c=de" scope=sub [...] -Dieter -- Dieter Klünter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

15 years, 2 months

Re: Openldap server with TLS not working

by btb

On 2013.10.03 12.13, Michael Ströder wrote: > btb(a)bitrate.net wrote: >> >> On Oct 2, 2013, at 11.47, Michael Ströder <michael(a)stroeder.com> wrote: >> >>> btb wrote: >>>> On 2013.10.02 07.29, Axel Grosse wrote: >>>> >>>>> when I test on the server itself .. >>>>> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile >>>>> ./ssl/VordelCA.crt >>>>> CONNECTED(00000003) >>>>> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake >>>>> failure:s23_lib.c:188: >>>> >>>> ldaps [port 636] is deprecated. >>>> use starttls with the standard port [389]. >>>> to test, just use ldapsearch [see the reference to -Z in the man page] >>> >>> This is nonsense. >>> >>> From a security perspective there's no reason not to use LDAPS. Well, I'd even >>> recommend LDAPS since SSL/TLS handshake is done *before* a client can send an >>> LDAP PDU. >>> With my deployments I always enable both but prefer LDAPS. >>> >>> I cannot imagine that any LDAP server or client will ever drop support for >>> LDAPS since this would immediately rule out this implementation from broader >>> market share. >> >> i'm not sure what exactly you mean by "this is nonsense". ldaps was never >> offered as a formal specification, and *is* deprecated. > > I don't know of any document forbidding use of LDAPS. > I don't know any server which implements StartTLS which is not capable of > LDAPS (despite configuration choice). deprecated != forbidden. no has has claimed there are any servers which only implement starttls. >> that's a fact: http://www.openldap.org/faq/data/cache/605.html . > > FAQ entries are no formal specification. But you should read all of the FAQ: i guess you could take that up with the author of the faq entry - but you're right about formal specifications being important ;) . it's probably also worth noting that there are other quite well recognized protocols which have deprecated and/or abandoned their "tunneled" counterparts, some quite formally so - smtp, imap, and xmpp are a few which come to mind. > "Although there is no technical specification for ldaps:// it is widely used." sorry, i'm not sure what you're getting at. i've already clearly stated exactly that, as is clearly seen below. >> ldaps may well be in continued use even given its deprecation, but no one >> is debating that, and it's continued use in light of being deprecated does >> not change that it's deprecated. we all know it's still heavily used, and >> probably will continue to be for, at the very least, quite some time. > > And because it's heavily used it's nonsense to teach everybody this pseudo > argument about "deprecated". And as said I find it even to be more secure. you're welcome to find ldaps more secure than starttls. plenty of others don't. this has probably veered off topic enough at this point. over and out. -ben

11 years, 9 months

Re: Antw: [EXT] Re: STARTTLS vs LDAPS

by Quanah Gibson-Mount

--On Thursday, March 31, 2022 9:03 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > So while talking about FAQs, maybe someone add: > "How to convert am OpenLDAP STARTLTS configuration to ldaps://?" Not sure what you're going for here. Steps are basically ensure that ldaps is one of the URIs passed to slapd, and adjust client code to use the ldaps URI instead of ldap URI. --Quanah

3 years, 3 months

Re: Trying to understand an error message

by Hallvard B Furuseth

Khaled Blah writes: > Thanks for your reply, Hallvard. Do I understand it correctly that I > can re-use LDAP structures on which a bind has already been done? Yes, a Bind on an LDAP* remains in force until the next Bind, possibly StartTLS (I don't remember) or Unbind. > Do you know of any other stateful data I would have to look at? The assertion implies a broken data structure, so my guess is you either reused the LDAP* after Unbind, or you have some data corruption in your program. -- Hallvard

14 years, 8 months

Re: ldap with TLS

by Quanah Gibson-Mount

--On Tuesday, April 23, 2013 5:38 PM -0400 Rodney Simioni <rodney.simioni(a)verio.net> wrote: > When I issue a ' ldapsearch –x ZZ', it works flawlessly but when > URI ldap://127.0.0.1/ And what URI do you use for ldapsearch? I'm guessing one with a hostname. Good luck trying to get startTLS to work with an IP address. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

12 years, 2 months

openldap-technical search results for query "starttls"