openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8923) compare op with dynlist returns wrong code when requested DN is in scope but doesn't exist
by ondra＠mistotebe.net 24 Sep '19

24 Sep '19

On Wed, Oct 03, 2018 at 08:25:44PM +0000, quanah(a)openldap.org wrote: > In a situation where a dynamic group has been created and a compare operation is > run with a DN that doesn't exist but is within the scope of the dynamic group > URI, the ldapcompare operation will incorrectly return an error 80 instead of > error 5 (compare FALSE). > > For example, if I have: > > dn: cn=planning,ou=Groups,dc=example,dc=com > objectClass: groupOfURLs > cn: planning > memberURL: ldap:///ou=planning,dc=example,dc=com??sub?(objectClass=inetorgpers > on) > > and I do an ldapcompare with: > > ldapcompare -x -H ldap://anvil2.rb.symas.net -D dc=example,dc=com -w secret > cn=planning,ou=Groups,dc=example,dc=com "member:cn=Ramakant > Wolow,ou=Planning,dc=example,dc=com" > > (i.e., this entry doesn't exist in the DB), I get: > > Compare Result: Other (e.g., implementation specific) error (80) > UNDEFINED > > This appears to be due to the fact that in this scenario, slapd attempts to find > the DN in the underlying DB and it doesn't exist, so an err=32 is returned back. > This is incorrectly interpreted as an unknown error, thus the err=80 result. > Instead it should be treated as "not a member of the group". I thought that exact scenario was being tested here? And that one passes. https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=tests/scr… -- 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#8964) ldap proxy segmentation fault
by ondra＠mistotebe.net 24 Sep '19

24 Sep '19

On Tue, Jan 29, 2019 at 03:10:02PM +0000, praveen.adini(a)fireeye.com wrote: > I'm trying to setup a openldap proxy wherein the proxy denies any search > requests for uid=root. When i tried using the rwm overlay to stop the > operation(#), i'm getting a segmentation fault although i see the unwilling to > perform operation 53 message being printed. here is the snippet of the conf that > i'm using. > > overlay rwm > rwm-rewriteEngine on > rwm-rewriteContext searchFilter > rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#" Hi Praveen, can you post a self-contained test script that triggers this issue? On its own, the above works as advertised, so maybe other overlays are interfering? There have been (probably still are) issues when combining rwm with some other overlays. 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

Re: (ITS#9018) dynlist don't close connection
by ondra＠mistotebe.net 24 Sep '19

24 Sep '19

On Thu, May 02, 2019 at 10:40:21AM +0000, i.harbuz(a)velcom.by wrote: > Any ldapsearch commands work fine if request doesn't hit into dynlist. > If request hit in dynlist then it output information and hanged up. Hello Ihar, it seems you have configured dynlist as a global overlay. I would note that not many overlays fully support this type of configuration at the moment and might not function correctly. It is possible that dynlist will do just fine for your use case. Make sure you test with a simpler scenario as well (where databases are not subordinate and/or without back-meta in the picture) to see if there might be interaction between them. Do let us know if you decide to investigate further and find a minimal use case where things start to break. Also a full test script that sets up a self-contained environment and reliably triggers the issue would greatly improve our chances of diagnosing it correctly. 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

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

23 Sep '19

On Mon, Sep 23, 2019 at 05:08:19PM +0200, Ond??ej Kuzn??k wrote: > Hi Greg, > thanks for both, I should merge that soon. Wonderful, thank you. :-) > On a side note, any ideas how to deal with ppolicy's pwdHistory here so > it can reject changing the password to an old one? AFAIK using these > schemas will prevent slap_passwd_check() from working and there isn't an > obvious way to proceed. I'm not familiar enough with how the ppolicy overlay hooks in to say ATM. I'll poke at this a bit and see if anything comes to mind... If the user is using the exop to set the password we do have access to the plaintext reusable password stripped of the OTP seed in the new hash_totp_and_pw() function, so if there's something better than calling lutil_passwd_hash() directly to restore this functionality I'd be perfectly fine with that change. Though I'm guessing it won't be quite that easy. ;-) -- Greg Veldman

1 0

Re: (ITS#9081) Memory leak in ldap_initialize/ldap_unbind
by ondra＠mistotebe.net 23 Sep '19

23 Sep '19

On Mon, Sep 16, 2019 at 11:53:58AM +0000, jengelh(a)inai.de wrote: > » cat x.c > #define LDAP_DEPRECATED 1 > #include <ldap.h> > int main() > { > LDAP *ld; > ldap_initialize(&ld, "ldapi:///"); > ldap_unbind(ld); > } > > unbind.c: > 123 for ( lm = ld->ld_responses; lm != NULL; lm = next ) { > 128 if ( ld->ld_abandoned != NULL ) { > 132 LDAP_MUTEX_UNLOCK( &ld->ld_res_mutex ); > 136 ber_int_sb_destroy( ld->ld_sb ); > > Should this probably be LBER_FREE rather than ber_int_sb_destroy? Hi Jan, thanks for the report. I think it should be doing both as _destroy() functions do not seem to be designed to free the pointer, only all its local structures. A patch has now been pushed to master. 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#9089) OpenLDAP sends searchResDone success to early
by marc.pape＠telekom.de 23 Sep '19

23 Sep '19

Full_Name: Marc Pape Version: 2.4.48 OS: Debian 9 Kernel 4.9 URL: https://qnap.testlab-lpz.de/share.cgi?ssid=0NbcOIY Submission from: (NULL) (80.153.108.120) Hello dear OpenLDAP-Team, we have a problem with the OpenLDAP Server which we operate as LDAP Proxy. In our deployment the OpenLDAP Proxy is for synchronization and authentication between a Cisco Callmanager 12.5 and two Microsoft ActiveDirectories in Version 2008R2. The Cisco Callmanager can only handle one Directory, but in some customer deployments exist two different directories. For that szenario we installed a Debian 9 server with OpenLDAP 2.4.48. The syncronization and authentication runs so far until one directory has more than 50 user. The Cisco Callmanager uses a SearchControlValue with size 50. By syncronize the Callmanager against one Microsoft AD directly the Microsoft Server will send responses with 50 user and in the end after all responses a unbindRequest. In our lab deployment we tested the Cisco Callmanager against a Microsoft AD with over 2000 enduser successfully. By implementing the OpenLDAP Server between the Cisco Callmanager and the Microsoft AD the OpenLDAP sends the unbindRequest directly after the first response with the first 50 user. All other requests and over 1950 user don't syncronize to the Cisco Callmanager. Is there a possible solution to send that unbindRequest after all responses and all users from the Microsoft AD were send to the Callmanager in that 50 users steps / responses? I've provided the configuration file of the OpenLDAP Server and a pcap file from a syncronizationrun in the upload below. The pcap file shows the following IPs and Server: 10.34.100.2 Cisco Callmanager 10.34.100.110 Debian 9 with OpenLDAP as LDAP Proxy 10.34.100.16 Microsoft AD #1 10.34.100.17 Microsoft AD #2 Kind regards Marc Pape

1 0

Re: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by quanah＠symas.com 23 Sep '19

23 Sep '19

--On Monday, September 23, 2019 10:22 AM +0000 jrajalakshmi(a)juniper.net wrote: > Full_Name: Rajalakshmi > Version: 2.4.44 > OS: RHEL 7.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (116.197.184.12) Hello, RedHat makes changes to OpenLDAP that are not reviewed by the OpenLDAP project. I would advise using an unmodified version of the current release of OpenLDAP to confirm whether or not this issue is in OpenLDAP itself or is caused by a change made by RedHat. You can use the packages from the LTB project for testing: <https://ltb-project.org/documentation/openldap-rpm#yum_repository> 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 ondra＠mistotebe.net 23 Sep '19

23 Sep '19

On Fri, Sep 13, 2019 at 11:57:14AM -0400, Greg Veldman wrote: > On Mon, Sep 09, 2019 at 04:01:59PM +0200, Ond??ej Kuzn??k wrote: >> I mean the ber_str2bv(,,1,) in both new functions. Not sure which code >> you think would overwrite parts of the buffer? ber_str2bv(,,0,) never >> touches it, manually initialising the berval certainly wouldn't either. >> And then you have fewer memory regions to scrub. >> >> Since you already know the length, you can also pass it in so ber_str2bv >> can skip its strlen() check (and since anything can be in a {PLAINTEXT} >> password, you're now embedded NUL safe). > > Ah, OK, I didn't realize that would be NUL safe. I made an > updated patch with that change[1]. > >> I think I mentioned this before as something worth changing: rather >> than call time(0L), you can use op->o_time which is stable and the >> closest you can get to the time the operation was received. > > Yes, sorry I did see that before just forgot to do it. It's > also included in the latest update[1]. Hi Greg, thanks for both, I should merge that soon. On a side note, any ideas how to deal with ppolicy's pwdHistory here so it can reject changing the password to an old one? AFAIK using these schemas will prevent slap_passwd_check() from working and there isn't an obvious way to proceed. 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#9088) Concurrency not seen in OpenLDAP 2.4.44
by jrajalakshmi＠juniper.net 23 Sep '19

23 Sep '19

Full_Name: Rajalakshmi Version: 2.4.44 OS: RHEL 7.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (116.197.184.12) (1) What problem/issue/behavior are you having trouble with? What do you expect to see? Using OpenLDAP version 2.4.44 we are not seeing Concurrency whereas in OpenLDAP Version 2.4.23 we are seeing Concurrent LDAP Requests. In our product OpenLDAP 2.4.23 was previously used and the concurrent request for search using the API ' ldap_search_ext_s() ' was working as expected and our product scalability was better. We have recently upgraded LDAP to OpenLDAP 2.4.44. But with this version, the api 'ldap_search_ext_s()' does not seem to work as expected, i.e concurrent requests handling is not happening. (2) Where are you experiencing the behavior? What environment? In RHEL 7.6. If we sent 10 Concurrent Requests each request is processed one by one. Most of the threads are waiting in ldap_search_req. (3) When does the behavior occur? Frequently? Repeatedly? At certain times? Repeatedly. (4) What information can you provide around timeframes and the business impact? There is a release impact due to the open issue. Hence seeking a reply at the earliest. In our product, the API ldap_search_req is used and this will be called by multiple threads at a time. On the process startup of the application, bind to ldap Server is created. status = ldap_search_ext_s(m_ld, pszBase, nScope, pszFilter, ppszAttrs2, nAttrsOnly, NULL, NULL, pTimeout2, LDAP_NO_LIMIT, ppResult); (5) Whether we need to do anything on that? Request for a solution at the earliest, is there any alternative api to support concurrency request Is there any open defect in the 'OpenLDAP 2.4.44' related to the synchronous handling method ' ldap_search_ext_s() '.

1 0

Re: (ITS#9084) Build issue when slaps is not included
by aixtools＠felt.demon.nl 22 Sep '19

22 Sep '19

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gJgclWXWHobp9Jm8TzWLGKLDSFUeHbtMu Content-Type: multipart/mixed; boundary="ftnTy1YEAYlvdoLUzJ64mQJw2X9PqF44q"; protected-headers="v1" From: Michael <aixtools(a)felt.demon.nl> To: openldap-its(a)OpenLDAP.org Cc: aixtools(a)felt.demon.nl Message-ID: <ab713cc5-89fb-8603-6a09-bc95e732c5cf(a)felt.demon.nl> Subject: Re: (ITS#9084) Build issue when slaps is not included --ftnTy1YEAYlvdoLUzJ64mQJw2X9PqF44q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Update. After uninstall openldap-2.4.46 and openldap-2.4.48 build fine. --ftnTy1YEAYlvdoLUzJ64mQJw2X9PqF44q-- --gJgclWXWHobp9Jm8TzWLGKLDSFUeHbtMu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE4MC4YtVFAh73PAYk4vWDeFkjp+AFAl2H0lgACgkQ4vWDeFkj p+CPrQf9Encsrt1sAI2T7VmR5MenhrXDQrZFeiMPjx7aILExkvu68yOSaM195nii yci/MQJWY982I1tA7EFuXKlN0NXM0LKTMK1FpjwrgkITQK6ov2KSPaLV3B9JoQSw MEQyCXhTIiN6ahAUWUw+pVqXk4o313mqqyfmQWoVrUxhgqiZlGFvyStSL+Fp5P+7 7YwxyfvhmEcQsolyqB/WLkw0T86jqPRgk/S8IV69NFiXd3A26bfVyA1sjrlWyRN4 5MRXg/btAimfvH+xlpAebY49GZ1MGt+AdZUu4qr1i2FlJi67Y2Ron/cq5EmwZeYu kqiD1Z5MOd3Ovfxz1UvWuMQ7EbvqwQ== =fAQW -----END PGP SIGNATURE----- --gJgclWXWHobp9Jm8TzWLGKLDSFUeHbtMu--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs