- openldap-bugs - openldap.org

(ITS#6193) OpenLDAP 2.4.16 does not compile on Windows
by frank.offermanns＠caseris.de 02 Jul '09

02 Jul '09

Hello, you are right, the Version 2.4.16 has this problem. I had the same=20 problem. You have to compile the version from CVS HEAD. There the=20 configure file has been fixed. Best regards, Frank Offermanns -- -- Frank Offermanns | Entwicklung | CASERIS GmbH=20 Fon: +49 2402 7654-566 Fax: +49 2402 7654-8566 | E-Mail: Frank.Offermanns(a)caseris.com=20 -- CASERIS GmbH | Am Birkenfeld 1-3 | D-52222 Stolberg Gesch=E4ftsf=FChrer Dipl.-Ing. Stefan Preu=DF | Registergericht: Amtsgerich= t=20 Aachen, HRB 14758 -- CAESAR und CASERIS - Ihr Team f=FCr die Zukunft --

1 0

RE: (ITS#6193) OpenLDAP 2.4.16 does not compile on Windows
by emmanuel.duru＠atosorigin.com 02 Jul '09

02 Jul '09

One just has to patch three makefiles to build this release, that's no problem for me... > -----Message d'origine----- > De=A0: Howard Chu [mailto:hyc@symas.com] > Envoy=E9=A0: jeudi 2 juillet 2009 10:56 > =C0=A0: emmanuel.duru(a)atosorigin.com > Cc=A0: openldap-its(a)openldap.org > Objet=A0: Re: (ITS#6193) OpenLDAP 2.4.16 does not compile on Windows >=20 > emmanuel.duru(a)atosorigin.com wrote: > > Full_Name: Emmanuel Duru > > Version: 2.4.16 > > OS: Windows > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (80.78.0.134) > > > > > > OpenLDAP 2.4.16 does not compile on Windows. > > When compiling liblber and libldap, there are undefined references = to > winsock > > functions. > > The last version I used was OpenLDAP 2.4.13 and it worked fine. > > Comparing both versions, I see that there misses -lws2_32 in liblber = and > libldap > > makefiles in 2.4.16 release. >=20 > That's interesting. At least one other person (ITS#6174) disagrees = with > you. > Seems there's something wrong with your build environment. Since other > folks > are building on Windows, I don't believe this is a bug in OpenLDAP. >=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#6193) OpenLDAP 2.4.16 does not compile on Windows
by hyc＠symas.com 02 Jul '09

02 Jul '09

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.4.16 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.78.0.134) > > > OpenLDAP 2.4.16 does not compile on Windows. > When compiling liblber and libldap, there are undefined references to winsock > functions. > The last version I used was OpenLDAP 2.4.13 and it worked fine. > Comparing both versions, I see that there misses -lws2_32 in liblber and libldap > makefiles in 2.4.16 release. That's interesting. At least one other person (ITS#6174) disagrees with you. Seems there's something wrong with your build environment. Since other folks are building on Windows, I don't believe this is a bug in OpenLDAP. -- -- 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#6193) OpenLDAP 2.4.16 does not compile on Windows
by emmanuel.duru＠atosorigin.com 02 Jul '09

02 Jul '09

Full_Name: Emmanuel Duru Version: 2.4.16 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.134) OpenLDAP 2.4.16 does not compile on Windows. When compiling liblber and libldap, there are undefined references to winsock functions. The last version I used was OpenLDAP 2.4.13 and it worked fine. Comparing both versions, I see that there misses -lws2_32 in liblber and libldap makefiles in 2.4.16 release.

1 0

Re: (ITS#6174) Backtrace for a segfault
by hyc＠symas.com 01 Jul '09

01 Jul '09

Please do not send HTML or MIME emails, the contents are unintelligible. frank.offermanns(a)caseris.de wrote: > Dies ist eine mehrteilige Nachricht im MIME-Format. > --=_alternative 002BEC64C12575DF_= > Content-Type: text/plain; charset="ISO-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hello, > > for this test setup i got an empty database and tried to add 20000 Users=20 > under o=3Dcaesar,ou=3DUsers,o=3Dtestcas at server1 (windos vista) while try= > ing=20 > to add 20000 Users under o=3Dcaesar,ou=3DUsers,o=3Dtestxp at server2 (Windo= > ws=20 > XP). The slapd.exe on the XP Server crashed. Compiled the version from=20 > HEAD with Mingw/MSYS for windows. > - > Frank Offermanns | Entwicklung | CASERIS GmbH=20 > Fon: +49 2402 7654-566 > Fax: +49 2402 7654-8566 | E-Mail: Frank.Offermanns(a)caseris.com=20 > -- > CASERIS GmbH | Am Birkenfeld 1-3 | D-52222 Stolberg > Gesch=E4ftsf=FChrer Dipl.-Ing. Stefan Preu=DF | Registergericht: Amtsgerich= > t=20 > Aachen, HRB 14758 > > --=_alternative 002BEC64C12575DF_= > Content-Type: text/html; charset="ISO-8859-1" > Content-Transfer-Encoding: quoted-printable -- -- 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#6192) OpenLDAP doesn't support SHA-256 signed certificates
by hyc＠symas.com 01 Jul '09

01 Jul '09

sjv(a)genoscope.cns.fr wrote: > Full_Name: Simon Vallet > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.83.221.39) > > > Hi, > > trying to use SHA-256 signed certificates for SSL connections to an OpenLDAP > server leads to the following OpenSSL error messages : > > TLS certificate verification: Error, certificate signature failure > tls_write: want=7, written=7 > 0000: 15 03 01 00 02 02 33 ......3 > TLS trace: SSL3 alert write:fatal:decrypt error > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS: can't connect: error:0D0C50A1:asn1 encoding > routines:ASN1_item_verify:unknown message digest algorithm. > > This is due to OpenLDAP not explicitly enabling SHA-2 ciphers after calling > SSLeay_add_ssl_algorithms(), which only enables some digest algorithms. > > As SHA-256 is becoming more common and as it is, in fact, mandated by TLS 1.2, I > think OpenLDAP should support it. > > For a similar problem, you might want to take a look at > http://bugs.exim.org/show_bug.cgi?id=674 Thanks for the report. I've chosen to call OpenSSL_add_all_digests() in our init. Note that this has no impact on the actual TLS protocol handshake, since OpenSSL still only supports TLSv1.0. -- -- 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#5836) hung writers
by quanah＠zimbra.com 01 Jul '09

01 Jul '09

--On Monday, June 29, 2009 10:15 AM +0200 Jorge Perez Burgos <jorge.perez(a)adaptia.net> wrote: > Hello, > > I still reproduce this problem with 2.4.17-prerelease. I have a client > that request a lof of operations at the same time through a connection. > The slapd seems to overload and finally close the connection sending a > reset to the client and when this happens the connection hungs eating the > CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the > same point of the first trace sent in this report. This should now really be fixed in HEAD and RE24. Please test. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6192) OpenLDAP doesn't support SHA-256 signed certificates
by sjv＠genoscope.cns.fr 01 Jul '09

01 Jul '09

Full_Name: Simon Vallet Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.83.221.39) Hi, trying to use SHA-256 signed certificates for SSL connections to an OpenLDAP server leads to the following OpenSSL error messages : TLS certificate verification: Error, certificate signature failure tls_write: want=7, written=7 0000: 15 03 01 00 02 02 33 ......3 TLS trace: SSL3 alert write:fatal:decrypt error TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm. This is due to OpenLDAP not explicitly enabling SHA-2 ciphers after calling SSLeay_add_ssl_algorithms(), which only enables some digest algorithms. As SHA-256 is becoming more common and as it is, in fact, mandated by TLS 1.2, I think OpenLDAP should support it. For a similar problem, you might want to take a look at http://bugs.exim.org/show_bug.cgi?id=674 Simon

1 0

Re: (ITS#6191) test022-ppolicy failed (exit 21)
by michael＠stroeder.com 01 Jul '09

01 Jul '09

hyc(a)symas.com wrote: > Thanks, fixed in HEAD. Seems to work now. Ciao, Michael.

1 0

Re: (ITS#6084) ppolicy should allow scheduled password expiration
by Guillaume.Rousse＠inria.fr 01 Jul '09

01 Jul '09

Howard Chu a écrit : > Guillaume Rousse wrote: >> Howard Chu a écrit : >>> Since the ppolicy module's behavior is dictated by the Behera draft, any >>> suggestions for changes in this area should probably first be raised on >>> the ietf-ldapext mailing list. >> Right, but openldap implementation already have extension, such >> pwdCheckModule. Additional extension could be implemented, before >> getting standardized. >> >> Also, the ietf-ldapext seems to be an highly-technical list, and I don't >> feel confortable enough to post this kind of request directly there. >> Discussing various limitations of ppolicy among openldap users first >> would probably allow openldap core team to suggest a more polished >> extension request themselves. > > The draft doesn't say anything about setting pwdAccountLockedTime to a > value in the future; since it doesn't preclude it I've fixed up the code > to handle this case. However, it's not a good solution for your purpose, > since the pwdAccountLockedTime value is automatically replaced with the > current time if too many Bind failures occur, and it's automatically > deleted when a password is changed. We'll leave this in HEAD on an > experimental basis for now, until a real solution is spec'd out. Indeed. Moreover, a variable date field is not a practical field for sorting out valid accounts in search requests, for authorization purposes. Anyway, thanks for the change. -- BOFH excuse #320: You've been infected by the Telescoping Hubble virus.

1 0

Re: (ITS#6191) test022-ppolicy failed (exit 21)
by hyc＠symas.com 01 Jul '09

01 Jul '09

Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Howard Chu wrote: >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Ströder >>>>> Version: HEAD synced now >>>>> OS: openSUSE Linux 11.1 >>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>> Submission from: (NULL) (84.163.60.129) >>>> >>>>> Setting up policy state forwarding test... >>>>> Starting slapd consumer on TCP/IP port 9012... >>>>> Configuring syncprov on provider... >>>>> Using ldapsearch to check that slapd is running... >>>>> Waiting 5 seconds for slapd to start... >>>>> Configuring syncrepl on consumer... >>>>> ldapmodify failed (21)! >>>>>>>>>> ./scripts/test022-ppolicy failed (exit 21) >>>>> make[2]: *** [bdb-mod] Error 21 >>>>> make[2]: Leaving directory >>>>> `/usr/src/michael/openldap/HEAD/openldap/tests' >>>>> make[1]: *** [test] Error 2 >>>>> make[1]: Leaving directory >>>>> `/usr/src/michael/openldap/HEAD/openldap/tests' >>>>> make: *** [test] Error 2 >>>> >>>> Please provide a tarball of the testrun directory. >>> >>> Here it is: >>> http://www.stroeder.com/temp/openldap/its-6191-testrun-test022-ppolicy_fail… >>> >> >> Looks like you don't have back-ldap enabled in your slapd. What were >> your configure flags? > > See my build script below (lines wrapped herein). Thanks, fixed in HEAD. -- -- 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#6191) test022-ppolicy failed (exit 21)
by michael＠stroeder.com 01 Jul '09

01 Jul '09

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Ströder >>>> Version: HEAD synced now >>>> OS: openSUSE Linux 11.1 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (84.163.60.129) >>> >>>> Setting up policy state forwarding test... >>>> Starting slapd consumer on TCP/IP port 9012... >>>> Configuring syncprov on provider... >>>> Using ldapsearch to check that slapd is running... >>>> Waiting 5 seconds for slapd to start... >>>> Configuring syncrepl on consumer... >>>> ldapmodify failed (21)! >>>>>>>>> ./scripts/test022-ppolicy failed (exit 21) >>>> make[2]: *** [bdb-mod] Error 21 >>>> make[2]: Leaving directory >>>> `/usr/src/michael/openldap/HEAD/openldap/tests' >>>> make[1]: *** [test] Error 2 >>>> make[1]: Leaving directory >>>> `/usr/src/michael/openldap/HEAD/openldap/tests' >>>> make: *** [test] Error 2 >>> >>> Please provide a tarball of the testrun directory. >> >> Here it is: >> http://www.stroeder.com/temp/openldap/its-6191-testrun-test022-ppolicy_fail… >> > > Looks like you don't have back-ldap enabled in your slapd. What were > your configure flags? See my build script below (lines wrapped herein). Note that this worked until your recent changes to ppolicy. Ciao, Michael. --------------------------- snip --------------------------- OPENLDAP_VERSION=$1 BDB_PREFIX="/dummy" SSL_PREFIX="/dummy" KRB5_PREFIX="/dummy" SASL_PREFIX="/dummy" OPENLDAP_PREFIX="/opt/openldap-${OPENLDAP_VERSION}" export CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER" export CPPFLAGS="-I${SSL_PREFIX}/include -I${BDB_PREFIX}/include -I${KRB5_PREFIX}/include -I${SASL_PREFIX}/include -DDEVEL" #export CPPFLAGS="-I${SSL_PREFIX}/include -I${BDB_PREFIX}/include" export LDFLAGS="-L${BDB_PREFIX}/lib -L${SSL_PREFIX}/lib -L${KRB5_PREFIX}/lib -L${SASL_PREFIX}/lib -Wl,-R${SSL_PREFIX}/lib -Wl,-R${BDB_PREFI X}/lib,-R${SASL_PREFIX}/lib,-R${KRB5_PREFIX}/lib" make distclean ./configure \ --prefix=${OPENLDAP_PREFIX} \ --enable-dynamic=yes \ --enable-ndb=no \ --enable-modules \ --enable-backends=mod \ --enable-overlays=mod \ --enable-perl=no \ --enable-shell=no \ --enable-local=yes \ --enable-slapi=yes \ --with-cyrus-sasl=yes \ --with-kerberos=yes \ --with-tls=yes \ --with-threads=yes \ --with-odbc=auto \ --enable-crypt=yes \ --enable-spasswd=yes \ --enable-lmpasswd=yes \ --enable-shared=yes make depend make ulimit -c unlimited export SLEEP1=7 export SLEEP2=15 export SLAPD_DEBUG=16389 rm ./tests/core.* make test

1 0

Re: (ITS#6191) test022-ppolicy failed (exit 21)
by hyc＠symas.com 01 Jul '09

01 Jul '09

Michael Ströder wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD synced now >>> OS: openSUSE Linux 11.1 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (84.163.60.129) >> >>> Setting up policy state forwarding test... >>> Starting slapd consumer on TCP/IP port 9012... >>> Configuring syncprov on provider... >>> Using ldapsearch to check that slapd is running... >>> Waiting 5 seconds for slapd to start... >>> Configuring syncrepl on consumer... >>> ldapmodify failed (21)! >>>>>>>> ./scripts/test022-ppolicy failed (exit 21) >>> make[2]: *** [bdb-mod] Error 21 >>> make[2]: Leaving directory >>> `/usr/src/michael/openldap/HEAD/openldap/tests' >>> make[1]: *** [test] Error 2 >>> make[1]: Leaving directory >>> `/usr/src/michael/openldap/HEAD/openldap/tests' >>> make: *** [test] Error 2 >> >> Please provide a tarball of the testrun directory. > > Here it is: > http://www.stroeder.com/temp/openldap/its-6191-testrun-test022-ppolicy_fail… Looks like you don't have back-ldap enabled in your slapd. What were your configure flags? -- -- 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#6191) test022-ppolicy failed (exit 21)
by michael＠stroeder.com 01 Jul '09

01 Jul '09

Howard Chu wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD synced now >> OS: openSUSE Linux 11.1 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.60.129) > >> Setting up policy state forwarding test... >> Starting slapd consumer on TCP/IP port 9012... >> Configuring syncprov on provider... >> Using ldapsearch to check that slapd is running... >> Waiting 5 seconds for slapd to start... >> Configuring syncrepl on consumer... >> ldapmodify failed (21)! >>>>>>> ./scripts/test022-ppolicy failed (exit 21) >> make[2]: *** [bdb-mod] Error 21 >> make[2]: Leaving directory >> `/usr/src/michael/openldap/HEAD/openldap/tests' >> make[1]: *** [test] Error 2 >> make[1]: Leaving directory >> `/usr/src/michael/openldap/HEAD/openldap/tests' >> make: *** [test] Error 2 > > Please provide a tarball of the testrun directory. Here it is: http://www.stroeder.com/temp/openldap/its-6191-testrun-test022-ppolicy_fail… Ciao, Michael.

1 0

Re: (ITS#6191) test022-ppolicy failed (exit 21)
by hyc＠symas.com 01 Jul '09

01 Jul '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD synced now > OS: openSUSE Linux 11.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.60.129) > Setting up policy state forwarding test... > Starting slapd consumer on TCP/IP port 9012... > Configuring syncprov on provider... > Using ldapsearch to check that slapd is running... > Waiting 5 seconds for slapd to start... > Configuring syncrepl on consumer... > ldapmodify failed (21)! >>>>>> ./scripts/test022-ppolicy failed (exit 21) > make[2]: *** [bdb-mod] Error 21 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 Please provide a tarball of the testrun directory. -- -- 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#6191) test022-ppolicy failed (exit 21)
by michael＠stroeder.com 01 Jul '09

01 Jul '09

Full_Name: Michael Ströder Version: HEAD synced now OS: openSUSE Linux 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.60.129) >>>>> Starting test022-ppolicy ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Testing account lockout... Waiting 20 seconds for lockout to reset... Testing password expiration Waiting 20 seconds for password to expire... Resetting password to clear expired status Filling password history... Testing password history... Testing forced reset... Clearing forced reset... Testing Safe modify... Testing length requirement... Testing hashed length requirement... Testing multiple password add/modify checks... Setting up policy state forwarding test... Starting slapd consumer on TCP/IP port 9012... Configuring syncprov on provider... Using ldapsearch to check that slapd is running... Waiting 5 seconds for slapd to start... Configuring syncrepl on consumer... ldapmodify failed (21)! >>>>> ./scripts/test022-ppolicy failed (exit 21) make[2]: *** [bdb-mod] Error 21 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6089) connection_destroy() c->c_writers == 0 assertion failure
by jwm＠horde.net 30 Jun '09

30 Jun '09

On Tue, Jun 30, 2009 at 06:05:09PM -0700, Howard Chu wrote: > John Morrissey wrote: > > It's happened once or twice, but it hasn't had much time since this is > > the same machine I just got done chasing the i386 heap fragmentation on. > > Our backtrace/core/BDB harness is still on this slapd, so we should have > > information if it happens again. > > I was able to reproduce this today, a fix is now in HEAD. Please test, > thanks. Sorry Howard, we've retired our i386 machines and haven't seen this with RE24 as of 20090511 on amd64. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#6089) connection_destroy() c->c_writers == 0 assertion failure
by hyc＠symas.com 30 Jun '09

30 Jun '09

John Morrissey wrote: > It's happened once or twice, but it hasn't had much time since this is the > same machine I just got done chasing the i386 heap fragmentation on. Our > backtrace/core/BDB harness is still on this slapd, so we should have > information if it happens again. I was able to reproduce this today, a fix is now in HEAD. Please test, thanks. -- -- 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#6190) back-meta tls start only works when set before any target specification
by stephan.duehr＠dass-it.de 30 Jun '09

30 Jun '09

Full_Name: Stephan Duehr Version: 2.4.16 OS: SLES 10 SP2 URL: Submission from: (NULL) (84.44.166.251) I specified tls start below each target specification and did not find any STARTTLS in the targets log, running at loglevel 256. man slapd-meta says: tls {[try-]start|[try-]propagate} execute the StartTLS extended operation when the connection is initialized; only works if the URI directive protocol scheme is not ldaps://. propagate issues the StartTLS operation only if the original connection did. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is highly deprecated. If set before any target specification, it affects all targets, unless overridden by any per-target directive. So it should work when set for a target. I verified the behavior by removing start tls before any target specfication and setting it below each target, which resulted in not STARTTLS being sent again.

1 0

Re: (ITS#6084) ppolicy should allow scheduled password expiration
by hyc＠symas.com 30 Jun '09

30 Jun '09

Guillaume Rousse wrote: > Howard Chu a écrit : >> Since the ppolicy module's behavior is dictated by the Behera draft, any >> suggestions for changes in this area should probably first be raised on >> the ietf-ldapext mailing list. > Right, but openldap implementation already have extension, such > pwdCheckModule. Additional extension could be implemented, before > getting standardized. > > Also, the ietf-ldapext seems to be an highly-technical list, and I don't > feel confortable enough to post this kind of request directly there. > Discussing various limitations of ppolicy among openldap users first > would probably allow openldap core team to suggest a more polished > extension request themselves. The draft doesn't say anything about setting pwdAccountLockedTime to a value in the future; since it doesn't preclude it I've fixed up the code to handle this case. However, it's not a good solution for your purpose, since the pwdAccountLockedTime value is automatically replaced with the current time if too many Bind failures occur, and it's automatically deleted when a password is changed. We'll leave this in HEAD on an experimental basis for now, until a real solution is spec'd out. -- -- 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#6163) back-sql DoS when searching for empty attr
by stephane.chazelas＠seebyte.com 30 Jun '09

30 Jun '09

Hiya, see also https://bugs.launchpad.net/bugs/382677 Whole text included here: When using the SQL backend, a search like: ldapsearch ... '(cn=)' causes slapd to crash with this error: slapd: /tmp/openldap-2.4.15/servers/slapd/back-sql/search.c:1366: backsql_process_filter_attr: Assertion `0' failed. Looking at the code there, it does a switch(f->f_choice) { .... default: assert(0); } As it happens, in that instance f_choice is something like 0x80a3, that is SLAPD_FILTER_UNDEFINED|LDAP_FILTER_EQUALITY. And the back-sql backend doesn't support that SLAPD_FILTER_UNDEFINED flag like the other backends, hence the abort() on that assert. A work around for that (change in indentation not shown): --- search.c~ 2009-06-01 15:55:16.000000000 +0100 +++ servers/slapd/back-sql/search.c 2009-06-01 17:00:51.000000000 +0100 @@ -717,6 +717,9 @@ goto done; } + if (f->f_choice & SLAPD_FILTER_UNDEFINED) { + rc = -1; + } else { switch( f->f_choice ) { case LDAP_FILTER_OR: rc = backsql_process_filter_list( bsi, f->f_or, @@ -772,6 +775,7 @@ ad = f->f_av_desc; break; } + } if ( rc == -1 ) { goto done; That's only a work around. The fix would be to implement the support for such searches. Best regards, Stephane

1 0

Re: (ITS#6186) sizelimit broken
by h.b.furuseth＠usit.uio.no 29 Jun '09

29 Jun '09

Christian.Fischer(a)fischundfischer.com writes: > Args debugging showed me ors_slimit of 500 in all cases > (servers/slapd/search.c:do_search():123) Note that at this point the fields have just been parsed from the protocol message. So that's the limit as it was sent by the client. (From SIZELIMIT in ldap.conf, maybe?) If the client sends 500, limits_check() should not reset it. -- Hallvard

1 0

Re: (ITS#6186) sizelimit broken
by Christian.Fischer＠fischundfischer.com 29 Jun '09

29 Jun '09

On Monday 29 June 2009, Howard Chu wrote: > Unfortunately not. I was also unable to reproduce this behavior on 2.4.16 > or on current code. Without a clear way to illustrate the problem, we have > nothing to investigate. Yes, I understand this. > Likewise, since you mention that you're running > "patched slapd" we can't help you with that either. The patch sets ors_slimit = 0, nothing else. This is only FYI if someone runs into the same problem. Christian

1 0

Re: (ITS#6186) sizelimit broken
by hyc＠symas.com 29 Jun '09

29 Jun '09

Christian Fischer wrote: > On Wednesday 24 June 2009, Howard Chu wrote: > >> Your explanation is a bit unclear. Please provide an ldapsearch commandline >> that demonstrates the problem with the slapd.conf you provided. >> >> When a given sizelimit is configured on the server, what values of >> sizelimit requested by the client are working correctly or incorrectly? > > Due to all servers run a patched slapd and all are in productive state i've > set up 2 testsystems (provider - consumer). > > I can't reproduce the buggy behavior. > > Let me explain what i have done before submitting the bug report. > > I've set up two slapd in mirrormode and one as proxy and some customer slapd, > all unpatched. After working around ITS#6167 I've initiated the initial > customer replication with the proxy as peer and got a sizelimit of 500. I've > tried replication against one mirror, that failed with sizelimit 500. The > providers sizelimit was set to unlimited. > > I've tried replication with different sizelimit values, 10 gave me 10 entries > back, 500 gave me 500 back, 502 gave me 500 and -1 gave me 500 back. > > Args debugging showed me ors_slimit of 500 in all cases > (servers/slapd/search.c:do_search():123) > > Hope that helps Unfortunately not. I was also unable to reproduce this behavior on 2.4.16 or on current code. Without a clear way to illustrate the problem, we have nothing to investigate. Likewise, since you mention that you're running "patched slapd" we can't help you with that either. -- -- 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#6186) sizelimit broken
by Christian.Fischer＠fischundfischer.com 29 Jun '09

29 Jun '09

On Wednesday 24 June 2009, Howard Chu wrote: > Your explanation is a bit unclear. Please provide an ldapsearch commandline > that demonstrates the problem with the slapd.conf you provided. > > When a given sizelimit is configured on the server, what values of > sizelimit requested by the client are working correctly or incorrectly? Due to all servers run a patched slapd and all are in productive state i've set up 2 testsystems (provider - consumer). I can't reproduce the buggy behavior. Let me explain what i have done before submitting the bug report. I've set up two slapd in mirrormode and one as proxy and some customer slapd, all unpatched. After working around ITS#6167 I've initiated the initial customer replication with the proxy as peer and got a sizelimit of 500. I've tried replication against one mirror, that failed with sizelimit 500. The providers sizelimit was set to unlimited. I've tried replication with different sizelimit values, 10 gave me 10 entries back, 500 gave me 500 back, 502 gave me 500 and -1 gave me 500 back. Args debugging showed me ors_slimit of 500 in all cases (servers/slapd/search.c:do_search():123) Hope that helps Christian

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs