- openldap-bugs - openldap.org

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 18 Jul '19

18 Jul '19

On Thu, Jul 18, 2019 at 08:32:22PM +0100, Howard Chu wrote: > it doesn't support setting > the password using the PasswordModify exop. That seems to imply that users are > required to generate their passwords using some other tool, and set them using a > normal Modify op, but doing so is deprecated. That is correct. > Password changes should only be done > using the PasswordModify exop. I wasn't sure how to do this. My implementation is essentially two password checks in one, so I need a way to tell the data apart. For the check functions this was easy as the OTP key is stored base32 encoded, and the DELIM character should not appear in a base32 string. For actual password input, I don't think I can make that assumption. I think the safest way to hash this scheme would be to have two separate input prompts, but I didn't see in the existing code a provision for this. It's possible I wasn't looking in the right places. If you have any suggestions I'd be happy to try writing that code. -- Greg Veldman IT Infrastructure Services, Purdue University gv(a)purdue.edu | (765)-496-2456

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by quanah＠symas.com 18 Jul '19

18 Jul '19

--On Thursday, July 18, 2019 7:37 PM +0000 gv(a)members.scinet.supercomputing.org wrote: > - Allow the OTP from the previous time window to be accepted, provided > there has been no successful bind in or after that time window. This > avoids false authentication failures if for example the time window rolls > over as the OTP is being entered or transmitted. This should be a configuration item that is an integer value of the number of seconds to allow outside of the timeslice, with 0 meaning only the default time slice is allowed. Allowing people to authenticate outside of the time slice is of course a security issue and should not be allowed by default (So the default value of the parameter should be 0). 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#9055) contrib/slapd-modules/passwd/totp improvements
by hyc＠symas.com 18 Jul '19

18 Jul '19

gv(a)members.scinet.supercomputing.org wrote: > Full_Name: Greg Veldman > Version: HEAD > OS: CentOS 7 > URL: https://scinet.supercomputing.org/~gv/slapd-totp.txt > Submission from: (NULL) (128.210.189.74) > > > Improve the contrib/slapd-modules/passwd/totp module in the following ways: > > - Add support for two-factor (password+OTP) authentication, where password can > be defined via any currently-supported scheme. Your implementation of this feature is problematic, as it doesn't support setting the password using the PasswordModify exop. That seems to imply that users are required to generate their passwords using some other tool, and set them using a normal Modify op, but doing so is deprecated. Password changes should only be done using the PasswordModify exop. -- -- 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#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 18 Jul '19

18 Jul '19

Full_Name: Greg Veldman Version: HEAD OS: CentOS 7 URL: https://scinet.supercomputing.org/~gv/slapd-totp.txt Submission from: (NULL) (128.210.189.74) Improve the contrib/slapd-modules/passwd/totp module in the following ways: - Add support for two-factor (password+OTP) authentication, where password can be defined via any currently-supported scheme. - Allow the OTP from the previous time window to be accepted, provided there has been no successful bind in or after that time window. This avoids false authentication failures if for example the time window rolls over as the OTP is being entered or transmitted. 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 Greg Veldman <gv(a)members.scinet.supercomputing.org>. I have not assigned rights and/or interest in this work to any party. I, Greg Veldman, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by henrik.bohnenkamp＠ionos.com 18 Jul '19

18 Jul '19

On Mon, Jul 15, 2019 at 07:44:05PM +0100, Howard Chu wrote: > Howard Chu wrote: > > Henrik Bohnenkamp wrote: > >> On Mon, Jul 15, 2019 at 02:26:59PM +0100, Howard Chu wrote: > >>> > >>> Fyi, on our problematic test database with 11M entries and 3.7M aliases, a search with -a always , starting from the > >>> DB suffix, took 4 minutes without this patch, and 1235 minutes with this patch. > >>> > >>> Needless to say, that's not looking good. Still checking other test cases. I start to understand why this is the case. I believe that our two approaches to solve the problem each have their Nemesis... I have constructed a test case where the patched slapd needs 2 minutes (1 minute on a repeat) for a search for people objects, but the master branch has yet to finish after 30 minutes (and might not finish today). The test case is modeled similar to what is done in my company: group objects have not only member entries for people, but each member has an alias to the corresponding person object, these aliases being children to the respective group object. Furthermore, subgroups/group inclusion is modeled by adding aliases (also as children) to the group object, pointing to the group objects representing the included groups. So there is some recursive descent to get all person objects of all subgroups. In total I have 5 mio entries, 3 mio of which are aliases. There are no cycles, but in this test case the depth of the recursion is absolutely unrealistic. I believe, in the master-slapd, each step down in the recursion needs a call to mdb_idscope, which in turn goes through all 3 mio aliases to compute the intersection with the scope of the group object (that's what I remember, but I have not looked at the algorithm for a year now). The patch traverses in this case just very small sub-trees (although many of those) to collect the relevant aliases and continues from there. That seems to be much more efficient here. If I understand your description above correctly, my patch sucks with your test case because it does a full traversal of the LDAP tree to collect all aliases ... with 11 mio entries that takes a while. The master branch, however, just computes intersection with the scope once and continues from there, which must be much faster. I actually do not know what to conclude from all this. I wonder however, if a combination of both approaches could be beneficial. With the patch the diskNode of an entry contains not only the number of children in the scope, but also the number of aliases. If the total number of aliases in the database is large, but the search scope is small, the tree traversal might be faster. If the number of entries in the scope is big, and there are aliases in the search scope, the intersection in mdb_idscope might be more efficient. If there are no aliases in the search scope, nothing has to be done at all.

1 0

Re: (ITS#9054) Add support for multiple EECDH curves
by quanah＠symas.com 17 Jul '19

17 Jul '19

--On Tuesday, July 16, 2019 9:45 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.47 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.128.44) > > > Currently OpenLDAP only allows for a single EECDH curve to be configured. > However, OpenSSL 1.0.2 released in January 2015 was the first release to > implement negotiation of supported curves in TLS servers. OpenLDAP needs > updating to support this functionality. tls_dh.c in postfix/src/tls_dh.c gives some insight into how to correctly do this with OpenSSL, in the tls_auto_eecdh_curves fucntion. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9054) Add support for multiple EECDH curves
by quanah＠openldap.org 16 Jul '19

16 Jul '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) Currently OpenLDAP only allows for a single EECDH curve to be configured. However, OpenSSL 1.0.2 released in January 2015 was the first release to implement negotiation of supported curves in TLS servers. OpenLDAP needs updating to support this functionality.

1 0

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by Mark.Cairney＠ed.ac.uk 16 Jul '19

16 Jul '19

Hi Howard, Brilliant- I notice that there's a 2.4.48 RC due out shortly so Ill roll that out on a Dev box and see how it performs. Kind regards, Mark On 15/07/2019 17:07, Howard Chu wrote: > Fyi, we recently revisited this issue and are seeing improved results with > commit e90e8c7d3c12d897bb0584ba04dc519d4f23acf9 in master. > -- /**************************** Mark Cairney ITI Enterprise Services Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk PGP: 0x435A9621 *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by hyc＠symas.com 15 Jul '19

15 Jul '19

This is a multi-part message in MIME format. --------------AED2FFEE73F73B1613190B64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit hyc(a)symas.com wrote: > The tool to generate the test LDIF is attached. It reads an LDIF containing 500,000 users on stdin, and outputs the same LDIF, > with aliases interspersed, on stdout. > Slightly tweaked, creates the alias after the target entry. In case the server does referential integrity on loading. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------AED2FFEE73F73B1613190B64 Content-Type: text/x-csrc; name="mkalias.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mkalias.c" #include <stdio.h> #include <stdlib.h> #include <string.h> #include <time.h> #define NUMUSERS 500000 #define NUMALIASES 30000 #define NUMSUBALIASES 435 #define SUFFIX "dc=example,dc=com" static const char ou1[] = "\ dn: ou=alias1," SUFFIX "\n\ objectclass: top\n\ objectclass: organizationalUnit\n\ ou: alias1\n"; static const char ou2[] = "\ dn: ou=alias2," SUFFIX "\n\ objectclass: top\n\ objectclass: organizationalUnit\n\ ou: alias2\n"; int qcmp(const void *a, const void *b) { const int *i = a, *j = b; return *i - *j; } int main() { char line[1024], dn[1024], *ou; int aliases[NUMALIASES]; int subaliases[NUMSUBALIASES]; int i; int nusers=0, naliases=0, nsubaliases=0, showalias=0; /* select a random subset of users to generate aliases */ srand(time(0L)); for (i=0; i<NUMALIASES; i++) { aliases[i] = rand() % NUMUSERS; } uniq1: qsort(aliases, NUMALIASES, sizeof(int), qcmp); /* make sure they're unique */ for (i=1; i<NUMALIASES; i++) { if (aliases[i-1] == aliases[i]) { aliases[i] = rand() % NUMUSERS; goto uniq1; } } /* select a random susbset of aliases for the target subtree */ for (i=0; i<NUMSUBALIASES; i++) { subaliases[i] = rand() % NUMALIASES; } uniq2: qsort(subaliases, NUMSUBALIASES, sizeof(int), qcmp); /* make sure they're unique */ for (i=1; i<NUMSUBALIASES; i++) { if (subaliases[i-1] == subaliases[i]) { subaliases[i] = rand() % NUMALIASES; goto uniq2; } } for (i=0; i<NUMSUBALIASES; i++) { subaliases[i] = aliases[subaliases[i]]; } /* read LDIF */ while (fgets(line, sizeof(line), stdin) != NULL) { if (line[0] == '#') continue; if (!strncmp(line, "dn: ", 4)) { /* we assume all users' DNs use uid for RDN */ if (!strncmp(line+4, "uid=", 4)) { if (!nusers) { puts(ou1); puts(ou2); } if (showalias) { printf("dn: uid=x.%d,ou=%s," SUFFIX "\n", nusers, ou); puts("objectclass: alias"); puts("objectclass: extensibleObject"); printf("aliasedObjectName: %s\n", dn); showalias = 0; } if (nusers == aliases[naliases] || nusers == subaliases[nsubaliases]) { if (nusers == subaliases[nsubaliases]) { ou = "alias2"; nsubaliases++; } else { ou = "alias1"; } naliases++; strcpy(dn, line+4); showalias = 1; } nusers++; } } fputs(line, stdout); } return 0; } --------------AED2FFEE73F73B1613190B64--

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by hyc＠symas.com 15 Jul '19

15 Jul '19

This is a multi-part message in MIME format. --------------0F1DE22CD9273A65E1AE5118 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Howard Chu wrote: > Henrik Bohnenkamp wrote: >> On Mon, Jul 15, 2019 at 02:26:59PM +0100, Howard Chu wrote: >>> >>> Fyi, on our problematic test database with 11M entries and 3.7M aliases, a search with -a always , starting from the >>> DB suffix, took 4 minutes without this patch, and 1235 minutes with this patch. >>> >>> Needless to say, that's not looking good. Still checking other test cases. >> >> Interesting, so the behavior is reversed now :-). I assume you have >> found an alternative approach to solve the problem. That's fine with >> me, I want the problem solved, not my patch integrated. I'm of course >> interested in how you do it. Surely you did not get the 4 minutes with >> a stock 2.4.48 slapd? > > For this size of DB we needed the ITS#8977 patches to accommodate larger IDLs. > (I used 24 bits for IDLs, 16.7M slots) > Also at this size, the IDL processing itself is the main bottleneck now. We would > need to switch to bitmaps or trees to avoid this bottleneck, but that's also a > much larger change than we can consider for this release. > I've set up a more modest test database along the lines of ITS#7657. It has 500,000 users, 30,000 aliases total, and 435 in ou=alias2 (all the rest under ou=alias1). For unpatched back-mdb: time ../clients/tools/ldapsearch -x -H ldap://:9012 -D cn=manager,dc=example,dc=com -w secret -b ou=alias1,dc=example,dc=com -a always # search result search: 2 result: 0 Success # numResponses: 29567 # numEntries: 29566 real 0m42.504s user 0m1.344s sys 0m2.996s time ../clients/tools/ldapsearch -x -H ldap://:9012 -D cn=manager,dc=example,dc=com -w secret -b ou=alias2,dc=example,dc=com -a always # search result search: 2 result: 0 Success # numResponses: 437 # numEntries: 436 real 0m48.406s user 0m0.040s sys 0m0.076s For back-mdb with e90e8c7d3c12d897bb0584ba04dc519d4f23acf9 time ../clients/tools/ldapsearch -x -H ldap://:9012 -D cn=manager,dc=example,dc=com -w secret -b ou=alias1,dc=example,dc=com -a always # search result search: 2 result: 0 Success # numResponses: 29567 # numEntries: 29566 real 0m5.500s user 0m1.516s sys 0m2.944s time ../clients/tools/ldapsearch -x -H ldap://:9012 -D cn=manager,dc=example,dc=com -w secret -b ou=alias2,dc=example,dc=com -a always # search result search: 2 result: 0 Success # numResponses: 437 # numEntries: 436 real 0m0.399s user 0m0.048s sys 0m0.060s For back-mdb with this ITS#8875 patch time ../clients/tools/ldapsearch -x -H ldap://:9012 -D cn=manager,dc=example,dc=com -w secret -b ou=alias1,dc=example,dc=com -a always # search result search: 2 result: 0 Success # numResponses: 29567 # numEntries: 29566 real 0m6.020s user 0m1.640s sys 0m3.372s time ../clients/tools/ldapsearch -x -H ldap://:9012 -D cn=manager,dc=example,dc=com -w secret -b ou=alias2,dc=example,dc=com -a always # search result search: 2 result: 0 Success # numResponses: 437 # numEntries: 436 real 0m0.203s user 0m0.052s sys 0m0.048s It seems close enough in this case (I didn't do enough repeated runs to average out any measurement error) while the committed patch performs better on the really ugly test case. The tool to generate the test LDIF is attached. It reads an LDIF containing 500,000 users on stdin, and outputs the same LDIF, with aliases interspersed, on stdout. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------0F1DE22CD9273A65E1AE5118 Content-Type: text/x-csrc; name="mkalias.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mkalias.c" #include <stdio.h> #include <stdlib.h> #include <string.h> #include <time.h> #define NUMUSERS 500000 #define NUMALIASES 30000 #define NUMSUBALIASES 435 static const char ou1[] = "\ dn: ou=alias1,dc=example,dc=com\n\ objectclass: top\n\ objectclass: organizationalUnit\n\ ou: alias1\n"; static const char ou2[] = "\ dn: ou=alias2,dc=example,dc=com\n\ objectclass: top\n\ objectclass: organizationalUnit\n\ ou: alias2\n"; int qcmp(const void *a, const void *b) { const int *i = a, *j = b; return *i - *j; } int main() { char line[1024]; int aliases[NUMALIASES]; int subaliases[NUMSUBALIASES]; int i; int gotuser = 0, nusers=0, naliases=0, nsubaliases=0; /* select a random subset of users to generate aliases */ srand(time(0L)); for (i=0; i<NUMALIASES; i++) { aliases[i] = rand() % NUMUSERS; } uniq1: qsort(aliases, NUMALIASES, sizeof(int), qcmp); /* make sure they're unique */ for (i=1; i<NUMALIASES; i++) { if (aliases[i-1] == aliases[i]) { aliases[i] = rand() % NUMUSERS; goto uniq1; } } /* select a radnom susbset of aliases for the target subtree */ for (i=0; i<NUMSUBALIASES; i++) { subaliases[i] = rand() % NUMALIASES; } uniq2: qsort(subaliases, NUMSUBALIASES, sizeof(int), qcmp); /* make sure they're unique */ for (i=1; i<NUMSUBALIASES; i++) { if (subaliases[i-1] == subaliases[i]) { subaliases[i] = rand() % NUMALIASES; goto uniq2; } } for (i=0; i<NUMSUBALIASES; i++) { subaliases[i] = aliases[subaliases[i]]; } while (fgets(line, sizeof(line), stdin) != NULL) { if (line[0] == '#') continue; if (!strncmp(line, "dn: ", 4)) { if (!gotuser) { if (!strncmp(line+4, "uid=", 4)) { gotuser = 1; puts(ou1); puts(ou2); } } else { if (nusers == aliases[naliases] || nusers == subaliases[nsubaliases]) { char *ou; int id; sscanf(line, "dn: uid=user.%d,", &id); if (nusers == subaliases[nsubaliases]) { ou = "alias2"; nsubaliases++; } else { ou = "alias1"; } naliases++; printf("dn: uid=x.%d,ou=%s,dc=example,dc=com\n", id, ou); puts("objectclass: alias"); puts("objectclass: extensibleObject"); printf("aliasedObjectName: %s\n", line+4); } nusers++; } } fputs(line, stdout); } return 0; } --------------0F1DE22CD9273A65E1AE5118--

1 0

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by Howard Chu 15 Jul '19

15 Jul '19

Fyi, we recently revisited this issue and are seeing improved results with commit e90e8c7d3c12d897bb0584ba04dc519d4f23acf9 in master.

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by hyc＠symas.com 15 Jul '19

15 Jul '19

Henrik Bohnenkamp wrote: > On Mon, Jul 15, 2019 at 02:26:59PM +0100, Howard Chu wrote: >> >> Fyi, on our problematic test database with 11M entries and 3.7M aliases, a search with -a always , starting from the >> DB suffix, took 4 minutes without this patch, and 1235 minutes with this patch. >> >> Needless to say, that's not looking good. Still checking other test cases. > > Interesting, so the behavior is reversed now :-). I assume you have > found an alternative approach to solve the problem. That's fine with > me, I want the problem solved, not my patch integrated. I'm of course > interested in how you do it. Surely you did not get the 4 minutes with > a stock 2.4.48 slapd? For this size of DB we needed the ITS#8977 patches to accommodate larger IDLs. (I used 24 bits for IDLs, 16.7M slots) Also at this size, the IDL processing itself is the main bottleneck now. We would need to switch to bitmaps or trees to avoid this bottleneck, but that's also a much larger change than we can consider for this release. -- -- 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#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by henrik.bohnenkamp＠ionos.com 15 Jul '19

15 Jul '19

On Mon, Jul 15, 2019 at 02:26:59PM +0100, Howard Chu wrote: >=20 > Fyi, on our problematic test database with 11M entries and 3.7M aliases, = a search with -a always , starting from the > DB suffix, took 4 minutes without this patch, and 1235 minutes with this = patch. >=20 > Needless to say, that's not looking good. Still checking other test cases. Interesting, so the behavior is reversed now :-). I assume you have found an alternative approach to solve the problem. That's fine with me, I want the problem solved, not my patch integrated. I'm of course interested in how you do it. Surely you did not get the 4 minutes with a stock 2.4.48 slapd?

1 0

Re: Regression after ITS#8427 fix with back-ldap
by ondra＠mistotebe.net 15 Jul '19

15 Jul '19

On Wed, Jul 10, 2019 at 07:02:48PM +0100, Howard Chu wrote: > Ondřej Kuzník wrote: >> On Wed, Jul 10, 2019 at 04:48:55PM +0000, hyc(a)symas.com wrote: >>> ondra(a)mistotebe.net wrote: >>>> On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: >>>>> Hello, >>>>> >>>>> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up >>>>> TLS settings on each reconnection) introduce a regression when the proxy >>>>> connect to the**Backend ldap server via ldaps:// >>>>> >>>>> The relevent part of my config is: >>>>> >>>>> dn: olcDatabase={2}ldap,cn=config >>>>> objectClass: olcDatabaseConfig >>>>> objectClass: olcLDAPConfig >>>>> olcDatabase: {2}ldap >>>>> olcSuffix: dc=local >>>>> olcDbURI: ldaps://ldap.local >>>>> olcDbChaseReferrals: TRUE >>>>> olcDbRebindAsUser: TRUE >>>>> olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt >>>>> olcDbIDAssertAuthzFrom: "*" >>>>> >>>>> (I also tried by setting LDAPTLS_CACERT env var when starting slapd) >>>>> >>>>> On backend ldap server logs, I get the message "TLS negociation failure" >>>> >>>> I've set up a test script here >>>> https://github.com/mistotebe/openldap/tree/its8427-regression >>>> >>>> This runs without issues but if you replace olcDbStartTLS with an >>>> analogous olcDbIDAssertBind in the configs, it seems the CA certificate >>>> is not set for the connection. >>> >>> Then this is a new bug. Clearly the idassert-bind option takes tls_cacert >>> as a parameter, so if it is provided it is expected to be used. >> >> Sure, on idassert connections only, though. When does back-ldap use one? >> I want to edit the linked script to do exercise that so we have a decent >> test for this now. > > idassert is used when you want back-ldap to propagate the incoming client's > identity to the remote server. It affects every operation that a client issues. Had to have a look at the code, so this is what seems to happen and I think the code does what it should regardless of the ITS#8427 patch, see updated test at the same place: https://github.com/mistotebe/openldap/tree/its8427-regression There are three completely separate types of connections as reflected in the configuration: - acl connections ("private" in terms of the code), used for internal operations and anything issued by the rootdn - idassert connections, used when the client identity should be asserted over the other side (bindmethod setting applies or proxyauth is in effect through other means), also currently used for acl connections if acl is unconfigured - normal connections (configured with the tls keyword) All of this should default to the slapd's internal client TLS settings, not sure how exactly that works yet and whether it reflects later changes to the slapd's client settings. So if anything should be shared between all connections, the preferred way should be using global TLS* options if I understand correctly. If different settings need to apply to different ldap backends, they need to be copied over to each option (acl, idassert and tls) that's in effect. There was a slight issue with how late configuration of olcStartTLS might not take effect, that is also handled in the above branch (and master soon after both full make test and make its finish). -- 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#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by hyc＠symas.com 15 Jul '19

15 Jul '19

henrik.bohnenkamp(a)ionos.com wrote: > On Thu, Jun 27, 2019 at 10:34:19PM -0700, Quanah Gibson-Mount wrote: >> --On Sunday, April 07, 2019 10:15 AM +0000 henrik.bohnenkamp(a)ionos.com >> wrote: >> >>> On Thu, Apr 04, 2019 at 05:32:16PM +0100, Howard Chu wrote: >> >> Had a customer who was hitting this issue try out these patches -- It >> greatly decreases the search time (from unknown/infinite to 1 minute). >> Unfortunately slapd then segv's. Working on getting a test database to >> reproduce the issue with for a good backtrace. > > oh, that's too bad. I'd be happy to participate in the bug hunt. May I > ask: which version did your customer use? I have modified the patch to > work with the recent changes on master, but I did not dig in very deep > to understand these changes. So I must admit that these modifications > to the patch are completely untested (except the tests in the tests > subdir). > > Things might work better with the 2.4.46/47 patch, if that is an > option for your customer. > > Wrt getting a test-tree, maybe the python script I have in the github > repo for the patch can provide > one. (https://github.com/hbo/openldap-mdb-deref-problem/blob/master/scripts/write…) > > I'm of course very interested to keep this patch alive, so if you have > details on the segv, please let me know. Fyi, on our problematic test database with 11M entries and 3.7M aliases, a search with -a always , starting from the DB suffix, took 4 minutes without this patch, and 1235 minutes with this patch. Needless to say, that's not looking good. Still checking other test cases. -- -- 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#9053) Ldap synchronization problem
by feng.wang＠iquantex.com 15 Jul '19

15 Jul '19

--_B51161C3-08D0-4E0E-AFBF-4338AF61897D_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Thank you very much for your advice, I will go to implement it. =E5=8F=91=E9=80=81=E8=87=AA Windows 10 =E7=89=88=E9=82=AE=E4=BB=B6=E5=BA=94= =E7=94=A8 =E5=8F=91=E4=BB=B6=E4=BA=BA: Quanah Gibson-Mount =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B47=E6=9C=8815=E6=97=A5 11= :53 =E6=94=B6=E4=BB=B6=E4=BA=BA: feng.wang(a)iquantex.com; openldap-its(a)OpenLDAP.= org =E4=B8=BB=E9=A2=98: Re: (ITS#9053) Ldap synchronization problem --On Monday, July 15, 2019 3:42 AM +0000 feng.wang(a)iquantex.com wrote: > Sorry, take up your precious time. I encountered a problem. In the > openldap HA environment, the update user group found that it was not > synchronized to the client in time (8 hosts, 5 stations, 3 syncs, not > synchronized, waiting for half an hour to complete synchronization). Has > anyone encountered such a problem? And would like to know how to > troubleshoot such problems, I use openldap soon. thank you very much! Hello, The ITS system is for bug reports, not usage issues. Please direct your=20 questions to the openldap-technical @openldap.org mailing list. In=20 addition the version in use, please note whether you are using standard=20 syncrepl or delta-syncrepl, and any relevant configuration information. I= =20 would note that numerous bugs with MMR have been fixed since 2.4.44 and=20 that it is strongly advised to use delta-syncrepl as the replication=20 mechanism if stability is desired. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --_B51161C3-08D0-4E0E-AFBF-4338AF61897D_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DZH-CN link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1> = Thank you very much for your advice, I will go to implement it.<span= lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Arial",sans-serif;colo= r:#777777'><o:p></o:p><o:p> </o:p><= span lang=3DEN-US><o:p> </o:p>=E5=8F= =91=E9=80=81=E8=87=AA Windows 10 =E7=89=88<a href=3D"https://go.microsoft.com/fwlink/?LinkId=3D550986"><s= pan lang=3DEN-US>=E9=82=AE=E4=BB=B6</a></s= pan>=E5=BA=94=E7=94=A8<o:p> </o:p><div style= =3D'mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;= padding:3.0pt 0cm 0cm 0cm'>=E5=8F=91=E4=BB=B6=E4=BA=BA: <a href=3D"mailto:quanah@symas.com">Quanah Gibson-Mount</a><br= >=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2019=E5=B9=B47=E6= =9C=8815=E6=97=A5 11:53 </s= pan>=E6=94=B6=E4=BB=B6=E4=BA=BA: <a href=3D"mailto:feng.wang@iquantex.com">feng.wang(a)iquantex.com<= /a>; <a href=3D"mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org= </a> =E4=B8=BB=E9=A2=98: Re: (ITS#9053) Ldap synchronization problem</div><o:p> </o:p>--On Monday, July 15, 2019 3:42 AM +0000 feng.wang(a)iquantex.com wrote:</sp= an><o:p> </o:p>= > Sorry, take up your precious t= ime. I encountered a problem. In the> openldap HA environment, the update user group found that = it was not> synchroni= zed to the client in time (8 hosts, 5 stations, 3 syncs, not> synchronized, waiting for half an = hour to complete synchronization). Has<span= lang=3DEN-US>> anyone encountered such a problem? And would like to kno= w how to> troubleshoo= t such problems, I use openldap soon. thank you very much!<o:p> </o:p>Hello,<o:p> </o:p>The ITS system is for bug reports, not usage issues.=C2=A0 Please direct = your questions to the op= enldap-technical @openldap.org mailing list.=C2=A0 In addition the version in use, please note wh= ether you are using standard syncrepl or delta-syncrepl, and any relevant configuration information= .=C2=A0 I would note tha= t numerous bugs with MMR have been fixed since 2.4.44 and that it is strongly advised to use delta-= syncrepl as the replication mechanism if stability is desired.<span= lang=3DEN-US><o:p> </o:p>Regards,Quanah<= /span><o:p> </o:p><= /p><o:p> </o:p><o:p> </o:p>--<o:p> </o:p>Quanah Gibson-MountPro= duct ArchitectSymas Corp= orationPackaged, certifi= ed, and supported LDAP solutions powered by OpenLDAP:<http://www.symas.com><o:p> </o:p><o:p> </o:p></div></body></html>= --_B51161C3-08D0-4E0E-AFBF-4338AF61897D_--

1 0

Re: (ITS#9053) Ldap synchronization problem
by quanah＠symas.com 15 Jul '19

15 Jul '19

--On Monday, July 15, 2019 3:42 AM +0000 feng.wang(a)iquantex.com wrote: > Sorry, take up your precious time. I encountered a problem. In the > openldap HA environment, the update user group found that it was not > synchronized to the client in time (8 hosts, 5 stations, 3 syncs, not > synchronized, waiting for half an hour to complete synchronization). Has > anyone encountered such a problem? And would like to know how to > troubleshoot such problems, I use openldap soon. thank you very much! Hello, The ITS system is for bug reports, not usage issues. Please direct your questions to the openldap-technical @openldap.org mailing list. In addition the version in use, please note whether you are using standard syncrepl or delta-syncrepl, and any relevant configuration information. I would note that numerous bugs with MMR have been fixed since 2.4.44 and that it is strongly advised to use delta-syncrepl as the replication mechanism if stability is desired. 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#9053) Ldap synchronization problem
by feng.wang＠iquantex.com 15 Jul '19

15 Jul '19

Full_Name: wangfeng Version: 2.4.44 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2408:84e1:103:3d23:7c55:cd40:7721:3c1e) Sorry, take up your precious time. I encountered a problem. In the openldap HA environment, the update user group found that it was not synchronized to the client in time (8 hosts, 5 stations, 3 syncs, not synchronized, waiting for half an hour to complete synchronization). Has anyone encountered such a problem? And would like to know how to troubleshoot such problems, I use openldap soon. thank you very much!

1 0

Re: Regression after ITS#8427 fix with back-ldap
by hyc＠symas.com 10 Jul '19

10 Jul '19

Ond=C5=99ej Kuzn=C3=ADk wrote: > On Wed, Jul 10, 2019 at 04:48:55PM +0000, hyc(a)symas.com wrote: >> ondra(a)mistotebe.net wrote: >>> On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: >>>> Hello, >>>> >>>> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set= up=20 >>>> TLS settings on each reconnection) introduce a regression when the p= roxy=20 >>>> connect to the**Backend ldap server via ldaps:// >>>> >>>> The relevent part of my config is: >>>> >>>> dn: olcDatabase=3D{2}ldap,cn=3Dconfig >>>> objectClass: olcDatabaseConfig >>>> objectClass: olcLDAPConfig >>>> olcDatabase: {2}ldap >>>> olcSuffix: dc=3Dlocal >>>> olcDbURI: ldaps://ldap.local >>>> olcDbChaseReferrals: TRUE >>>> olcDbRebindAsUser: TRUE >>>> olcDbIDAssertBind: bindmethod=3Dnone tls_cacert=3D/etc/pki/tls/certs= /ca.crt >>>> olcDbIDAssertAuthzFrom: "*" >>>> >>>> (I also tried by setting LDAPTLS_CACERT env var when starting slapd) >>>> >>>> On backend ldap server logs, I get the message "TLS negociation fail= ure" >>> >>> I've set up a test script here >>> https://github.com/mistotebe/openldap/tree/its8427-regression >>> >>> This runs without issues but if you replace olcDbStartTLS with an >>> analogous olcDbIDAssertBind in the configs, it seems the CA certifica= te >>> is not set for the connection. >> >> Then this is a new bug. Clearly the idassert-bind option takes tls_cac= ert >> as a parameter, so if it is provided it is expected to be used. >=20 > Sure, on idassert connections only, though. When does back-ldap use one= ? > I want to edit the linked script to do exercise that so we have a decen= t > test for this now. idassert is used when you want back-ldap to propagate the incoming client= 's identity to the remote server. It affects every operation that a client i= ssues. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Regression after ITS#8427 fix with back-ldap
by ondra＠mistotebe.net 10 Jul '19

10 Jul '19

On Wed, Jul 10, 2019 at 04:48:55PM +0000, hyc(a)symas.com wrote: > ondra(a)mistotebe.net wrote: >> On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: >>> Hello, >>> >>> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up >>> TLS settings on each reconnection) introduce a regression when the proxy >>> connect to the**Backend ldap server via ldaps:// >>> >>> The relevent part of my config is: >>> >>> dn: olcDatabase={2}ldap,cn=config >>> objectClass: olcDatabaseConfig >>> objectClass: olcLDAPConfig >>> olcDatabase: {2}ldap >>> olcSuffix: dc=local >>> olcDbURI: ldaps://ldap.local >>> olcDbChaseReferrals: TRUE >>> olcDbRebindAsUser: TRUE >>> olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt >>> olcDbIDAssertAuthzFrom: "*" >>> >>> (I also tried by setting LDAPTLS_CACERT env var when starting slapd) >>> >>> On backend ldap server logs, I get the message "TLS negociation failure" >> >> I've set up a test script here >> https://github.com/mistotebe/openldap/tree/its8427-regression >> >> This runs without issues but if you replace olcDbStartTLS with an >> analogous olcDbIDAssertBind in the configs, it seems the CA certificate >> is not set for the connection. > > Then this is a new bug. Clearly the idassert-bind option takes tls_cacert > as a parameter, so if it is provided it is expected to be used. Sure, on idassert connections only, though. When does back-ldap use one? I want to edit the linked script to do exercise that so we have a decent test for this now. >> I guess we've introduced a behaviour change with ITS#8427, not sure what >> the documentation implies should happen in these cases, whether the new >> behaviour is inconsistent with it or you've been relying on incorrect >> behaviour that has since been corrected. -- 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: Regression after ITS#8427 fix with back-ldap
by hyc＠symas.com 10 Jul '19

10 Jul '19

ondra(a)mistotebe.net wrote: > On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: >> Hello, >> >> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up >> TLS settings on each reconnection) introduce a regression when the proxy >> connect to the**Backend ldap server via ldaps:// >> >> The relevent part of my config is: >> >> dn: olcDatabase={2}ldap,cn=config >> objectClass: olcDatabaseConfig >> objectClass: olcLDAPConfig >> olcDatabase: {2}ldap >> olcSuffix: dc=local >> olcDbURI: ldaps://ldap.local >> olcDbChaseReferrals: TRUE >> olcDbRebindAsUser: TRUE >> olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt >> olcDbIDAssertAuthzFrom: "*" >> >> (I also tried by setting LDAPTLS_CACERT env var when starting slapd) >> >> On backend ldap server logs, I get the message "TLS negociation failure" > > I've set up a test script here > https://github.com/mistotebe/openldap/tree/its8427-regression > > This runs without issues but if you replace olcDbStartTLS with an > analogous olcDbIDAssertBind in the configs, it seems the CA certificate > is not set for the connection. Then this is a new bug. Clearly the idassert-bind option takes tls_cacert as a parameter, so if it is provided it is expected to be used. > > I guess we've introduced a behaviour change with ITS#8427, not sure what > the documentation implies should happen in these cases, whether the new > behaviour is inconsistent with it or you've been relying on incorrect > behaviour that has since been corrected. > > Regards, > -- -- 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: Regression after ITS#8427 fix with back-ldap
by a.chelouah＠gmail.com 10 Jul '19

10 Jul '19

This is a multi-part message in MIME format. --------------AC617754E4A0ACE1B2AD0EAA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 09/07/2019 à 14:14, ondra(a)mistotebe.net a écrit : > On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: >> Hello, >> >> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up >> TLS settings on each reconnection) introduce a regression when the proxy >> connect to the**Backend ldap server via ldaps:// >> >> The relevent part of my config is: >> >> dn: olcDatabase={2}ldap,cn=config >> objectClass: olcDatabaseConfig >> objectClass: olcLDAPConfig >> olcDatabase: {2}ldap >> olcSuffix: dc=local >> olcDbURI: ldaps://ldap.local >> olcDbChaseReferrals: TRUE >> olcDbRebindAsUser: TRUE >> olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt >> olcDbIDAssertAuthzFrom: "*" >> >> (I also tried by setting LDAPTLS_CACERT env var when starting slapd) >> >> On backend ldap server logs, I get the message "TLS negociation failure" > I've set up a test script here > https://github.com/mistotebe/openldap/tree/its8427-regression > > This runs without issues but if you replace olcDbStartTLS with an > analogous olcDbIDAssertBind in the configs, it seems the CA certificate > is not set for the connection. > > I guess we've introduced a behaviour change with ITS#8427, not sure what > the documentation implies should happen in these cases, whether the new > behaviour is inconsistent with it or you've been relying on incorrect > behaviour that has since been corrected. > > Regards, > I confirm that using the configuration dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=local olcDbURI:ldaps://ldap.local olcDbChaseReferrals: TRUE olcDbRebindAsUser: TRUE olcDbIDAssertAuthzFrom: "*" olcDbStartTLS: ldaps tls_cacert=/etc/pki/tls/certs/ca.crt /i.e/,removing olcDbIDAssertBind, test is running without issue. Regards. --------------AC617754E4A0ACE1B2AD0EAA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">Le 09/07/2019 à 14:14, <a class="moz-txt-link-abbreviated" href="mailto:ondra@mistotebe.net">ondra(a)mistotebe.net</a> a écrit : </div> <blockquote type="cite" cite="mid:E1hkp0a-0005zG-VU@gauss.openldap.net"> <pre class="moz-quote-pre" wrap="">On Thu, Jun 27, 2019 at 08:08:19PM +0000, <a class="moz-txt-link-abbreviated" href="mailto:a.chelouah@gmail.com">a.chelouah(a)gmail.com</a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Hello, Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up TLS settings on each reconnection) introduce a regression when the proxy connect to the**Backend ldap server via <a class="moz-txt-link-freetext" href="ldaps://">ldaps://</a> The relevent part of my config is: dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=local olcDbURI: <a class="moz-txt-link-freetext" href="ldaps://ldap.local">ldaps://ldap.local</a> olcDbChaseReferrals: TRUE olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt olcDbIDAssertAuthzFrom: "*" (I also tried by setting LDAPTLS_CACERT env var when starting slapd) On backend ldap server logs, I get the message "TLS negociation failure" </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> I've set up a test script here <a class="moz-txt-link-freetext" href="https://github.com/mistotebe/openldap/tree/its8427-regression">https://github.com/mistotebe/openldap/tree/its8427-regression</a> This runs without issues but if you replace olcDbStartTLS with an analogous olcDbIDAssertBind in the configs, it seems the CA certificate is not set for the connection. I guess we've introduced a behaviour change with ITS#8427, not sure what the documentation implies should happen in these cases, whether the new behaviour is inconsistent with it or you've been relying on incorrect behaviour that has since been corrected. Regards, </pre> </blockquote> I confirm that using the configuration <pre class="moz-quote-pre" wrap="">dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=local olcDbURI: <a class="moz-txt-link-freetext">ldaps://ldap.local</a> olcDbChaseReferrals: TRUE olcDbRebindAsUser: TRUE olcDbIDAssertAuthzFrom: "*" olcDbStartTLS: ldaps tls_cacert=/etc/pki/tls/certs/ca.crt </pre> i.e,removing olcDbIDAssertBind, test is running without issue. <pre class="moz-quote-pre" wrap=""> </pre> Regards. <pre class="moz-quote-pre" wrap=""> </pre> </body> </html> --------------AC617754E4A0ACE1B2AD0EAA--

1 0

Re: Regression after ITS#8427 fix with back-ldap
by ondra＠mistotebe.net 09 Jul '19

09 Jul '19

On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote: > Hello, > > Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up > TLS settings on each reconnection) introduce a regression when the proxy > connect to the**Backend ldap server via ldaps:// > > The relevent part of my config is: > > dn: olcDatabase={2}ldap,cn=config > objectClass: olcDatabaseConfig > objectClass: olcLDAPConfig > olcDatabase: {2}ldap > olcSuffix: dc=local > olcDbURI: ldaps://ldap.local > olcDbChaseReferrals: TRUE > olcDbRebindAsUser: TRUE > olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt > olcDbIDAssertAuthzFrom: "*" > > (I also tried by setting LDAPTLS_CACERT env var when starting slapd) > > On backend ldap server logs, I get the message "TLS negociation failure" I've set up a test script here https://github.com/mistotebe/openldap/tree/its8427-regression This runs without issues but if you replace olcDbStartTLS with an analogous olcDbIDAssertBind in the configs, it seems the CA certificate is not set for the connection. I guess we've introduced a behaviour change with ITS#8427, not sure what the documentation implies should happen in these cases, whether the new behaviour is inconsistent with it or you've been relying on incorrect behaviour that has since been corrected. 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

Re: (ITS#9051) slapo-accesslog fails to log compare, search
by quanah＠symas.com 09 Jul '19

09 Jul '19

--On Monday, July 08, 2019 11:33 PM +0000 quanah(a)openldap.org wrote: Note: compare operations are confirmed also to not log. :~# ldapcompare -Y EXTERNAL -H ldapi:/// cn=admin,dc=rb,dc=symas,dc=net cn:admin TRUE ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=accesslog -LLL dn: cn=accesslog objectClass: auditContainer cn: accesslog dn: reqStart=20190708222217.000000Z,cn=accesslog objectClass: auditBind reqStart: 20190708222217.000000Z reqEnd: 20190708222217.000001Z reqType: bind reqSession: 1014 reqAuthzID: reqDN: cn=admin,dc=rb,dc=symas,dc=net reqResult: 0 reqVersion: 3 reqMethod: SIMPLE dn: reqStart=20190709001033.000000Z,cn=accesslog objectClass: auditBind reqStart: 20190709001033.000000Z reqEnd: 20190709001033.000001Z reqType: bind reqSession: 1019 reqAuthzID: reqDN: cn=admin,dc=rb,dc=symas,dc=net reqResult: 0 reqVersion: 3 reqMethod: SIMPLE --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9051) slapo-accesslog fails to log compare, search
by quanah＠openldap.org 09 Jul '19

09 Jul '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) In testing out various logging scenarios with the accesslog overlay, it has been found that it fails to log certain operations in the underlying accesslog DB. Specifically, it fails to log "reads" or "compare" + "search". It does however log "writes" or "bind". Example configuration: dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap/accesslog olcAddContentAcl: FALSE olcDbIndex: default eq olcDbIndex: objectClass olcDbIndex: entryUUID olcDbIndex: entryCSN olcDbIndex: reqStart olcDbIndex: reqEnd olcDbIndex: reqResult olcDbIndex: reqDN olcDbMaxReaders: 0 olcDbMaxSize: 5120000 olcDbMode: 0600 olcDbNoSync: FALSE olcDbRtxnSize: 10000 olcDbSearchStack: 16 olcLastMod: TRUE olcMaxDerefDepth: 15 olcMonitoring: TRUE olcReadOnly: FALSE olcRootDN: cn=config olcSuffix: cn=accesslog olcSyncUseSubentry: FALSE olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth manage by * break dn: olcOverlay={0}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcAccessLogConfig objectClass: olcOverlayConfig olcAccessLogDB: cn=accesslog olcOverlay: {0}accesslog olcAccessLogOps: reads olcAccessLogOps: writes olcAccessLogPurge: 1+00:00 1+00:00 olcAccessLogSuccess: TRUE Performing a search in this scenario results in nothing logged. Changing it to "reads" only (no writes), nothing logged Changing it to "bind, search, compare", the bind is logged, but nothing else: root@anvil3:~/accesslog-testing# ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=accesslog -LLL -Q dn: cn=accesslog objectClass: auditContainer cn: accesslog dn: reqStart=20190708222217.000000Z,cn=accesslog objectClass: auditBind reqStart: 20190708222217.000000Z reqEnd: 20190708222217.000001Z reqType: bind reqSession: 1014 reqAuthzID: reqDN: cn=admin,dc=rb,dc=symas,dc=net reqResult: 0 reqVersion: 3 reqMethod: SIMPLE Search is clearly logged at STATS level logging: Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 fd=12 ACCEPT from IP=[::1]:51644 (IP=[::]:389) Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 BIND dn="cn=admin,dc=rb,dc=symas,dc=net" method=128 Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 BIND dn="cn=admin,dc=rb,dc=symas,dc=net" mech=SIMPLE ssf=0 Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 RESULT tag=97 err=0 text= Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=1 SRCH base="dc=rb,dc=symas,dc=net" scope=2 deref=0 filter="(objectClass=*)" Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=1 SEARCH RESULT tag=101 err=0 nentries=2 text= Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=2 UNBIND Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 fd=12 closed

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by henrik.bohnenkamp＠ionos.com 08 Jul '19

08 Jul '19

On Thu, Jun 27, 2019 at 10:34:19PM -0700, Quanah Gibson-Mount wrote: > --On Sunday, April 07, 2019 10:15 AM +0000 henrik.bohnenkamp(a)ionos.com > wrote: > > > On Thu, Apr 04, 2019 at 05:32:16PM +0100, Howard Chu wrote: > > Had a customer who was hitting this issue try out these patches -- It > greatly decreases the search time (from unknown/infinite to 1 minute). > Unfortunately slapd then segv's. Working on getting a test database to > reproduce the issue with for a good backtrace. oh, that's too bad. I'd be happy to participate in the bug hunt. May I ask: which version did your customer use? I have modified the patch to work with the recent changes on master, but I did not dig in very deep to understand these changes. So I must admit that these modifications to the patch are completely untested (except the tests in the tests subdir). Things might work better with the 2.4.46/47 patch, if that is an option for your customer. Wrt getting a test-tree, maybe the python script I have in the github repo for the patch can provide one. (https://github.com/hbo/openldap-mdb-deref-problem/blob/master/scripts/write…) I'm of course very interested to keep this patch alive, so if you have details on the segv, please let me know. Henrik > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> -- Dr. rer. nat. Henrik Bohnenkamp Senior Sysadmin IT Operations Monitoring & Infrastructure 1&1 IONOS SE | Brauerstraße 48 | 76135 Karlsruhe | Germany Phone: +49 721 91374 - 4159 E-mail: henrik.bohnenkamp(a)ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.

1 0

ITS#9047 published: SECURITY: Coverity report on LMDB
by openldap-its＠OpenLDAP.org 08 Jul '19

08 Jul '19

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

1 0

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com 08 Jul '19

08 Jul '19

--On Thursday, June 27, 2019 8:56 PM +0000 quanah(a)symas.com wrote: > --On Thursday, June 27, 2019 8:35 PM +0000 hyc(a)symas.com wrote: > >> No, because order is irrelevant for these. > > Cool, thanks! I'll continue on with deeper testing then. :) Given the current implementation of OpenLDAP, this feature is impossible to use w/o recompiling OpenLDAP when a change to the IDL size is made. This is because LDAP_PVT_THREAD_STACK_SIZE must be adjusted as well and that requires a recompile. The default size for LDAP_PVT_THREAD_STACK_SIZE is: ( 1 * 1024 * 1024 * sizeof(void *) ) which works for an IDL size of 16 (2^16) which is 65536. If you change the IDL size, say to 22, then the new IDL size is: 4,194,304. We then use this difference to find the offset we need to adjust LDAP_PVT_THREAD_STACK_SIZE by: 4194304/65536 = 64 So it needs to be 64 time larger: ( 64 * 1024 * 1024 * sizeof(void *) ) Generally, this feature is simply unusuable (currently) as a tunable given the requirement for recompiling OpenLDAP to use it. --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#9045) Crashes in cn=config (test050)
by ondra＠openldap.org 02 Jul '19

02 Jul '19

On Fri, Jun 28, 2019 at 09:49:51AM +0000, ondra(a)openldap.org wrote: > Every so often (roughly once in a thousand runs or so it seems), a server will > crash in test050 on master. This test replicates cn=config which is not > officially supported yet. > > Some output from a gdb session from the core is uploaded here: > ftp://ftp.openldap.org/incoming/test050-crash-master-20190628.txt > > It's not clear to me how attrs_dup has reached the attribute at 0x170b6a8 unless > there was another thread messing with the same structure. str2entry2 is running > in another thread, but I wouldn't think it runs on the same entry? Stuff is > optimised out in this one. Another crash, this time with better logs and an unoptimized binary: ftp://ftp.openldap.org/incoming/test050-crash-20190702.txz Again, attribute is being accessed that seems to have been cleaned and released and another thread is running str2entry2 (on cn=config as well, just with a different pointer), might still be a red herring. 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#9046) Regex Constraint Overlay Error
by mrojo＠gmv.com 01 Jul '19

01 Jul '19

Full_Name: Mar.a Rojo Gonz.lez Version: 2.4.44 OS: CentOS Linux release 7.6.1810 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.0.110.2) Hello, We installed a fresh OpenLDAP server and created the following test backend: # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 a008278f dn: olcDatabase={3}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {3}hdb olcDbDirectory: /var/lib/ldap2 olcSuffix: dc=example,dc=org olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonym ous auth by dn="cn=admin,dc=example,dc=org" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=org" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=org olcRootPW:: e1NTSEF9RnZwTERwWkFQRlhId012TnhBWXpkemY3b0JUN2tNR3M= olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq structuralObjectClass: olcHdbConfig entryUUID: 238efe88-303a-1039-97b5-d1f261d139b7 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20190701105301Z entryCSN: 20190701105301.031755Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20190701105301Z Then we added the following constraint using ldapadd: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap/ olcModuleLoad: constraint.la dn: olcOverlay=constraint,olcDatabase={3}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcConstraintConfig olcOverlay: constraint olcConstraintAttribute: userPassword regex ^[^{].* Finally, we tested some combinations of passwords and constraints (replacing the previous olcConstraintAttribute) and these are the results: # Operation Password Constraint Result 1 ldapmodify hola ^[^{].* err=0 2 ldapmodify {hola ^[^{].* err=19 3 ldappasswd hola ^[^{].* err=19 4 ldappasswd {hola ^[^{].* err=19 5 ldapmodify hola ^[^H].* err=0 6 ldapmodify Hola ^[^H].* err=19 7 ldappasswd hola ^[^H].* err=0 8 ldappasswd Hola ^[^H].* err=0 where the ldapmodify was executed as follows: ldapmodify -x -D "cn=person1,ou=people,dc=example,dc=org" -W Enter LDAP Password: dn: cn=person1,ou=people,dc=example,dc=org changetype: modify replace: userPassword userPassword: hola modifying entry "cn=person1,ou=people,dc=example,dc=org" and ldappasswd was run as such: ldappasswd -x -D "cn=person1,ou=people,dc=example,dc=org" -w pass -a pass -s hola Result: Constraint violation (19) The unexpected results were: # Operation Password Constraint Result 3 ldappasswd hola ^[^{].* err=19 8 ldappasswd Hola ^[^H].* err=0 Here is some sample output from the slapd log files: Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 fd=26 ACCEPT from IP=[::1]:33328 (IP=[::]:389) Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=0 BIND dn="cn=person1,ou=people,dc=example,dc=org" method=128 Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=0 BIND dn="cn=person1,ou=people,dc=example,dc=org" mech=SIMPLE ssf=0 Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=0 RESULT tag=97 err=0 text= Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=1 PASSMOD old new Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=1 RESULT oid= err=19 text=(#001 Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=2 UNBIND Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 fd=26 closed Note the strange text on the RESULT. We consistently found the same error text when we executed executing test #3. Do you know what may be causing this behaviour? Thank you in advance.

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 29 Jun '19

29 Jun '19

Quanah, I can think of three reasons why the patch is causing problems: 1. The patch is three years old and was not validated against the current OpenLDAP version, to which it has been applied. Without additional testing, I am not even sure if the issue that the patch fixes still exists. 2. The patch was not tested in the proxy configuration. 3. The patch changes the way tls_reqcert parameter is handled. It is therefore possible that a setup with an incorrect TLS certificate would stop working. However, that is a general remark and the cause of Abdelkader Chelouah's problems may be entirely different. Unfortunately, I do not feel that I would be able to help with any further work on this patch. Due to the passage of time since this bug was reported, I would need to redo all the work from scratch (my test environment is long gone, and the limited understanding of OpenLDAP internals that I once had, has since faded from my memory). I do not believe that I can afford such an effort, particularly when I worry that the result could be shelved for years again. I would be grateful if others, who are more knowledgeable with OpenLDAP internals, look into this issue. Thank you very much Maciej Puzio

1 0

(ITS#9045) Crashes in cn=config (test050)
by ondra＠openldap.org 28 Jun '19

28 Jun '19

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.10.24.68) Every so often (roughly once in a thousand runs or so it seems), a server will crash in test050 on master. This test replicates cn=config which is not officially supported yet. Some output from a gdb session from the core is uploaded here: ftp://ftp.openldap.org/incoming/test050-crash-master-20190628.txt It's not clear to me how attrs_dup has reached the attribute at 0x170b6a8 unless there was another thread messing with the same structure. str2entry2 is running in another thread, but I wouldn't think it runs on the same entry? Stuff is optimised out in this one.

1 0

(ITS#9044) fanruan
by leo.li＠fanruan.com 28 Jun '19

28 Jun '19

Full_Name: leo.li Version: 2.4.44 OS: CentOS7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (114.223.227.133) I want to deploy Openldap server with the backend of mysql. By following https://gist.github.com/mahirrudin/9b7754e54f1e8e532049484864beba42#file-ub… , Openldap is started but I can't add new records. Log shows, 5d15b75a <<< dnPrettyNormal: <dc=fanruan,dc=com>, <dc=fanruan,dc=com> 5d15b75a ==>backsql_add("dc=fanruan,dc=com") 5d15b75a oc_check_required entry (dc=fanruan,dc=com), objectClass "dcObject" 5d15b75a oc_check_required entry (dc=fanruan,dc=com), objectClass "organization" 5d15b75a oc_check_allowed type "o" 5d15b75a oc_check_allowed type "objectClass" 5d15b75a oc_check_allowed type "structuralObjectClass" 5d15b75a oc_check_allowed type "dc" 5d15b75a backsql_add("dc=fanruan,dc=com"): create procedure is not defined for structuralObjectClass "organization" - aborting 5d15b75a send_ldap_result: conn=1012 op=1 p=3 5d15b75a send_ldap_result: err=53 matched="" text="operation not permitted within namingContext" 5d15b75a send_ldap_response: msgid=2 tag=105 err=53 ber_flush2: 58 bytes to sd 10 5d15b75a <==backsql_add("dc=fanruan,dc=com"): 53 "operation not permitted within namingContext" 5d15b75a connection_get(10) 5d15b75a connection_get(10): got connid=1012 5d15b75a connection_read(10): checking for input on id=1012 ber_get_next ber_get_next: tag 0x30 len 5 contents: 5d15b75a op tag 0x42, time 1561704282 I know I need to configure mysql table but how to do it? Any guide for it ?

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by quanah＠symas.com 28 Jun '19

28 Jun '19

--On Sunday, April 07, 2019 10:15 AM +0000 henrik.bohnenkamp(a)ionos.com wrote: > On Thu, Apr 04, 2019 at 05:32:16PM +0100, Howard Chu wrote: > Hi Howard, > > thanks for your comments. There is now a new version of patches available > in my github repository. Apart from addressing your comments, I have > rebased the patches against the current master branch (quite a lot > activity in the last two months, I have noticed). In particular, the new > function mdb_get_aliases now also uses the global size variables for IDL > dimensions, rather than the previous CPP constants. Had a customer who was hitting this issue try out these patches -- It greatly decreases the search time (from unknown/infinite to 1 minute). Unfortunately slapd then segv's. Working on getting a test database to reproduce the issue with for a good backtrace. --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#8427) Incorrect value of tls_reqcert in syncrepl
by quanah＠symas.com 27 Jun '19

27 Jun '19

Hello, Unfortunately this patch introduces a regression and breaks existing configurations where the protocol in use is ldaps:///. 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: Regression after ITS#8427 fix with back-ldap
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Thursday, June 27, 2019 11:51 PM +0200 Abdelkader Chelouah <a.chelouah(a)gmail.com> wrote: > > I tried with with > > > olcDbStartTLS: ldaps > > > with no success. > > > Logs on the proxy > > > 2019-06-27T20:46:07.602925+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > fd=11 ACCEPT from IP=[::1]:46462 (IP=[::1]:10020) > 2019-06-27T20:46:07.603476+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 BIND dn="uid=alice,ou=people,dc=local" method=128 > 2019-06-27T20:46:07.609212+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 ldap_back_retry: retrying URI="ldaps://arrakis.local:10011" DN="" > 2019-06-27T20:46:07.613435+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 RESULT tag=97 err=52 text=Proxy operation retry failed > 2019-06-27T20:46:07.613968+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=1 UNBIND > 2019-06-27T20:46:07.614264+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > fd=11 closed > > Logs on the backend ldap server > > > 2019-06-27T20:46:07.609971+00:00 arrakis slapd-2.4-aa[14682]: conn=1011 > fd=12 ACCEPT from IP=172.18.0.2:47156 (IP=172.18.0.2:10011) > 2019-06-27T20:46:07.613718+00:00 arrakis slapd-2.4-aa[14682]: conn=1011 > fd=12 closed (TLS negotiation failure) Thanks! Please include the openldap-its list in your replies so that they properly get associated with the relevant ITS. I'll raise this up as a priority for the 2.4.48 release. 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: Regression after ITS#8427 fix with back-ldap
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Thursday, June 27, 2019 9:08 PM +0000 a.chelouah(a)gmail.com wrote: > This is a multi-part message in MIME format. > --------------93F3FA89632EC27DC6224304 > Content-Type: text/plain; charset=utf-8; format=flowed > Content-Transfer-Encoding: 7bit > > Hello, > > Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up > TLS settings on each reconnection) introduce a regression when the proxy > connect to the**Backend ldap server via ldaps:// Thanks for the follow up! It may be useful in the future to participate in the testing calls that are noted on the openldap-devel list as well. Does the issue persist if you set: olcDbStartTLS: ldaps as documented in the slapd-ldap(5) man page? Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Regression after ITS#8427 fix with back-ldap
by a.chelouah＠gmail.com 27 Jun '19

27 Jun '19

This is a multi-part message in MIME format. --------------93F3FA89632EC27DC6224304 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up TLS settings on each reconnection) introduce a regression when the proxy connect to the**Backend ldap server via ldaps:// The relevent part of my config is: dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=local olcDbURI: ldaps://ldap.local olcDbChaseReferrals: TRUE olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt olcDbIDAssertAuthzFrom: "*" (I also tried by setting LDAPTLS_CACERT env var when starting slapd) On backend ldap server logs, I get the message "TLS negociation failure" Regards --------------93F3FA89632EC27DC6224304 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hello, Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up TLS settings on each reconnection) introduce a regression when the proxy connect to the Backend ldap server via <a class="moz-txt-link-freetext" href="ldaps://">ldaps://</a> The relevent part of my config is: dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=local olcDbURI: <a class="moz-txt-link-freetext" href="ldaps://ldap.local">ldaps://ldap.local</a> olcDbChaseReferrals: TRUE olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt olcDbIDAssertAuthzFrom: "*" (I also tried by setting LDAPTLS_CACERT env var when starting slapd) On backend ldap server logs, I get the message "TLS negociation failure" Regards </body> </html> --------------93F3FA89632EC27DC6224304--

1 0

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Thursday, June 27, 2019 8:35 PM +0000 hyc(a)symas.com wrote: > No, because order is irrelevant for these. Cool, thanks! I'll continue on with deeper testing then. :) --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#8977) Make IDL sizes configurable in back-mdb
by hyc＠symas.com 27 Jun '19

27 Jun '19

Quanah Gibson-Mount wrote: > --On Tuesday, June 25, 2019 7:07 PM +0000 quanah(a)symas.com wrote: >=20 >> c) That conversion from slapd.conf to cn=3Dconfig be fixed so that it = works. >=20 >=20 > I'm not entirely sure that the fix that went in for this in ec411582d66= 3667d6b638162db51dfa70f5263d3 is correct.=C2=A0 Specifically, unlike ever= ything else, there is > no associated weight.=C2=A0 If in the future other backends (such as SQ= L, LDAP, etc) support server-wide settings via an olcBackend configuratio= n, the weight would > need to exist. >=20 > root@anvil4:/tmp/q/slapd.d/cn=3Dconfig# ls -l > total 64 > -rw------- 1 root root=C2=A0=C2=A0 448 Jun 27 12:19 'cn=3Dmodule{0}.ldi= f' > drwxr-x--- 2 root root=C2=A0 4096 Jun 27 12:19 'cn=3Dschema' > -rw------- 1 root root 39646 Jun 27 12:19 'cn=3Dschema.ldif' > -rw------- 1 root root=C2=A0=C2=A0 435 Jun 27 12:19 'olcBackend=3Dmdb.l= dif' > -rw------- 1 root root=C2=A0=C2=A0 596 Jun 27 12:19 'olcDatabase=3D{-1}= frontend.ldif' > -rw------- 1 root root=C2=A0=C2=A0 584 Jun 27 12:19 'olcDatabase=3D{0}c= onfig.ldif' > -rw------- 1 root root=C2=A0=C2=A0 859 Jun 27 12:19 'olcDatabase=3D{1}m= db.ldif' >=20 >=20 > I.e., I was rather expecting: >=20 > olcBackend=3D{1}mdb.ldif >=20 > or similar. No, because order is irrelevant for these. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Tuesday, June 25, 2019 7:07 PM +0000 quanah(a)symas.com wrote: > c) That conversion from slapd.conf to cn=config be fixed so that it works. I'm not entirely sure that the fix that went in for this in ec411582d663667d6b638162db51dfa70f5263d3 is correct. Specifically, unlike everything else, there is no associated weight. If in the future other backends (such as SQL, LDAP, etc) support server-wide settings via an olcBackend configuration, the weight would need to exist. root@anvil4:/tmp/q/slapd.d/cn=config# ls -l total 64 -rw------- 1 root root 448 Jun 27 12:19 'cn=module{0}.ldif' drwxr-x--- 2 root root 4096 Jun 27 12:19 'cn=schema' -rw------- 1 root root 39646 Jun 27 12:19 'cn=schema.ldif' -rw------- 1 root root 435 Jun 27 12:19 'olcBackend=mdb.ldif' -rw------- 1 root root 596 Jun 27 12:19 'olcDatabase={-1}frontend.ldif' -rw------- 1 root root 584 Jun 27 12:19 'olcDatabase={0}config.ldif' -rw------- 1 root root 859 Jun 27 12:19 'olcDatabase={1}mdb.ldif' I.e., I was rather expecting: olcBackend={1}mdb.ldif or similar. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9043) Improve loglevel sync logging
by ondra＠openldap.org 26 Jun '19

26 Jun '19

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.10.24.68) The existing replication logs are quite hard to follow. In syncprov, messages about different sessions mingle with no indication where they belong and many important replication decisions are not logged at all. And what is logged is very hard to follow and understand why the provider/consumer does what it does. The following could be done to improve matters: - prepend the request information to syncprov messages - add information to existing messages, especially human-readable commentary that can be followed as a story, giving context in terms of "X happened so doing Y" - log when checkpoints happen, what cookies are generated and why, ... Most of the above is drafted here: https://github.com/mistotebe/openldap/tree/its9043

1 0

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com 25 Jun '19

25 Jun '19

--On Monday, May 06, 2019 9:28 PM +0000 quanah(a)symas.com wrote: To further document the issues after further testing with OpenLDAP master as of 6/25/2019 a) If a value for idlexp is set in a slapd.conf file that is not allowed (< 16 or > 31), converting to cn=config using slaptest will incorrectly report that the target "slapd.d" directory doesn't exist, like: /usr/local/etc/openldap# /usr/local/sbin/slaptest -f slapd.conf -F /tmp/slapd.d slaptest: bad configuration directory! ls -ld /tmp/slapd.d drwxr-xr-x 2 root root 40 Jun 25 17:59 /tmp/slapd.d b) If the idlexp value is corrected to be within the allowed range, the converted cn=config database loses the backend configuration and the idlexp setting: /usr/local/sbin/slaptest -f slapd.conf -F /tmp/slapd.d config file testing succeeded cd /tmp/slapd.d/ find . -type f | xargs grep -i idlexp ./cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgBkAt:12.1 NAME 'olcBkMdbIdlExp' DESC 'Power of 2 u ./cn=config/cn=schema.ldif: onfiguration' SUP olcBackendConfig STRUCTURAL MAY olcBkMdbIdlExp ) No olcBackend... file exists, etc. Suggested remedies: a) The man page documentation be updated to note the limitations on valid ranges for the idlexp setting (16<=x<=31), at least for 64-bit systems. b) slaptest provides a valid error if the idlexp setting is not within the valid range (as opposed to complaining the target directory does not exist, when in fact it does). c) That conversion from slapd.conf to cn=config be fixed so that it works. --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#9042) loglevel setting that allows seeing attribute values for MOD operations
by quanah＠symas.com 25 Jun '19

25 Jun '19

--On Tuesday, June 25, 2019 5:04 PM +0000 quanah(a)openldap.org wrote: > Currently there is no way to see what values a client is providing for a > MOD operation outside of the "packets" debug level. It would be helpful > for debugging purposes where one does not have control of the client to > be able to set a loglevel that would expose this information. STATS2 would be the appropriate loglevel setting. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9042) loglevel setting that allows seeing attribute values for MOD operations
by quanah＠openldap.org 25 Jun '19

25 Jun '19

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) Currently there is no way to see what values a client is providing for a MOD operation outside of the "packets" debug level. It would be helpful for debugging purposes where one does not have control of the client to be able to set a loglevel that would expose this information.

1 0

Re: (ITS#9041) cyrus.c includes limits.h twice
by quanah＠symas.com 25 Jun '19

25 Jun '19

--On Friday, June 21, 2019 10:58 PM +0000 quanah(a)openldap.org wrote: > This should be cleaned up. Fixed in b02807ea2f5eaf85e57e67e5851931a116947b94 --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#7996) Tighten race in ldap_int_initialize
by Armin.Tueting＠tueting-online.com 23 Jun '19

23 Jun '19

Am Freitag, den 21.06.2019, 13:31 +0200 schrieb Ond=C5=99ej Kuzn=C3=ADk: [...] > Hi Armin, Hi Ondrej, > thank you very much for your report, this should now be fixed in master > with commit b2f4cacd4783cfe49370accc712863f9537f9924. I'm not following 'master' - I'm afraid! But, the commit has been merged into 'OPENLDAP_REL_ENG_2_4' and slapd is now serving our requests! So far, so good! Thanks for your effort! >=20 > Regards, Regards, Armin.

1 0

(ITS#9041) cyrus.c includes limits.h twice
by quanah＠openldap.org 21 Jun '19

21 Jun '19

Full_Name: Quanah Gibson-Mount Version: RE24 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) There appear to have been dueling commits on April 10, 2005 and April 9, 2005, so that we get: 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 28)#ifdef HAVE_LIMITS_H 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 29)#include <limits.h> 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 30)#endif 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 31) bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 32)#include "ldap-int.h" bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 33) bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 34)#ifdef HAVE_CYRUS_SASL bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 35) eca819d866 (Howard Chu 2005-04-09 06:41:39 +0000 36)#ifdef HAVE_LIMITS_H eca819d866 (Howard Chu 2005-04-09 06:41:39 +0000 37)#include <limits.h> eca819d866 (Howard Chu 2005-04-09 06:41:39 +0000 38)#endif This should be cleaned up.

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by myk＠mykzilla.org 21 Jun '19

21 Jun '19

After stepping through the test program in a debugger, I see that mdb_page_search returns MDB_NOTFOUND if mc->mc_db->md_root is P_INVALID because the tree is empty. And mdb_cursor_put sets rc to MDB_NO_ROOT if mc->mc_db->md_root is P_INVALID. So that can't be related to the crash, at least not in the instances I'm investigating, because insert_key and insert_data (and hence rc) is always MDB_NOTFOUND in their minidumps when the crash occurs, which can't happen when rc is set to MDB_NO_ROOT. -myk

1 0

Re: (ITS#7996) Tighten race in ldap_int_initialize
by ondra＠mistotebe.net 21 Jun '19

21 Jun '19

On Tue, Jun 18, 2019 at 07:33:48AM +0000, Armin.Tueting(a)tueting-online.com wrote: > Am Montag, den 17.06.2019, 15:40 -0700 schrieb Quanah Gibson-Mount: >> --On Monday, June 17, 2019 7:16 PM +0200 Armin T=C3=BCting=20 >> <Armin.Tueting(a)tueting-online.com> wrote: >>>> I.e., it started and then got as far as reading your ldap.conf file. >>>> What is the contents of ldap.conf? >>> Attached 'ldap.conf'. Nothing unusual... >>> >>>> Have you run the test suite (make test)? Does it pass? fail? >>> Attached 'make_test.txt'. As far as I can see - it has been passed. >> >> Ok, so make test passes without issue, so it would appear there's something >> specific with your configuration that is triggering the problem. Would you >> be able to provide your slapd configuration (minus any passwords and the >> like)? > I'll privately send it to you in a seperate email. > >> >> Additionally, if you could get a full gdb backtrace of the hung slapd=20 >> process that would be useful as well. I.e.: >> >> start up slapd >> gdb /path/to/slapd <pid #> > (gdb) thr apply all bt full > #3 0x00007ffa4a92a135 in ldap_pvt_thread_mutex_lock > #4 0x00007ffa4a944e6e in ldap_set_option > #5 0x00007ffa4a943ed3 in openldap_ldap_init_w_conf > #6 0x00007ffa4a944318 in openldap_ldap_init_w_sysconf > #8 0x00007ffa4a944e38 in ldap_set_option > #9 0x0000000000413cd6 in main () Hi Armin, thank you very much for your report, this should now be fixed in master with commit b2f4cacd4783cfe49370accc712863f9537f9924. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs