Search results for "starttls" - openldap-technical

Re: SSL/TLS connection on port 389

by Howard Chu

Tony Earnshaw wrote: > Buchan Milne skrev, on 30-01-2008 10:57: >>> 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. Probably because it still uses OpenSSL, and not GnuTLS like Debian does. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

16 years, 9 months

Re: How do tool verify certs with ldapi:// ?

by Michael Ströder

Peter Marschall wrote: > On Monday, 28. May 2012, Michael Ströder wrote: >> Peter Marschall wrote: >>> On Monday, 28. May 2012, Philip Guenther wrote: >>>> On Mon, 28 May 2012, Michael Ströder wrote: >>>>> Peter Marschall wrote: >>>>>> how do the openldap tools technically verfify certificates with >>>>>> ldapi:// ? >>>>> >>>>> Which certs do you want to verify? >>>> >>>> I assume the answer is "the one the server returns when you do StartTLS >>>> on the ldapi:// connection". >>> >>> Correct. >> >> So if the quite liberal RFC 6125 does not provide any inspiration this >> boils down to being undefined. StartTLS over LDAPI is an unusal scenario >> anyway. > > Thanks for your reply. > It helps a bit ("looking at the issue from the standard angle"), but > my question was how the openldap tools do it. I think the standards are what is relevant here. The arbitrarily check for "localhost" does not make sense because "localhost" does not sufficiently specify the name of the server. The server is an end entity for the CA and the CA guarantees having checked the server's identity (or checked whether someone was authorized to request a cert for the server's name). So I wouldn't trust any CA which issues certs for "localhost". => StartTLS over LDAP is undefined and probably every API should simple refuse it at all or accept any server cert. In both cases the underlying LDAPI channel is fully trusted anyway. If the client really would like to implement an additional *security* check that a rogue attacker did not trick the client to connect to another Unix domain socket (MITM service) checking the server's identity by matching "localhost" also does not make sense to me. Ciao, Michael.

12 years, 5 months

RE: Strange behavior with TLS with self-signed certs

by Michael Starling

Ahh.. Thanks for the explanations. -Mike From: Chris.Jacobs(a)apollogrp.edu To: mlstarling31(a)hotmail.com; daff(a)pseudoterminal.org; openldap-technical(a)openldap.org Date: Fri, 7 Jan 2011 12:55:57 -0700 Subject: RE: Strange behavior with TLS with self-signed certs Equipment limitation: Our old load balancers could load balance StartTLS, not SSL. Our new ones can load balance SSL, not StartTLS. Paranoia: If you wish to encrypt the entire session, from the very beginning, use SSL. Firewall limits you to port 389 (corp policy, difficult network/firewall team, etc): … and want encryption, then use StartTLS. - chris From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Michael Starling Sent: Friday, January 07, 2011 11:45 AM To: daff(a)pseudoterminal.org; openldap-technical(a)openldap.org Subject: RE: Strange behavior with TLS with self-signed certs Ok..I implemented what you explained for testing purposes and found the following to be true: If I use ssl start_tls with the ldap:// URL schema then my client connects to my LDAP server on port 389. If I use ssl on with ldaps://. then my client connects on port 636. I think i remember reading somewhere that TLS could use either port so my question is when my client connects on 389 using ssl start_tls is the session encrypted? My other question would be why the two different means to the same end? Is it just a matter of which port you want to use? -Mike > From: daff(a)pseudoterminal.org > To: openldap-technical(a)openldap.org > Subject: Re: Strange behavior with TLS with self-signed certs > Date: Fri, 7 Jan 2011 19:45:46 +0100 > > On Friday 07 January 2011 04:18:40 Michael Starling wrote: > > #TLS settings > > ssl start_tls > > ssl on > > That should be either "ssl start_tls" OR "ssl on", not both. If you > specify "ssl start_tls" then you should use the ldap:// URL schema, if > you specify "ssl on" then you should use ldaps://. > > Andreas This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

13 years, 10 months

Problems with 4-way multi-master

by Mark

I've been testing a 4-way multi-master setup using OpenLDAP 2.4.25 and I'm having some sporadic problems with it that I'm having difficulty diagnosing.. I have four identical RHEL 4.9 machines on the same switch (NTP syncronized to same stratum 2 servers): dual-core Xeon 5110 1.60GHz 8GB RAM 100Mb full-duplex NIC OpenLDAP 2.4.25, BDB 4.8.30, OpenSSL 1.0.0d, Cyrus SASL 2.1.23 (using no tls/ssl at this time) I start the slapds with '-d conns,sync' then commence. I ldapadd 1000 DNs to one of the servers. After all the syncing has stopped I then compare the slapd contents against each other looking for differences. Occasionally there are as much as a couple hundred DNs missing from one or more of the instances. When that happens I've noticed that the mmaster with less DNs has lost its consumer connection to a mmaster provider (confirmed using lsof and netstat) and will never attempt a re-connect, but the provider still shows the connection (using lsof and netstat). When the consumer gets in this state I can connect to its cn=config and cn=monitor backends (and browse them) but when I try to connect to its multi-master'd backend the connection attempt just hangs. It's almost like the connect succeeds but the client is waiting for a response from the server (and never gets it). Also, the consumer slapd will not respond to a 'kill -TERM' at this time and must be 'kill -KILL'd. The same thing occurs sometimes when I delete the entire tree. I've been trying to catch logging information that might help but so far nothing's jumping out at me. While I continue to try to reproduce and parse through logfiles maybe someone can look at my slapd.confs below and see if I might have configured something wrong (I'm listing the original slapd.conf files below, but I've used slaptest to convert them to slapd.d/cn=config.ldif format): HOST1 slapd.conf: include /tmp/openldap/multi-master/etc/schema/core.schema include /tmp/openldap/multi-master/etc/schema/cosine.schema include /tmp/openldap/multi-master/etc/schema/nis.schema argsfile /tmp/openldap/multi-master/var/run/slapd.args pidfile /tmp/openldap/multi-master/var/run/slapd.pid threads 16 idletimeout 0 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 001 modulepath /tmp/openldap/multi-master/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,cn=config rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm database monitor rootdn cn=manager,cn=monitor rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R database hdb suffix dc=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI directory /tmp/openldap/multi-master/var/data/dc=example,dc=com cachesize 30000 cachefree 5 checkpoint 128 15 dncachesize 25000 idlcachesize 100000 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://host2:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://host3:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=003 provider=ldap://host4:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off HOST2 slapd.conf: include /tmp/openldap/multi-master/etc/schema/core.schema include /tmp/openldap/multi-master/etc/schema/cosine.schema include /tmp/openldap/multi-master/etc/schema/nis.schema argsfile /tmp/openldap/multi-master/var/run/slapd.args pidfile /tmp/openldap/multi-master/var/run/slapd.pid threads 16 idletimeout 0 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 002 modulepath /tmp/openldap/multi-master/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,cn=config rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm database monitor rootdn cn=manager,cn=monitor rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R database hdb suffix dc=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI directory /tmp/openldap/multi-master/var/data/dc=example,dc=com cachesize 30000 cachefree 5 checkpoint 128 15 dncachesize 25000 idlcachesize 100000 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://host1:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://host3:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=003 provider=ldap://host4:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off HOST3 slapd.conf: include /tmp/openldap/multi-master/etc/schema/core.schema include /tmp/openldap/multi-master/etc/schema/cosine.schema include /tmp/openldap/multi-master/etc/schema/nis.schema argsfile /tmp/openldap/multi-master/var/run/slapd.args pidfile /tmp/openldap/multi-master/var/run/slapd.pid threads 16 idletimeout 0 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 003 modulepath /tmp/openldap/multi-master/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,cn=config rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm database monitor rootdn cn=manager,cn=monitor rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R database hdb suffix dc=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI directory /tmp/openldap/multi-master/var/data/dc=example,dc=com cachesize 30000 cachefree 5 checkpoint 128 15 dncachesize 25000 idlcachesize 100000 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://host1:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://host2:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=003 provider=ldap://host4:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off HOST4 slapd.conf: include /tmp/openldap/multi-master/etc/schema/core.schema include /tmp/openldap/multi-master/etc/schema/cosine.schema include /tmp/openldap/multi-master/etc/schema/nis.schema argsfile /tmp/openldap/multi-master/var/run/slapd.args pidfile /tmp/openldap/multi-master/var/run/slapd.pid threads 16 idletimeout 0 writetimeout 5 reverse-lookup off timelimit time.soft=30 time.hard=300 sizelimit size.soft=500 size.hard=1000 password-hash {SSHA} loglevel stats sync serverid 004 modulepath /tmp/openldap/multi-master/libexec moduleload back_monitor.la moduleload back_hdb.la moduleload syncprov.la database config rootdn cn=manager,cn=config rootpw {SSHA}yMFj3Y7KPh223NkkKLQsFeLUVm08Ckpm database monitor rootdn cn=manager,cn=monitor rootpw {SSHA}vPVSN8o8eRnLdC/bGS7yDwQGeH4BHc0R database hdb suffix dc=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw {SSHA}0obbsJw5Yq2XAkdd/kS7vokaB9rrSOtI directory /tmp/openldap/multi-master/var/data/dc=example,dc=com cachesize 30000 cachefree 5 checkpoint 128 15 dncachesize 25000 idlcachesize 100000 index objectClass eq index entryCSN eq index entryUUID eq syncrepl rid=001 provider=ldap://host1:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=002 provider=ldap://host2:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off syncrepl rid=003 provider=ldap://host3:1389 type=refreshAndPersist interval=00:00:05:00 retry="15 +" searchbase="dc=example,dc=com" binddn="cn=manager,dc=example,dc=com" credentials="example_pass" starttls=no schemachecking=off Thank you.

13 years, 7 months

Re: connection problem with ldapmodify -Y EXTERNAL -H ldapi:///

by Howard Chu

Dan White wrote: > On 03/10/11 21:43 +0200, Andreas Rudat wrote: >> Am 03.10.2011 20:51, schrieb Dan White: >>> On 03/10/11 19:41 +0200, Andreas Rudat wrote: >>>> tls_cert >>>> tls_key >>> >>> My mail client may have corrupted this part of your configuration. You'll >>> of course need valid entries here. >>> >> These options are defaults in my conf. With some comments, after >> installing the slapd package > > You'll need to create a (client) certificate and populate those two values, > or otherwise find a way to specify them while performing your ldapsearch > command. > > I don't see how you will will be able to obtain SASL EXTERNAL over STARTTLS > otherwise. How did this conversation get to STARTTLS? The Subject is asking about SASL EXTERNAL over ldapi, which does not need TLS. -- -- 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, 1 month

Re: TLS + SSL and openldap

by Bjørn Ruberg

Dieter Kluenter wrote: > Bruno Steven <aspenbr(a)gmail.com> writes: > > >> Hi, >> >> I am trying configure openldap work with tls , but I have two question about this, first >> when I use tls openldap use port 389 and ssl port 639 , is this correct ? >> Second How I can test connection between client and server, cryptography is working ? >> > > There is no ssl port! SSL (Secure Socket Layer) is a proprietary, > licence based protocol, owned by Netscape? I don't know whether the > IPR of this protocol have been part of the Netscape/AOL deal. OpenLDAP, > and most other network based applications, have implemented Transport > Layer Security (TLS), RFC 2246. As a LPI certified professional you > should be aware of this. > [citation needed] > OpenLDAP uses port 639, which has not been assigned by IANA to LDAP(S) > protocol, as TLS-enabled port. Port 389 is still required for the LDAP > extended operation startTLS (RFC-4513). > # getent services ldaps ldaps 636/tcp In my experience, OpenLDAP has no problems listening to port 636 as an SSL enabled port. TLS (using STARTTLS) runs on 389. - Bjørn

14 years, 11 months

Re: Problems using OpenLPAP for authentification of users: Client library issues STARTTLS but TLS is not configured

by Quanah Gibson-Mount

--On Thursday, July 10, 2008 1:11 PM +0200 Dieter Kluenter <dieter(a)dkluenter.de> wrote: > Hi, > > Jörg Spilker <js(a)jetsys.de> writes: > >> Hi, >> >> well, i don´t know what i´m doing wrong. I just want to authenticate >> unix and windows users against OpenLDAP Database. I followed some howtos >> to setup openldap, winbind etc. and nearly everything seems just fine. >> But authenticating unix users finally doesn´t work. I´ve attached the >> syslog output. START TLS extension not supportet. This is true, as i >> haven´t configured OpenLPAP for TLS. But my LDAP client configuration >> doesn´t specify an LDAPS URL. So what´s going wrong? > > Some Linux distributions have enabled 'ssl start_tls' as default, > please check your /etc/ldap.conf carefully. Also, don't confuse startTLS and LDAPS. They are two entirely different things. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

16 years, 4 months

Re: Dovecot can't connect to openldap over starttls

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

7 years, 7 months

ldap_start_tls_s fails

by James Gordon

Hi, I have just installed symas openldap v2.6. Everything seems to be running ok, except that I cannot get C interface ldap_start_tls_s() to work. If I do something like this the program works fine: ldap_initialize(&ld, HOST)); rc = ldap_simple_bind_s(ld, BASEDN, BASEPWD); ldap_unbind(ld); However, if I do something like this the program fails with ldap error string "local error": ldap_initialize(&ld, HOST)); ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE); ldap_start_tls_s(ld, NULL, NULL); rc = ldap_simple_bind_s(ld, BASEDN, BASEPWD); ldap_unbind(ld); From the command line, TLS seems to work fine: The following works ok: ldapsearch -H ldap://ldap.domain.com:389 -D "cn=admin,dc=domain,dc=com" -w secret -b “ou=users,dc=domain,dc=com” -ZZ This also works ok from a different server openssl s_client -verify 10 -starttls ldap -showcerts -connect ldap.domain.com:389 -CApath /etc/ssl/certs (verification = ok): However, if I omit the CApath it fails, not sure if that is a clue to the problem: openssl s_client -verify 10 -starttls ldap -showcerts -connect ldap.domain.com:389 (Verification error: unable to get local issuer certificate). Any help would be appreciated. If this is the wrong list, let me know. ldapsearch -H ldap://ldap.red0rb.com:389 -D "cn=admin,dc=red0rb,dc=com" -w MdKlUIGYm0o63HxQ0RWYuKWkRkgr3Ohy -b “ou=users,dc=red0rb,dc=com” -ZZ

2 years, 8 months

Re: STARTTLS vs LDAPS

by thomaswilliampritchard＠gmail.com

Quanah Gibson-Mount wrote: > --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania > <stefan(a)kania-online.de> 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 ;) > Unfortunately, the FAQ is dead weight we want to kill and not maintained in > any way, shape, or form. It's currently provided for historical purposes. > > As to this overall discussion, one of the primary issues with connections > over ldap:/// is that there's zero way with simple binds to prevent the > bind dn + password being sent in the clear by a client to the server. With > ldaps:/// the encryption is set up before the BIND occurs so you don't run > this risk. Is that true? Surely I can 1. connect to the server 2. Send starttls 3. Then bind bind can't I? I'm fairly certain I've used LDAP Client operating in that order. > > So from that standpoint, I'd personally prefer to see ldaps:/// qualified > in an RFC so the standardization argument goes away and ldaps be noted as > the preferred method for sites that require encryption. I agree there is no technical reason LDAPS would not be better. It should be made standard.

2 years, 7 months

openldap-technical search results for query "starttls"