- openldap-bugs - openldap.org

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 06 Apr '17

06 Apr '17

On Thu, Apr 06, 2017 at 05:14:15PM +0200, Michael Ströder wrote: > ondra(a)mistotebe.net wrote: >> On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael StrĂśder wrote: >>> => There could be a slapd per-backend configuation directive to disallow it with a >>> strong hint in the docs recommending to disallow it when using delta-syncrepl. >>> >>> Suggestion: >>> disallow mod_attr_repeated >> >> In my view, that's more pain than it's worth. > > Hmm, I think slapd should be able to disallow a crazy modify request like this: > > dn: cn=foobar,dc=example,dc=com > changetype: modify > replace: description > description: foobar1 > - > replace: description > description: foobar2 > - > .. > replace: description > description: foobar1000 > - Well, the clients are allowed to request a lot of strange things, some of which border on a DoS: e.g. right now slapd can't disallow a modify request like: dn: cn=foobar,dc=example,dc=com changetype: modify replace: description description: foobar1 description: foobar2 ... description: foobar1000 So there. If we can agree on a way to handle that, we might see whether it could be repurposed. I should have a patch for the accesslog issue soon. -- 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#6545) delta-syncrepl rejects modification master accepted
by michael＠stroeder.com 06 Apr '17

06 Apr '17

ondra(a)mistotebe.net wrote: > On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael Ströder wrote: >> ondra(a)mistotebe.net wrote: >>> On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >>>> Thanks for the patch to provide a test script that just shows the same >>>> thing. >>>> >>>> I see two possible solutions: >>>> >>>> 1) replacing the same attribute twice in the same modify LDIF is illegal >>>> (as it was in older releases) >>> >>> AFAIK, LDAP doesn't forbid it so I don't see that going away. >> >> Yes, there's no text in RFC 4511 which forbids this: >> https://tools.ietf.org/html/rfc4511#section-4.6 >> >> However personally I consider LDAP clients sending modify requests like this to be >> broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) > > I'm not saying it's common or good practice ;) > >> => There could be a slapd per-backend configuation directive to disallow it with a >> strong hint in the docs recommending to disallow it when using delta-syncrepl. >> >> Suggestion: >> disallow mod_attr_repeated > > In my view, that's more pain than it's worth. Hmm, I think slapd should be able to disallow a crazy modify request like this: dn: cn=foobar,dc=example,dc=com changetype: modify replace: description description: foobar1 - replace: description description: foobar2 - .. replace: description description: foobar1000 - Ciao, Michael.

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 06 Apr '17

06 Apr '17

On Wed, 5 Apr 2017 at 8:18am, ondra(a)mistotebe.net wrote: > AFAIK, LDAP doesn't forbid it so I don't see that going away. Well, then that means that the current behavior is a bug in either the syncrepl implementation or the accesslog recording. Since the MASTER gets updated correctly and the REPLICAs (and other MMR members) all fall down when attempting to process the accesslog entry. > It does need a fair bit of attention, the problem is it's something that > would require a format change and there are already existing consumers > that would be affected. > > I'm going to try with a patch to record something like this: > regMod: sn:= George > regMod: : > regMod: sn:= George > > Together with the relevant syncrepl updates. > > While consumers would still be affected, this should be quite rare and > the current handling of that case would have been incorrect anyway. The > change would then only make the silent failure a noisy one. Noisy in that the replica/mmr falls over dead or just logs more stuff? To be honest, my goal is consistency. I want the replicas (and MMR mates) to all wind up with the same values the master has. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 06 Apr '17

06 Apr '17

On Wed, 5 Apr 2017 at 10:14am, michael(a)stroeder.com wrote: > However personally I consider LDAP clients sending modify requests like this to be > broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) My original report was from 2010 - I presume it was something that the perl code (using Net::LDAP module) that I had written at the time tripped onto [or it was some awful edgecase test that I had devised]. To the best of my knowledge, this was not something that I had a client doing to the LDAP servers from the wild. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#8629) slapauth segfault with GSSAPI + olcAuthzRegexp using internal LDAP search + ppolicy overlay
by clement.oudot＠savoirfairelinux.com 06 Apr '17

06 Apr '17

Hello, I would like to know if some of you have an idea on how to fix this bug? I am able to test a patch if you can provide one. Regards, Cl=E9ment.

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by henson＠acm.org 06 Apr '17

06 Apr '17

On Mon, Apr 03, 2017 at 11:15:17AM -0700, Quanah Gibson-Mount wrote: > Looks like this has actually been reported before: > <http://www.openldap.org/its/index.cgi/?findid=7400> Yikes, from 2012, and never resolved 8-/. I'm curious though why Howard says the work has to be distributed to all the replicas locally as it wouldn't scale otherwise? For adding or removing a user from a group, replicating the memberOf attribute on the user in addition to the member attribute on the group only doubles the replication load which doesn't seem excessive. I suppose if you delete a group with a large membership that would result in updating a large number of users, but that's no different than if a delete a single user from a large number of groups, which doesn't seem to cause any issues. Unless I'm misunderstanding something? In any case, I suppose this ITS can be closed now too, with the same resolution that the memberof overlay is no longer supported in a replicated configuration and to switch to the dynlist implementation...

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 06 Apr '17

06 Apr '17

On Mon, Apr 03, 2017 at 02:44:48PM +0100, Howard Chu wrote: > You should probably switch to a non-optimized build. The backtrace you > posted initially had most parameters optimized out, which also makes > things harder to trace. Ok, I installed binaries built with -O0 on the master server that's been failing; I'll post a new backtrace the next time it crashes, thanks.

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 06 Apr '17

06 Apr '17

--On Thursday, April 06, 2017 2:02 AM +0100 Howard Chu <hyc(a)symas.com> wrote: >> +#if OPENSSL_VERSION_NUMBER < 0x10100000 > > Are you sure about exactly when these functions were removed? The title > of this ITS is for 1.1.0c, and the earlier patches were for 1.1.0a. For > version 1.1.0c we should be comparing to 0x1010003f, not 0x10100000. Yes, I checked against OpenSSL 1.1.0 (released before 1.1.0a). The OpenSSL shipped headers are clear on this as well, for example: #if OPENSSL_API_COMPAT < 0x10100000L # define SSL_library_init() OPENSSL_init_ssl(0, NULL) #endif #if OPENSSL_API_COMPAT < 0x10100000L # define SSL_load_error_strings() \ OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS \ | OPENSSL_INIT_LOAD_CRYPTO_STRINGS, NULL) #endif etc -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by hyc＠symas.com 06 Apr '17

06 Apr '17

quanah(a)symas.com wrote: > --On Wednesday, April 05, 2017 11:12 PM +0000 quanah(a)symas.com wrote: > >>> The following 5 function calls are problematic: >>> >>> ./.libs/libldap.so: undefined reference to `OpenSSL_add_all_digests' >>> ./.libs/libldap.so: undefined reference to `SSL_load_error_strings' >>> ./.libs/libldap.so: undefined reference to `ERR_free_strings' >>> ./.libs/libldap.so: undefined reference to `EVP_cleanup' >>> ./.libs/libldap.so: undefined reference to `SSL_library_init' > > The above can be fixed with the following patch: > > build@u12build:~/git/symas-packages/thirdparty/openldap/build/UBUNTU12_64/symas-openldap/libraries/libldap$ > diff -u tls_o.c.orig tls_o.c > --- tls_o.c.orig 2017-04-05 14:40:02.849559862 -0700 > +++ tls_o.c 2017-04-05 15:13:09.371718493 -0700 > @@ -154,9 +154,16 @@ > (void) tlso_seed_PRNG( lo->ldo_tls_randfile ); > #endif > > +#if OPENSSL_VERSION_NUMBER < 0x10100000 Are you sure about exactly when these functions were removed? The title of this ITS is for 1.1.0c, and the earlier patches were for 1.1.0a. For version 1.1.0c we should be comparing to 0x1010003f, not 0x10100000. > SSL_load_error_strings(); > SSL_library_init(); > OpenSSL_add_all_digests(); > +#else > + OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS \ > + | OPENSSL_INIT_LOAD_CRYPTO_STRINGS, NULL); > + OPENSSL_init_ssl(0, NULL); > + OPENSSL_init_crypto(OPENSSL_INIT_ADD_ALL_DIGESTS, NULL); > +#endif > > /* FIXME: mod_ssl does this */ > X509V3_add_standard_extensions(); > @@ -172,6 +179,7 @@ > { > struct ldapoptions *lo = LDAP_INT_GLOBAL_OPT(); > > +#if OPENSSL_VERSION_NUMBER < 0x10100000 > EVP_cleanup(); > #if OPENSSL_VERSION_NUMBER < 0x10000000 > ERR_remove_state(0); > @@ -179,6 +187,9 @@ > ERR_remove_thread_state(NULL); > #endif > ERR_free_strings(); > +#else > + ERR_remove_thread_state(NULL); > +#endif > > if ( lo->ldo_tls_randfile ) { > LDAP_FREE( lo->ldo_tls_randfile ); > > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > > > > -- -- 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#8533) Support OpenSSL-1.1.0c
by hyc＠symas.com 06 Apr '17

06 Apr '17

quanah(a)symas.com wrote: > --On Wednesday, April 05, 2017 10:38 PM +0000 quanah(a)symas.com wrote: > >> --On Wednesday, April 05, 2017 7:58 PM +0000 quanah(a)symas.com wrote: >> >>> If openssl 1.1.0 is built with the option "no-deprecated" the build will >>> fail, as portions of the code still use the pre 1.1 API. This needs >>> fixing before release. >> >> The following 5 function calls are problematic: >> >> ./.libs/libldap.so: undefined reference to `OpenSSL_add_all_digests' >> ./.libs/libldap.so: undefined reference to `SSL_load_error_strings' >> ./.libs/libldap.so: undefined reference to `ERR_free_strings' >> ./.libs/libldap.so: undefined reference to `EVP_cleanup' >> ./.libs/libldap.so: undefined reference to `SSL_library_init' >> >> >> Looking at the best way in which to fix. > > These also need fixing, as they don't exist in 1.1 when the old API is > disabled. > > CRYPTO_num_locks() > CRYPTO_LOCK > CRYPTO_set_locking_callback() > CRYPTO_set_id_callback() These only exist because OpenSSL's support for threading was mostly nonexistent in the past. They should just be #ifdef'd away for 1.1. -- -- 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#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 06 Apr '17

06 Apr '17

--On Wednesday, April 05, 2017 11:12 PM +0000 quanah(a)symas.com wrote: >> The following 5 function calls are problematic: >> >> ./.libs/libldap.so: undefined reference to `OpenSSL_add_all_digests' >> ./.libs/libldap.so: undefined reference to `SSL_load_error_strings' >> ./.libs/libldap.so: undefined reference to `ERR_free_strings' >> ./.libs/libldap.so: undefined reference to `EVP_cleanup' >> ./.libs/libldap.so: undefined reference to `SSL_library_init' The above can be fixed with the following patch: build@u12build:~/git/symas-packages/thirdparty/openldap/build/UBUNTU12_64/symas-openldap/libraries/libldap$ diff -u tls_o.c.orig tls_o.c --- tls_o.c.orig 2017-04-05 14:40:02.849559862 -0700 +++ tls_o.c 2017-04-05 15:13:09.371718493 -0700 @@ -154,9 +154,16 @@ (void) tlso_seed_PRNG( lo->ldo_tls_randfile ); #endif +#if OPENSSL_VERSION_NUMBER < 0x10100000 SSL_load_error_strings(); SSL_library_init(); OpenSSL_add_all_digests(); +#else + OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS \ + | OPENSSL_INIT_LOAD_CRYPTO_STRINGS, NULL); + OPENSSL_init_ssl(0, NULL); + OPENSSL_init_crypto(OPENSSL_INIT_ADD_ALL_DIGESTS, NULL); +#endif /* FIXME: mod_ssl does this */ X509V3_add_standard_extensions(); @@ -172,6 +179,7 @@ { struct ldapoptions *lo = LDAP_INT_GLOBAL_OPT(); +#if OPENSSL_VERSION_NUMBER < 0x10100000 EVP_cleanup(); #if OPENSSL_VERSION_NUMBER < 0x10000000 ERR_remove_state(0); @@ -179,6 +187,9 @@ ERR_remove_thread_state(NULL); #endif ERR_free_strings(); +#else + ERR_remove_thread_state(NULL); +#endif if ( lo->ldo_tls_randfile ) { LDAP_FREE( lo->ldo_tls_randfile ); --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#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 06 Apr '17

06 Apr '17

--On Wednesday, April 05, 2017 10:38 PM +0000 quanah(a)symas.com wrote: > --On Wednesday, April 05, 2017 7:58 PM +0000 quanah(a)symas.com wrote: > >> If openssl 1.1.0 is built with the option "no-deprecated" the build will >> fail, as portions of the code still use the pre 1.1 API. This needs >> fixing before release. > > The following 5 function calls are problematic: > > ./.libs/libldap.so: undefined reference to `OpenSSL_add_all_digests' > ./.libs/libldap.so: undefined reference to `SSL_load_error_strings' > ./.libs/libldap.so: undefined reference to `ERR_free_strings' > ./.libs/libldap.so: undefined reference to `EVP_cleanup' > ./.libs/libldap.so: undefined reference to `SSL_library_init' > > > Looking at the best way in which to fix. These also need fixing, as they don't exist in 1.1 when the old API is disabled. CRYPTO_num_locks() CRYPTO_LOCK CRYPTO_set_locking_callback() CRYPTO_set_id_callback() --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#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 05 Apr '17

05 Apr '17

--On Wednesday, April 05, 2017 7:58 PM +0000 quanah(a)symas.com wrote: > If openssl 1.1.0 is built with the option "no-deprecated" the build will > fail, as portions of the code still use the pre 1.1 API. This needs > fixing before release. The following 5 function calls are problematic: ./.libs/libldap.so: undefined reference to `OpenSSL_add_all_digests' ./.libs/libldap.so: undefined reference to `SSL_load_error_strings' ./.libs/libldap.so: undefined reference to `ERR_free_strings' ./.libs/libldap.so: undefined reference to `EVP_cleanup' ./.libs/libldap.so: undefined reference to `SSL_library_init' Looking at the best way in which to fix. --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#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 05 Apr '17

05 Apr '17

If openssl 1.1.0 is built with the option "no-deprecated" the build will fail, as portions of the code still use the pre 1.1 API. This needs fixing before release. --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#7013) OpenLDAP freezes and doesn't respond
by quanah＠symas.com 05 Apr '17

05 Apr '17

Hello, Due to inactivity and the noted improper configuration, I am closing this ITS. I would note there have been hundreds of fixes to OpenLDAP since this report was filed, including a new BDB-free backend. If you ever drop OpenDJ and move back to OpenLDAP and can reproduce the issue using back-mdb (based on LMDB), please file a new ITS. Thanks! --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#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 05 Apr '17

05 Apr '17

On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael Ströder wrote: > ondra(a)mistotebe.net wrote: >> On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >>> Thanks for the patch to provide a test script that just shows the same >>> thing. >>> >>> I see two possible solutions: >>> >>> 1) replacing the same attribute twice in the same modify LDIF is illegal >>> (as it was in older releases) >> >> AFAIK, LDAP doesn't forbid it so I don't see that going away. > > Yes, there's no text in RFC 4511 which forbids this: > https://tools.ietf.org/html/rfc4511#section-4.6 > > However personally I consider LDAP clients sending modify requests like this to be > broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) I'm not saying it's common or good practice ;) > => There could be a slapd per-backend configuation directive to disallow it with a strong > hint in the docs recommending to disallow it when using delta-syncrepl. > > Suggestion: > disallow mod_attr_repeated In my view, that's more pain than it's worth. >>> 2) the accesslog/syncrepl needs to record the final result, not every bit >>> of the change. >> >> Two problems: >> - the log is meant to record the request for review/statistics purposes >> as well and should record the intent, not just the result >> - the modification might fail, in that case you still need an accurate >> record of the request > > IIRC slapo-accesslog was primarily implemented for delta-syncrepl. > > Personally I'm in the (ab)use-slapo-accesslog-as-auditlog camp. ;-) > But still I'd consider an optimized changes list written to accesslog to be perfectly > fine for security auditing because it would represent what caused the modification of the > database content. I don't think it matters what it was written for, the fact that it's officially useful for that as you and others have realised means they might object to us making drastic changes in 2.4, a series the project have tried to freeze even maintenance for. > Also note that not every failed modification is written to accesslog-DB anyway because > most malformed write operations already fail in slapd's front-end (schema check etc.) and > never reach the DB backend (and thus slapo-accesslog). So debugging errornous clients is > something for which you have to use Wireshark etc. in most cases anyway. I think most of the ones that don't reach accesslog get a protocol error or come from anonymous connections, schema checking and ACL should happen later. > I'm not familiar with the inner workings of slapd but these things should be carefully > considered when optimizing the changes list of a modify request: > 1. constraint checking (slapo-unique and slapo-constraint) > 2. impact on indexing > 3. access control, especially with val=foo part in the ACL > > 1. and 2. are hopefully already done on the "resulting entry after the entire list of > modifications is performed" (RFC 4511). Not sure I follow. On the consumer, syncrepl bypasses all ACLs and the overlays you mention should already be capable of passing the operation intact. On the provider side it depends on the overlay order and the administrator has the option to decide that if they wish. Consistency and data model are generally maintained quite alright. -- 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#6545) delta-syncrepl rejects modification master accepted
by michael＠stroeder.com 05 Apr '17

05 Apr '17

ondra(a)mistotebe.net wrote: > On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >> Thanks for the patch to provide a test script that just shows the same >> thing. >> >> I see two possible solutions: >> >> 1) replacing the same attribute twice in the same modify LDIF is illegal >> (as it was in older releases) > > AFAIK, LDAP doesn't forbid it so I don't see that going away. Yes, there's no text in RFC 4511 which forbids this: https://tools.ietf.org/html/rfc4511#section-4.6 However personally I consider LDAP clients sending modify requests like this to be broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) => There could be a slapd per-backend configuation directive to disallow it with a strong hint in the docs recommending to disallow it when using delta-syncrepl. Suggestion: disallow mod_attr_repeated >> 2) the accesslog/syncrepl needs to record the final result, not every bit >> of the change. > > Two problems: > - the log is meant to record the request for review/statistics purposes > as well and should record the intent, not just the result > - the modification might fail, in that case you still need an accurate > record of the request IIRC slapo-accesslog was primarily implemented for delta-syncrepl. Personally I'm in the (ab)use-slapo-accesslog-as-auditlog camp. ;-) But still I'd consider an optimized changes list written to accesslog to be perfectly fine for security auditing because it would represent what caused the modification of the database content. Also note that not every failed modification is written to accesslog-DB anyway because most malformed write operations already fail in slapd's front-end (schema check etc.) and never reach the DB backend (and thus slapo-accesslog). So debugging errornous clients is something for which you have to use Wireshark etc. in most cases anyway. I'm not familiar with the inner workings of slapd but these things should be carefully considered when optimizing the changes list of a modify request: 1. constraint checking (slapo-unique and slapo-constraint) 2. impact on indexing 3. access control, especially with val=foo part in the ACL 1. and 2. are hopefully already done on the "resulting entry after the entire list of modifications is performed" (RFC 4511). Ciao, Michael.

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 05 Apr '17

05 Apr '17

On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: > Thanks for the patch to provide a test script that just shows the same > thing. > > I see two possible solutions: > > 1) replacing the same attribute twice in the same modify LDIF is illegal > (as it was in older releases) AFAIK, LDAP doesn't forbid it so I don't see that going away. > 2) the accesslog/syncrepl needs to record the final result, not every bit > of the change. Two problems: - the log is meant to record the request for review/statistics purposes as well and should record the intent, not just the result - the modification might fail, in that case you still need an accurate record of the request > I believe the easiest solution is #1. However, #2 would be proper if this > kind of abuse is legal. > > Consider the following deck: > > [...] > > Is that legal? Well, it works and results in an entry in the accesslog that > contains: > > [...] > > and has no issues in the replication. > > Therefore, why does this deck: > > dn: cn=Oh Noes,ou=People,dc=example,dc=com > changetype: modify > replace: sn > sn: Thomas > - > replace: sn > sn: George > - > > which creates an accesslog entry that contains: > > reqMod: sn:= Thomas > reqMod: sn:= George > > Interestingly, this morning when I was performing this, the replica ate that > accesslog entry and put both of those sn's into the LDAP entry on the > replica (instead of the normal barking in the logs that it failed). Perhaps > because I had done the former test with the delete/add/delete/add sequence? Your original example did two replacements with the same value, the test case runs two replacements with different values as that will cause the two servers to de-sync silently. > At this point, I'm thinking the accesslog should probably generate the > minimal changes necessary to get to the right state. That would mean the > former test should produce: > > reqMod: sn:- George > reqMod: sn:+ George > > and the latter: > > reqMod:sn:= George > > Either that, or the syncrepl processing of what accesslog is sending needs > some serious investigation. I'll see what I can find for time to look into > that serious investigation. It does need a fair bit of attention, the problem is it's something that would require a format change and there are already existing consumers that would be affected. I'm going to try with a patch to record something like this: regMod: sn:= George regMod: : regMod: sn:= George Together with the relevant syncrepl updates. While consumers would still be affected, this should be quite rare and the current handling of that case would have been incorrect anyway. The change would then only make the silent failure a noisy one. -- 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#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 05 Apr '17

05 Apr '17

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1015574222-1491391973=:71829 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Thanks for the patch to provide a test script that just shows the same thing. I see two possible solutions: 1) replacing the same attribute twice in the same modify LDIF is illegal (as it was in older releases) 2) the accesslog/syncrepl needs to record the final result, not every bit of the change. I believe the easiest solution is #1. However, #2 would be proper if this kind of abuse is legal. Consider the following deck: dn: cn=Oh Noes,ou=People,dc=example,dc=com changetype: modify delete: sn sn: George - add: sn sn: Thomas - delete: sn sn: Thomas - add: sn sn: George - Is that legal? Well, it works and results in an entry in the accesslog that contains: reqMod: sn:- George reqMod: sn:+ Thomas reqMod: sn:- Thomas reqMod: sn:+ George and has no issues in the replication. Therefore, why does this deck: dn: cn=Oh Noes,ou=People,dc=example,dc=com changetype: modify replace: sn sn: Thomas - replace: sn sn: George - which creates an accesslog entry that contains: reqMod: sn:= Thomas reqMod: sn:= George Interestingly, this morning when I was performing this, the replica ate that accesslog entry and put both of those sn's into the LDAP entry on the replica (instead of the normal barking in the logs that it failed). Perhaps because I had done the former test with the delete/add/delete/add sequence? At this point, I'm thinking the accesslog should probably generate the minimal changes necessary to get to the right state. That would mean the former test should produce: reqMod: sn:- George reqMod: sn:+ George and the latter: reqMod:sn:= George Either that, or the syncrepl processing of what accesslog is sending needs some serious investigation. I'll see what I can find for time to look into that serious investigation. - Frank On Tue, 4 Apr 2017 at 1:54pm, Ondřej Kuzník wrote: > The attached patch updates the testsuite to reproduce the issue: > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170404-ITS-6545-testcase.pa… > > The issue is that there is information lost when creating the log entry: > - the ordering of values is not guaranteed by LDAP, even though this is > rarely an issue with OpenLDAP with main backends (unless some overlay > interferes) > - there is no way to record where one modification ends and another > begins > > The obvious way to fix this is to record that a modification has ended. > This is technically a change to the accesslog format but delta syncrepl > will recover by falling back to plain syncrepl (which it already does in > the reported case). > > We could also record the order modifications as well (implementing the > X-ORDERED trait on the attribute), but that would break most consumers > of this format. > > -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) --0-1015574222-1491391973=:71829--

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 04 Apr '17

04 Apr '17

The attached patch updates the testsuite to reproduce the issue: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170404-ITS-6545-testcase.pa… The issue is that there is information lost when creating the log entry: - the ordering of values is not guaranteed by LDAP, even though this is rarely an issue with OpenLDAP with main backends (unless some overlay interferes) - there is no way to record where one modification ends and another begins The obvious way to fix this is to record that a modification has ended. This is technically a change to the accesslog format but delta syncrepl will recover by falling back to plain syncrepl (which it already does in the reported case). We could also record the order modifications as well (implementing the X-ORDERED trait on the attribute), but that would break most consumers of this format. -- 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#8630) Objectclass name being overwritten when loading schema
by quanah＠symas.com 04 Apr '17

04 Apr '17

--On Tuesday, April 04, 2017 7:30 AM +0000 thomas.fazekas(a)gmail.com wrote: > Full_Name: Thomas Fazekas > Version: 2.4.44 > OS: raspbian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.181.38.213) Hi Thomas, The back-sql backend is clearly noted as being experimental in the man page. Currently there is no active maintainer/developer for the backend, so no promises if/when this will be fixed. I would note that there have been a number of people who have working installations of back-sql, but I don't know the specifics of their setup. Hope that helps. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8630) Objectclass name being overwritten when loading schema
by thomas.fazekas＠gmail.com 04 Apr '17

04 Apr '17

Full_Name: Thomas Fazekas Version: 2.4.44 OS: raspbian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.181.38.213) My system info : Linux berry 4.4.34+ #930 Wed Nov 23 15:12:30 GMT 2016 armv6l GNU/Linux (raspberry pi 3 with latest raspbian) openldap 2.4.44 built from sources : "./configure --prefix=/opt/openldap-2.4.44 --enable-sql" Mysql deployed from repository : 5.5.54-0+deb8u1 (Raspbian) followed the mysql specific README from the rdbms sources folder (created the db, schema & test data) Now, when I try to start-up the server I get : 58e33726 backend_startup_one: starting "dc=berry,dc=office,dc=company,dc=com" 58e33726 ==>backsql_db_open(): testing RDBMS connection 58e33726 backsql_db_open(): concat func not specified (use "concat_pattern" directive in slapd.conf) 58e33726 backsql_db_open(): children search SQL condition not specified (use "children_cond" directive in slapd.conf); preparing default 58e33726 backsql_db_open(): setting "ldap_entries.dn LIKE CONCAT('%,',?)" as default "children_cond" 58e33726 backsql_db_open(): DN match search SQL condition not specified (use "dn_match_cond" directive in slapd.conf); preparing default 58e33726 backsql_db_open(): setting "ldap_entries.dn=?" as default "dn_match_cond" 58e33726 backsql_db_open(): objectclass mapping SQL statement not specified (use "oc_query" directive in slapd.conf) 58e33726 backsql_db_open(): setting "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" by default 58e33726 backsql_db_open(): attribute mapping SQL statement not specified (use "at_query" directive in slapd.conf) 58e33726 backsql_db_open(): setting "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" by default 58e33726 backsql_db_open(): entry deletion SQL statement not specified (use "delentry_stmt" directive in slapd.conf) 58e33726 backsql_db_open(): setting "DELETE FROM ldap_entries WHERE id=?" by default 58e33726 backsql_db_open(): entry deletion SQL statement not specified (use "renentry_stmt" directive in slapd.conf) 58e33726 backsql_db_open(): setting "UPDATE ldap_entries SET dn=?,parent=?,keyval=? WHERE id=?" by default 58e33726 backsql_db_open(): objclasses deletion SQL statement not specified (use "delobjclasses_stmt" directive in slapd.conf) 58e33726 backsql_db_open(): setting "DELETE FROM ldap_entry_objclasses WHERE entry_id=?" by default 58e33726 ==>backsql_get_db_conn() 58e33726 ==>backsql_open_db_handle() 58e33726 <==backsql_open_db_handle() 58e33726 <==backsql_get_db_conn() 58e33726 ==>backsql_load_schema_map() 58e33726 backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" 58e33726 objectClass: id="1" name="inetOrgPerson" keytbl="persons" keycol="id" create_proc="" create_keyval="" delete_proc="" expect_return="0"create_hint="" 58e33726 backsql_load_schema_map(): objectClass "inetOrgPerson": keytbl="persons" keycol="id" 58e33726 expect_return: add=0, del=0; attributes: 58e33726 objectClass: id="2" name="documenterson" keytbl="documents" keycol="id" create_proc="" create_keyval="" delete_proc="" expect_return="0"create_hint="" 58e33726 backsql_load_schema_map(): objectClass "documenterson" is not defined in schema 58e33726 backsql_db_open(): schema mapping failed, exiting 58e33726 backend_startup_one (type=sql, suffix="dc=berry,dc=office,dc=company,dc=com"): bi_db_open failed! (1) 58e33726 slapd shutdown: initiated 58e33726 ==>backsql_db_close() 58e33726 <==backsql_db_close() 58e33726 slapd destroy: freeing system resources. My related DB content : mysql> select * from ldap_oc_mappings; +----+---------------+------------+--------+-------------+-------------+---------------+ | id | name | keytbl | keycol | create_proc | delete_proc | expect_return | +----+---------------+------------+--------+-------------+-------------+---------------+ | 1 | inetOrgPerson | persons | id | NULL | NULL | 0 | | 2 | document | documents | id | NULL | NULL | 0 | | 3 | organization | institutes | id | NULL | NULL | 0 | | 4 | referral | referrals | id | NULL | NULL | 0 | +----+---------------+------------+--------+-------------+-------------+---------------+ 4 rows in set (0.00 sec) Now, as far as I can tell what is happening is that when loading the schema the first one (inetOrgPerson) is being overwritten by the second (document) without a terminator, ending up with an "documenterson" which obviously doesn't exist.

1 0

Re: (ITS#8425)
by quanah＠symas.com 03 Apr '17

03 Apr '17

Hello, The issue you opened is not about a software bug, but how to configure OpenLDAP. The ITS system is for issue reports only. Please use the OpenLDAP Technical list for help on how to configure OpenLDAP: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. 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#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by quanah＠symas.com 03 Apr '17

03 Apr '17

--On Friday, December 23, 2016 2:17 AM +0000 henson(a)acm.org wrote: > I sent this to the mailing list and was advised to add it to ITS 8444, > so here it is: Looks like this has actually been reported before: <http://www.openldap.org/its/index.cgi/?findid=7400> --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#7183) Open LDAP - Failed user id creation
by quanah＠symas.com 03 Apr '17

03 Apr '17

Hello, This report does not contain any useful or actionable items. The first step I would advise is to use a current release of OpenLDAP, and if you continue to have issues, please read the FAQ on how to report an issue: <http://www.openldap.org/faq/data/cache/59.html> This ITS will be closed 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#7498) Openldap syncrepl issue
by quanah＠symas.com 03 Apr '17

03 Apr '17

Hello, I would strongly advise retrying with a current OpenLDAP release. Numerous sync replication bugs have been fixed since 2.4.33. Also, to answer your earlier question, there's no such thing as "mirror mode". "mirror mode" is entirely a concept. A system either is or isn't multimaster, which delta-syncrepl works with. See also: <http://www.openldap.org/its/index.cgi/?findid=8511> 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#7474) memberOf and full syncreplication
by quanah＠symas.com 03 Apr '17

03 Apr '17

Hello, As noted in the slapo-memberof(5) man page, it is unsafe for use with replication. See also <http://www.openldap.org/its/index.cgi/?findid=8613> for ways in which to replicate memberOf functionality in a replication safe manner using slapo-dynlist. This ITS will be closed. 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#7791) 3-Way delta MMR segfault
by quanah＠symas.com 03 Apr '17

03 Apr '17

Hello, I can say that I've not seen this issue in numerous current OpenLDAP deployments with OpenLDAP 2.4.44. However, be aware of ITS#8432 which does impact 2.4.44. I'd guess that whatever was causing the problem was fixed between 2.4.38 and 2.4.44. Unfortunately, a clear backtrace with full debugging symbols and no optimization of slapd was never provided, so work on this ITS can't really go forward. I will close it for now, given that I've not seen this issue impact large volume 3 & 4 way MMR setups with current releases. If you can reproduce with current OpenLDAP, please feel free to respond, at which time I will reopen the issue. 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#8609) segfault in mods.c - modify_add_values
by hyc＠symas.com 03 Apr '17

03 Apr '17

henson(a)acm.org wrote: > So slapd crashed two days in a row, yesterday morning and this morning > :(. Same backtrace. You should probably switch to a non-optimized build. The backtrace you posted initially had most parameters optimized out, which also makes things harder to trace. -- -- 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#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 03 Apr '17

03 Apr '17

So slapd crashed two days in a row, yesterday morning and this morning :(. Same backtrace. What's worse whereas unlike today and every time before it was relatively harmless, something *weird* happened yesterday. I did my usual of just restarting slapd on the master and letting the load balancer fail back over to it and having it catch back up on replication from the changes made to the secondary, which has always been fine before other than maybe having to tune up whatever change was in the middle of being committed when the primary actually died. But somehow yesterday things that happened like a week and a half ago just mysteriously disappeared 8-/. 10 groups that were created on 3/22 were just *gone* without a trace. I had to go dig up ldif backups from then and manually readd them back to the directory to clean stuff up. It looks like there's some group membership corruption too, I'm going to look at it in more detail tomorrow, it should be identical to our AD environment so I can compare and clean up against that. It doesn't look like any users fell into limbo, I diff'd the user DN's from the backup the day before against the one after and they're all still there modulo 5 that were deleted intentionally. I haven't been overly concerned about this issue, while it's been annoying, it hasn't had much of a production impact. But it just turned ugly :(, assuming this was caused by the crash, and I can't see how it wouldn't have been... <sigh>. Is there any logging or something I could turn on that would help for the next occurance but wouldn't be an excessive impact in terms of load or disk utilization on a production box? Thanks...

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 31 Mar '17

31 Mar '17

On Thu, Mar 30, 2017 at 12:30:09PM -0700, Paul B. Henson wrote: >> From: Ond=C5=99ej Kuzn=C3=ADk >> Sent: Monday, March 27, 2017 8:10 AM >>=20 >> I've had a look whether I could reproduce the issue somehow and there = is >> a potential crasher if the accesslog entry contained "reqmod: >> eduPersonAffiliation:+". Can you confirm whether you have entries like >> this in your logdb? >=20 > There aren't currently any entries like that in the log, although the l= ast > crash was a week or two ago. I will check again right after the next cr= ash. > However, here is one of the log entries that appeared to correlate with= what > was being processed in the backtrace of one of the crashes: >=20 > [...] >=20 > And it does not appear to have that signature. Hi Paul, "modify: replace" entries should result in modify_replace_values being called instead, where modify_add_values is called when the mod is LDAP_MOD_ADD (set up from reqMod values starting "attr:+"). Not sure if there is a way to reset the LDAPResult *msg in syncrepl_message_to_op to retrieve the entry from there but that would be the place I'd look when you get a another crash. Regards, --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 31 Mar '17

31 Mar '17

> From: Quanah Gibson-Mount > Sent: Thursday, March 30, 2017 5:16 PM > > 2.4.44+ITS8432. ;) So I think there's something specific to your use case > (the hardest kinds to track down!). * Specific to my use case - check * Not reproducible - check * Only occurs sporadically at randomly dispersed intervals - check Perhaps we've hit a heisenbug ;). I was kind of hoping it would get fixed by accident by other updates in the next release :).

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 31 Mar '17

31 Mar '17

--On Friday, March 31, 2017 1:05 AM +0000 henson(a)acm.org wrote: >> From: Quanah Gibson-Mount >> Sent: Thursday, March 30, 2017 3:14 PM >> >> released. In addition, this very bug report indicates a regression >> between 2.4.44 and what's currently scheduled for 2.4.45, which is >> further reasoning not to release 2.4.45 at this time. > > Hmm, I started seeing this problem when I upgraded from 2.4.43 to > 2.4.44+ITS 8432 patch. I've never run stock 2.4.44; so I can't say > whether this issue would occur without the ITS 8432 patch... Either way, it's a significant regression that needs fixing before I'd be comforable with a 2.4.45 release. Interestingly, I never saw this problem @ Zimbra, even though it is constantly modifying data and has 2.4.44+ITS8432. ;) So I think there's something specific to your use case (the hardest kinds to track down!). --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#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 31 Mar '17

31 Mar '17

> From: Quanah Gibson-Mount > Sent: Thursday, March 30, 2017 3:14 PM > > released. In addition, this very bug report indicates a regression between > 2.4.44 and what's currently scheduled for 2.4.45, which is further > reasoning not to release 2.4.45 at this time. Hmm, I started seeing this problem when I upgraded from 2.4.43 to 2.4.44+ITS 8432 patch. I've never run stock 2.4.44; so I can't say whether this issue would occur without the ITS 8432 patch...

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 31 Mar '17

31 Mar '17

--On Thursday, March 30, 2017 8:20 PM +0000 henson(a)acm.org wrote: >> From: Quanah Gibson-Mount >> Sent: Monday, March 27, 2017 8:09 AM >> >> There's too many outstanding issues to release 2.4.45, including this >> one. > > Well, are those new issues that don't exist in 2.4.44, or simply existing > bugs already in the wild that haven't been fixed? If the former, then > certainly you don't want to release fresh bugs 8-/, but if the latter, it > seems to me that pushing a release that improves the state of production > by fixing some known bugs, even if other existing known bugs still remain > to be quashed, is preferable than leaving a larger number of known bugs > at large on production systems :(. It seems the circular replication bug > is particularly bad, I'm surprised more people aren't having issues with > it. 2.4.43 introduced new bugs and those were continued in 2.4.44. I think it's important that the regressions are addressed before 2.4.45 is released. In addition, this very bug report indicates a regression between 2.4.44 and what's currently scheduled for 2.4.45, which is further reasoning not to release 2.4.45 at this time. --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#8626) TLS trace: SSL3 alert write:fatal:certificate unknown
by quanah＠symas.com 31 Mar '17

31 Mar '17

--On Thursday, March 30, 2017 10:14 AM +0000 anitha.seshadri(a)emc.com wrote: > Could you let us know what we could be missing here? Hello Anitha, It is clearly noted on the ITS submission page that the ITS system is for bug reports only. It is not meant for configuration and usage questions, such as what you have filed. The proper forum for configuration/usage questions is the openldap-technical list: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> I would additionally note that OpenLDAP 2.4.33 is closing in on 5 years old. I would strongly advise upgrading. In addition, you may wish to read over the documentation on certificates: <http://www.openldap.org/doc/admin24/tls.html> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ITS#8626 published: SECURITY: TLS trace: SSL3 alert write:fatal:certificate unknown
by openldap-its＠OpenLDAP.org 30 Mar '17

30 Mar '17

Private ITS#8626 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8626

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by michael＠stroeder.com 30 Mar '17

30 Mar '17

ondra(a)mistotebe.net wrote: > The other reading is "using relax might let you do more, but you still > need the right permissions", which is closer to how manageDSAIt works > and it seems that's what OpenLDAP (but not slapo-constraint) does. The > hassle is that you need to check permissions if you want to follow that > and that's hard to do correctly if you're an overlay. AFAIK using Relax Rules control makes slapd finish a write operation in case a constraintViolation would be returned without this control provided the bound identity has manage privilege (and of course does not hit insufficientAccess before because of missing write privilege). IMO slapo-unique should do the very same. If the behaviour is unclear I'd hack a test configuration. Ciao, Michael.

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by ondra＠mistotebe.net 30 Mar '17

30 Mar '17

On Thu, Mar 30, 2017 at 05:13:47PM +0200, Michael Ströder wrote: > ondra(a)mistotebe.net wrote: >> Given that relax control is still allowed for everyone (and no ACL >> support for controls exists yet), this patch will buy us little. > > Please correct if I'm wrong but AFAIK you need 'manage' privilege to circumvent > constraints (e.g. slapo-constraint and slapo-ppolicy). You don't need to be granted ACL_MANAGE to bypass slapo-constraint. Just your providing -e '!relax' will do. Just that some features and operations (add/rename) are protected by an additional ACL_MANAGE check if you run with the relax control so they will fail unless you have that privilege. I guess there is some room in the interpretation of what draft-zeilenga-ldap-relax-01 says: "[it is] expected that use of this extension will be restricted by administrative and/or access controls" One options is that if you specify the control, especially since you have to make it critical, you should qualify for administrative permissions on that operation or have it fail regardless of whether it would ordinarily succeed. If OpenLDAP backends adhered to that reading, constraint would do the right thing now and unique would as well with the patches I provided. The other reading is "using relax might let you do more, but you still need the right permissions", which is closer to how manageDSAIt works and it seems that's what OpenLDAP (but not slapo-constraint) does. The hassle is that you need to check permissions if you want to follow that and that's hard to do correctly if you're an overlay. -- 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#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 30 Mar '17

30 Mar '17

> From: Ond=F8ej Kuzn=EDk > Sent: Monday, March 27, 2017 8:10 AM >=20 > I've had a look whether I could reproduce the issue somehow and there = is > a potential crasher if the accesslog entry contained "reqmod: > eduPersonAffiliation:+". Can you confirm whether you have entries like > this in your logdb? There aren't currently any entries like that in the log, although the = last crash was a week or two ago. I will check again right after the next = crash. However, here is one of the log entries that appeared to correlate with = what was being processed in the backtrace of one of the crashes: dn: reqStart=3D20170214120013.000001Z,cn=3Daccesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170214120013.000001Z reqEnd: 20170214120013.000002Z reqType: modify reqSession: 37859 reqAuthzID: cn=3Didmgmt,ou=3Duser,ou=3Dservice,dc=3Dcsupomona,dc=3Dedu reqDN: uid=3Dvntruong,ou=3Duser,dc=3Dcsupomona,dc=3Dedu reqResult: 0 reqMod: eduPersonAffiliation:=3D reqMod: eduPersonPrimaryAffiliation:=3D reqMod: csupomonaEduPersonAffiliation:=3D reqMod: entryCSN:=3D 20170214120013.628665Z#000000#000#000000 reqMod: modifiersName:=3D = cn=3Didmgmt,ou=3Duser,ou=3Dservice,dc=3Dcsupomona,dc=3Dedu reqMod: modifyTimestamp:=3D 20170214120013Z reqEntryUUID: bd5ba51c-7a1b-4bdb-8bf3-fe90552f5909 entryCSN: 20170214120013.628665Z#000000#000#000000 entryUUID: 4737c48c-e46e-45a4-ba4b-2eb61540b27b creatorsName: cn=3Daccesslog createTimestamp: 20170214120013Z modifiersName: cn=3Daccesslog modifyTimestamp: 20170214120013Z And it does not appear to have that signature. Thanks.

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 30 Mar '17

30 Mar '17

> From: Quanah Gibson-Mount > Sent: Monday, March 27, 2017 8:09 AM > > There's too many outstanding issues to release 2.4.45, including this one. Well, are those new issues that don't exist in 2.4.44, or simply existing bugs already in the wild that haven't been fixed? If the former, then certainly you don't want to release fresh bugs 8-/, but if the latter, it seems to me that pushing a release that improves the state of production by fixing some known bugs, even if other existing known bugs still remain to be quashed, is preferable than leaving a larger number of known bugs at large on production systems :(. It seems the circular replication bug is particularly bad, I'm surprised more people aren't having issues with it. > I would consider at least the patch for ITS#8413 as mandatory as well. Hmm, I haven't run into that one yet myself, but thanks for the pointer.

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by michael＠stroeder.com 30 Mar '17

30 Mar '17

ondra(a)mistotebe.net wrote: > Given that relax control is still allowed for everyone (and no ACL > support for controls exists yet), this patch will buy us little. Please correct if I'm wrong but AFAIK you need 'manage' privilege to circumvent constraints (e.g. slapo-constraint and slapo-ppolicy). Ciao, Michael.

1 0

(ITS#8629) slapauth segfault with GSSAPI + olcAuthzRegexp using internal LDAP search + ppolicy overlay
by clement.oudot＠savoirfairelinux.com 30 Mar '17

30 Mar '17

Full_Name: Clement Oudot Version: 2.4.44 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.248.50.71) Hello, with a simple olcAuthzRegexp configuration like: olcAuthzRegexp: {0}uid=(.*),cn=gssapi,cn=auth ldap:///dc=example,dc=com???(uid=$1) And ppolicy overlay configured, for example like: dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE We have a segfault when running this command: $ /usr/local/openldap/sbin/slapauth -F /home/clement/configuration/openldap/example /slapd.d/ -v coudot -M GSSAPI Here is the GDB backtrace: Program received signal SIGSEGV, Segmentation fault. 0x000000000055644f in ppolicy_restrict (op=0x7fffffffd0e0, rs=0x7fffffffd070) at ppolicy.c:1379 1379 ppolicy.c: Aucun fichier ou dossier de ce type. (gdb) bt #0 0x000000000055644f in ppolicy_restrict (op=0x7fffffffd0e0, rs=0x7fffffffd070) at ppolicy.c:1379 #1 0x00000000004a55ca in overlay_op_walk (op=op@entry=0x7fffffffd0e0, rs=0x7fffffffd070, which=op_search, oi=0xa59ef0, on=0xa571d0) at backover.c:661 #2 0x00000000004a574e in over_op_func (op=0x7fffffffd0e0, rs=<optimized out>, which=<optimized out>) at backover.c:730 #3 0x0000000000487375 in slap_sasl2dn (opx=0x7fffffffd710, saslname=0x0, sasldn=0x7fffffffd310, flags=-16, flags@entry=2) at saslauthz.c:2008 #4 0x000000000048e42b in slap_sasl_getdn (conn=conn@entry=0x7fffffffd450, op=op@entry=0x7fffffffd710, id=id@entry=0x7fffffffd440, user_realm=0x0, dn=dn@entry=0x7fffffffd410, flags=flags@entry=2) at sasl.c:1891 #5 0x00000000004aba73 in do_check (c=c@entry=0x7fffffffd450, op=op@entry=0x7fffffffd710, id=id@entry=0x7fffffffd440) at slapauth.c:44 #6 0x00000000004abe54 in slapauth (argc=<optimized out>, argv=0x7fffffffdcc8) at slapauth.c:161 #7 0x0000000000425e98 in main (argc=7, argv=0x7fffffffdc98) at main.c:664 Note that there is no bug if one of this condition is true: * overlay ppolicy is not configured * olcAuthRegexp does not use internal LDAP search * GSSAPI schema is not requested in slapauth Hope you have enough information in this report. Feel free to ask more if needed.

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by ondra＠mistotebe.net 30 Mar '17

30 Mar '17

On Tue, Sep 22, 2015 at 08:45:12PM +0000, ondra(a)mistotebe.net wrote: > On Tue, Sep 22, 2015 at 09:01:59AM +0000, geert(a)hendrickx.be wrote: >> For clarity I do agree that a control should exist to bypass uniqueness >> (and other) constraints. However I think manageDSAit is not the >> appropriate control by its definition, and also in practice given the >> fact it's set per default by popular client libs. >> >> Relax Rules seems much more appropriate for this use case, as it's intended >> to temporarily relax database constraints, for administrative use only. > > Yes, Relax control is better for manual bypass. We just need to make > sure the original issue that this code was created to address is not > reintroduced. ITS#6641 was put up to allow replication to bypass this > overlay and anything that was already loaded to one master should > happily replicate everywhere else. At that point, manageDSAit was the > only way I could find to distinguish an operation coming from syncrepl, > it seems that the constraint overlay has a more reliable check so that > might be a better idea. > > Patch to that effect is here: > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150922-ITS-8245-unique-rela… Given that relax control is still allowed for everyone (and no ACL support for controls exists yet), this patch will buy us little. I have updated the test suite accordingly so that this can be merged when OpenLDAP is ready: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170330-ITS-8245-unique-rela… -- 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#8266) empty ldapmodify refused with slapo-unique
by geert＠hendrickx.be 30 Mar '17

30 Mar '17

On Thu, Mar 30, 2017 at 12:00:41 +0200, Ondřej Kuzník wrote: > Hi Geert, > the following patch should fix the issue. > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170330a-ITS-8266-Allow-empt… Hi Ondřej, I verified your patch on 2.4.x and it works for me! Thanks, Geert -- geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

1 0

Re: (ITS#8266) empty ldapmodify refused with slapo-unique
by ondra＠mistotebe.net 30 Mar '17

30 Mar '17

On Thu, Oct 08, 2015 at 03:33:28PM +0000, geert(a)hendrickx.be wrote: > When slapo-unique constraints are in effect, it seems empty updates are > no longer allowed: > > $ ldapmodify -x -h localhost -D cn=Manager,dc=my-domain,dc=com -w secret > dn: cn=test1,dc=my-domain,dc=com > changetype: modify > modifying entry "cn=test1,dc=my-domain,dc=com" > ldap_modify: Invalid syntax (21) > additional info: unique_modify() got null op.orm_modlist > > Why is this considered invalid syntax? Without slapo-unique constraint, > empty updates like these are accepted. Hi Geert, the following patch should fix the issue. ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170330a-ITS-8266-Allow-empt… Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#8628) man pages & Makfile updaes for contrib
by peter＠adpm.de 30 Mar '17

30 Mar '17

Full_Name: Peter Marschall Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.130.171.22) Hi, the patches * Peter-Marschall-170330.0001-contrib-smbk5pwd-add-man-page-install-it-too.patch * Peter-Marschall-170330.0002-contrib-lastbind-install-man-page.patch * Peter-Marschall-170330.0003-contrib-passwd-sha2-add-man-page-install-it-too.patch * Peter-Marschall-170330.0004-contrib-adremap-install-man-page.patch * Peter-Marschall-170330.0005-contrib-allop-install-man-page.patch * Peter-Marschall-170330.0006-contrib-cloak-install-man-page.patch * Peter-Marschall-170330.0007-contrib-lastmod-install-man-page.patch * Peter-Marschall-170330.0008-contrib-nops-install-man-page.patch * Peter-Marschall-170330.0009-contrib-nssov-install-man-page.patch * Peter-Marschall-170330.0010-contrib-passwd-add-man-page-slapd-pw-radius.5-instal.patch * Peter-Marschall-170330.0011-contrib-passwd-totp-add-man-page-install-it-too.patch * Peter-Marschall-170330.0012-contrib-passwd-pbkdf2-add-man-page-install-it-too.patch * Peter-Marschall-170330.0013-contrib-passwd-totp-new-Makefile-variables-SSL_LIB-S.patch * Peter-Marschall-170330.0014-contrib-passwd-pbkdf2-new-Makefile-variables-SSL_LIB.patch make sure that * existing man pages for modules in contrib/ are installed with the module * some missing man pages are added to modules in contrib/ * Makefiles in contrib/ use the new Makefile variables SSL_INC & SSL_LIB The attached/mentioned patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter Marschall <peter(a)adpm.de>. I have not assigned rights and/or interest in this work to any party. Copyright 2015-2017 Peter Marschall- Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. Please consider them for inclusion in the next version of OpenLDAP

1 0

Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by ondra＠mistotebe.net 30 Mar '17

30 Mar '17

The patches have been uploaded here: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170330-ITS7100-dds-entryttl… The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Ondřej Kuzník <ondra(a)mistotebe.net>. I have not assigned rights and/or interest in this work to any party. I, Ondřej Kuzník, 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. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

ITS#8626 : TLS trace: SSL3 alert write:fatal:certificate unknown
by Anitha.Seshadri＠dell.com 30 Mar '17

30 Mar '17

--_000_15687A439BFEE848B596FFB9FB92A77B627F577AMX101CL01corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI We are using Openldap 2.4.33 (Linux 64 bit built with RSA MES 3.2.4.3 ) in= our application for LDAP synchronization. We have a customer case where the customer is using a certificate chain. Th= ey have converted the root and intermediate certificates into pem and are u= sing the pem to connect to the lDAP server. We are getting the below error : TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS trace: SSL_connect:SSLv3 process tls extension TLS trace: SSL_connect:SSL3 post/by-pass tls extension processing TLS trace: SSL_connect:SSLv3 read server certificate A TLS certificate verification: depth: 0, err: 0, subject: /CN=3DITSUSRANADC5= 5.na.jnj.com, issuer: /DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA C2 TLS certificate verification: depth: 1, err: 0, subject: /DC=3Dcom/DC=3Djnj= /CN=3DJNJ Internal Online CA C2, issuer: /DC=3DCOM/DC=3DJNJ/CN=3DJNJ Intern= al Root Certification Authority TLS certificate verification: depth: 2, err: 0, subject: /DC=3DCOM/DC=3DJNJ= /CN=3DJNJ Internal Root Certification Authority, issuer: /DC=3DCOM/DC=3DJNJ= /CN=3DJNJ Internal Root Certification Authority TLS trace: SSL3 alert write:fatal:certificate unknown TLS trace: SSL_connect:error in SSL3 certificate verify A TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE= :certificate verify failed (ok). After Calling ldap_int_open_connection rc =3D 0 LDAP_SERVER_DOWN The same certificate (pem) connects perfectly with openssl commands. [dmfs4adm@itsusral00157 ldapdb]$ openssl s_client -CAfile /dmfs4/apps/docum= entum/dba/secure/ldapdb/INT-PROD-Root-Intermedia_0320.pem -connect ITSUSRAN= ADC41.na.j nj.com:3269 CONNECTED(00000003) depth=3D2 DC =3D COM, DC =3D JNJ, CN =3D JNJ Internal Root Certification Au= thority verify return:1 depth=3D1 DC =3D com, DC =3D jnj, CN =3D JNJ Internal Online CA A2 verify return:1 depth=3D0 CN =3D ITSUSRANADC41.na.jnj.com verify return:1 - Certificate chain 0 s:/CN=3DITSUSRANADC41.na.jnj.com i:/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA A2 1 s:/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA A2 i:/DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certification Authority - Server certificate ----BEGIN CERTIFICATE---- MIIG0zCCBbugAwIBAgIKNPjZjAAAANPqDjANBgkqhkiG9w0BAQUFADBOMRMwEQYK CZImiZPyLGQBGRYDY29tMRMwEQYKCZImiZPyLGQBGRYDam5qMSIwIAYDVQQDExlK TkogSW50ZXJuYWwgT25saW5lIENBIEEyMB4XDTE2MDkwNjIzMTI0M1oXDTE3MDkw NjIzMTI0M1owIzEhMB8GA1UEAxMYSVRTVVNSQU5BREM0MS5uYS5qbmouY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlmJd7MNGtotF5zXbWJdSaezG LDk1ty98yceBIDz6P1JIYAP84QtEMA+xO3GW7Y+oPjBtMjoEd7P1gLmCVxC9zf69 GNOgYjMsjo4QbynPcgcxMGnpwj8yHQVPLkRe7Do2qpfDz3jhVRT7cJ+u3xu+z66x /JbhCrySeekqL9O6O96YpqMFi+897Lgg9QPphjgrvrD5VmxHfH0V7p7sc/DcIufJ Ifjj7DGotaffcc90VZxj+vQd1iO5AchaDkIUiPLES9AsbcXei8Fau6pcFKpQBh5l fynm73EU01FP+RN//6WpyoIVXVc5uTE9ua7q+O2nGb46FnKlegGpI3iJCh5NJwID AQABo4ID3DCCA9gwOwYJKwYBBAGCNxUHBC4wLAYkKwYBBAGCNxUIgtGfI5rtGIad nTSHnpIqh8HUUmmEo+JQuZUUAgFkAgEFMDMGA1UdJQQsMCoGCCsGAQUFCAICBgor BgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQDAgWgMBgG A1UdIAQRMA8wDQYLYIZIAYb4AgMCAQowQQYJKwYBBAGCNxUKBDQwMjAKBggrBgEF BQgCAjAMBgorBgEEAYI3FAICMAoGCCsGAQUFBwMBMAoGCCsGAQUFBwMCMIGjBgNV HREEgZswgZiCGElUU1VTUkFOQURDNDEubmEuam5qLmNvbYIKbmEuam5qLmNvbYIN bmFkaXIuam5qLmNvbYITbmFsZWdhY3lkaXIuam5qLmNvbYITbmFuZXh0b3NkaXIu am5qLmNvbYIQbmFpY2VkaXIuam5qLmNvbYIUbmFzcGVjaWFsZGlyLmpuai5jb22C D25hZndkaXIuam5qLmNvbTAdBgNVHQ4EFgQU11fVbuyGZpo8ApfMelvW1TFrH3ow HwYDVR0jBBgwFoAUhlNccpOupTSpisgGUUr+XzVQOeEwggEJBgNVHR8EggEAMIH9 MIH6oIH3oIH0hoHKbGRhcDovLy9DTj1KTkolMjBJbnRlcm5hbCUyME9ubGluZSUy MENBJTIwQTIsQ049SVRTVVNSQUpOSkNBMyxDTj1DRFAsQ049UHVibGljJTIwS2V5 JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1qbmos REM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFz cz1jUkxEaXN0cmlidXRpb25Qb2ludIYlaHR0cDovL2ludHByb2Rjcmwuam5qLmNv bS9pbnRjYWEyLmNybDCCAQIGCCsGAQUFBwEBBIH1MIHyMIG8BggrBgEFBQcwAoaB r2xkYXA6Ly8vQ049Sk5KJTIwSW50ZXJuYWwlMjBPbmxpbmUlMjBDQSUyMEEyLENO PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPWpuaixEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29i amVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwMQYIKwYBBQUHMAKGJWh0 dHA6Ly9pbnRwcm9kcGtpLmpuai5jb20vaW50Y2FhMi5wN2MwDQYJKoZIhvcNAQEF BQADggEBAE1hMzal6XiA0Rz1zsTlqAvZiXJg9urK/FcoeL4kiSGCVXQFPYZPRRG7 cwVBTkqABfNvTr2L7WTr2wqZL25HjY4hphK97I4BvCydpQLCEYPiSatY8kFN8Mpu rDTqNlzTEKt7qId9yDrsKmOI+Gs3hHrWPri1fdOeSlkwIUN5gKCwdH/h44LYU8Z5 4tSjWAkh0hkOU0pija45i7tkBzTholXoOEmAmv7G9UlhLuk950yLzu58yW4aBda1 rev0YtUsKjpfSbTWRwcxeYhspcEq2oGYsWD47wLxQJXHUiRWcXyYuOKiQiu4gjZ7 hS9/xvPvJ3zvxHoI7qF4A8VBgF8c4lQ=3D ----END CERTIFICATE---- subject=3D/CN=3DITSUSRANADC41.na.jnj.com issuer=3D/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA A2 - Acceptable client certificate CA names /CN=3DITSUSRANADC41.na.jnj.com /C=3DSE/O=3DAddTrust AB/OU=3DAddTrust External TTP Network/CN=3DAddTrust Ex= ternal CA Roo t /C=3DUS/O=3DJNJ/OU=3DJNJ Public Key Authorities/CN=3DJNJ 2048bit Root Certi= fication Auth ority /C=3DUS/O=3DJNJ/OU=3DJNJ Public Key Authorities/CN=3DJNJ Root Certification= Authority /DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certification Authority /C=3DUS/O=3DVeriSign, Inc./OU=3DVeriSign Trust Network/OU=3D(c) 2008 VeriSi= gn, Inc. - Fo r authorized use only/CN=3DVeriSign Universal Root Certificat= ion Authority /C=3DUS/O=3DVeriSign, Inc./OU=3DVeriSign Trust Network/OU=3D(c) 2006 VeriSi= gn, Inc. - Fo r authorized use only/CN=3DVeriSign Class 3 Public Primary Ce= rtification Authority - G5 /C=3DUS/O=3DVeriSign, Inc./OU=3DClass 3 Public Primary Certification Author= ity /C=3DUS/O=3DVeriSign, Inc./OU=3DClass 3 Public Primary Certification Author= ity - G2/OU =3D(c) 1998 VeriSign, Inc. - For authorized use only/OU=3DVeriS= ign Trust Network /C=3DUS/ST=3DWashington/L=3DRedmond/O=3DMicrosoft Corporation/CN=3DMicrosof= t Root Certific ate Authority 2011 /C=3DUS/O=3DGTE Corporation/OU=3DGTE CyberTrust Solutions, Inc./CN=3DGTE Cy= berTrust Glob al Root /C=3DIE/O=3DBaltimore/OU=3DCyberTrust/CN=3DBaltimore CyberTrust Root /C=3DUS/ST=3DWashington/L=3DRedmond/O=3DMicrosoft Corporation/CN=3DMicrosof= t Root Certific ate Authority 2010 /O=3DSymantec Corporation/CN=3DSymantec Root CA /OU=3DCopyright (c) 1997 Microsoft Corp./OU=3DMicrosoft Corporation/CN=3DMi= crosoft Roo t Authority /C=3DUS/O=3DSymantec Corporation/CN=3DSymantec Root 2005 CA /DC=3Dcom/DC=3Dmicrosoft/CN=3DMicrosoft Root Certificate Authority /CN=3DNT AUTHORITY - SSL handshake has read 5700 bytes and written 619 bytes - New, TLSv1/SSLv3, Cipher is AES128-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : AES128-SHA256 Session-ID: 743C00003D9B50EAA53C45E670C3E9682DBE86BA873CEA5B35BFB16B7CE5A62= 5 Session-ID-ctx: Master-Key: 0DB1DB6C4E9B3BE57E6E3A38B3A68EACAF96A78650EA978B4A8860B35BBDCCB= 4 61DA777F8C0D83ED53CCFE82748D3F86 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1490103903 Timeout : 300 (sec) Verify return code: 0 (ok) - Could you let us know what we could be missing here? The pem contains certificates JNJ Internal Root Certification Authority and= CN=3DJNJ Internal Online CA C2 .Are we missing anything here? Any help would be greatly appreciated. Thanks Anitha --_000_15687A439BFEE848B596FFB9FB92A77B627F577AMX101CL01corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> HI<o:p></o:p> <o:p> </o:p> We are using Openldap 2.4.33 (Linux 64 bit  bui= lt with RSA MES 3.2.4.3 ) in our application for LDAP synchronization.<o:p>= </o:p> We have a customer case where the customer is using = a certificate chain. They have converted the root and intermediate certific= ates into pem and are using the pem to connect to the lDAP server.<o:p></o:= p> We are getting the below error :<o:p></o:p> <o:p> </o:p> TLS trace: SSL_connect:before/connect initialization= <o:p></o:p> TLS trace: SSL_connect:SSLv3 write client hello A<o:= p></o:p> TLS trace: SSL_connect:SSLv3 read server hello A<o:p= ></o:p> TLS trace: SSL_connect:SSLv3 process tls extension<o= :p></o:p> TLS trace: SSL_connect:SSL3 post/by-pass tls extensi= on processing<o:p></o:p> TLS trace: SSL_connect:SSLv3 read server certificate= A<o:p></o:p> TLS certificate verification: depth: 0, err: 0, subj= ect: /CN=3DITSUSRANADC55.na.jnj.com, issuer: /DC=3Dcom/DC=3Djnj/CN=3DJNJ In= ternal Online CA C2<o:p></o:p> TLS certificate verification: depth: 1, err: 0, subj= ect: /DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA C2, issuer: /DC=3DCOM/D= C=3DJNJ/CN=3DJNJ Internal Root Certification Authority<o:p></o:p> TLS certificate verification: depth: 2, err: 0, subj= ect: /DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certification Authority, iss= uer: /DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certification Authority<o:p>= </o:p> TLS trace: SSL3 alert write:fatal:certificate unknown<o:p></o:p><= /p> TLS trace: SSL_connect:error in SSL3 certificate verify A<o:p></o:p></sp= an> TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFIC= ATE:certificate verify failed (ok).<o:p></o:p> After Calling ldap_int_open_connection rc =3D 0<o:p>= </o:p> LDAP_SERVER_DOWN<o:p></o:p> <o:p> </o:p> The same certificate (pem) connects perfectly with o= penssl commands.<o:p></o:p> <o:p> </o:p> [dmfs4adm@itsusral00157 ldapdb]$ openssl s_client -CAfile /dmfs4/apps/do= cumentum/dba/secure/ldapdb/INT-PROD-Root-Intermedia_0320.pem -connect ITSUS= RANADC41.na.j nj.com:3269<o:p></o:p> CONNECTED(00000003)<o:p></o:p> depth=3D2 DC =3D COM, DC =3D JNJ, CN =3D JNJ Interna= l Root Certification Authority<o:p></o:p> verify return:1<o:p></o:p> depth=3D1 DC =3D com, DC =3D jnj, CN =3D JNJ Interna= l Online CA A2<o:p></o:p> verify return:1<o:p></o:p> depth=3D0 CN =3D ITSUSRANADC41.na.jnj.com<o:p></o:p>= verify return:1<o:p></o:p> —<o:p></o:p> Certificate chain<o:p></o:p> 0 s:/CN=3DITSUSRANADC41.na.jnj.com<o:p></o:p> i:/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA A2<= o:p></o:p> 1 s:/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online CA A= 2<o:p></o:p> i:/DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certific= ation Authority<o:p></o:p> —<o:p></o:p> Server certificate<o:p></o:p> ----BEGIN CERTIFICATE----<o:p></o:p> MIIG0zCCBbugAwIBAgIKNPjZjAAAANPqDjANBgkqhkiG9w0BAQUF= ADBOMRMwEQYK<o:p></o:p> CZImiZPyLGQBGRYDY29tMRMwEQYKCZImiZPyLGQBGRYDam5qMSIw= IAYDVQQDExlK<o:p></o:p> TkogSW50ZXJuYWwgT25saW5lIENBIEEyMB4XDTE2MDkwNjIzMTI0= M1oXDTE3MDkw<o:p></o:p> NjIzMTI0M1owIzEhMB8GA1UEAxMYSVRTVVNSQU5BREM0MS5uYS5q= bmouY29tMIIB<o:p></o:p> IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlmJd7MNGtotF= 5zXbWJdSaezG<o:p></o:p> LDk1ty98yceBIDz6P1JIYAP84QtEMA+xO3GW7Y+oPjBt= MjoEd7P1gLmCVxC9zf69<o:p></o:p> GNOgYjMsjo4QbynPcgcxMGnpwj8yHQVPLkRe7Do2qpfDz3jhVRT7= cJ+u3xu+z66x<o:p></o:p> /JbhCrySeekqL9O6O96YpqMFi+897Lgg9QPphjgrvrD5VmxH= fH0V7p7sc/DcIufJ<o:p></o:p> Ifjj7DGotaffcc90VZxj+vQd1iO5AchaDkIUiPLES9AsbcXe= i8Fau6pcFKpQBh5l<o:p></o:p> fynm73EU01FP+RN//6WpyoIVXVc5uTE9ua7q+O2nGb46= FnKlegGpI3iJCh5NJwID<o:p></o:p> AQABo4ID3DCCA9gwOwYJKwYBBAGCNxUHBC4wLAYkKwYBBAGCNxUI= gtGfI5rtGIad<o:p></o:p> nTSHnpIqh8HUUmmEo+JQuZUUAgFkAgEFMDMGA1UdJQQsMCoG= CCsGAQUFCAICBgor<o:p></o:p> BgEEAYI3FAICBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/= BAQDAgWgMBgG<o:p></o:p> A1UdIAQRMA8wDQYLYIZIAYb4AgMCAQowQQYJKwYBBAGCNxUKBDQw= MjAKBggrBgEF<o:p></o:p> BQgCAjAMBgorBgEEAYI3FAICMAoGCCsGAQUFBwMBMAoGCCsGAQUF= BwMCMIGjBgNV<o:p></o:p> HREEgZswgZiCGElUU1VTUkFOQURDNDEubmEuam5qLmNvbYIKbmEu= am5qLmNvbYIN<o:p></o:p> bmFkaXIuam5qLmNvbYITbmFsZWdhY3lkaXIuam5qLmNvbYITbmFu= ZXh0b3NkaXIu<o:p></o:p> am5qLmNvbYIQbmFpY2VkaXIuam5qLmNvbYIUbmFzcGVjaWFsZGly= Lmpuai5jb22C<o:p></o:p> D25hZndkaXIuam5qLmNvbTAdBgNVHQ4EFgQU11fVbuyGZpo8ApfM= elvW1TFrH3ow<o:p></o:p> HwYDVR0jBBgwFoAUhlNccpOupTSpisgGUUr+XzVQOeEwggEJ= BgNVHR8EggEAMIH9<o:p></o:p> MIH6oIH3oIH0hoHKbGRhcDovLy9DTj1KTkolMjBJbnRlcm5hbCUy= ME9ubGluZSUy<o:p></o:p> MENBJTIwQTIsQ049SVRTVVNSQUpOSkNBMyxDTj1DRFAsQ049UHVi= bGljJTIwS2V5<o:p></o:p> JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv= bixEQz1qbmos<o:p></o:p> REM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v= YmplY3RDbGFz<o:p></o:p> cz1jUkxEaXN0cmlidXRpb25Qb2ludIYlaHR0cDovL2ludHByb2Rj= cmwuam5qLmNv<o:p></o:p> bS9pbnRjYWEyLmNybDCCAQIGCCsGAQUFBwEBBIH1MIHyMIG8Bggr= BgEFBQcwAoaB<o:p></o:p> r2xkYXA6Ly8vQ049Sk5KJTIwSW50ZXJuYWwlMjBPbmxpbmUlMjBD= QSUyMEEyLENO<o:p></o:p> PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2= aWNlcyxDTj1D<o:p></o:p> b25maWd1cmF0aW9uLERDPWpuaixEQz1jb20/Y0FDZXJ0aWZpY2F0= ZT9iYXNlP29i<o:p></o:p> amVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwMQYIKwYB= BQUHMAKGJWh0<o:p></o:p> dHA6Ly9pbnRwcm9kcGtpLmpuai5jb20vaW50Y2FhMi5wN2MwDQYJ= KoZIhvcNAQEF<o:p></o:p> BQADggEBAE1hMzal6XiA0Rz1zsTlqAvZiXJg9urK/FcoeL4kiSGC= VXQFPYZPRRG7<o:p></o:p> cwVBTkqABfNvTr2L7WTr2wqZL25HjY4hphK97I4BvCydpQLCEYPi= SatY8kFN8Mpu<o:p></o:p> rDTqNlzTEKt7qId9yDrsKmOI+Gs3hHrWPri1fdOeSlkwIUN5= gKCwdH/h44LYU8Z5<o:p></o:p> 4tSjWAkh0hkOU0pija45i7tkBzTholXoOEmAmv7G9UlhLuk950yL= zu58yW4aBda1<o:p></o:p> rev0YtUsKjpfSbTWRwcxeYhspcEq2oGYsWD47wLxQJXHUiRWcXyY= uOKiQiu4gjZ7<o:p></o:p> hS9/xvPvJ3zvxHoI7qF4A8VBgF8c4lQ=3D<o:p></o:p> ----END CERTIFICATE----<o:p></o:p> subject=3D/CN=3DITSUSRANADC41.na.jnj.com<o:p></o:p><= /p> issuer=3D/DC=3Dcom/DC=3Djnj/CN=3DJNJ Internal Online= CA A2<o:p></o:p> —<o:p></o:p> Acceptable client certificate CA names<o:p></o:p></p= > /CN=3DITSUSRANADC41.na.jnj.com<o:p></o:p> /C=3DSE/O=3DAddTrust AB/OU=3DAddTrust External TTP N= etwork/CN=3DAddTrust External CA Roo t<o:p></o:p> /C=3DUS/O=3DJNJ/OU=3DJNJ Public Key Authorities/CN= =3DJNJ 2048bit Root Certification Auth ority<o:p></o:p> /C=3DUS/O=3DJNJ/OU=3DJNJ Public Key Authorities/CN= =3DJNJ Root Certification Authority<o:p></o:p> /DC=3DCOM/DC=3DJNJ/CN=3DJNJ Internal Root Certificat= ion Authority<o:p></o:p> /C=3DUS/O=3DVeriSign, Inc./OU=3DVeriSign Trust Netwo= rk/OU=3D(c) 2008 VeriSign, Inc. - Fo r authorized use only/CN=3DVeriSign Un= iversal Root Certification Authority<o:p></o:p> /C=3DUS/O=3DVeriSign, Inc./OU=3DVeriSign Trust Netwo= rk/OU=3D(c) 2006 VeriSign, Inc. - Fo r authorized use only/CN=3DVeriSign Cl= ass 3 Public Primary Certification Authority - G5<o:p></o:p> /C=3DUS/O=3DVeriSign, Inc./OU=3DClass 3 Public Prima= ry Certification Authority<o:p></o:p> /C=3DUS/O=3DVeriSign, Inc./OU=3DClass 3 Public Prima= ry Certification Authority - G2/OU =3D(c) 1998 VeriSign, Inc. - For authori= zed use only/OU=3DVeriSign Trust Network<o:p></o:p> /C=3DUS/ST=3DWashington/L=3DRedmond/O=3DMicrosoft Co= rporation/CN=3DMicrosoft Root Certific ate Authority 2011<o:p></o:p> /C=3DUS/O=3DGTE Corporation/OU=3DGTE CyberTrust Solu= tions, Inc./CN=3DGTE CyberTrust Glob al Root<o:p></o:p> /C=3DIE/O=3DBaltimore/OU=3DCyberTrust/CN=3DBaltimore= CyberTrust Root<o:p></o:p> /C=3DUS/ST=3DWashington/L=3DRedmond/O=3DMicrosoft Co= rporation/CN=3DMicrosoft Root Certific ate Authority 2010<o:p></o:p> /O=3DSymantec Corporation/CN=3DSymantec Root CA<o:p>= </o:p> /OU=3DCopyright (c) 1997 Microsoft Corp./OU=3DMicros= oft Corporation/CN=3DMicrosoft Roo t Authority<o:p></o:p> /C=3DUS/O=3DSymantec Corporation/CN=3DSymantec Root = 2005 CA<o:p></o:p> /DC=3Dcom/DC=3Dmicrosoft/CN=3DMicrosoft Root Certifi= cate Authority<o:p></o:p> /CN=3DNT AUTHORITY<o:p></o:p> —<o:p></o:p> SSL handshake has read 5700 bytes and written 619 by= tes<o:p></o:p> —<o:p></o:p> New, TLSv1/SSLv3, Cipher is AES128-SHA256<o:p></o:p>= Server public key is 2048 bit<o:p></o:p> Secure Renegotiation IS supported<o:p></o:p> Compression: NONE<o:p></o:p> Expansion: NONE<o:p></o:p> SSL-Session:<o:p></o:p> Protocol : TLSv1.2<o:p></o:p> Cipher : AES128-SHA256<o:p></o:p> Session-ID: 743C00003D9B50EAA53C45E670C3E9682DBE86BA= 873CEA5B35BFB16B7CE5A625<o:p></o:p> Session-ID-ctx:<o:p></o:p> Master-Key: 0DB1DB6C4E9B3BE57E6E3A38B3A68EACAF96A786= 50EA978B4A8860B35BBDCCB4 61DA777F8C0D83ED53CCFE82748D3F86<o:p></o:p> Key-Arg : None<o:p></o:p> Krb5 Principal: None<o:p></o:p> PSK identity: None<o:p></o:p> PSK identity hint: None<o:p></o:p> Start Time: 1490103903<o:p></o:p> Timeout : 300 (sec)<o:p></o:p> Verify return code: 0 (ok)<o:p></o:p> —<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Could you let us know what we could be missing here?= <o:p></o:p> <o:p> </o:p> The pem contains certificates JNJ Internal Root Cert= ification Authority and CN=3DJNJ Internal Online CA C2 .Are we missing &nbs= p;anything here?<o:p></o:p> Any help would be greatly appreciated.<o:p></o:p></p= > <o:p> </o:p> Thanks<o:p></o:p> Anitha<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html> --_000_15687A439BFEE848B596FFB9FB92A77B627F577AMX101CL01corpem_--

1 0

Re: (ITS#8291) ./run -b hdb test007 fails
by ondra＠mistotebe.net 30 Mar '17

30 Mar '17

The patches are available at ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170330-slapmodify-BerkeleyD… -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs