- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs