Search results for "starttls" - openldap-technical

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

1 year, 5 months

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

7 years, 8 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, 1 month

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

14 years, 7 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, 1 month

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

2 years, 7 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

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

11 years, 7 months

Re: SSL/TLS connection on port 389

by Buchan Milne

On Tuesday 29 January 2008 19:18:15 Carr, Chris wrote: > > 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. > What log level are you choosing to get this output? Is it just "conns"? stats (256). > > However, if you select 636 as the port, it greys out the "Use secure > > connection" drop-down box, and does ldaps. > > Yes. > > > Jan 29 18:03:51 seaknight slapd[840]: conn=14 fd=27 ACCEPT from > > IP=127.0.0.1:54153 (IP=0.0.0.0:636) > > Jan 29 18:03:51 seaknight slapd[840]: conn=14 fd=27 closed > > (TLS negotiation > > failure) > > Jan 29 18:03:58 seaknight slapd[840]: conn=15 fd=27 ACCEPT from > > IP=127.0.0.1:45074 (IP=0.0.0.0:389) > > > > (Can't get it to work right right now with ldaps ...). Note that this may simply be due to me using self-signed certs ... > Me neither, though I had assumed that was password-related. > > > Note however that evo caches LDAP connections, it seems you > > need to restart it for your config changes to take effect. > > Ah, I didn't know that - thanks. > > > And, it will only prompt you for the password once the > > connection is up ... > > Hmmm. If I understand the output correctly, it's rejecting the > connection before asking for a password. I will have to investigate this > again. > > > > Could somebody explain to me how to tell slapd to accept secure > > > connections on port 389? > > > > start slapd with with no -h flag, or -h "ldaps:/// ldap:///" > > so it listens on port 636 for ldaps connections, and 389 for > > ldap connections (which could use START_TLS to upgrade). > > I just have -h "ldaps:///" - I presumed the ldap:/// was covered > automatically as the default. No, logically there should be a way to prevent the use of a port which could be used by some other application ... > > > Sorry if this is a really stupid question, but according to > > > the docs the "startTLS" process should be automatic if a > > > secure connection comes in on port 389. Something is > > > obviously not quite right. > > > > Hmm, SSL/TLS isn't really automatic ... > > Sorry, I meant that the connection is upgraded to SSL/TLS if the > STARTTLS command is sent by the client (which you have verified > Evolution does). > > Thanks muchly for your help. I will do some more testing with Evolution > until I lose the will to live once again. > > I am now even getting errors with Outlook. It seems to connect ok, but > whenever I do a search it says "The Properties dialog box could not be > displayed. To display the Properties dialog box, you must select exactly > one item." - I don't know what this is about, I get the same message > whether my search is gibberish (should return no matches), unique > (should return a single match) or general (should return multiple > matches). No results are returned. It seems to be a completely incorrect > error message. It seems Outlook doesn't like self-signed certs, so I'll look at this later once I've had time to sort out certificates for these boxes. Regards, Buchan

16 years, 10 months

Re: Syncrepl SSL fail

by Hugo Deprez

Hello, if I don't sepcify the key path I get the following error when starting slpad : slap_client_connect: URI=ldaps://ldap.domain.fr:1024/ TLS context initialization failed (-1) slapd[31043]: do_syncrepl: rid=003 rc -1 retrying (9 retries left) So I need the tls_key=/etc/ldap/ssl/ldap-key.pem pointing to the key of the provider. Any idea why I should specify the private key of the provider ? Regards, On 2 December 2011 15:11, Raffael Sahli <public(a)raffaelsahli.com> wrote: > On 12/02/2011 02:50 PM, Hugo Deprez wrote: >> >> Hello Philip, >> >> thank you for your explanation. >> >> This is more clear now. >> >> So I changed my configuration like : >> >> Syncrepl rid=003 >> provider=ldaps://my.server:1024/ >> type=refreshOnly >> retry="60 10 600 +" >> interval=00:00:00:10 >> searchbase="dc=my,dc=domain" >> scope=sub >> schemachecking=on >> bindmethod=simple >> tls_reqcert=demand >> tls_cert=/etc/ssl/certs/ldap-cert.pem >> tls_cacert=/etc/ssl/certs/ldap-cert.pem >> tls_key=/etc/ldap/ssl/ldap-key.pem >> binddn="cn=syncrepluser..." >> credentials=******** >> >> I added the tls_key, tls_cacert, tls_reqcert parameter. >> The tls option are using the certificate and the key of the LDAP Provider. >> >> The last thing I don't understand is that the tls_key is needed. So I >> need to deploy the private key of the provider to each consumer. >> >> I though the certificate would be sufficient ? > > > No you don't have to deploy the private key! > In syncrepl, just define the tls_cacert, and it works. > > > >> >> Regards, >> >> >> >> >> >> On 18 October 2011 06:28, Philip Guenther >> <guenther+ldaptech(a)sendmail.com> wrote: >>> >>> On Sun, 16 Oct 2011, Hugo Deprez wrote: >>>> >>>> It seems that the proper configuration for my case is : >>>> >>>> syncrepl rid=003 >>>> provider=ldaps://ldap.mydomain.fr:1024/ >>>> type=refreshOnly >>>> retry="60 10 600 +" >>>> interval=00:00:00:10 >>>> searchbase="dc=mydomain,dc=fr" >>>> scope=sub >>>> schemachecking=on >>>> bindmethod=simple >>>> tls_reqcert=never >>>> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" >>>> credentials=my_password >>>> >>>> It works, but I am confuse with those parameters. If I understand >>>> well, I will never use TLS here, but only ssl ? >>>> Hence, it was a TLS issue ? >>> >>> No, you're using TLS. You're just not using the StartTLS operation. >>> >>> There are two ways to use SSL/TLS: "negotiate-on-connect" and "upgrade >>> from clear". The former is what you get when you use an ldaps:// URL, >>> where the first data the client sends is the raw SSL/TLS ClientHello >>> packet. The latter is what you get when you use an ldap:// URL and have >>> starttls=yes or starttls=critical, where the first data the client sends >>> is LDAP protocol data in the clear, including a StartTLS request. If the >>> server sends a success response to that StartTLS request, then the client >>> starts the SSL/TLS handshake with its ClientHello packet. >>> >>> This should answer why it failed when you tried to combine an ldaps:// >>> URL >>> with starttls=yes: the exchange was already using SSL/TLS and (rightly) >>> libldap won't let you negotiate multiple levels of SSL/TLS encryption. >>> >>> (You may note that I write "SSL/TLS". That's because they're just >>> different versions of the same protocol. Using 'SSL' as a shorthand for >>> "negotiate on connect" and 'TLS' for "upgrade from clear" is poor naming, >>> as the choice of method is orthogonal to the protocol version. Your >>> ldaps:// connection is probably negotiating the TLS 1.0 protocol (aka SSL >>> version 3.1), just as an ldap:// connection using StartTLS may, on a >>> poorly configured server, negotiate SSL 3.0) >>> >>> >>> Next: the fact that you need tls_reqcert=never for TLS negotiation to >>> succeed strongly suggests the problem is either >>> a) the subject and subjectAltName of the cert don't match the hostname in >>> the URL, OR >>> b) the client doesn't have the self-signed CA cert at the root of the >>> signing chain for the server's cert. >>> >>> Those are both necessary to protect the server against Man-in-the-Middle >>> attacks. >>> >>> (It used to be that tls_reqcert=allow would disable check (b) and only >>> perform check (a), or at least that was the case when using the OpenSSL >>> crypto backend, but that behavior has apparently been removed from the >>> version in git as of August. Given the vagaries of the error reporting >>> of >>> the underlying crypto libraries, this was a useful tool in tracking down >>> which check was causing TLS failures. Oh well.) >>> >>> So, does the server's certificate subject or subjectAltName match the >>> hostname from the URL the client is using? Have you verified that the CA >>> at the root of the server's cert's chain really is configured for the >>> client? >>> >>> >>> Philip Guenther > > > > -- > Raffael Sahli > public(a)raffaelsahli.com > Switzerland >

12 years, 11 months

openldap-technical search results for query "starttls"