openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

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 11 Oct '18

11 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 11 Oct '18

11 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs