- openldap-bugs - openldap.org

Re: (ITS#8373) replica with multiple providers hits errors
by quanah＠symas.com 18 Oct '18

18 Oct '18

--On Friday, February 19, 2016 1:33 AM +0000 quanah(a)zimbra.com wrote: Played around with this again today, and the issue no longer occurs. It seems one of the many replication related fixes since I reported this ITS has solved the problem. Closing the ITS. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by douglas.royds＠taitradio.com 18 Oct '18

18 Oct '18

Full_Name: Douglas Royds Version: HEAD OS: Ubuntu 16.04 URL: ftp://ftp.openldap.org/incoming/douglas-royds-181017.patch Submission from: (NULL) (202.37.96.2) To achieve binary-reproducible builds across different build hosts, build paths, and users, we need to set the WHOWHERE value with something fixed. In this patch I set it to the SOURCE_DATE_EPOCH if set (see https://reproducible-builds.org/specs/source-date-epoch/). If you're not trying to do a reproducible build, it won't be set, so the existing WHOWHERE string will apply. Debian have set this string to their own Debian-specific value: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833179 WHOWHERE="$(dpkg-vendor --query vendor) package version $(dpkg-parsechangelog -SVersion)" Tait Communications Ltd hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8925) Please remove the entry for mirror.switch.ch from the Download page
by quanah＠symas.com 17 Oct '18

17 Oct '18

Hi Thomas, --On Thursday, October 11, 2018 12:08 PM +0000 switchmirror(a)switch.ch wrote: > I already sent twice a message to info(a)openldap.org, but no action or > answer received. The ITS system is the correct spot for this request. ;) > So I try it on this channel. > > Please drop the reference to SWITCH (Switzerland, mirror.switch.ch) on the > Download web page: > http://www.openldap.org/software/download/ Done. > BTW: I noticed that the Austrian mirror on gd.tuwien.ac.at has completely > disappeared, there is no DNS entry for it anymore. Thanks, I removed that one as well. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re:Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by quanah＠symas.com 17 Oct '18

17 Oct '18

--On Sunday, October 14, 2018 10:03 PM +0800 =E8=8E=AB=E4=BA=9A=E7=94=B7 = <nanmor(a)126.com>=20 wrote: > Run ' ldd /usr/local/openldap.2.4.46/bin/ldapsearch' in Redhat, result: > linux-vdso.so.1 =3D> (0x00007ffd959d6000) > libsasl2.so.3 =3D> /lib64/libsasl2.so.3 (0x00007fae80012000) > libssl.so.10 =3D> /lib64/libssl.so.10 (0x00007fae7fd9f000) > libcrypto.so.10 =3D> /lib64/libcrypto.so.10 Your Redhat build is linked to the system OpenSSL 1.0.2k release. This=20 clearly won't support TLS 1.3. lrwxrwxrwx 1 root root 16 Jun 19 14:00 libssl.so.10 -> libssl.so.1.0.2k Closing this ITS as invalid. I suggest fixing your build process on your=20 RedHat box to link to the correct OpenSSL build. It appears you have the=20 RH openssl development package installed, which is why you're encountering=20 various issues. However, none of this is related to OpenLDAP itself, which = as I've already noted, behaves correctly when all sides (client & server)=20 are linked to OpenSSL 1.1.1. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠symas.com 16 Oct '18

16 Oct '18

--On Tuesday, October 16, 2018 1:30 PM +0200 Ond=C5=99ej Kuzn=C3=ADk=20 <ondra(a)mistotebe.net> wrote: >> - test we're a replicated op, not just on shadow > > The patch is available here: > https://github.com/mistotebe/openldap/tree/its8927 I still get err 16 with this patch and the servers fall back to REFRESH. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8927) slapo-ppolicy is destructive to delta-sync replication
by ondra＠mistotebe.net 16 Oct '18

16 Oct '18

On Fri, Oct 12, 2018 at 05:32:52PM +0000, quanah(a)symas.com wrote: > --On Friday, October 12, 2018 5:27 PM +0000 quanah(a)symas.com wrote: > > > So this should succeed, and yet it fails. Need to figure out why. > > I dug into this further with Ondrej, and the issue is that ppolicy was > never updated to work correctly in a delta-sync MMR environment. ppolicy on > the receiving server currently has logic to test if it is a shadow (i.e., > replica) and if so, change its behavior. But there is no similar logic to > handle the case if the receiving server is an MMR node (i.e., a shadow and > a master). > > The following 3 changes to the code base for ppolicy would alleviate this > issue and other potential issues: > > - test we're a replicated op, not just on shadow The patch is available here: https://github.com/mistotebe/openldap/tree/its8927 > - issue MOD_REPLACE (concurrent binds could have cleared that attribute on > the other servers) > - expect MOD_REPLACE as well as MOD_DELETE on replicated ops Maybe not exactly required since ppolicy will actually treat these deletes as soft deletes if needed. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by ondra＠mistotebe.net 16 Oct '18

16 Oct '18

On Mon, Oct 15, 2018 at 02:54:56PM +0000, hyc(a)symas.com wrote: > Ondřej Kuzník wrote: >> On Mon, Oct 15, 2018 at 01:53:30PM +0000, hyc(a)symas.com wrote: >>> ondra(a)mistotebe.net wrote: >>>> Also, whenever we fall back from deltasync into plain syncrepl, >>>> we should make sure that the accesslog entries we generate from >>>> this are never used for further replication which might be >>>> thought to be a separate issue. >>> >>> That should already be the case, since none of these ops will have a >>> valid CSN. >> >> I faintly remember Quanah seeing these accesslog entries used by >> consumers at some point, but I might be mistaken. >> >> The more general point is making sure its potential syncrepl consumer >> not even try and use the accesslog entries we added before these - the >> refresh has created a strange gap in the middle (or worse, duplicated >> ops if a contextCSN element jumped backwards). But if we enforced that, >> the question is how to get modifications originating from this replica >> replicated elsewhere - unless we decide they can't be salvaged? > > We could set the replica to reject user mods while in refresh phase. > Not sure how friendly that is, whether apps would be smart enough to > retry somewhere else. The concern here is about changes that have happened before we found out we can't replicate from another server. And it is likely some of these changes are the reason we couldn't reconcile with our provider and would cause the same if we decided to push them. >> And should the contextCSN reset terminate not just all inbound syncrepl >> sessions, but the outbound ones as well? > > Need to be careful about race conditions here, or you could end up > with all nodes just terminating each other and everything halting. Yes, that would actually happen... The existing state seems quite destructive though, if you have that same situation now (two masters in present phase from each other at the same time), you lose data. The question is what is the priority here? Currently it seems we want replication to continue at the expense of losing modifications on conflict. We might at least log that happened and allow someone to revert this decision later. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by hyc＠symas.com 15 Oct '18

15 Oct '18

Ond=C5=99ej Kuzn=C3=ADk wrote: > On Mon, Oct 15, 2018 at 01:53:30PM +0000, hyc(a)symas.com wrote: >> ondra(a)mistotebe.net wrote: >>> Also, whenever we fall back from deltasync into plain syncrepl, we >>> should make sure that the accesslog entries we generate from this = are >>> never used for further replication which might be thought to be a >>> separate issue. >> >> That should already be the case, since none of these ops will have a v= alid CSN. >=20 > I faintly remember Quanah seeing these accesslog entries used by > consumers at some point, but I might be mistaken. >=20 > The more general point is making sure its potential syncrepl consumer > not even try and use the accesslog entries we added before these - the > refresh has created a strange gap in the middle (or worse, duplicated > ops if a contextCSN element jumped backwards). But if we enforced that, > the question is how to get modifications originating from this replica > replicated elsewhere - unless we decide they can't be salvaged? We could set the replica to reject user mods while in refresh phase. Not = sure how friendly that is, whether apps would be smart enough to retry somewhe= re else. > And should the contextCSN reset terminate not just all inbound syncrepl > sessions, but the outbound ones as well? Need to be careful about race conditions here, or you could end up with a= ll nodes just terminating each other and everything halting. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by ondra＠mistotebe.net 15 Oct '18

15 Oct '18

On Mon, Oct 15, 2018 at 01:53:30PM +0000, hyc(a)symas.com wrote: > ondra(a)mistotebe.net wrote: >> This is my understanding of the above discussion: >> - deltasync consumer has just switched to full refresh (but is ahead >> from this provider in some ways) >> - provider sends the present list >> - consumer deletes extra entries, builds a new cookie >> - problem is that the new cookie is built to reflect the union of both >> the local and received cookies even though we may have undone some of >> the changes which we then ignore >> >> If that's accurate, there are some approaches that could fix it: >> >> 1. Simple one is to remember the actual cookie we got from the server >> and refuse to delete entries with entryCSN ahead of the provided CSN >> set. Problem is that we get even further from being able to replicate >> from a generic RFC4533 provider. >> >> 2. Instead, when present phase is initiated, we might terminate all >> other sessions, adopt the complete CSN set and restart them only once >> the new CSN set has been fully established. > > (2) makes sense. >> >> Also, whenever we fall back from deltasync into plain syncrepl, we >> should make sure that the accesslog entries we generate from this are >> never used for further replication which might be thought to be a >> separate issue. > > That should already be the case, since none of these ops will have a valid CSN. I faintly remember Quanah seeing these accesslog entries used by consumers at some point, but I might be mistaken. The more general point is making sure its potential syncrepl consumer not even try and use the accesslog entries we added before these - the refresh has created a strange gap in the middle (or worse, duplicated ops if a contextCSN element jumped backwards). But if we enforced that, the question is how to get modifications originating from this replica replicated elsewhere - unless we decide they can't be salvaged? And should the contextCSN reset terminate not just all inbound syncrepl sessions, but the outbound ones as well? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by hyc＠symas.com 15 Oct '18

15 Oct '18

ondra(a)mistotebe.net wrote: > This is my understanding of the above discussion: > - deltasync consumer has just switched to full refresh (but is ahead > from this provider in some ways) > - provider sends the present list > - consumer deletes extra entries, builds a new cookie > - problem is that the new cookie is built to reflect the union of both > the local and received cookies even though we may have undone some of > the changes which we then ignore > > If that's accurate, there are some approaches that could fix it: > > 1. Simple one is to remember the actual cookie we got from the server > and refuse to delete entries with entryCSN ahead of the provided CSN > set. Problem is that we get even further from being able to replicate > from a generic RFC4533 provider. > > 2. Instead, when present phase is initiated, we might terminate all > other sessions, adopt the complete CSN set and restart them only once > the new CSN set has been fully established. (2) makes sense. > > Also, whenever we fall back from deltasync into plain syncrepl, we > should make sure that the accesslog entries we generate from this are > never used for further replication which might be thought to be a > separate issue. That should already be the case, since none of these ops will have a valid CSN. > Maybe the ITS#8486 work might be useful for this if > we have a way of signalling to accesslog to reset minCSN accordingly > to the new CSN set. > > The former is simpler, but the latter feels like the only one that > actually addresses these problems in full. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by ondra＠mistotebe.net 15 Oct '18

15 Oct '18

This is my understanding of the above discussion: - deltasync consumer has just switched to full refresh (but is ahead from this provider in some ways) - provider sends the present list - consumer deletes extra entries, builds a new cookie - problem is that the new cookie is built to reflect the union of both the local and received cookies even though we may have undone some of the changes which we then ignore If that's accurate, there are some approaches that could fix it: 1. Simple one is to remember the actual cookie we got from the server and refuse to delete entries with entryCSN ahead of the provided CSN set. Problem is that we get even further from being able to replicate from a generic RFC4533 provider. 2. Instead, when present phase is initiated, we might terminate all other sessions, adopt the complete CSN set and restart them only once the new CSN set has been fully established. Also, whenever we fall back from deltasync into plain syncrepl, we should make sure that the accesslog entries we generate from this are never used for further replication which might be thought to be a separate issue. Maybe the ITS#8486 work might be useful for this if we have a way of signalling to accesslog to reset minCSN accordingly to the new CSN set. The former is simpler, but the latter feels like the only one that actually addresses these problems in full. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re:Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by nanmor＠126.com 14 Oct '18

14 Oct '18

--Apple-Mail=_375D3C00-4B90-466D-8A3B-98B223B1B007 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Quanah, Run ' ldd /usr/local/bin/ldapsearch' in ubuntu client, result: linux-vdso.so.1 =3D> (0x00007ffd6a0f2000) libssl.so.1.0.0 =3D> /lib/x86_64-linux-gnu/libssl.so.1.0.0 = (0x00007f659a72a000) libcrypto.so.1.0.0 =3D> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 = (0x00007f659a2e6000) libresolv.so.2 =3D> /lib/x86_64-linux-gnu/libresolv.so.2 = (0x00007f659a0cb000) libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 = (0x00007f6599d01000) libdl.so.2 =3D> /lib/x86_64-linux-gnu/libdl.so.2 = (0x00007f6599afd000) /lib64/ld-linux-x86-64.so.2 (0x00007f659a993000) =20 Run ' ldd /usr/local/openldap.2.4.46/bin/ldapsearch' in Redhat, result: linux-vdso.so.1 =3D> (0x00007ffd959d6000) libsasl2.so.3 =3D> /lib64/libsasl2.so.3 (0x00007fae80012000) libssl.so.10 =3D> /lib64/libssl.so.10 (0x00007fae7fd9f000) libcrypto.so.10 =3D> /lib64/libcrypto.so.10 =20 Run ' ldd /usr/local/ssl/bin/openssl' in both, result : linux-vdso.so.1 =3D> (0x00007ffff61fb000) libssl.so.1.1 =3D> /usr/local/ssl/lib/libssl.so.1.1 = (0x00007f1ca0272000) libcrypto.so.1.1 =3D> /usr/local/ssl/lib/libcrypto.so.1.1 = (0x00007f1c9fd8e000) libz.so.1 =3D> /lib64/libz.so.1 (0x00007f1c9fb78000) libdl.so.2 =3D> /lib64/libdl.so.2 (0x00007f1c9f974000) libpthread.so.0 =3D> /lib64/libpthread.so.0 (0x00007f1c9f757000) libc.so.6 =3D> /lib64/libc.so.6 (0x00007f1c9f38a000) /lib64/ld-linux-x86-64.so.2 (0x00007f1ca0519000) =20 They are not use same libssl.so.1.1, when I changed the ubuntu /redhat = libssl.so link to the libssl.so.1.1 and libcrypto.so link to = libcrypto.so.1.1, and make the openldap.2.4.46 again, it will pop out an = error, =20 cc -g -O2 -o apitest apitest.o ./.libs/libldap.a = /home/openldap-soft/openldap-2.4.46/libraries/liblber/.libs/liblber.a = ../../libraries/liblber/.libs/liblber.a = ../../libraries/liblutil/liblutil.a -lsasl2 -lssl -lcrypto -lresolv ./.libs/libldap.a(os-ip.o): In function `ldap_pvt_is_socket_ready': /home/openldap-soft/openldap-2.4.46/libraries/libldap/os-ip.c:262: = warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' = instead /home/openldap-soft/openldap-2.4.46/libraries/libldap/os-ip.c:262: = warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' = instead ./.libs/libldap.a(tls_o.o): In function `tlso_session_chkhost': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:629: = undefined reference to `sk_num' /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:633: = undefined reference to `sk_value' ./.libs/libldap.a(tls_o.o): In function `tlso_ctx_init': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:415: = undefined reference to `SSL_CTX_set_tmp_rsa_callback' ./.libs/libldap.a(tls_o.o): In function `tlso_ca_list': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:169: = undefined reference to `sk_new_null' /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:174: = undefined reference to `sk_free' ./.libs/libldap.a(tls_o.o): In function `tlso_ctx_new': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:245: = undefined reference to `SSLv23_method' ./.libs/libldap.a(tls_o.o): In function `tlso_destroy': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:227: = undefined reference to `EVP_cleanup' /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:233: = undefined reference to `ERR_free_strings' ./.libs/libldap.a(tls_o.o): In function `tlso_init': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:201: = undefined reference to `SSL_load_error_strings' /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:202: = undefined reference to `SSL_library_init' /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:203: = undefined reference to `OpenSSL_add_all_digests' ./.libs/libldap.a(tls_o.o): In function `tlso_ctx_ref': /home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:255: = undefined reference to `CRYPTO_add_lock' collect2: error: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory = `/home/openldap-soft/openldap-2.4.46/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory = `/home/openldap-soft/openldap-2.4.46/libraries' make: *** [all-common] Error 1 =20 And we found in openldap2.4.46 code in line 629 of = libraries/libldap/tls_o.c will call sk_GENERAL_NAME_num from openssl = code, we checked the openssl1.1.1 code, it does not have = sk_GENERAL_NAME_num, but it could be find in openssl1.0. Thanks a lot, best regards, nancy --Apple-Mail=_375D3C00-4B90-466D-8A3B-98B223B1B007 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial" class=""><div class=""><span style="font-family: Arial" class="">Hi</span><span style="font-family:"Microsoft YaHei"" class=""></span> Quanah<span style="font-family:"Microsoft YaHei"" class="">,<br class=""></span></div><div class=""><br class=""><span style="font-family:"Microsoft YaHei"" class=""></span></div><div style="margin: 0in;" class=""><span style="font-family:"Microsoft YaHei";font-size: 10.0pt;color:black" lang="en-US" class="">Run '</span><span style="font-family:Calibri; font-size:11.0pt" lang="zh-CN" class=""> ldd /usr/local/bin/ldapsearch</span><span style="font-family:"Microsoft YaHei";font-size:10.0pt;color:black" lang="en-US" class="">' in ubuntu client, result: </span></div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class="">linux-vdso.so.1 =><span style="mso-spacerun:yes" class="">  </span>(0x00007ffd6a0f2000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f659a72a000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f659a2e6000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f659a0cb000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6599d01000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6599afd000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>/lib64/ld-linux-x86-64.so.2 (0x00007f659a993000)</div><p style="margin:0in;font-family:Calibri;font-size:11.0pt" lang="zh-CN" class=""> </p><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span lang="en-US" class="">Run '</span><span lang="zh-CN" class=""> ldd /usr/local/openldap.2.4.46/bin/ldapsearch</span><span lang="en-US" class="">' in Redhat, result: </span></div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span lang="en-US" class=""><span style="mso-spacerun:yes" class="">        </span></span><span lang="zh-CN" class="">linux-vdso.so.1 =><span style="mso-spacerun:yes" class="">  </span>(0x00007ffd959d6000)</span></div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007fae80012000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libssl.so.10 => /lib64/libssl.so.10 (0x00007fae7fd9f000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span lang="en-US" class=""><span style="mso-spacerun:yes" class="">       </span></span><span lang="zh-CN" class=""><span style="mso-spacerun:yes" class=""> </span>libcrypto.so.10 => /lib64/libcrypto.so.10 </span></div><p style="margin:0in;font-family:Calibri;font-size:11.0pt" class=""> </p><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span lang="en-US" class="">Run '</span><span lang="zh-CN" class=""> ldd /usr/local/ssl/bin/openssl</span><span lang="en-US" class="">' in both, result :</span></div><div style="margin: 0in; font-size: 11pt;" class=""><span style="font-family:"Microsoft YaHei"" lang="en-US" class=""><span style="mso-spacerun:yes" class="">      </span></span><span style="font-family:Calibri" lang="zh-CN" class=""><span style="mso-spacerun:yes" class=""> </span>linux-vdso.so.1 =><span style="mso-spacerun:yes" class="">  </span>(0x00007ffff61fb000)</span></div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libssl.so.1.1 => /usr/local/ssl/lib/libssl.so.1.1 (0x00007f1ca0272000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libcrypto.so.1.1 => /usr/local/ssl/lib/libcrypto.so.1.1 (0x00007f1c9fd8e000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libz.so.1 => /lib64/libz.so.1 (0x00007f1c9fb78000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libdl.so.2 => /lib64/libdl.so.2 (0x00007f1c9f974000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1c9f757000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>libc.so.6 => /lib64/libc.so.6 (0x00007f1c9f38a000)</div><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span style="mso-spacerun:yes" class="">        </span>/lib64/ld-linux-x86-64.so.2 (0x00007f1ca0519000)</div><p style="margin:0in;font-family:Calibri;font-size:11.0pt" class=""> </p><div style="margin: 0in; font-family: Calibri; font-size: 11pt;" class=""><span lang="en-US" class="">They are not use same </span><span lang="zh-CN" class=""><span style="mso-spacerun:yes" class=""> </span>libssl.so.1.1</span><span lang="en-US" class="">, when I changed the ubuntu /redhat libssl.so link to the libssl.so.1.1 and </span><span lang="zh-CN" class="">libcrypto.so</span><span lang="en-US" class=""> link to </span><span lang="zh-CN" class="">libcrypto.so.1.1</span><span lang="en-US" class="">, and make the openldap.2.4.46 again, it will pop out an error,</span></div><p style="margin:0in;font-family:Arial;font-size:11.0pt" class=""> </p><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">cc -g -O2 -o apitest apitest.o ./.libs/libldap.a /home/openldap-soft/openldap-2.4.46/libraries/liblber/.libs/liblber.a ../../libraries/liblber/.libs/liblber.a ../../libraries/liblutil/liblutil.a -lsasl2 -lssl -lcrypto -lresolv</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(os-ip.o): In function `ldap_pvt_is_socket_ready':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/os-ip.c:262: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/os-ip.c:262: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_session_chkhost':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:629: undefined reference to `sk_num'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:633: undefined reference to `sk_value'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_ctx_init':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:415: undefined reference to `SSL_CTX_set_tmp_rsa_callback'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_ca_list':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:169: undefined reference to `sk_new_null'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:174: undefined reference to `sk_free'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_ctx_new':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:245: undefined reference to `SSLv23_method'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_destroy':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:227: undefined reference to `EVP_cleanup'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:233: undefined reference to `ERR_free_strings'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_init':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:201: undefined reference to `SSL_load_error_strings'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:202: undefined reference to `SSL_library_init'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:203: undefined reference to `OpenSSL_add_all_digests'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">./.libs/libldap.a(tls_o.o): In function `tlso_ctx_ref':</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">/home/openldap-soft/openldap-2.4.46/libraries/libldap/tls_o.c:255: undefined reference to `CRYPTO_add_lock'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">collect2: error: ld returned 1 exit status</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">make[2]: *** [apitest] Error 1</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">make[2]: Leaving directory `/home/openldap-soft/openldap-2.4.46/libraries/libldap'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">make[1]: *** [all-common] Error 1</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">make[1]: Leaving directory `/home/openldap-soft/openldap-2.4.46/libraries'</div><div style="margin: 0in; font-family: Arial; font-size: 10pt; color: black;" class="">make: *** [all-common] Error 1</div><p style="margin:0in;font-family:Calibri;font-size:11.0pt" class=""> </p><div style="margin: 0in;" class=""><span style="font-family:Calibri;font-size:11.0pt" lang="en-US" class="">And we found in openldap2.4.46 code in line 629 of<span style="mso-spacerun:yes" class="">  </span></span><span style="font-family:Calibri; font-size:11.0pt" lang="zh-CN" class="">libraries/libldap/tls_o.c</span><span style="font-family:Calibri;font-size:11.0pt" lang="en-US" class=""> will call<span style="mso-spacerun:yes" class="">  </span></span><span style="font-family:Arial; font-size:10.0pt" lang="en-US" class="">sk_GENERAL_NAME_num from openssl code, we checked the openssl1.1.1 code, it does not have sk_GENERAL_NAME_num, but it could be find in openssl1.0. </span></div> <br class=""><br class=""><div id="spnEditorSign" style="position:relative;zoom:1" class=""></div><div id="divNeteaseMailCard" class=""></div><div class=""><br class=""></div><div class="">Thanks a lot,</div><div class=""><br class=""></div><div class="">best regards,</div><div class="">nancy</div><div class=""><br class=""></div> </div></body></html> --Apple-Mail=_375D3C00-4B90-466D-8A3B-98B223B1B007--

1 0

Re: (ITS#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠symas.com 12 Oct '18

12 Oct '18

--On Friday, October 12, 2018 5:27 PM +0000 quanah(a)symas.com wrote: > So this should succeed, and yet it fails. Need to figure out why. I dug into this further with Ondrej, and the issue is that ppolicy was never updated to work correctly in a delta-sync MMR environment. ppolicy on the receiving server currently has logic to test if it is a shadow (i.e., replica) and if so, change its behavior. But there is no similar logic to handle the case if the receiving server is an MMR node (i.e., a shadow and a master). The following 3 changes to the code base for ppolicy would alleviate this issue and other potential issues: - test we're a replicated op, not just on shadow - issue MOD_REPLACE (concurrent binds could have cleared that attribute on the other servers) - expect MOD_REPLACE as well as MOD_DELETE on replicated ops --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠symas.com 12 Oct '18

12 Oct '18

--On Friday, October 12, 2018 4:14 PM +0000 quanah(a)symas.com wrote: > --On Thursday, October 11, 2018 9:25 PM +0000 quanah(a)openldap.org wrote: > >> When the second action is performed (c), all consumers will go into >> REFRESH mode: > > There appears to be a serious bug in ppolicy. If I look at the accesslog > data that was written out, the "pwdFailureTime" attribute is cleared on > two different entries instead of just the user entry that had its > password reset. I.e., pwdFailureTime is cleared on the user AND the DN > of the manager entry that made the change. Ok, this was a red herring. The idmgmt user had a pwdFailure attribute set. I removed that, and still the underlying err=16 problem occurs, but the idmgmt user reset does not (which is correct now). The user entry on the other masters has the following set after the password failure: pwdFailureTime: 20181012161037.177876Z The MOD op recorded for it on the master accepting changes has: reqMod: userPassword:= {SSHA}He+QPQcFD+1/j9uGZl617/eP50B3/QKj reqMod: pwdChangedTime:= 20181012161047Z reqMod: pwdFailureTime:- reqMod: entryCSN:= 20181012161047.202928Z#000000#001#000000 reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqMod: modifyTimestamp:= 20181012161047Z So this should succeed, and yet it fails. Need to figure out why. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠symas.com 12 Oct '18

12 Oct '18

--On Thursday, October 11, 2018 9:25 PM +0000 quanah(a)openldap.org wrote: > When the second action is performed (c), all consumers will go into > REFRESH mode: There appears to be a serious bug in ppolicy. If I look at the accesslog data that was written out, the "pwdFailureTime" attribute is cleared on two different entries instead of just the user entry that had its password reset. I.e., pwdFailureTime is cleared on the user AND the DN of the manager entry that made the change. dn: reqStart=20181012145703.000000Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20181012145703.000000Z reqEnd: 20181012145703.000001Z reqType: modify reqSession: 1003 reqAuthzID: cn=ldaproot,dc=example,dc=com reqDN: uid=user1,ou=user,dc=example,dc=com reqResult: 0 reqMod: pwdFailureTime:+ 20181012145703.125562Z reqMod: entryCSN:= 20181012145703.125803Z#000000#001#000000 reqMod: modifiersName:= cn=ldaproot,dc=example,dc=com reqMod: modifyTimestamp:= 20181012145703Z reqEntryUUID: ac657c60-e60a-412d-b015-522fc451e89a entryUUID: d2b4a16c-627a-1038-9d4c-dbb80effb9f4 creatorsName: cn=accesslog createTimestamp: 20181012145703Z entryCSN: 20181012145703.125803Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20181012145703Z dn: reqStart=20181012145706.000000Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20181012145706.000000Z reqEnd: 20181012145706.000001Z reqType: modify reqSession: 1003 reqAuthzID: cn=ldaproot,dc=example,dc=com reqDN: cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqResult: 0 reqMod: pwdFailureTime:- reqMod: entryCSN:= 20181012145706.147871Z#000000#001#000000 reqMod: modifiersName:= cn=ldaproot,dc=example,dc=com reqMod: modifyTimestamp:= 20181012145706Z reqEntryUUID: bf72bf9a-6079-102b-83cd-8572a998cec3 entryUUID: d4822668-627a-1038-9d4d-dbb80effb9f4 creatorsName: cn=accesslog createTimestamp: 20181012145706Z entryCSN: 20181012145706.147871Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20181012145706Z dn: reqStart=20181012145706.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20181012145706.000002Z reqEnd: 20181012145706.000003Z reqType: modify reqSession: 1003 reqAuthzID: cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqDN: uid=user1,ou=user,dc=example,dc=com reqResult: 0 reqMod: userPassword:= {SSHA}y8UHEPuMnrOwrZnufP3XrG7ofbHKRpT0 reqMod: pwdChangedTime:= 20181012145706Z reqMod: pwdFailureTime:- reqMod: entryCSN:= 20181012145706.171028Z#000000#001#000000 reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=example,dc=com reqMod: modifyTimestamp:= 20181012145706Z reqEntryUUID: ac657c60-e60a-412d-b015-522fc451e89a entryUUID: d4845d20-627a-1038-9d4e-dbb80effb9f4 creatorsName: cn=accesslog createTimestamp: 20181012145706Z entryCSN: 20181012145706.171028Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20181012145706Z --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8926) glue records + syncrepl
by frederic.goudal＠bordeaux-inp.fr 12 Oct '18

12 Oct '18

> Le 11 oct. 2018 =C3=A0 18:32, Howard Chu <hyc(a)symas.com> a =C3=A9crit = : >=20 > goudal(a)bordeaux-inp.fr wrote: >> Full_Name: Fr.d.ric Goudal >>=20 >> Solution=20 >> -remove by hand the dn: uid=3Dfoo,ou=3Dbar,dc=3Dmy,dc=3Ddomain, = that remove the >> glue object >> - create by hand the ou=3Dbar,dc=3Dmy,dc=3Ddomain >>=20 >> What IMHO slapd should do : >> - either check that it does not add an object before its parent = objects >=20 > No. This behavior is already documented in the Syncrepl specification. >=20 >> - either convert the glue object to the correct object when the real = creation is >> needed. >=20 > The slapd consumer already does this when running on a local database. = It would > require Manage privileges when running through back-ldap. Check your = back-ldap configuration. Well=E2=80=A6 I=E2=80=99v read 5 time the documentation on my setup, = never seen the manage privilege mentioned anywhere=E2=80=A6 Even in the example given for the backend configuration the acls don=E2=80= =99t mention this =C2=AB manage =C2=BB privilege : =46rom page : = https://www.openldap.org/doc/admin24/replication.html#Syncrepl # Give the replica DN unlimited read access. This ACL may need to be # merged with other ACL statements. access to * by dn.base=3D"cn=3Dreplicator,dc=3Dsuretecsystems,dc=3Dcom" = write by * break access to dn.base=3D"" by * read access to dn.base=3D"cn=3DSubschema" by * read access to dn.subtree=3D"cn=3DMonitor" by dn.exact=3D"uid=3Dadmin,dc=3Dsuretecsystems,dc=3Dcom" = write by users read by * none access to * by self write by * read Wel.. I can accept it=E2=80=99s a documentation bug=E2=80=A6but where is = the correct documentation ? f.g.

1 0

Re: (ITS#8926) glue records + syncrepl
by frederic.goudal＠bordeaux-inp.fr 12 Oct '18

12 Oct '18

> Le 11 oct. 2018 =C3=A0 18:32, Howard Chu <hyc(a)symas.com> a =C3=A9crit = : >=20 > goudal(a)bordeaux-inp.fr wrote: >> Full_Name: Fr.d.ric Goudal >>=20 >> Solution=20 >> -remove by hand the dn: uid=3Dfoo,ou=3Dbar,dc=3Dmy,dc=3Ddomain, = that remove the >> glue object >> - create by hand the ou=3Dbar,dc=3Dmy,dc=3Ddomain >>=20 >> What IMHO slapd should do : >> - either check that it does not add an object before its parent = objects >=20 > No. This behavior is already documented in the Syncrepl specification. >=20 >> - either convert the glue object to the correct object when the real = creation is >> needed. >=20 > The slapd consumer already does this when running on a local database. = It would > require Manage privileges when running through back-ldap. Check your = back-ldap configuration. Well=E2=80=A6 I=E2=80=99v read 5 time the documentation on my setup, = never seen the manage privilege mentioned anywhere=E2=80=A6 Even in the example given for the backend configuration the acls don=E2=80= =99t mention this =C2=AB manage =C2=BB privilege : =46rom page : = https://www.openldap.org/doc/admin24/replication.html#Syncrepl # Give the replica DN unlimited read access. This ACL may need to = be # merged with other ACL statements. access to * by dn.base=3D"cn=3Dreplicator,dc=3Dsuretecsystems,dc=3Dcom" = write by * break access to dn.base=3D"" by * read access to dn.base=3D"cn=3DSubschema" by * read access to dn.subtree=3D"cn=3DMonitor" by dn.exact=3D"uid=3Dadmin,dc=3Dsuretecsystems,dc=3Dcom" = write by users read by * none access to * by self write by * read Wel.. I can accept it=E2=80=99s a documentation bug=E2=80=A6but where is = the correct documentation ? f.g.

1 0

(ITS#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠openldap.org 11 Oct '18

11 Oct '18

Full_Name: Quanah Gibson-Mount Version: 2.4.46 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) While investigating a report of an issue with slapo-ppolicy in an MMR environment, I've found that ppolicy is destructive in a delta-sync replicated environment. The root cause of course is that there is no guidance on how to handle how replication works with ppolicy, a deficiency that must be addressed before any final draft is completed. Reproduction case: a) Set up a delta-sync replicated environment with slapo-ppolicy enabled and a default policy of: pwdAttribute: userPassword pwdLockout: TRUE pwdLockoutDuration: 1800 pwdMaxFailure: 100 pwdFailureCountInterval: 300 b) Bind as a user to master1 with an invalid password c) perform an ldap v3 password modify against master1 as an administrative user and reset the password for the user in step b When the second action is performed (c), all consumers will go into REFRESH mode: Oct 11 11:44:37 anvil2 slapd[5791]: syncrepl_null_callback : error code 0x10 Oct 11 11:44:37 anvil2 slapd[5791]: slap_graduate_commit_csn: removing 0x7faf10106000 20181011184437.093014Z#000000#001#000000 Oct 11 11:44:37 anvil2 slapd[5791]: syncrepl_message_to_op: rid=001 be_modify uid=user1,ou=user,dc=example,dc=com (16) Oct 11 11:44:37 anvil2 slapd[5791]: do_syncrep2: rid=001 delta-sync lost sync on (reqStart=20181011184437.000001Z,cn=accesslog), switching to REFRESH As noted in ITS#8125, going into REFRESH mode can cause data loss.

1 0

Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by quanah＠symas.com 11 Oct '18

11 Oct '18

--On Thursday, October 11, 2018 3:52 PM +0800 moyanan <nanmor(a)126.com> wrote: > I set the parameter in client: TLS_PROTOCOL_MIN 3.4, the client still > start a client hello with TLS1.2, i doubt that the parameter not work in > my configuration. > here is my ldap.conf: Hi Nancy, I would suggest reading the man page for ldap.conf(5): <http://www.openldap.org/software/man.cgi?query=ldap.conf&apropos=0&sektion=…> Some of the settings in the ldap.conf you provided do not seem valid. Again, I'd confirm what SSL library the ldapsearch you're using is linked to. (I.e., ldd /path/to/ldapsearch). I only see TLS 1.3 negotiated by default in my build setup where both slapd and the ldap* tools are linked to OpenSSL 1.1.1. Per the ldap.conf(5) man page, the TLS_PROTOCOL_MIN parameter is ignored by GnuTLS, which makes me wonder if you're using a GnuTLS linked ldapsearch binary. The ldap.conf file I'm using simply sets TLS_REQCERT never and no other options configured. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8926) glue records + syncrepl
by hyc＠symas.com 11 Oct '18

11 Oct '18

goudal(a)bordeaux-inp.fr wrote: > Full_Name: Fr.d.ric Goudal > Version: 2.4.46 > OS: ubuntu 18.14 LTS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (147.210.204.135) > > > The global setup is the following : > - 1 master ldap (2.4.40) > - 1 hidden slave on the master ldap, same suffix, ldap backend > - 1 ldap backend on a distant server (2.4.46) > > When starting synchronisation the following event are happening : > - for some reason the sync process ask for creating > dn:uid=foo,ou=bar,dc=my,dc=domaine BEFORE the creation of > dn : ou=bar,dc=my,dc=domain > > - on the backend the following entries are created in that order > - dn:ou=bar,dc=my,dc=domain with the object class glue > - dn: uid=foo,ou=bar,dc=my,dc=domain > > Than... the sync tries to create ou=bar,dc=my,dc=domain with the correct > objectClass : organizationalUnit > But, as the object exists on the backend ldap, creation fails, and > synchronization stops. > > Solution > -remove by hand the dn: uid=foo,ou=bar,dc=my,dc=domain, that remove the > glue object > - create by hand the ou=bar,dc=my,dc=domain > > What IMHO slapd should do : > - either check that it does not add an object before its parent objects No. This behavior is already documented in the Syncrepl specification. > - either convert the glue object to the correct object when the real creation is > needed. The slapd consumer already does this when running on a local database. It would require Manage privileges when running through back-ldap. Check your back-ldap configuration. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8926) glue records + syncrepl
by goudal＠bordeaux-inp.fr 11 Oct '18

11 Oct '18

Full_Name: Fr.d.ric Goudal Version: 2.4.46 OS: ubuntu 18.14 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.210.204.135) The global setup is the following : - 1 master ldap (2.4.40) - 1 hidden slave on the master ldap, same suffix, ldap backend - 1 ldap backend on a distant server (2.4.46) When starting synchronisation the following event are happening : - for some reason the sync process ask for creating dn:uid=foo,ou=bar,dc=my,dc=domaine BEFORE the creation of dn : ou=bar,dc=my,dc=domain - on the backend the following entries are created in that order - dn:ou=bar,dc=my,dc=domain with the object class glue - dn: uid=foo,ou=bar,dc=my,dc=domain Than... the sync tries to create ou=bar,dc=my,dc=domain with the correct objectClass : organizationalUnit But, as the object exists on the backend ldap, creation fails, and synchronization stops. Solution -remove by hand the dn: uid=foo,ou=bar,dc=my,dc=domain, that remove the glue object - create by hand the ou=bar,dc=my,dc=domain What IMHO slapd should do : - either check that it does not add an object before its parent objects - either convert the glue object to the correct object when the real creation is needed. f

1 0

(ITS#8925) Please remove the entry for mirror.switch.ch from the Download page
by switchmirror＠switch.ch 11 Oct '18

11 Oct '18

Full_Name: Thomas Lenggenhager Version: 2.4.9 OS: Solaris URL: Submission from: (NULL) (2001:620:0:44:12dd:b1ff:fed3:e027) I already sent twice a message to info(a)openldap.org, but no action or answer received. So I try it on this channel. Please drop the reference to SWITCH (Switzerland, mirror.switch.ch) on the Download web page: http://www.openldap.org/software/download/ Here the message I sent: ------------ The SWITCHmirror service hosted on mirror.switch.ch will be decommissioned soon. Could you please remove the entry for mirror.switch.ch from your list of mirror sites and notify us once accomplished? Thereafter, we will stop the mirroring of this package and drop it from our repository. PS: See http://mirror.switch.ch for details on the decommissioning. BTW: I noticed that the Austrian mirror on gd.tuwien.ac.at has completely disappeared, there is no DNS entry for it anymore.

1 0

Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by nanmor＠126.com 11 Oct '18

11 Oct '18

--Apple-Mail=_A57FFFE0-FA22-44A6-A24D-07E9ADC17D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Quanah, I=E2=80=99m afraid that the message will be encoded so that you can not = see, so send again.=20 After I set a parameter in server: TLSProtocolMin 3.4, restart the ldap = server, it works that the server will not negotiated with lower TLS = version. I set the parameter in client: TLS_PROTOCOL_MIN 3.4, the client still = start a client hello with TLS1.2, i doubt that the parameter not work in = my configuration. here is my ldap.conf: ssl start_tls TLS_CACERTDIR /usr/local/etc/openldap/cacerts TLS_CACERT /usr/local/etc/openldap/cacerts/cacert.pem TLS_REQCERT never TLS_PROTOCOL_MIN 3.4 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never SASL_NOCANON on BASE cn=3Dlocalhost debug 9 local4.* /var/log/ldap.log I used "openssl s_client -connect mydomain.com:636 = <http://mydomain.com:636/> -tls1_3" to connect the same server from = the same client, it will used TLS1.3 successfully. I think the openssl = for TLS1.3 works well.=20 How can I make sure our client and server link to the openssl ? And = could you please show your configuration about TLS in ldap.conf and = slap.conf to me, if you are convenient.=20 Thanks a lot. best regards=20 nancy > On Oct 9, 2018, at 9:56 PM, Quanah Gibson-Mount <quanah(a)symas.com> = wrote: >=20 > --On Tuesday, October 09, 2018 10:02 AM +0000 nanmor(a)126.com wrote: >=20 >> We can get the result, but from Wireshark result, we find that they = used >> TLS1.2 to negotiated. >=20 > I do not find this to be the case with OpenLDAP 2.4.46. >=20 >> The openSSL is support for TLS1.3,however openldap-2.4.46 is still = used >> TLS1.2 by default. Need some parameters to specify TLS1.3 in openldap >> configuration? >=20 > Nope. >=20 >> By the way, I have tested that other application can negotiated with >> TLS1.3 by default when the client and server both use openssl-1.1.1. >=20 > That is the behavior I see. >=20 > OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 for both the client and = server: >=20 > 5bbcb282 connection_read(14): checking for input on id=3D1001 > TLS trace: SSL_accept:TLSv1.3 early data > TLS trace: SSL_accept:SSLv3/TLS read finished > TLS trace: SSL_accept:SSLv3/TLS write session ticket > TLS trace: SSL_accept:SSLv3/TLS write session ticket >=20 > Perhaps the ldapsearch you picked up was not the one linked to OpenSSL = 1.1.1. >=20 > You may also want to read the slapd.conf(5) or slapd-config(5) man = pages on how to set a minimum required TLS protocol version. >=20 > Regards, > Quanah >=20 > -- >=20 > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> --Apple-Mail=_A57FFFE0-FA22-44A6-A24D-07E9ADC17D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div = style=3D"font-family: Arial; font-size: 14px;" class=3D"">Hi = Quanah,</div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D""><br class=3D""></div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">I=E2=80=99m afraid that the message will be = encoded so that you can not see, so send again. </div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D""><br = class=3D""></div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D"">After I set a parameter in server:  TLSProtocolMin 3.4, = restart the ldap server, it works that the server will not negotiated = with lower TLS version.<br class=3D""></div><div style=3D"font-family: = Arial; font-size: 14px;" class=3D"">I set the parameter in client: = TLS_PROTOCOL_MIN 3.4, the client still start a client hello with TLS1.2, = i doubt that the parameter not work in my configuration.</div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D"">here is my = ldap.conf:</div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D""><br class=3D"">ssl start_tls<br class=3D"">TLS_CACERTDIR  = /usr/local/etc/openldap/cacerts<br class=3D"">TLS_CACERT = /usr/local/etc/openldap/cacerts/cacert.pem<br class=3D"">TLS_REQCERT = never<br class=3D"">TLS_PROTOCOL_MIN 3.4<br = class=3D"">#SIZELIMIT      12<br = class=3D"">#TIMELIMIT      15<br = class=3D"">#DEREF          = never<br class=3D"">SASL_NOCANON    on<br class=3D"">BASE = cn=3Dlocalhost<br class=3D"">debug 9<br = class=3D"">local4.*         &= nbsp;  /var/log/ldap.log</div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">I used "openssl s_client -connect <a = href=3D"http://mydomain.com:636" = class=3D"">mydomain.com:636</a> -tls1_3"   to connect the same = server from the same client, it will used TLS1.3 successfully. I think = the openssl for TLS1.3 works well. <br class=3D""></div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D""><br = class=3D""></div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D"">How can I make sure our client and server link to the openssl = ?  And could you please  show your configuration about TLS in = ldap.conf and slap.conf to me, if you are convenient. <br = class=3D""></div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D""><br class=3D""></div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">Thanks a lot.</div><div style=3D"font-family:= Arial; font-size: 14px;" class=3D""><br class=3D""></div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D"">best = regards <br class=3D""></div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">nancy<br class=3D""></div><br = style=3D"font-family: Arial; font-size: 14px;" class=3D""><div = style=3D"font-family: Arial; font-size: 14px; position: relative; zoom: = 1;" class=3D""></div><div id=3D"divNeteaseMailCard" style=3D"font-family: = Arial; font-size: 14px;" class=3D""></div><div><br class=3D""><blockquote = type=3D"cite" class=3D""><div class=3D"">On Oct 9, 2018, at 9:56 PM, = Quanah Gibson-Mount <<a href=3D"mailto:quanah@symas.com" = class=3D"">quanah(a)symas.com</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">--On = Tuesday, October 09, 2018 10:02 AM +0000 <a href=3D"mailto:nanmor@126.com"= class=3D"">nanmor(a)126.com</a> wrote:<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">We can get the result, = but from Wireshark result, we find that they used<br class=3D"">TLS1.2 = to negotiated.<br class=3D""></blockquote><br class=3D"">I do not find = this to be the case with OpenLDAP 2.4.46.<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">The openSSL is support = for TLS1.3,however openldap-2.4.46 is still used<br class=3D"">TLS1.2 by = default. Need some parameters to specify TLS1.3 in openldap<br = class=3D"">configuration?<br class=3D""></blockquote><br = class=3D"">Nope.<br class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D"">By the way, I have tested that other application can = negotiated with<br class=3D"">TLS1.3 by default when the client and = server both use openssl-1.1.1.<br class=3D""></blockquote><br = class=3D"">That is the behavior I see.<br class=3D""><br = class=3D"">OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 for both the client = and server:<br class=3D""><br class=3D"">5bbcb282 connection_read(14): = checking for input on id=3D1001<br class=3D"">TLS trace: = SSL_accept:TLSv1.3 early data<br class=3D"">TLS trace: = SSL_accept:SSLv3/TLS read finished<br class=3D"">TLS trace: = SSL_accept:SSLv3/TLS write session ticket<br class=3D"">TLS trace: = SSL_accept:SSLv3/TLS write session ticket<br class=3D""><br = class=3D"">Perhaps the ldapsearch you picked up was not the one linked = to OpenSSL 1.1.1.<br class=3D""><br class=3D"">You may also want to read = the slapd.conf(5) or slapd-config(5) man pages on how to set a minimum = required TLS protocol version.<br class=3D""><br class=3D"">Regards,<br = class=3D"">Quanah<br class=3D""><br class=3D"">--<br class=3D""><br = class=3D"">Quanah Gibson-Mount<br class=3D"">Product Architect<br = class=3D"">Symas Corporation<br class=3D"">Packaged, certified, and = supported LDAP solutions powered by OpenLDAP:<br class=3D""><<a = href=3D"http://www.symas.com" class=3D"">http://www.symas.com</a>><br = class=3D""></div></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_A57FFFE0-FA22-44A6-A24D-07E9ADC17D6A--

1 0

Re:Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by nanmor＠126.com 10 Oct '18

10 Oct '18

------=_Part_53823_903760140.1539140876552 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGkgUXVhbmFoLAoKCkFmdGVyIEkgc2V0IGEgcGFyYW1ldGVyIGluIHNlcnZlcjogIFRMU1Byb3Rv Y29sTWluIDMuNCwgcmVzdGFydCB0aGUgbGRhcCBzZXJ2ZXIsIGl0IHdvcmtzIHRoYXQgdGhlIHNl cnZlciB3aWxsIG5vdCBuZWdvdGlhdGVkIHdpdGggbG93ZXIgVExTIHZlcnNpb24uCgpJIHNldCB0 aGUgcGFyYW1ldGVyIGluIGNsaWVudDogVExTX1BST1RPQ09MX01JTiAzLjQsIHRoZSBjbGllbnQg c3RpbGwgc3RhcnQgYSBjbGllbnQgaGVsbG8gd2l0aCBUTFMxLjIsIGkgZG91YnQgdGhhdCB0aGUg cGFyYW1ldGVyIG5vdCB3b3JrIGluIG15IGNvbmZpZ3VyYXRpb24uCmhlcmUgaXMgbXkgbGRhcC5j b25mOgoKc3NsIHN0YXJ0X3RscwpUTFNfQ0FDRVJURElSICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRh cC9jYWNlcnRzClRMU19DQUNFUlQgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2FjZXJ0cy9jYWNl cnQucGVtClRMU19SRVFDRVJUIG5ldmVyClRMU19QUk9UT0NPTF9NSU4gMy40CiNTSVpFTElNSVQg ICAgICAxMgojVElNRUxJTUlUICAgICAgMTUKI0RFUkVGICAgICAgICAgIG5ldmVyClNBU0xfTk9D QU5PTiAgICBvbgpCQVNFIGNuPWxvY2FsaG9zdApkZWJ1ZyA5CmxvY2FsNC4qICAgICAgICAgICAg L3Zhci9sb2cvbGRhcC5sb2cKSSB1c2VkICJvcGVuc3NsIHNfY2xpZW50IC1jb25uZWN0IG15ZG9t YWluLmNvbTo2MzYgLXRsczFfMyIgICB0byBjb25uZWN0IHRoZSBzYW1lIHNlcnZlciBmcm9tIHRo ZSBzYW1lIGNsaWVudCwgaXQgd2lsbCB1c2VkIFRMUzEuMyBzdWNjZXNzZnVsbHkuIEkgdGhpbmsg dGhlIG9wZW5zc2wgZm9yIFRMUzEuMyB3b3JrcyB3ZWxsLgoKCgpIb3cgY2FuIEkgbWFrZSBzdXJl IG91ciBjbGllbnQgYW5kIHNlcnZlciBsaW5rIHRvIHRoZSBvcGVuc3NsID8gIEFuZCBjb3VsZCB5 b3UgcGxlYXNlICBzaG93IHlvdXIgY29uZmlndXJhdGlvbiBhYm91dCBUTFMgaW4gbGRhcC5jb25m IGFuZCBzbGFwLmNvbmYgdG8gbWUsIGlmIHlvdSBhcmUgY29udmVuaWVudC4KCgoKVGhhbmtzIGEg bG90LgoKCmJlc3QgcmVnYXJkcwoKbmFuY3kKCgoKCkF0IDIwMTgtMTAtMDkgMjE6NTY6MjMsICJR dWFuYWggR2lic29uLU1vdW50IiA8cXVhbmFoQHN5bWFzLmNvbT4gd3JvdGU6Cj4tLU9uIFR1ZXNk YXksIE9jdG9iZXIgMDksIDIwMTggMTA6MDIgQU0gKzAwMDAgbmFubW9yQDEyNi5jb20gd3JvdGU6 Cj4KPj4gV2UgY2FuIGdldCB0aGUgcmVzdWx0LCBidXQgZnJvbSBXaXJlc2hhcmsgcmVzdWx0LCB3 ZSBmaW5kIHRoYXQgdGhleSB1c2VkCj4+IFRMUzEuMiB0byBuZWdvdGlhdGVkLgo+Cj5JIGRvIG5v dCBmaW5kIHRoaXMgdG8gYmUgdGhlIGNhc2Ugd2l0aCBPcGVuTERBUCAyLjQuNDYuCj4KPj4gVGhl IG9wZW5TU0wgaXMgc3VwcG9ydCBmb3IgVExTMS4zLGhvd2V2ZXIgb3BlbmxkYXAtMi40LjQ2IGlz IHN0aWxsIHVzZWQKPj4gVExTMS4yIGJ5IGRlZmF1bHQuIE5lZWQgc29tZSBwYXJhbWV0ZXJzIHRv IHNwZWNpZnkgVExTMS4zIGluIG9wZW5sZGFwCj4+IGNvbmZpZ3VyYXRpb24/Cj4KPk5vcGUuCj4K Pj4gQnkgdGhlIHdheSwgSSBoYXZlIHRlc3RlZCB0aGF0IG90aGVyIGFwcGxpY2F0aW9uIGNhbiBu ZWdvdGlhdGVkIHdpdGgKPj4gVExTMS4zIGJ5IGRlZmF1bHQgd2hlbiB0aGUgY2xpZW50IGFuZCBz ZXJ2ZXIgYm90aCB1c2Ugb3BlbnNzbC0xLjEuMS4KPgo+VGhhdCBpcyB0aGUgYmVoYXZpb3IgSSBz ZWUuCj4KPk9wZW5MREFQIDIuNC40NiBsaW5rZWQgdG8gT3BlblNTTCAxLjEuMSBmb3IgYm90aCB0 aGUgY2xpZW50IGFuZCBzZXJ2ZXI6Cj4KPjViYmNiMjgyIGNvbm5lY3Rpb25fcmVhZCgxNCk6IGNo ZWNraW5nIGZvciBpbnB1dCBvbiBpZD0xMDAxCj5UTFMgdHJhY2U6IFNTTF9hY2NlcHQ6VExTdjEu MyBlYXJseSBkYXRhCj5UTFMgdHJhY2U6IFNTTF9hY2NlcHQ6U1NMdjMvVExTIHJlYWQgZmluaXNo ZWQKPlRMUyB0cmFjZTogU1NMX2FjY2VwdDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQK PlRMUyB0cmFjZTogU1NMX2FjY2VwdDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQKPgo+ UGVyaGFwcyB0aGUgbGRhcHNlYXJjaCB5b3UgcGlja2VkIHVwIHdhcyBub3QgdGhlIG9uZSBsaW5r ZWQgdG8gT3BlblNTTCAKPjEuMS4xLgo+Cj5Zb3UgbWF5IGFsc28gd2FudCB0byByZWFkIHRoZSBz bGFwZC5jb25mKDUpIG9yIHNsYXBkLWNvbmZpZyg1KSBtYW4gcGFnZXMgb24gCj5ob3cgdG8gc2V0 IGEgbWluaW11bSByZXF1aXJlZCBUTFMgcHJvdG9jb2wgdmVyc2lvbi4KPgo+UmVnYXJkcywKPlF1 YW5haAo+Cj4tLQo+Cj5RdWFuYWggR2lic29uLU1vdW50Cj5Qcm9kdWN0IEFyY2hpdGVjdAo+U3lt YXMgQ29ycG9yYXRpb24KPlBhY2thZ2VkLCBjZXJ0aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBz b2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoKPjxodHRwOi8vd3d3LnN5bWFzLmNvbT4K ------=_Part_53823_903760140.1539140876552 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+SGkgUXVhbmFoLDwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+QWZ0ZXIgSSBzZXQgYSBwYXJhbWV0ZXIgaW4gc2VydmVyOiZuYnNwOyBUTFNQcm90b2NvbE1p biAzLjQsIHJlc3RhcnQgdGhlIGxkYXAgc2VydmVyLCBpdCB3b3JrcyB0aGF0IHRoZSBzZXJ2ZXIg d2lsbCBub3QgbmVnb3RpYXRlZCB3aXRoIGxvd2VyIFRMUyB2ZXJzaW9uLjxicj48L2Rpdj48ZGl2 Pkkgc2V0IHRoZSBwYXJhbWV0ZXIgaW4gY2xpZW50OiBUTFNfUFJPVE9DT0xfTUlOIDMuNCwgdGhl IGNsaWVudCBzdGlsbCBzdGFydCBhIGNsaWVudCBoZWxsbyB3aXRoIFRMUzEuMiwgaSBkb3VidCB0 aGF0IHRoZSBwYXJhbWV0ZXIgbm90IHdvcmsgaW4gbXkgY29uZmlndXJhdGlvbi48L2Rpdj48ZGl2 PmhlcmUgaXMgbXkgbGRhcC5jb25mOjwvZGl2PjxkaXY+PGJyPnNzbCBzdGFydF90bHM8YnI+VExT X0NBQ0VSVERJUiZuYnNwOyAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9jYWNlcnRzPGJyPlRMU19D QUNFUlQgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2FjZXJ0cy9jYWNlcnQucGVtPGJyPlRMU19S RVFDRVJUIG5ldmVyPGJyPlRMU19QUk9UT0NPTF9NSU4gMy40PGJyPiNTSVpFTElNSVQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTI8YnI+I1RJTUVMSU1JVCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAxNTxicj4jREVSRUYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV2ZXI8YnI+U0FTTF9OT0NBTk9OJm5ic3A7Jm5ic3A7 Jm5ic3A7IG9uPGJyPkJBU0UgY249bG9jYWxob3N0PGJyPmRlYnVnIDk8YnI+bG9jYWw0LiombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgL3Zhci9sb2cvbGRhcC5sb2c8L2Rpdj48ZGl2PkkgdXNlZCAib3BlbnNzbCBzX2NsaWVu dCAtY29ubmVjdCBteWRvbWFpbi5jb206NjM2IC10bHMxXzMiICZuYnNwOyB0byBjb25uZWN0IHRo ZSBzYW1lIHNlcnZlciBmcm9tIHRoZSBzYW1lIGNsaWVudCwgaXQgd2lsbCB1c2VkIFRMUzEuMyBz dWNjZXNzZnVsbHkuIEkgdGhpbmsgdGhlIG9wZW5zc2wgZm9yIFRMUzEuMyB3b3JrcyB3ZWxsLiA8 YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ib3cgY2FuIEkgbWFrZSBzdXJlIG91ciBjbGll bnQgYW5kIHNlcnZlciBsaW5rIHRvIHRoZSBvcGVuc3NsID8mbmJzcDsgQW5kIGNvdWxkIHlvdSBw bGVhc2UmbmJzcDsgc2hvdyB5b3VyIGNvbmZpZ3VyYXRpb24gYWJvdXQgVExTIGluIGxkYXAuY29u ZiBhbmQgc2xhcC5jb25mIHRvIG1lLCBpZiB5b3UgYXJlIGNvbnZlbmllbnQuIDxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyBhIGxvdC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PmJlc3QgcmVnYXJkcyA8YnI+PC9kaXY+PGRpdj5uYW5jeTxicj48L2Rpdj48YnI+PGRpdiBzdHls ZT0icG9zaXRpb246cmVsYXRpdmU7em9vbToxIj48L2Rpdj48ZGl2IGlkPSJkaXZOZXRlYXNlTWFp bENhcmQiPjwvZGl2PjxwcmU+PGJyPkF0IDIwMTgtMTAtMDkgMjE6NTY6MjMsICJRdWFuYWggR2li c29uLU1vdW50IiAmbHQ7cXVhbmFoQHN5bWFzLmNvbSZndDsgd3JvdGU6CiZndDstLU9uIFR1ZXNk YXksIE9jdG9iZXIgMDksIDIwMTggMTA6MDIgQU0gKzAwMDAgbmFubW9yQDEyNi5jb20gd3JvdGU6 CiZndDsKJmd0OyZndDsgV2UgY2FuIGdldCB0aGUgcmVzdWx0LCBidXQgZnJvbSBXaXJlc2hhcmsg cmVzdWx0LCB3ZSBmaW5kIHRoYXQgdGhleSB1c2VkCiZndDsmZ3Q7IFRMUzEuMiB0byBuZWdvdGlh dGVkLgomZ3Q7CiZndDtJIGRvIG5vdCBmaW5kIHRoaXMgdG8gYmUgdGhlIGNhc2Ugd2l0aCBPcGVu TERBUCAyLjQuNDYuCiZndDsKJmd0OyZndDsgVGhlIG9wZW5TU0wgaXMgc3VwcG9ydCBmb3IgVExT MS4zLGhvd2V2ZXIgb3BlbmxkYXAtMi40LjQ2IGlzIHN0aWxsIHVzZWQKJmd0OyZndDsgVExTMS4y IGJ5IGRlZmF1bHQuIE5lZWQgc29tZSBwYXJhbWV0ZXJzIHRvIHNwZWNpZnkgVExTMS4zIGluIG9w ZW5sZGFwCiZndDsmZ3Q7IGNvbmZpZ3VyYXRpb24/CiZndDsKJmd0O05vcGUuCiZndDsKJmd0OyZn dDsgQnkgdGhlIHdheSwgSSBoYXZlIHRlc3RlZCB0aGF0IG90aGVyIGFwcGxpY2F0aW9uIGNhbiBu ZWdvdGlhdGVkIHdpdGgKJmd0OyZndDsgVExTMS4zIGJ5IGRlZmF1bHQgd2hlbiB0aGUgY2xpZW50 IGFuZCBzZXJ2ZXIgYm90aCB1c2Ugb3BlbnNzbC0xLjEuMS4KJmd0OwomZ3Q7VGhhdCBpcyB0aGUg YmVoYXZpb3IgSSBzZWUuCiZndDsKJmd0O09wZW5MREFQIDIuNC40NiBsaW5rZWQgdG8gT3BlblNT TCAxLjEuMSBmb3IgYm90aCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXI6CiZndDsKJmd0OzViYmNiMjgy IGNvbm5lY3Rpb25fcmVhZCgxNCk6IGNoZWNraW5nIGZvciBpbnB1dCBvbiBpZD0xMDAxCiZndDtU TFMgdHJhY2U6IFNTTF9hY2NlcHQ6VExTdjEuMyBlYXJseSBkYXRhCiZndDtUTFMgdHJhY2U6IFNT TF9hY2NlcHQ6U1NMdjMvVExTIHJlYWQgZmluaXNoZWQKJmd0O1RMUyB0cmFjZTogU1NMX2FjY2Vw dDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQKJmd0O1RMUyB0cmFjZTogU1NMX2FjY2Vw dDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQKJmd0OwomZ3Q7UGVyaGFwcyB0aGUgbGRh cHNlYXJjaCB5b3UgcGlja2VkIHVwIHdhcyBub3QgdGhlIG9uZSBsaW5rZWQgdG8gT3BlblNTTCAK Jmd0OzEuMS4xLgomZ3Q7CiZndDtZb3UgbWF5IGFsc28gd2FudCB0byByZWFkIHRoZSBzbGFwZC5j b25mKDUpIG9yIHNsYXBkLWNvbmZpZyg1KSBtYW4gcGFnZXMgb24gCiZndDtob3cgdG8gc2V0IGEg bWluaW11bSByZXF1aXJlZCBUTFMgcHJvdG9jb2wgdmVyc2lvbi4KJmd0OwomZ3Q7UmVnYXJkcywK Jmd0O1F1YW5haAomZ3Q7CiZndDstLQomZ3Q7CiZndDtRdWFuYWggR2lic29uLU1vdW50CiZndDtQ cm9kdWN0IEFyY2hpdGVjdAomZ3Q7U3ltYXMgQ29ycG9yYXRpb24KJmd0O1BhY2thZ2VkLCBjZXJ0 aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoK Jmd0OyZsdDtodHRwOi8vd3d3LnN5bWFzLmNvbSZndDsKPC9wcmU+PC9kaXY+PGJyPjxicj48c3Bh biB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHA+Jm5ic3A7PC9wPjwvc3Bhbj4= ------=_Part_53823_903760140.1539140876552--

1 0

Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by quanah＠symas.com 09 Oct '18

09 Oct '18

--On Tuesday, October 09, 2018 10:02 AM +0000 nanmor(a)126.com wrote: > We can get the result, but from Wireshark result, we find that they used > TLS1.2 to negotiated. I do not find this to be the case with OpenLDAP 2.4.46. > The openSSL is support for TLS1.3,however openldap-2.4.46 is still used > TLS1.2 by default. Need some parameters to specify TLS1.3 in openldap > configuration? Nope. > By the way, I have tested that other application can negotiated with > TLS1.3 by default when the client and server both use openssl-1.1.1. That is the behavior I see. OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 for both the client and server: 5bbcb282 connection_read(14): checking for input on id=1001 TLS trace: SSL_accept:TLSv1.3 early data TLS trace: SSL_accept:SSLv3/TLS read finished TLS trace: SSL_accept:SSLv3/TLS write session ticket TLS trace: SSL_accept:SSLv3/TLS write session ticket Perhaps the ldapsearch you picked up was not the one linked to OpenSSL 1.1.1. You may also want to read the slapd.conf(5) or slapd-config(5) man pages on how to set a minimum required TLS protocol version. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by nanmor＠126.com 09 Oct '18

09 Oct '18

Full_Name: Nancy Mo Version: openldap-clients-2.4.46 OS: Redhat 7, ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.38.0.87) openldap Client: Ubuntu 16.04.4 LTS/ openldap 2.4.46/ openssl-1.1.1 openldap Server: redhat 7, Linux 3.10.0-327.13.1.el7.x86_64 #1 SMP Mon Feb 29 13:22:02 EST 2016 x86_64 x86_64 x86_64 GNU/Linux openldap2.4.46/ openssl-1.1.1 In Client, configure ldap.conf: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com URI ldap://mydomain.com:389 ldaps://mydomain.com:636 ssl start_tls TLS_CACERTDIR /usr/local/etc/openldap/cacerts TLS_CACERT /usr/local/etc/openldap/cacerts/cacert.pem TLS_REQCERT never #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never SASL_NOCANON on BASE cn=localhost debug 9 local4.* /var/log/ldap.log In server: configure the slapd.conf (some important configuration) database mdb maxsize 1073741824 suffix "dc=mydomain,dc=com" rootdn "cn=Manager,dc=mydomain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}srNLpYqpwEpRTw94IV79Myw5YO6rn0Ym # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/openldap.2.4.46/var/openldap-data TLSCACertificateFile /usr/local/openldap.2.4.46/etc/openldap/cacerts/cacert.pem TLSCertificateFile /usr/local/openldap.2.4.46/etc/openldap/ldap.crt TLSCertificateKeyFile /usr/local/openldap.2.4.46/etc/openldap/ldap.key >From client connect to server: ldapsearch -x -H ldaps://mydomain.com:636 -D cn=Manager,dc=mydomain,dc=com -w passw0rd -b "" -s base objectclass=* We can get the result, but from Wireshark result, we find that they used TLS1.2 to negotiated. The openSSL is support for TLS1.3,however openldap-2.4.46 is still used TLS1.2 by default. Need some parameters to specify TLS1.3 in openldap configuration? By the way, I have tested that other application can negotiated with TLS1.3 by default when the client and server both use openssl-1.1.1. Thanks a lot. Best regards, nancy Mo

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by ryan＠nardis.ca 05 Oct '18

05 Oct '18

On Tue, Sep 18, 2018 at 10:55:50PM -0700, Ryan Tandy wrote: >There is some EAGAIN handling conditional on LDAP_USE_NON_BLOCKING_TLS >which itself is behind LDAP_DEVEL. However this code is meant for >non-blocking sockets, and in my case it ends up stuck in poll() >waiting for a notification that never arrives. This turned out to be because the fd and timeout fields are only initialized when timeout is configured and the non-blocking behaviour was triggered because of it. Otherwise the code simply doesn't anticipate EAGAIN could be returned and the behaviour is more or less undefined; it ends up calling poll() with fd = -1 and a garbage timeout. >It's possible that what I actually want here is a (ret > 0) case in >ldap_int_tls_start for when LDAP_USE_NON_BLOCKING_TLS is absent and >ldap_int_tls_connect returns 1. (I'd also need to adapt the >non-blocking path to be able to handle a blocking socket as well.) More precisely, what I actually want is a (ret > 0) case that is used unless both USE_NON_BLOCKING_TLS is true and a timeout is configured. If we added to ber_sockbuf_ctrl() the ability to query whether the socket is non-blocking, for GnuTLS at least we could bypass poll() and go straight back into ldap_int_tls_connect(). However I don't see a lot of benefit to this as long as calling poll() on a blocking socket has no downside.

1 0

(ITS#8923) compare op with dynlist returns wrong code when requested DN is in scope but doesn't exist
by quanah＠openldap.org 03 Oct '18

03 Oct '18

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) In a situation where a dynamic group has been created and a compare operation is run with a DN that doesn't exist but is within the scope of the dynamic group URI, the ldapcompare operation will incorrectly return an error 80 instead of error 5 (compare FALSE). For example, if I have: dn: cn=planning,ou=Groups,dc=example,dc=com objectClass: groupOfURLs cn: planning memberURL: ldap:///ou=planning,dc=example,dc=com??sub?(objectClass=inetorgpers on) and I do an ldapcompare with: ldapcompare -x -H ldap://anvil2.rb.symas.net -D dc=example,dc=com -w secret cn=planning,ou=Groups,dc=example,dc=com "member:cn=Ramakant Wolow,ou=Planning,dc=example,dc=com" (i.e., this entry doesn't exist in the DB), I get: Compare Result: Other (e.g., implementation specific) error (80) UNDEFINED This appears to be due to the fact that in this scenario, slapd attempts to find the DN in the underlying DB and it doesn't exist, so an err=32 is returned back. This is incorrectly interpreted as an unknown error, thus the err=80 result. Instead it should be treated as "not a member of the group".

1 0

Re: (ITS#8922) tls_o bug with OpenSSL 1.1.1
by norm.green＠gemtalksystems.com 01 Oct '18

01 Oct '18

Thank you Michael, you are correct. Somehow I missed the 2.4.46 release. This issue may be closed. Norm Green On 10/1/2018 2:38 AM, Michael Ströder wrote: > On 10/1/18 6:18 AM, norm.green(a)gemtalksystems.com wrote: >> Full_Name: Norman Green >> Version: 2.4.45 >> >> Unfortunately the layout of the BIO_METHOD struct changed in OpenSSL >> 1.1.1 and the static initialization is now incorrect: > CHANGES of release 2.4.46 contains this: > > -------------------------- snip -------------------------- > OpenLDAP 2.4.46 Release (2018/03/22) > [..] > Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791) > -------------------------- snip -------------------------- > > So your report might be a duplicate of this: > > https://www.openldap.org/its/index.cgi?findid=8791 > > Ciao, Michael.

1 0

Re: (ITS#8922) tls_o bug with OpenSSL 1.1.1
by michael＠stroeder.com 01 Oct '18

01 Oct '18

On 10/1/18 6:18 AM, norm.green(a)gemtalksystems.com wrote: > Full_Name: Norman Green > Version: 2.4.45 > > Unfortunately the layout of the BIO_METHOD struct changed in OpenSSL > 1.1.1 and the static initialization is now incorrect: CHANGES of release 2.4.46 contains this: -------------------------- snip -------------------------- OpenLDAP 2.4.46 Release (2018/03/22) [..] Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791) -------------------------- snip -------------------------- So your report might be a duplicate of this: https://www.openldap.org/its/index.cgi?findid=8791 Ciao, Michael.

1 0

(ITS#8922) tls_o bug with OpenSSL 1.1.1
by norm.green＠gemtalksystems.com 01 Oct '18

01 Oct '18

Full_Name: Norman Green Version: 2.4.45 OS: AIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.53.145.234) in tls_o.c, the function tlso_sb_setup has this code on line 833: bio = BIO_new( &tlso_bio_method ); which uses a statically allocated BIO_METHOD. Unfortunately the layout of the BIO_METHOD struct changed in OpenSSL 1.1.1 and the static initialization is now incorrect: static BIO_METHOD tlso_bio_method = { ( 100 | 0x400 ), /* it's a source/sink BIO */ "sockbuf glue", tlso_bio_write, tlso_bio_read, tlso_bio_puts, tlso_bio_gets, tlso_bio_ctrl, tlso_bio_create, tlso_bio_destroy }; In 1.1.1, this (internal) SSL struct looks like this: struct bio_method_st { int type; char *name; int (*bwrite) (BIO *, const char *, size_t, size_t *); int (*bwrite_old) (BIO *, const char *, int); int (*bread) (BIO *, char *, size_t, size_t *); int (*bread_old) (BIO *, char *, int); int (*bputs) (BIO *, const char *); int (*bgets) (BIO *, char *, int); long (*ctrl) (BIO *, int, long, void *); int (*create) (BIO *); int (*destroy) (BIO *); long (*callback_ctrl) (BIO *, int, BIO_info_cb *); };

1 0

Re: (ITS#8918) sasl.c:326: possible bad assignment ?
by quanah＠symas.com 26 Sep '18

26 Sep '18

--On Saturday, September 22, 2018 11:11 AM +0000 dcb314(a)hotmail.com wrote: > Full_Name: David Binderman > Version: 2.4.46 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.65.83.114) Thanks for the report, this has been fixed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8921) Content Sync Refresh Required when provider accesslog is empty
by au＠hcsd.de 26 Sep '18

26 Sep '18

Full_Name: Stephan Austerm.hle Version: 2.4.46 OS: Linux (Debian unstable) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.20.232.53) Consumer slapd emits endless 5babd9c4 do_syncrep2: rid=001 (4096) Content Sync Refresh Required messages when the provider has an empty accesslog (because it was freshly setup and nothing has been added/updated since then). This issue was mentioned back in 2013 (see http://www.openldap.org/lists/openldap-technical/201301/msg00229.html) already but it looks like it was not reported. The provider likewise logs 5babd9cf conn=1000 op=60677 SRCH base="dc=company,dc=com" scope=2 deref=0 filter="(objectClass=*)" 5babd9cf conn=1000 op=60677 SRCH attr=* + 5babd9cf conn=1000 op=60677 SEARCH RESULT tag=101 err=0 nentries=0 text= for every attempt from the consumer to lookup records in the accesslog.

1 0

Re:Re: (ITS#8920) OpenLDAP
by nanmor＠126.com 26 Sep '18

26 Sep '18

------=_Part_106754_1961220656.1537947199160 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGkgUXVhbmFoo6wKVGhhbmtzIGEgbG90IGZvciB5b3VyIGhlbHAuIEkgd2lsbCB1cGdyYWRlIG15 IG9wZW5sZGFwIHRvIDIuNC40NiB2ZXJzaW9uIHRoZW4gaGF2ZSBhIHRyeS4gdGhhbmtzIGFnYWlu LgoKCmJlc3QgcmVnYXJkcywKbmFuY3kKCgoKCgpBdCAyMDE4LTA5LTI1IDA4OjU5OjIxLCAiUXVh bmFoIEdpYnNvbi1Nb3VudCIgPHF1YW5haEBzeW1hcy5jb20+IHdyb3RlOj4tLU9uIFR1ZXNkYXks IFNlcHRlbWJlciAyNSwgMjAxOCAxOjQ2IEFNICswMDAwIG5hbm1vckAxMjYuY29tIHdyb3RlOgo+ Cj4+IEZ1bGxfTmFtZTogTmFuY3kgTW8KPj4gVmVyc2lvbjogb3BlbmxkYXAtY2xpZW50cy0yLjQu NDQtMTUuZWw3XzUueDg2XzY0Cj4+IE9TOiBSZWRoYXQgNwo+PiBVUkw6IGZ0cDovL2Z0cC5vcGVu bGRhcC5vcmcvaW5jb21pbmcvCj4+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICgxMDYuMzguMC44 NykKPgo+SGVsbG8sCj4KPlRoZSBJVFMgc3lzdGVtIGlzIGZvciBidWcgcmVwb3J0cyBvbmx5LiAg UGxlYXNlIGRpcmVjdCB1c2FnZSBxdWVzdGlvbnMgdG8gCj50aGUgb3BlbmxkYXAtdGVjaG5pY2Fs IGxpc3QuICBJIHdpbGwgbm90ZSB0aGF0IEkndmUgdGVzdGVkIE9wZW5MREFQIDIuNC40NiAKPndp dGggYm90aCBzdGFydFRMUyBhbmQgTERBUFMgdXNpbmcgVExTIDEuMyB3aGVuIGNvbXBpbGVkIG9u IGJvdGggdGhlIHNlcnZlciAKPmFuZCBjbGllbnQgc2lkZSB3aXRoIE9wZW5TU0wgMS4xLjEgYW5k IGl0IHdvcmtlZCBjb3JyZWN0bHkuICBZb3Ugd2lsbCBuZWVkIAo+dG8gcHJvdmlkZSBzaWduaWZp Y2FudGx5IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgeW91ciBjb25maWd1cmF0aW9uL3NldHVwIAo+ d2hlbiBjb250YWN0aW5nIHRoZSBvcGVubGRhcC10ZWNobmljYWwgbGlzdCBmb3IgYW55IGZ1cnRo ZXIgYXNzaXN0YW5jZS4KPgo+SSB3b3VsZCBhbHNvIG5vdGUgdGhhdCBvZmZpY2lhbCBzdXBwb3J0 IGZvciBPcGVuU1NMIDEuMS4wIGFuZCBsYXRlciB3YXMgbm90IAo+YWRkZWQgdW50aWwgdGhlIE9w ZW5MREFQIDIuNC40NSByZWxlYXNlLCB3aXRoIGZ1cnRoZXIgZml4ZXMgaW4gdGhlIE9wZW5MREFQ IAo+Mi40LjQ2IHJlbGVhc2UuICBUaHVzIEkgd291bGQgYWR2aXNlIGEgZmlyc3Qgc3RlcCBvZiB1 cGdyYWRpbmcgdG8gT3BlbkxEQVAgCj4yLjQuNDYuCj4KPldhcm0gcmVnYXJkcywKPlF1YW5haAo+ Cj4KPi0tCj4KPlF1YW5haCBHaWJzb24tTW91bnQKPlByb2R1Y3QgQXJjaGl0ZWN0Cj5TeW1hcyBD b3Jwb3JhdGlvbgo+UGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0 aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQOgo+PGh0dHA6Ly93d3cuc3ltYXMuY29tPgo= ------=_Part_106754_1961220656.1537947199160 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+SGkgUXVhbmFoo6w8L2Rpdj48ZGl2PlRoYW5rcyBhIGxv dCBmb3IgeW91ciBoZWxwLiBJIHdpbGwgdXBncmFkZSBteSBvcGVubGRhcCB0byAyLjQuNDYgdmVy c2lvbiB0aGVuIGhhdmUgYSB0cnkuIHRoYW5rcyBhZ2Fpbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PmJlc3QgcmVnYXJkcyw8L2Rpdj48ZGl2Pm5hbmN5PGJyPjwvZGl2Pjxicj48YnI+PGJyPjxk aXYgc3R5bGU9InBvc2l0aW9uOnJlbGF0aXZlO3pvb206MSI+PC9kaXY+PGRpdiBpZD0iZGl2TmV0 ZWFzZU1haWxDYXJkIj48L2Rpdj5BdCAyMDE4LTA5LTI1IDA4OjU5OjIxLCAiUXVhbmFoIEdpYnNv bi1Nb3VudCIgJmx0O3F1YW5haEBzeW1hcy5jb20mZ3Q7IHdyb3RlOiZndDstLU9uIFR1ZXNkYXks IFNlcHRlbWJlciAyNSwgMjAxOCAxOjQ2IEFNICswMDAwIG5hbm1vckAxMjYuY29tIHdyb3RlOgo8 cHJlPiZndDsKJmd0OyZndDsgRnVsbF9OYW1lOiBOYW5jeSBNbwomZ3Q7Jmd0OyBWZXJzaW9uOiBv cGVubGRhcC1jbGllbnRzLTIuNC40NC0xNS5lbDdfNS54ODZfNjQKJmd0OyZndDsgT1M6IFJlZGhh dCA3CiZndDsmZ3Q7IFVSTDogZnRwOi8vZnRwLm9wZW5sZGFwLm9yZy9pbmNvbWluZy8KJmd0OyZn dDsgU3VibWlzc2lvbiBmcm9tOiAoTlVMTCkgKDEwNi4zOC4wLjg3KQomZ3Q7CiZndDtIZWxsbywK Jmd0OwomZ3Q7VGhlIElUUyBzeXN0ZW0gaXMgZm9yIGJ1ZyByZXBvcnRzIG9ubHkuICBQbGVhc2Ug ZGlyZWN0IHVzYWdlIHF1ZXN0aW9ucyB0byAKJmd0O3RoZSBvcGVubGRhcC10ZWNobmljYWwgbGlz dC4gIEkgd2lsbCBub3RlIHRoYXQgSSd2ZSB0ZXN0ZWQgT3BlbkxEQVAgMi40LjQ2IAomZ3Q7d2l0 aCBib3RoIHN0YXJ0VExTIGFuZCBMREFQUyB1c2luZyBUTFMgMS4zIHdoZW4gY29tcGlsZWQgb24g Ym90aCB0aGUgc2VydmVyIAomZ3Q7YW5kIGNsaWVudCBzaWRlIHdpdGggT3BlblNTTCAxLjEuMSBh bmQgaXQgd29ya2VkIGNvcnJlY3RseS4gIFlvdSB3aWxsIG5lZWQgCiZndDt0byBwcm92aWRlIHNp Z25pZmljYW50bHkgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB5b3VyIGNvbmZpZ3VyYXRpb24vc2V0 dXAgCiZndDt3aGVuIGNvbnRhY3RpbmcgdGhlIG9wZW5sZGFwLXRlY2huaWNhbCBsaXN0IGZvciBh bnkgZnVydGhlciBhc3Npc3RhbmNlLgomZ3Q7CiZndDtJIHdvdWxkIGFsc28gbm90ZSB0aGF0IG9m ZmljaWFsIHN1cHBvcnQgZm9yIE9wZW5TU0wgMS4xLjAgYW5kIGxhdGVyIHdhcyBub3QgCiZndDth ZGRlZCB1bnRpbCB0aGUgT3BlbkxEQVAgMi40LjQ1IHJlbGVhc2UsIHdpdGggZnVydGhlciBmaXhl cyBpbiB0aGUgT3BlbkxEQVAgCiZndDsyLjQuNDYgcmVsZWFzZS4gIFRodXMgSSB3b3VsZCBhZHZp c2UgYSBmaXJzdCBzdGVwIG9mIHVwZ3JhZGluZyB0byBPcGVuTERBUCAKJmd0OzIuNC40Ni4KJmd0 OwomZ3Q7V2FybSByZWdhcmRzLAomZ3Q7UXVhbmFoCiZndDsKJmd0OwomZ3Q7LS0KJmd0OwomZ3Q7 UXVhbmFoIEdpYnNvbi1Nb3VudAomZ3Q7UHJvZHVjdCBBcmNoaXRlY3QKJmd0O1N5bWFzIENvcnBv cmF0aW9uCiZndDtQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExEQVAgc29sdXRp b25zIHBvd2VyZWQgYnkgT3BlbkxEQVA6CiZndDsmbHQ7aHR0cDovL3d3dy5zeW1hcy5jb20mZ3Q7 CjwvcHJlPjwvZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxwPiZuYnNw OzwvcD48L3NwYW4+ ------=_Part_106754_1961220656.1537947199160--

1 0

Re: (ITS#8920) OpenLDAP
by quanah＠symas.com 25 Sep '18

25 Sep '18

--On Tuesday, September 25, 2018 2:06 AM +0000 hyc(a)symas.com wrote: >> Why the openldap client can not use TLS1.3? > > RedHat builds their OpenLDAP packages with MozillaNSS, not OpenSSL. Incorrect. Their latest builds for RHEL7 use OpenSSL. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8920) OpenLDAP
by hyc＠symas.com 25 Sep '18

25 Sep '18

nanmor(a)126.com wrote: > Full_Name: Nancy Mo > Version: openldap-clients-2.4.44-15.el7_5.x86_64 > OS: Redhat 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (106.38.0.87) > > > Hi team, > > Linux server is redhat7, and installed Openssl-1.1.1 which is support for > TLS1.3。 > I tried to connect a LDAP server which is used TLS1.3, the openldap client > connection failed, if the server setting change to TLS 1.2, it can connected > successfully。 > By the way, use the openssl s_client -connect HOSTNAME.com:636, it will use TLS > 1.3, and connect successfully. > In the ldap.conf, I have set two parameters： > > TLS_CACERTDIR /etc/openldap/certs > TLS_REQCERT never > > Why the openldap client can not use TLS1.3? RedHat builds their OpenLDAP packages with MozillaNSS, not OpenSSL. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8920) OpenLDAP
by quanah＠symas.com 25 Sep '18

25 Sep '18

--On Tuesday, September 25, 2018 1:46 AM +0000 nanmor(a)126.com wrote: > Full_Name: Nancy Mo > Version: openldap-clients-2.4.44-15.el7_5.x86_64 > OS: Redhat 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (106.38.0.87) Hello, The ITS system is for bug reports only. Please direct usage questions to the openldap-technical list. I will note that I've tested OpenLDAP 2.4.46 with both startTLS and LDAPS using TLS 1.3 when compiled on both the server and client side with OpenSSL 1.1.1 and it worked correctly. You will need to provide significantly more information about your configuration/setup when contacting the openldap-technical list for any further assistance. I would also note that official support for OpenSSL 1.1.0 and later was not added until the OpenLDAP 2.4.45 release, with further fixes in the OpenLDAP 2.4.46 release. Thus I would advise a first step of upgrading to OpenLDAP 2.4.46. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8920) OpenLDAP
by nanmor＠126.com 25 Sep '18

25 Sep '18

Full_Name: Nancy Mo Version: openldap-clients-2.4.44-15.el7_5.x86_64 OS: Redhat 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.38.0.87) Hi team, Linux server is redhat7, and installed Openssl-1.1.1 which is support for TLS1.3。 I tried to connect a LDAP server which is used TLS1.3, the openldap client connection failed, if the server setting change to TLS 1.2, it can connected successfully。 By the way, use the openssl s_client -connect HOSTNAME.com:636, it will use TLS 1.3, and connect successfully. In the ldap.conf, I have set two parameters： TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT never Why the openldap client can not use TLS1.3? Thanks a lot. beat regards nancy

1 0

Re: (ITS#8919) common.c:2329: suspicious expression ?
by hyc＠symas.com 24 Sep '18

24 Sep '18

dcb314(a)hotmail.com wrote: > Full_Name: David Binderman > Version: 2.4.46 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.65.83.114) > > > common.c:2329:10: warning: logical not is only applied to the left hand side of > this bitwise operator [-Wlogical-not-parentheses] Next time please provide a full pathname, not just a filename. Next time please use "git diff" or "git format-patch" > Source code is > > if ( !tool_ctrl_response[j].mask & tool_type ) { > > Maybe better code: > > if ( !(tool_ctrl_response[j].mask & tool_type) ) { > > I can recommend compiling the openldap product with the clang C/C++ compiler. Next time read the code you're commenting on. This is an empty if statement, it has no effect regardless. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8919) common.c:2329: suspicious expression ?
by hyc＠symas.com 23 Sep '18

23 Sep '18

dcb314(a)hotmail.com wrote: > Full_Name: David Binderman > Version: 2.4.46 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.65.83.114) > > > common.c:2329:10: warning: logical not is only applied to the left hand side of > this bitwise operator [-Wlogical-not-parentheses] > > Source code is > > if ( !tool_ctrl_response[j].mask & tool_type ) { > > Maybe better code: > > if ( !(tool_ctrl_response[j].mask & tool_type) ) { > > I can recommend compiling the openldap product with the clang C/C++ compiler. Please use diff. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8917) OpenLDAP
by quanah＠symas.com 23 Sep '18

23 Sep '18

--On Saturday, September 22, 2018 11:56 PM +0200 Matus Honek <mhonek(a)redhat.com> wrote: > However, I believe TLS 1.3 already works with OpenLDAP and OpenSSL. > You might want to give a try to Docker image fedora:rawhide. I was > able to successfully establish TLS 1.3 connection ldapsearch<->slapd. Hi Matus, I just happened to be looking into this yesterday (ITS#8914) and was able to successfully compile OpenLDAP with OpenSSL 1.1.1 without issue as well, and was able to confirm (via the TLS testsuite available in the OpenLDAP HEAD release) that TLS 1.3 works fine. I've followed up with the person who filed ITS#8914 to give more information on what issue(s) they faced since it works for me. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8917) OpenLDAP
by mhonek＠redhat.com 22 Sep '18

22 Sep '18

Thanks for the response Quanah. You're right they're mentioning "some" LDAP server. And as you indirectly mentioned, with OpenSSL 1.0 the TLS 1.3 is not supported. However, I believe TLS 1.3 already works with OpenLDAP and OpenSSL. You might want to give a try to Docker image fedora:rawhide. I was able to successfully establish TLS 1.3 connection ldapsearch<->slapd. Tested with: openldap-2.4.46-8.fc30.x86_64 openssl-1.1.1-0.pre9.2.fc30.x86_64 HTH Best regards, Matus On Fri, Sep 21, 2018 at 8:23 PM Quanah Gibson-Mount <quanah(a)symas.com> wrot= e: > > --On Friday, September 21, 2018 10:59 AM +0000 mhonek(a)redhat.com wrote: > > > Hi Nancy, > > > > I'm not aware of RHEL7 shipping with OpenSSL-1.1, OpenLDAP is linked > > with openssl-1.0.2 there. > > > > Anyway, please report all issues related to TLS in OpenLDAP in Red Hat > > products to Red Hat Support or Bugzilla, first. > > Based on what I read in their report, they have an LDAP server (not > OpenLDAP) that has TLS 1.3 support, and the ldapsearch binaries on their > RedHat system won't negotiate TLS 1.3 with that server. This is not > surprising, as TLS 1.3 support in OpenSSL is only in the 1.1.1 release > series and OpenLDAP is not yet updated to link to OpenSSL 1.1.1 (See > ITS#8914). I'm currently examining what's necessary for such support. I > would not expect any OpenLDAP based ldapsearch binary to be able to > negotiate TLS 1.3 at this time, and I definitely wouldn't expect any Linu= x > distribution OpenLDAP based ldapsearch binary to support it for quite som= e > time. GnuTLS also only recently added TLS 1.3 support in the 3.6.3 relea= se > as of July 2018, so this would not work in debian based distributions > either unless running the very bleeding edge. > > Warm regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > --=20 Mat=C3=BA=C5=A1 Hon=C4=9Bk Software Engineer Red Hat Czech

1 0

(ITS#8919) common.c:2329: suspicious expression ?
by dcb314＠hotmail.com 22 Sep '18

22 Sep '18

Full_Name: David Binderman Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.65.83.114) common.c:2329:10: warning: logical not is only applied to the left hand side of this bitwise operator [-Wlogical-not-parentheses] Source code is if ( !tool_ctrl_response[j].mask & tool_type ) { Maybe better code: if ( !(tool_ctrl_response[j].mask & tool_type) ) { I can recommend compiling the openldap product with the clang C/C++ compiler.

1 0

(ITS#8918) sasl.c:326: possible bad assignment ?
by dcb314＠hotmail.com 22 Sep '18

22 Sep '18

Full_Name: David Binderman Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.65.83.114) sasl.c:326:6: warning: equality comparison result unused [-Wunused-comparison] view +326 openldap/openldap-2.4.46/servers/slapd/sasl.c Source code is if ( !conn ) { rc == LDAP_SUCCESS; goto done; } Suggest new code if ( !conn ) { rc = LDAP_SUCCESS; goto done; }

1 0

Re: (ITS#8914) OpenLDAP and OpenSSL v1.1.1
by quanah＠symas.com 21 Sep '18

21 Sep '18

--On Friday, September 21, 2018 9:46 PM +0000 quanah(a)symas.com wrote: > --On Thursday, September 13, 2018 1:20 PM +0000 nea.brown(a)threesl.com > wrote: > >> Full_Name: Neal Brown >> Version: 2.4.46 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.98.37.245) >> >> >> OpenLDAP will not configure for building against OpenSSL v1.1.1 due to >> SSLv3 being disabled. > > Please provide the configure options you used with OpenSSL v1.1.1 and > OpenLDAP, as I as able to build OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 > without issue. Hi Neal, See above. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8914) OpenLDAP and OpenSSL v1.1.1
by quanah＠symas.com 21 Sep '18

21 Sep '18

--On Thursday, September 13, 2018 1:20 PM +0000 nea.brown(a)threesl.com wrote: > Full_Name: Neal Brown > Version: 2.4.46 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.98.37.245) > > > OpenLDAP will not configure for building against OpenSSL v1.1.1 due to > SSLv3 being disabled. Please provide the configure options you used with OpenSSL v1.1.1 and OpenLDAP, as I as able to build OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 without issue. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8917) OpenLDAP
by quanah＠symas.com 21 Sep '18

21 Sep '18

--On Friday, September 21, 2018 10:59 AM +0000 mhonek(a)redhat.com wrote: > Hi Nancy, > > I'm not aware of RHEL7 shipping with OpenSSL-1.1, OpenLDAP is linked > with openssl-1.0.2 there. > > Anyway, please report all issues related to TLS in OpenLDAP in Red Hat > products to Red Hat Support or Bugzilla, first. Based on what I read in their report, they have an LDAP server (not OpenLDAP) that has TLS 1.3 support, and the ldapsearch binaries on their RedHat system won't negotiate TLS 1.3 with that server. This is not surprising, as TLS 1.3 support in OpenSSL is only in the 1.1.1 release series and OpenLDAP is not yet updated to link to OpenSSL 1.1.1 (See ITS#8914). I'm currently examining what's necessary for such support. I would not expect any OpenLDAP based ldapsearch binary to be able to negotiate TLS 1.3 at this time, and I definitely wouldn't expect any Linux distribution OpenLDAP based ldapsearch binary to support it for quite some time. GnuTLS also only recently added TLS 1.3 support in the 3.6.3 release as of July 2018, so this would not work in debian based distributions either unless running the very bleeding edge. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8917) OpenLDAP
by mhonek＠redhat.com 21 Sep '18

21 Sep '18

Hi Nancy, I'm not aware of RHEL7 shipping with OpenSSL-1.1, OpenLDAP is linked with openssl-1.0.2 there. Anyway, please report all issues related to TLS in OpenLDAP in Red Hat products to Red Hat Support or Bugzilla, first. Thanks! Regards. On Fri, Sep 21, 2018 at 11:21 AM <nanmor(a)126.com> wrote: > > Full_Name: Nancy Mo > Version: openldap-clients-2.4.44-15.el7_5.x86_64 > OS: Redhat 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (106.38.0.87) > > > Hi team, > > Linux server is redhat7, and installed Openssl-1.1.1 which is support for > TLS1.3。 > I tried to connect a LDAP server which is used TLS1.3, the openldap clien= t > connection failed, if the server setting change to TLS 1.2, it can connec= ted > successfully。 > By the way, use the openssl s_client -connect HOSTNAME.com:636, it will u= se TLS > 1.3, and connect successfully. > In the ldap.conf, I have set two parameters： > > TLS_CACERTDIR /etc/openldap/certs > TLS_REQCERT never > > Why the openldap client can not use TLS1.3? > > Thanks a lot. > > beat regards > > nancy > --=20 Mat=C3=BA=C5=A1 Hon=C4=9Bk Software Engineer Red Hat Czech

1 0

(ITS#8917) OpenLDAP
by nanmor＠126.com 21 Sep '18

21 Sep '18

Full_Name: Nancy Mo Version: openldap-clients-2.4.44-15.el7_5.x86_64 OS: Redhat 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.38.0.87) Hi team, Linux server is redhat7, and installed Openssl-1.1.1 which is support for TLS1.3。 I tried to connect a LDAP server which is used TLS1.3, the openldap client connection failed, if the server setting change to TLS 1.2, it can connected successfully。 By the way, use the openssl s_client -connect HOSTNAME.com:636, it will use TLS 1.3, and connect successfully. In the ldap.conf, I have set two parameters： TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT never Why the openldap client can not use TLS1.3? Thanks a lot. beat regards nancy

1 0

Re: (ITS#8916) MDB_VL32 in readonly causes MDB_CORRUPTED
by pierre.chambart＠ocamlpro.com 19 Sep '18

19 Sep '18

On 19/09/2018 17:35, Howard Chu wrote: > pierre.chambart(a)ocamlpro.com wrote: >> Full_Name: Pierre Chambart >> Version:=20 >> OS:=20 >> URL:=20 >> Submission from: (NULL) (185.194.234.133) >> >> >> We have been trying LMDB compiled with the MDB_VL32 flag and encounter= ed some >> MDB_CORRUPTED error that didn't occur without MDB_VL32. >> We could produce a minimal reproduction case: >> https://raw.githubusercontent.com/chambart/lmdb/vl32_readonly_fix/libr= aries/liblmdb/vl32_failure.c >> This is basically writing a key, reading it, writing something else th= en reading >> it again. >> >> After some investigation, this is how I understand what is happening: >> >> * The chunk being mapped for the first read contains 3 pages instead o= f the 16 >> pages that would be mapped without readonly. >> * The second write extend the size of the base to 5 pages >> * Finally the last read retrieve the mapped chunk from the first read,= which has >> size 3, but assumes that it has size 5, hence reading some random valu= e in >> memory past the end of the pages. >> >> It can be verified by asserting that id3.mcnt is larger than rem at th= e end of >> mdb_rpage_get, around this line: >> >> ok: >> p =3D (MDB_page *)((char *)id3.mptr + rem * env->me_psize); >> >> This does not seem to be the case. >> >> I made a dirty fix that seems to work. It's simply to remove those lin= es: >> >> /* don't map past last written page in read-only envs */ >> if ((env->me_flags & MDB_RDONLY) && pgno + MDB_RPAGE_CHUNK-1 >= >> txn->mt_last_pgno) >> id3.mcnt =3D txn->mt_last_pgno + 1 - pgno; >> else >> >> This seems to be some optimization that avoids mapping the 16 pages of= the >> chunk. But given that those pages are >> initialized, there doesn't seem to be much harm in mapping a few more = pages in >> that relatively rare situation. > Please check git history before assuming the code is an optimization. > > These lines prevent a crash on Windows. > Sorry, about that. Also I'm not suggesting that this is a proper fix, rather that this is so= me clue to understand the problem. I'm happy producing a patch if you indicate what kind of fix you would like. --=20 Pierre

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs