openldap-devel

openldap-devel@openldap.org

1 participants
1442 discussions

User bind is failing with error LDAP_REFERRAL with ldap_simple_bind API call when LDAP_OPT_REFERRALS=ON in OpenLDAP C SDK 2.6.7
by venugopal chinnakotla 04 Jun '26

04 Jun '26

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code. We are using OpenLDAP 2.6.7. As part of this migration, we are facing one issue related to LDAP Referrals when LDAP_OPT_REFERRALS=ON (which means SDK will handle Referrals internally) While testing our application which makes use of OpenLDAP sdk , we see a difference in the referral handling when LDAP_OPT_REFERRALS=ON when compared with NSLDAP C SDK with user bind We are testing with Oracle Unified Directory, referrals is enabled at server. *With OpenLDAP C SDK:* When our application follows the bind(synchronous) request for the users which is present in another server (where chase should happen) ldap_bind_s → - Which internally calls ldap_sasl_bind_s → ldap_sasl_bind + ldap_result able to succeed the bind (LDAP_SUCCESS). And When our application follows the bind(asynchronous) request for the users which is present in another server (where chase should happen) ldap_simple_bind -> - which internally calls ldap_sasl_bind failed to bind and returned (LDAP_REFERRAL) instead. On further analysis of OpenLDAP code *result.c* (line# 728) we observed, there is exclusion for bind request *tag != LDAP_RES_BIND*, which is preventing to chase the referral internally. * /* Do we need to check for referrals? */ if ( tag != LDAP_RES_BIND && ( LDAP_BOOL_GET(&ld->ld_options, LDAP_BOOL_REFERRALS) || lr->lr_parent != NULL )) { char **refs = NULL; ber_len_t len; /* Check if V3 referral */ if ( ber_peek_tag( &tmpber, &len ) == LDAP_TAG_REFERRAL ) { ... /* Chase the referral */ refer_cnt = ldap_chase_v3referrals( ld, lr, refs, ... );* However, we don't see such exclusion with NSLDAP C SDK specifically for bind requests. We would like to understand the limitation for asynchronous bind when handling referral internally. Are there any known issues/limitations with this use case when OpenLDAP C SDK handles referrals? Is there any way (like any flag/option) to make automatic referrals work with asynchronous bind calls ldap_simple_bind? Please note that, the ldap_search succeeds with when LDAP_OPT_REFERRALS=ON, no issue observed.

1 0

generated attributes and syncrepl
by Emmanuel Dreyfus 31 May '26

31 May '26

Hello I still work on slapo-supann, an overlay that generates attributes from user-supplied attributes. On a successful modify or add operation, I start an internal modify operation to add the generated attributes. It works fine, except that syncrepl sometimes miss this second operation: it only catch the first one. If I modify the entry again, it will get the missed second modification. This is because my internal modify operation does not update entryCSN. syncrepl has no way to know there was a second update. But why entryCSN fails to be updated? If I add op2.orm_no_opattrs = 0 and call slap_get_csn(), all operative attributes are updated. This probably fixes my problem, but modifiersName is changed to root, I preferd when I had the original user of the fist modify operation. If I do not set op2.orm_no_opattrs = 0, but I call slap_get_csn() and I perform a Modification like fhis, then only entryCSN is updated. mods->sml_op = LDAP_MOD_REPLACE; mods->sml_flags = SLAP_MOD_INTERNAL; mods->sml_desc = slap_schema.si_ad_entryCSN; mods->sml_numvals = 1; mods->sml_values = csn; I was happy about it, but the discovered that syncrepl consumer still misses the second modification, even if the master still has a more recent entryCSN than the replica. There must be a mising bit somewhere. Any hint? -- Emmanuel Dreyfus manu(a)netbsd.org

2 5

personal status & OL 2.7 release work
by Quanah Gibson-Mount 06 May '26

06 May '26

My main system I work from had a CPU failure. I'm currently getting it RMA'd (free, because this is apparently a known issue with some batches of the CPU). But it'll be next week before I'm fully back up and running. I'm working on getting things sync'd as able. I opened a PR to merge MDB 1.0 into mainline to prep it for 2.7. Ondrej, there was this pipeline failure that I think is odd, because it reports the test succeeded and then marks it failed: <https://git.openldap.org/quanah/openldap/-/jobs/20114> Not sure if it's related to the recent changes to the test suite. --Quanah

1 0

ITS#10489 potential 1-byte overread - is it a CVE or not?
by Howard Chu 11 Apr '26

11 Apr '26

IMO this doesn't qualify for a CVE and the reporter is just trying to pad his resume with fluff. In practice reads are non-destructive and 1 byte beyond an allocated buffer isn't going to break anything. Note that there is zero impact on slapd itself, because all of our uses explicitly pad one extra byte on message allocations. So this is only a potential problem for 3rd party users of liblber/ber_init2, a function that wasn't part of the old LDAP API RFC and is specific to OpenLDAP's liblber. I.e., no standard-compliant apps are using it. Any other opinions? -- -- 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

Performance degrade observed with OpenLDAP 2.6.7 library
by venugopal chinnakotla 12 Mar '26

12 Mar '26

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code. We are using OpenLDAP 2.6.7. As part of this migration, we are facing one issue related to performance degradation under load on Windows platform. In our application, we are using a single/shared connection handle to perform LDAP operation on LDAP user store servers. As part of Authentication, we are using ldap_search_ext_s call to get users and to get any user attributes from LDAP servers. We are using synchronous calls. With Mozilla NSLDAP, the same application is working well without any issues. As we are migrating to OpenLDAP, we did required changes and also we used ldap_dup() API to avoid "-4:Decoding error" issues under the load. Now, we are facing performance degradation issues under the load with OpenLDAP library Whenever we are trying to get a user attribute from the LDAP user store server where that user attribute is not available or value for user attribute is empty, we observed performance degradation with OpenLDAP library clearly around 25-30%. In case, search for user attributes with value, no degradation observed. This degradation is happening only when the user attribute is not available or the value is empty. Here are the snippet of runs output where performance degrade is showing: *With search of user attribute having value at LDAP server side:* Total Elapsed: 0:10:01 Minimum Response Time: 0:00:00.000.056 Maximum Response Time: 0:00:00.783.140 Average Response Time: 0:00:00.016.124 Total Requests: 659316 Throughput (Req/Sec): 1094.447 *With search of user attribute, not having value/does not exist at LDAP server side:* Total Elapsed: 0:10:01 Minimum Response Time: 0:00:00.000.059 Maximum Response Time: 0:00:00.218.502 Average Response Time: 0:00:00.032.788 Total Requests: 355065 Throughput (Req/Sec): 590.258 Example search calls we are using: 1. ldap_search_ext_x() for user lookup 2. ldap_search_ext_s() for user attributes for that specific user. (filter: uid=* and base: "cn=user,dc=comain,dc=com) - Where uid attribute has some value for this user at LDAP server side 3. ldap_search_ext_s() for user attributes for that specific user. (filter: Name=* and base: "cn=user,dc=comain,dc=com) - Where Name attribute is not present for that user at LDAP server side (This is causing performance degrade) With the same above steps, we did not see any performance issues with NSLDAP. If we remove step 3 from the above, no degradation is observed with the OpenLDAP library. Could you please look into this issue and provide a solution to overcome this performance degradation issue? We are completely blocked here as part of OpenLDAP migration. Note: To investigate this performance degradation with OpenLDAP, I wrote one LDAP sample code with the above 3 operations with multiple threads. I executed the sample with NSLDAP and OpenLDAP using multiple threads. In the sample runs, OpenLDAP is giving very poor performance when compared with NSLDAP. Please have a look at the sample also and provide your thoughts. Thank you in advance for your time and help

1 0

non-ASCII output for ldapsearch [PATCH]
by Emmanuel Dreyfus 27 Feb '26

27 Feb '26

Hello It would be nice if ldapsearch could display non-ASCII strings in a configurable charset, instead of always encoding in base64. I understand the current behavior is a requirement for LDIF compliance, but I believe we can add a non-LDIF compliant output, if this is what the user requested. Attached is a quick patch that will let ldapsearch output in the charset specified by LDAP_CHARSET environment variable (inspiration from LESS_CHARSET for less(1)). That makes life much more confortable when handling non-english data. It uses iconv() if <iconv.h> is detected. This function has been in POSIX for a while: https://pubs.opengroup.org/onlinepubs/007908775/xsh/iconv.html Opinions? Thoughts? -- Emmanuel Dreyfus manu(a)netbsd.org

2 1

[RESEND] Proposal: Continuous fuzzing support via OSS-Fuzz
by emptyiscolor＠gmail.com 23 Feb '26

23 Feb '26

Dear OpenLDAP team, Apologies if this is a duplicate — I’m resending this message in case my previous post did not reach the list. I’m writing to ask for guidance on potential ongoing fuzzing and security contributions for OpenLDAP. This is not a bug report or patch submission. Brief context: we recently reported Bug 10429, which was fixed in MR 826 (thank you). We have since been applying our fuzzing infrastructure to OpenLDAP and integrated a set of LibFuzzer-based harnesses into OSS-Fuzz. Draft OSS-Fuzz integration: https://github.com/google/oss-fuzz/pull/14872 In addition to Bug 10429, several related issues identified through fuzzing have recently been reported to the Issue Tracking System by my collaborator Kang Yang (Issues 10445, 10446, 10447, 10448, 10449, and 10450), which further motivates broader and continuous fuzzing coverage. At present, this work lives entirely in OSS-Fuzz and does not modify the OpenLDAP source tree. We are continuing to verify additional harnesses and investigate findings; any confirmed bugs and patches will be submitted via the Issue Tracking System in accordance with the contribution guidelines. We would appreciate guidance on whether this OSS-Fuzz integration approach aligns with OpenLDAP’s expectations, and whether there are preferences regarding API scope or future in-tree fuzzing work. Thanks for your time. Best regards, Yunhang Zhang University of Utah

2 1

Modifying the modification
by Emmanuel Dreyfus 13 Feb '26

13 Feb '26

Hello In an overlay, I want to alter a modification operation so that modification to an attribute is not done. I crafted the code below, which seems to work, but is it right? There are XXX places where I expected another behavior, did I miss something? And after "Modifying the modification", I also have "Modifying an add", just below, with the same questions. /* Modifying the modification */ static void supann_rm_mods(Modifications *mods, Modifications **mods_prevp) { Modifications *mods_next = mods->sml_next; int freeit = 0; /* XXX Setting freeit to 1 crashes */ slap_mod_free(&mods->sml_mod, freeit); mods->sml_numvals = 0; free(mods); *mods_prevp = mods_next; return; } And this how it is used (of course removeit is a more complex logic, it is removed here for the sake of clarity) Modifications *mods; Modifications **mods_prev; Modifications *mods_next; mods_prev = &op->orm_modlist; for (mods = op->orm_modlist; mods; mods = mods_next) { short sm_op = mods->sml_op; Attribute a; mods_next = mods->sml_next; if (remove_it) supann_rm_mods(mods, mods_prev); else mods_prev = &mods->sml_next; } Same question, for add oprations: /* Modifying the add */ static void supann_rm_attr(Attribute *a, Attribute **a_prevp) { Attribute *a_next = a->a_next; attr_clean(a); #if 0 /* XXX This crashes */ free(a); #endif *a_prevp = a_next; return; } And its usage: Attribute **a_prev; Attribute *a_next; a_prev = &op->ora_e->e_attrs; for (a = op->ora_e->e_attrs; a; a = a_next) { a_next = a->a_next; if (removeit) supann_rm_attr(a, a_prev); else a_prev = &a->a_next; } -- Emmanuel Dreyfus manu(a)netbsd.org

2 4

Request for comment: allow ACLs to trigger based on op/controls
by Ondřej Kuzník 12 Feb '26

12 Feb '26

Dear community, for the next release, I've been preparing extensions to the ACL syntax to address a feature request that comes up relatively often - restrict access to data/actions based on what controls are involved. My thinking is that we could allow the following stanzas in the "access to <what>" part: - op=<operation name> or op=<OID> for extended requests - control=<OID> In here, we would probably provide a shorthand for known OIDs using the OID macro in schemas, so you could write something like this: ---- 8< ---- access to dn.subtree=ou=people,dc=example,dc=com attrs=userPassword control=ppolicy by anonymous auth access to dn.subtree=ou=people,dc=example,dc=com attrs=userPassword by group=cn=admin,ou=groups,dc=example,dc=com write by * none ---- 8< ---- As this is a deep change in how people work with ACLs, I'd like some feedback from the community at large before we commit to changing the syntax in a way that we have to live with for a long time. Have you needed something like this? Does the proposed addition solve your use-case? Can you see issues that are not covered or new ones that could crop up when used like this and might not be desirable? Any other feedback or proposals for how this could be expressed are also welcome. I'd like to add that this is unlikely to land until consensus has been achieved in the first place. For those happy to test actual code, the above proposal lives in a merge request: https://git.openldap.org/openldap/openldap/-/merge_requests/720 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

Proposal: Continuous fuzzing support via OSS-Fuzz
by emptyiscolor＠gmail.com 09 Feb '26

09 Feb '26

Dear OpenLDAP team, My name is Yunhang Zhang, working with Prof. Jun Xu at the University of Utah (CS). We recently reported a NULL pointer dereference issue to OpenLDAP (Bug 10429), which was fixed in merge request [826](https://git.openldap.org/openldap/openldap/-/merge_requests/826) . Thank you for the prompt fix. I’m writing to discuss potential ongoing fuzzing and security contributions and to ask for guidance on the preferred process. We are part of the DARPA AI Cyber Challenge (AIxCC) finalist team “42-b3yond-6ug,” where we developed an AI-driven Cyber Reasoning System (CRS) that automatically generates fuzzing harnesses and discovers vulnerabilities in large C/C++ codebases. Applying this system to OpenLDAP so far, we have: * Generated LibFuzzer-compatible fuzzing harnesses targeting public OpenLDAP APIs * Validated the harnesses against documented interfaces * Integrated the harnesses into OSS-Fuzz for continuous testing Our draft OSS-Fuzz integration is available here: https://github.com/google/oss-fuzz/pull/14872 At present, this work lives entirely in OSS-Fuzz and does not modify the OpenLDAP source tree. We are continuing to verify additional harnesses and investigate findings; any confirmed bugs and corresponding patches will be submitted through the Issue Tracking System in accordance with the contribution guidelines. The goal is to improve long-term robustness and security coverage with minimal maintenance overhead for the OpenLDAP project. We believe broader fuzzing coverage can help detect regressions and subtle issues earlier over time. We would appreciate guidance from the community on whether this approach aligns with OpenLDAP’s expectations, and whether there are preferences regarding API scope, exclusions, or future in-tree fuzzing contributions. Thanks for your time and for maintaining OpenLDAP. Best regards, Yunhang Zhang University of Utah (on behalf of the 42-b3yond-6ug / DARPA AIxCC team)

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel