- openldap-bugs - openldap.org

Re: (ITS#7336) Ldapmodify crashes slapd when updating olcTLSVerifyClient attribute via TLS authentication
by ondra＠mistotebe.net 22 Jun '18

22 Jun '18

On Sun, Mar 23, 2014 at 09:32:22AM +0000, ck(a)cksoft.de wrote: > Hi, > > I can confirm that openldap-2.4.39 still has in issue with this. > > When connecting via TLS I tried to modify olcTLSVerifyClient from never > to try with following ldif: > > dn: cn=config > changetype: modify > replace: olcTLSVerifyClient > olcTLSVerifyClient: try > > this caused slapd to hang indefinetely. > > I was able to successfully modify above when connecting without TLS. > > I need to complete my current task but will set up a small proof of > concept later on in my lab. Hi Christian, have you been able to set up a test configuration that reproduces it with latest OpenLDAP? A cursory test here doesn't seem to do anything of the sort. Thanks, -- 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#8868) Inefficiency when processing certain search filters
by quanah＠openldap.org 21 Jun '18

21 Jun '18

Full_Name: Quanah Gibson-Mount Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Certain search filters are not processed efficiently in the back-{bhm}db code base. An example is: "(|(&(subscriberid=1)(objectClass=XYZ))(&(subscriberid=2)(objectClass=XYZ)))" In this situation, the contiguous list of possibilities for the objectClass result gets turned into a range, causing each entry to be examined as a match. This significantly increases CPU load and causes a delay in returning the result. Re-arranging the search in the following manner bypasses this issue: (&(objectClass=XYZ)(|(subscriberid=1)(subscriberid=2)))" General timing with back-mdb: .477 seconds for the expensive search .020 seconds for the optimized search For back-bdb, the timing was: .665 seconds for the expensive search .020 seconds for the optimized search

1 0

Re: (ITS#8867) ldap_sasl_bind_s failed error during replication
by michael＠stroeder.com 21 Jun '18

21 Jun '18

The ITS is for reporting bugs only. Please subscribe to the openldap-technical mailing list and post your usage questions there: https://www.openldap.org/lists/mm/listinfo/openldap-technical Ciao, Michael.

1 0

(ITS#8867) ldap_sasl_bind_s failed error during replication
by appana.anil＠gmail.com 21 Jun '18

21 Jun '18

Full_Name: anil kumar appanna Version: 2.4 OS: RHEL URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (143.112.32.4) I configured multi master replication. The configuration went well without any errors, but the data is not replicated from one server to another one. When i looked at the log file, i am getting the below errors slap_client_connect: URI=ldap://***.com DN="cn=config" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=001 rc -1 retrying slap_client_connect: URI=ldap://***.com DN="cn=ldapadm,dc=****,dc=com" ldap_sasl_bind_s failed (-1) appreciate any quick help. I am very new to openldap.

1 0

Re: (ITS#8842) NULL pointer derefence
by ondra＠mistotebe.net 21 Jun '18

21 Jun '18

On Tue, May 01, 2018 at 08:14:50PM +0000, openldap(a)katzen.cc wrote: > 2 small issues: > I'm keeping it brief, let me know if you need more information. > > A malicious LDAP server or mitm attacker can craft a response that causes the > ldap client to crash. Nothing critical, just a simoke DoS. > [...] > The problem here is that retoid can be NULL after ldap_parse_intermediate() is > called. > > Another NULL pointer dereference caused by a bad response: > [...] > The PoC leads to memcpy being called with a NULL pointer as second argument > (ava->la_value.bv_val) in dn2domain() (libraries/libldap/getdn.c): > > AC_MEMCPY( str, ava->la_value.bv_val, ava->la_value.bv_len + 1); Both are fixed in this branch: https://github.com/mistotebe/openldap/tree/its8842 -- 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#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

On 06/20/2018 01:41 PM, Michael Ströder wrote: > Ouch! This was not yet complete. I'll come up with a new revision soon. Please review this patch: https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-u… Disclaimer: I'm not a C programmer. Thanks for your patience. Ciao, Michael.

1 0

Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

On 06/20/2018 01:26 PM, michael(a)stroeder.com wrote: > Find the patch against master here: > https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-u… Ouch! This was not yet complete. I'll come up with a new revision soon. Ciao, Michael.

1 0

Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

Rationale: This patch is meant to enhance user experience in case a client software is used to maintain data directly via LDAP. This is a real-world issue. Find the patch against master here: https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-u… Also cleanly applies to RE24 and therefore could be easily added to upcoming release 2.4.47. ;-)

1 0

(ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

Full_Name: Version: OS: URL: Submission from: (NULL) (213.240.182.62) See motivation and disclosure considerations in list archive: https://www.openldap.org/lists/openldap-devel/201711/msg00003.html Patch will follow.

1 0

Re: (ITS#8844) LMDB mdb_env_close is unsafe in forked child
by h.b.furuseth＠usit.uio.no 14 Jun '18

14 Jun '18

On 14/06/2018 21:04, Howard Chu wrote: > Hallvard Breien Furuseth wrote: >> On 14/06/2018 20:34, Howard Chu wrote: >>> If there are any table entries under that PID there's no problem >>> removing them. >> >> The problem is that it's arbitrary. Something is exiting without >> clearing its pid slots, and 0.001% of the time this code will catch it. > > Sure. But I don't think it's worthwhile to make a special case here to > skip this step. To my eyes the getpid() is a special case already, to someone trying to understand the code. Though adding a comment could fix that. See below. >> Better to skip this cleanup, or to always do it - but "always" belongs >> in env_open(). If a new env is seeing its pid in use, then it can >> safely clean it out. Last we talked about that, I liked it and you >> did not:-) > > And I don't see any particular reason to add this step. right >>(...) >> Parent, pid P: >> open env A. >> >> Child, pid Q: >> - open and start using env B with the same path. >> - close env A, while B is still open. >> With the new code, this clears pid Q - i.e. B's pids. >> But lmdb.h already lists that as a "don't do that", >> because it also removes B's lock on the lockfile. >> > Yeah, this is still a "don't do that" though, regardless of this > particular ITS. Right. So in summary, there are two cases when getpid() can be there to clean out, and in neither case does it make sense to clean it out. Other than the sense of avoiding one "if () { init two vars; }". I like that better than a comment about not bothering to, but a comment is OK too.

1 0

Re: (ITS#8844) LMDB mdb_env_close is unsafe in forked child
by hyc＠symas.com 14 Jun '18

14 Jun '18

Hallvard Breien Furuseth wrote: > On 14/06/2018 20:34, Howard Chu wrote: >> Hallvard Breien Furuseth wrote: >>> Wait, what? The child didn't write any pids to the table. If >>> there are pids for it to clear, something is wrong. That can be: >> >> No, there most likely aren't PIDs for it to clear. But most importantly, it >> must not clear using env->me_pid since that is still the parent's PID. >> >>> - The pid is from an older run, and the system reused the pid. If we >>> code for this, it should be to clear such pids during mdb_env_open. >>> It gets very arbitrary to clear them when the user does env_close() >>> in the child and the child happens to have the that reused pid. >> >> No. If the system reused the PID then that means the previous owner of that >> PID is dead already anyway. > > Right... > >> If there are any table entries under that PID there's no problem removing them. > > The problem is that it's arbitrary. Something is exiting without > clearing its pid slots, and 0.001% of the time this code will catch it. Sure. But I don't think it's worthwhile to make a special case here to skip this step. > Better to skip this cleanup, or to always do it - but "always" belongs > in env_open(). If a new env is seeing its pid in use, then it can safely > clean it out. Last we talked about that, I liked it and you > did not:-) And I don't see any particular reason to add this step. >>> - The child opened a new MDB_env with the same path, and closes the >>> parent's env afterwards. Don't Do That, users. But what to do in >>> this situation, if we are to have code for it, is to do nothing with >>> the lockfile. Not close it either, since closing it will lose the >>> lock for the env which was opened in the child. >> >> That's a completely different case. This ITS is specifically about a process >> with an open environment that subsequently forks. > > No, I mean: > > Parent, pid P: > open env A. > > Child, pid Q: > - open and start using env B with the same path. > - close env A, while B is still open. > With the new code, this clears pid Q - i.e. B's pids. > But lmdb.h already lists that as a "don't do that", > because it also removes B's lock on the lockfile. > Yeah, this is still a "don't do that" though, regardless of this particular ITS. -- -- 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#8844) LMDB mdb_env_close is unsafe in forked child
by h.b.furuseth＠usit.uio.no 14 Jun '18

14 Jun '18

On 14/06/2018 20:34, Howard Chu wrote: > Hallvard Breien Furuseth wrote: >> Wait, what? The child didn't write any pids to the table. If >> there are pids for it to clear, something is wrong. That can be: > > No, there most likely aren't PIDs for it to clear. But most importantly, > it must not clear using env->me_pid since that is still the parent's PID. > >> - The pid is from an older run, and the system reused the pid. If we >> code for this, it should be to clear such pids during mdb_env_open. >> It gets very arbitrary to clear them when the user does env_close() >> in the child and the child happens to have the that reused pid. > > No. If the system reused the PID then that means the previous owner of > that PID is dead already anyway. Right... > If there are any table entries under > that PID there's no problem removing them. The problem is that it's arbitrary. Something is exiting without clearing its pid slots, and 0.001% of the time this code will catch it. Better to skip this cleanup, or to always do it - but "always" belongs in env_open(). If a new env is seeing its pid in use, then it can safely clean it out. Last we talked about that, I liked it and you did not:-) >> - The child opened a new MDB_env with the same path, and closes the >> parent's env afterwards. Don't Do That, users. But what to do in >> this situation, if we are to have code for it, is to do nothing with >> the lockfile. Not close it either, since closing it will lose the >> lock for the env which was opened in the child. > > That's a completely different case. This ITS is specifically about a > process with an open environment that subsequently forks. No, I mean: Parent, pid P: open env A. Child, pid Q: - open and start using env B with the same path. - close env A, while B is still open. With the new code, this clears pid Q - i.e. B's pids. But lmdb.h already lists that as a "don't do that", because it also removes B's lock on the lockfile.

1 0

Re: (ITS#8844) LMDB mdb_env_close is unsafe in forked child
by hyc＠symas.com 14 Jun '18

14 Jun '18

Hallvard Breien Furuseth wrote: > On 02/05/2018 18:05, hyc(a)openldap.org wrote: >> Following on from ITS#8505. >> mdb_env_close0() uses env->me_pid when clearing the readers table. If the env >> was open in a process that forked, and the child process calls mdb_env_close(), >> it will be clearing the wrong PID. Change this to use getpid() instead. > > Wait, what? The child didn't write any pids to the table. If > there are pids for it to clear, something is wrong. That can be: No, there most likely aren't PIDs for it to clear. But most importantly, it must not clear using env->me_pid since that is still the parent's PID. > - The pid is from an older run, and the system reused the pid. If we > code for this, it should be to clear such pids during mdb_env_open. > It gets very arbitrary to clear them when the user does env_close() > in the child and the child happens to have the that reused pid. No. If the system reused the PID then that means the previous owner of that PID is dead already anyway. If there are any table entries under that PID there's no problem removing them. > - The child opened a new MDB_env with the same path, and closes the > parent's env afterwards. Don't Do That, users. But what to do in > this situation, if we are to have code for it, is to do nothing with > the lockfile. Not close it either, since closing it will lose the > lock for the env which was opened in the child. That's a completely different case. This ITS is specifically about a process with an open environment that subsequently forks. -- -- 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#8865) Publish admin guide in epub format
by dpa-bugs＠aegee.org 11 Jun '18

11 Jun '18

Full_Name: Dilian Palauzov Version: OS: URL: Submission from: (NULL) (87.118.146.153) Please offer the admin guide for downloading also in epub format. The guide is written in sdf, this could be converted to POD and then to EPUB. SDF offers also output in SGML, this can probably be converted to EPUB, too.

1 0

Re: (ITS#8573) ldap* tools should be able to function w/o a conf file
by ondra＠mistotebe.net 11 Jun '18

11 Jun '18

On Mon, Jan 23, 2017 at 11:43:59PM +0000, quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.26) > > > Right now, it is impossible to configure the ldap* command line tools so that > they function in major circumstances w/o also having a configuration file (I.e., > ldap.conf, .ldaprc, etc). For example, the ability to use startTLS with LDAP > requires such a file so that the CA file and/or cert path for the tool can be > defined. > > The "-o" option should be expanded to cover additional configuration parameters > from the conf file, as has already been done with the network timeout parameter. I have updated the documentation to extract the new options into ldap.conf(5) and reference it from each tool instead. The commits at https://github.com/mistotebe/openldap/tree/its8573-tables contain that change. -- 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#8864) ber_realloc doesn't update ber_rwptr
by ondra＠openldap.org 08 Jun '18

08 Jun '18

Full_Name: Ondrej Kuznik Version: master/re24 OS: URL: https://github.com/mistotebe/openldap/tree/ITS8864 Submission from: (NULL) (82.10.24.68) Running a ber_flush that doesn't manage to send everything and then adding data to the BerElement that ends up with its buffer reallocated will not update ber_rwptr, causing the following flush to fail. Patch available at the link above.

1 0

Re: (ITS#8731) Variadic Debug() macro
by ondra＠mistotebe.net 06 Jun '18

06 Jun '18

On Tue, Sep 12, 2017 at 12:55:20PM +0000, okuznik(a)symas.com wrote: > The patch series in the linked archive changes the logging macros to be fully > variadic: There is a new archive at: ftp://ftp.openldap.org/incoming/debug_macro_refactor_v2.tgz This addresses concerns that it should still be possible to build libldap (only) on compilers that might not support variadic macros. All patches are generated from the attached .cocci files against current master (commit 9069cbe543d079e9d7f55162decb8e732fc32338). I would welcome some review of the patch 01-logging.patch, which consists of the actual implementation. Rest is just to bring OpenLDAP up to scratch. At the end of the series, OpenLDAP seems to compile with CFLAGS containing -Werror=format-extra-args. -- 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#8863) openldap compilation failure when
by ramakanth.varala＠gmail.com 06 Jun '18

06 Jun '18

# It's possible (for near-UNIX clones) that sys_errlist doesn't exist if test $ol_cv_dcl_sys_errlist = no ; then above lines are from configure script , i don't want my binaries and libraries do be dependent on the symbols of errlist and nerr . As per mail trace "Re: How to get rid of sys_errlist and sys_nerr? - OpenLDAP" , this issue seems to existing from long back. The solution given is still not working. On 6/6/18, Howard Chu <hyc(a)symas.com> wrote: > ramakanth.varala(a)gmail.com wrote: >> Full_Name: Rama Kanth Varala >> Version: 2.4.46 >> OS: Cent OS Release 5.7 >> URL: ftp://ftp.openldap.org/incoming/openldap-bug.txt >> Submission from: (NULL) (72.163.217.107) >> >> >> I am trying to compile my binaries in a machine with has glibc 2.5 . >> Then i >> take these >> ldap libraries to link with the other process which is getting compiled >> in >> glibc 2.3.4. >> >> I am compiling with option of ol_cv_dcl_sys_errlist=no , so that i can >> disable >> offending symbols (sys_nerr and sys_errlist). configure go smooth but >> compilation fails. >> >> Below is the compilation failure trace. >> >> cc -g -O2 -I../../include -I../../include -I/usr/local/db48/include >> -DLDAP_LIBRARY -c string.c -fPIC -DPIC -o .libs/string.o >> cc -g -O2 -I../../include -I../../include -I/usr/local/db48/include >> -DLDAP_LIBRARY -c string.c -o string.o >/dev/null 2>&1 >> /bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include >> -I../../include -I/usr/local/db48/include -DLDAP_LIBRARY -c >> util-int.c >> cc -g -O2 -I../../include -I../../include -I/usr/local/db48/include >> -DLDAP_LIBRARY -c util-int.c -fPIC -DPIC -o .libs/util-int.o >> In file included from /usr/include/stdio.h:754, >> from /usr/include/resolv.h:64, >> from ../../include/ac/socket.h:58, >> from util-int.c:32: >> /usr/include/bits/sys_errlist.h:27: error: expected identifier or '(' >> before numeric constant >> /usr/include/bits/sys_errlist.h:28: error: expected identifier or '(' >> before 'char' >> /usr/include/bits/sys_errlist.h:28: error: expected ')' before numeric >> constant >> make[2]: *** [util-int.lo] Error 1 >> make[2]: Leaving directory >> `/home/admin/bug/openldap-2.4.46/libraries/libldap' >> make[1]: *** [all-common] Error 1 >> make[1]: Leaving directory `/home/admin/bug/openldap-2.4.46/libraries' >> make: *** [all-common] Error 1 > > What makes you think this is an OpenLDAP issue? The error message clearly > says > sys_errlist.h was included from stdio.h - we have no control over that. >> >> Uploading the comple configure log and compilation traces. >> >> > > > -- > -- 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#8863) openldap compilation failure when
by hyc＠symas.com 06 Jun '18

06 Jun '18

ramakanth.varala(a)gmail.com wrote: > Full_Name: Rama Kanth Varala > Version: 2.4.46 > OS: Cent OS Release 5.7 > URL: ftp://ftp.openldap.org/incoming/openldap-bug.txt > Submission from: (NULL) (72.163.217.107) > > > I am trying to compile my binaries in a machine with has glibc 2.5 . Then i > take these > ldap libraries to link with the other process which is getting compiled in > glibc 2.3.4. > > I am compiling with option of ol_cv_dcl_sys_errlist=no , so that i can disable > offending symbols (sys_nerr and sys_errlist). configure go smooth but > compilation fails. > > Below is the compilation failure trace. > > cc -g -O2 -I../../include -I../../include -I/usr/local/db48/include > -DLDAP_LIBRARY -c string.c -fPIC -DPIC -o .libs/string.o > cc -g -O2 -I../../include -I../../include -I/usr/local/db48/include > -DLDAP_LIBRARY -c string.c -o string.o >/dev/null 2>&1 > /bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include > -I../../include -I/usr/local/db48/include -DLDAP_LIBRARY -c > util-int.c > cc -g -O2 -I../../include -I../../include -I/usr/local/db48/include > -DLDAP_LIBRARY -c util-int.c -fPIC -DPIC -o .libs/util-int.o > In file included from /usr/include/stdio.h:754, > from /usr/include/resolv.h:64, > from ../../include/ac/socket.h:58, > from util-int.c:32: > /usr/include/bits/sys_errlist.h:27: error: expected identifier or '(' > before numeric constant > /usr/include/bits/sys_errlist.h:28: error: expected identifier or '(' > before 'char' > /usr/include/bits/sys_errlist.h:28: error: expected ')' before numeric constant > make[2]: *** [util-int.lo] Error 1 > make[2]: Leaving directory `/home/admin/bug/openldap-2.4.46/libraries/libldap' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/home/admin/bug/openldap-2.4.46/libraries' > make: *** [all-common] Error 1 What makes you think this is an OpenLDAP issue? The error message clearly says sys_errlist.h was included from stdio.h - we have no control over that. > > Uploading the comple configure log and compilation traces. > > -- -- 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#8863) openldap compilation failure when
by ramakanth.varala＠gmail.com 06 Jun '18

06 Jun '18

Full_Name: Rama Kanth Varala Version: 2.4.46 OS: Cent OS Release 5.7 URL: ftp://ftp.openldap.org/incoming/openldap-bug.txt Submission from: (NULL) (72.163.217.107) I am trying to compile my binaries in a machine with has glibc 2.5 . Then i take these ldap libraries to link with the other process which is getting compiled in glibc 2.3.4. I am compiling with option of ol_cv_dcl_sys_errlist=no , so that i can disable offending symbols (sys_nerr and sys_errlist). configure go smooth but compilation fails. Below is the compilation failure trace. cc -g -O2 -I../../include -I../../include -I/usr/local/db48/include -DLDAP_LIBRARY -c string.c -fPIC -DPIC -o .libs/string.o cc -g -O2 -I../../include -I../../include -I/usr/local/db48/include -DLDAP_LIBRARY -c string.c -o string.o >/dev/null 2>&1 /bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -I/usr/local/db48/include -DLDAP_LIBRARY -c util-int.c cc -g -O2 -I../../include -I../../include -I/usr/local/db48/include -DLDAP_LIBRARY -c util-int.c -fPIC -DPIC -o .libs/util-int.o In file included from /usr/include/stdio.h:754, from /usr/include/resolv.h:64, from ../../include/ac/socket.h:58, from util-int.c:32: /usr/include/bits/sys_errlist.h:27: error: expected identifier or '(' before numeric constant /usr/include/bits/sys_errlist.h:28: error: expected identifier or '(' before 'char' /usr/include/bits/sys_errlist.h:28: error: expected ')' before numeric constant make[2]: *** [util-int.lo] Error 1 make[2]: Leaving directory `/home/admin/bug/openldap-2.4.46/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/admin/bug/openldap-2.4.46/libraries' make: *** [all-common] Error 1 Uploading the comple configure log and compilation traces.

1 0

Re: (ITS#8862) typos manual slapd-mdb
by hyc＠symas.com 02 Jun '18

02 Jun '18

dpa-bugs(a)aegee.org wrote: > Full_Name: Dilyan Palauzov > Version: latest > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.234.198.115) > > > http://www.openldap.org/software/man.cgi?query=slapd-mdb says: The manual is correct. Closing this ITS. > > index {_attrlist_|default} [pres,eq,approx,sub,_special_] > ... > If only an _attr_ is given, the indices specified for default are > maintained. > > It means probably not _attr_ but _attrlist_. > > maxsize _bytes_: > ... > It is important to set this to as large a value as possible > > I am not a native speaker, but I think there shall be no "a" before "value". > > -- -- 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#8862) typos manual slapd-mdb
by dpa-bugs＠aegee.org 01 Jun '18

01 Jun '18

Full_Name: Dilyan Palauzov Version: latest OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.234.198.115) http://www.openldap.org/software/man.cgi?query=slapd-mdb says: index {_attrlist_|default} [pres,eq,approx,sub,_special_] ... If only an _attr_ is given, the indices specified for default are maintained. It means probably not _attr_ but _attrlist_. maxsize _bytes_: ... It is important to set this to as large a value as possible I am not a native speaker, but I think there shall be no "a" before "value".

1 0

(ITS#8861) slapd-(async)meta(5) tls option missing ldaps
by quanah＠openldap.org 01 Jun '18

01 Jun '18

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The slapd-asyncmeta(5) and slapd-meta(5) man pages are missing the fact that they support the "ldaps" option to the "tls" keyword. This section should be updated along the lines of back-ldap which also has this option as a keyword.

1 0

Re: (ITS#8860) searching issue
by ryan＠openldap.org 27 May '18

27 May '18

Hello, The ITS is for reporting bugs in the software. For user support please contact the openldap-technical(a)openldap.org mailing list. This ITS will be closed. On Sun, May 27, 2018 at 02:33:05PM +0000, bahaa.mosaad(a)barqsystems.com wrote: >Full_Name: bahaa mosaad ali >Version: 2.4.39-3.el7 >OS: redhat 7 >URL: https://drive.google.com/drive/my-drive >Submission from: (NULL) (41.69.233.85) > > >i have radius server and get openldap to connect with this (server) according to >bind ruels success binding to ldap but when i search for some users without >password i get all info about those users but if i search by command like this >ldapsearch -x -W -D (user) dc= & password the error is always invalid >credentials even if change the password more than one time > >according to this error when trying to authenticate users from radius it would >be fail > > > >

1 0

(ITS#8860) searching issue
by bahaa.mosaad＠barqsystems.com 27 May '18

27 May '18

Full_Name: bahaa mosaad ali Version: 2.4.39-3.el7 OS: redhat 7 URL: https://drive.google.com/drive/my-drive Submission from: (NULL) (41.69.233.85) i have radius server and get openldap to connect with this (server) according to bind ruels success binding to ldap but when i search for some users without password i get all info about those users but if i search by command like this ldapsearch -x -W -D (user) dc= & password the error is always invalid credentials even if change the password more than one time according to this error when trying to authenticate users from radius it would be fail

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs