- openldap-bugs - openldap.org

[Issue 10412] New: slapadd stops if the ldif files starts with 'version:'
by openldap-its＠openldap.org 16 Dec '25

16 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10412 Issue ID: 10412 Summary: slapadd stops if the ldif files starts with 'version:' Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- Injecting data with slapadd fails if the file starts with 'version: 1', with such a message: str2entry: entry -1 has no dn slapadd: could not parse entry (line=1) A LDIF file starting with 'version: 1' is a valid LDIF file per RFC 2849: ldif-file = ldif-content / ldif-changes ldif-content = version-spec 1*(1*SEP ldif-attrval-record) version-spec = "version:" FILL version-number version-number = 1*DIGIT ; version-number MUST be "1" for the ; LDIF format described in this document. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 7441] cn=config filters ignore {number}
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=7441 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 3d94d11c by Ondřej Kuzník at 2025-12-08T18:52:59+00:00 ITS#7441 Consider both parts of an X-ORDERED value -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6151] Update cosine.schema to RFC 4524
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=6151 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|CONFIRMED |RESOLVED Keywords|has_patch, IPR_OK | --- Comment #22 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • e6f666a1 by Ondřej Kuzník at 2025-12-04T18:26:33+00:00 ITS#6151 Update cosine.schema for RFC 4524 - adds a new substring match omitted previously (uniqueIdentifier) - removes streetAddress duplication in domain objectclass - prefers short names for MUST/MAY attributes - long definitions (for 'co', 'drink', ...) are NOT removed here - attributes/objectclasses removed by RFC 4524 are NOT removed here Chooses not to remove DESC tags removed in RFC1274 in the interests of keeping the diff small. • aa3e8f34 by Ondřej Kuzník at 2025-12-04T18:26:33+00:00 ITS#6151 Regenerate cosine.ldif -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=6938 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|CONFIRMED |RESOLVED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 15 Dec '25

15 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=6938 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Resolution|SUSPENDED |--- --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 90e6bfe0 by Howard Chu at 2025-12-01T16:18:46+00:00 ITS#6938 WIN32: silence warnings for redefined error codes by Howard Chu at 2025-12-01T16:18:46+00:00 ITS#6938 WIN32 IPv6: fix sockaddr_storage detection It's defined in winsock2.h. Also remove error for missing INET6_ADDRSTRLEN define, we already have it in our <ac/socket.h> if it's missing. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9936] New: slapd attempting free on address which was not malloced
by openldap-its＠openldap.org 12 Dec '25

12 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9936 Issue ID: 9936 Summary: slapd attempting free on address which was not malloced Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kimjuhi96(a)snu.ac.kr Target Milestone: --- I get invalid free running this on the latest openldap from git, built with CFLAGS="-fsanitize=address" using clang 15. Seems this is similar to https://bugs.openldap.org/show_bug.cgi?id=9912. ./servers/slapd/slapd -T c -s1 -s1 Stopped reason: SIGABRT __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. gdb-peda$ bt #0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff78ca859 in __GI_abort () at abort.c:79 #2 0x00005555556eb04f in __sanitizer::Abort () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:143 #3 0x00005555556e8aac in __sanitizer::Die () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:58 #4 0x00005555556c5dda in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7fffffffbe7e, __in_chrg=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:192 #5 0x00005555556c72b8 in __asan::ReportFreeNotMalloced (addr=<optimized out>, free_stack=0x7fffffffca90) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:199 #6 0x00005555556c02ab in __interceptor_free (ptr=0x7fffffffe359) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:53 #7 0x0000555555d3efe2 in ber_memfree_x () #8 0x0000555555847d33 in ch_free () #9 0x0000555555a31178 in slap_tool_init () #10 0x0000555555a2e54d in slapcat () #11 0x000055555570901f in main () #12 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>, argc=0x5, argv=0x7fffffffdfc8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdfb8) at ../csu/libc-start.c:308 #13 0x000055555561011e in _start () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:397 gdb-peda$ -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 7392] ACL a_dn.a_self is skipped in case of "acl_mask: to all values ..."
by openldap-its＠openldap.org 10 Dec '25

10 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=7392 --- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> --- I'm not so sure this is actually viable, allowing a self<permission> like what's requested would allow selfwrite with a blanket delete which is contrary to what our documentation says about selfwrite? Don't know how to square those two and I think there is a way to write acls that achieve the same intent by splitting them somewhat? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10362] New: Normalised value confusions in replication
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10362 Issue ID: 10362 Summary: Normalised value confusions in replication Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- A lot of code expects a_nvals state to be consistent across modifies and multiple instances of the same attribute (with asserts to that effect), but replication doesn't seem to obey this: Add this assert into syncrepl_diff_entry()[0] : assert( ( old->a_nvals == NULL ) == ( new->a_nvals == NULL ) ); if ( old->a_nvals ) assert( ( old->a_nvals == old->a_vals ) == ( new->a_nvals == new->a_vals ) ); You'll see many tests fail this, the first of which is test043. [0]. https://git.openldap.org/openldap/openldap/-/blob/14d47146b0442df85bd949b21… -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10311] New: Work with IETF LDAP working group to update password hashing mechanism RFC
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10311 Issue ID: 10311 Summary: Work with IETF LDAP working group to update password hashing mechanism RFC Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Work with the IETF ldap working group to update the RFC to make the suggested hashing mechanism be what is currently "best practice" rather than a specific hashing mechanism. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10100] New: Non-sequential timestamps being logged on Windows
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10100 Issue ID: 10100 Summary: Non-sequential timestamps being logged on Windows Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Presents as a dsync during replication. Consumer will log ``` 650af021.2eadd901 0000000000001b40 slap_queue_csn: queueing 0000000002ac1620 20230920131409.992477Z#000000#001#000000 650af021.2eaed239 0000000000001b40 slap_graduate_commit_csn: removing 0000000002ac1620 20230920131409.992477Z#000000#001#000000 650af021.317b2a35 000000000000185c do_syncrep2: rid=102 CSN too old, ignoring 20230920131409.040136Z#000000#001#000000 (uid=slapd-test1-FOO1-6,ou=People,dc=example,dc=com) ``` The entry was not be added. The provider will log messages using non-sequential timestamps. For example, when grepping the CSN from above (in provider log): ``` # This: 650af021.3b3060d9 0000000000001ad8 conn=1001 op=1 syncprov_sendresp: to=002, cookie=rid=102,sid=001,csn=20230920131409.992477Z#000000#001#000000 # and: 650af021.02648749 0000000000001810 slap_get_csn: conn=1003 op=7 generated new csn=20230920131409.040136Z#000000#001#000000 manage=1 ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10277] New: How to deal with desync between cn=config and back-ldif DNs
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10277 Issue ID: 10277 Summary: How to deal with desync between cn=config and back-ldif DNs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If someone deletes a cn=config entry offline (or through bugs in cn=config, they exist, will file as I isolate), the X-ORDERED RDNs will not be contiguous. cn=config papers over this internally at a cost of never being able to modify the entries affected. Right now the only remedy is slapcat+slapadd of the whole config DB, is that the best we can do? When we detect this (doesn't always happen), should we fix the on-disk copy on startup? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10269] New: slap-constraint: Refactor to use a sorted array
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10269 Issue ID: 10269 Summary: slap-constraint: Refactor to use a sorted array Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- As noted in the comments for slapo-constraint: /* * Linked list of attribute constraints which we should enforce. * This is probably a sub optimal structure - some form of sorted * array would be better if the number of attributes constrained is * likely to be much bigger than 4 or 5. We stick with a list for * the moment. */ -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10217] New: autoca should support more key types
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10217 Issue ID: 10217 Summary: autoca should support more key types Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently autoca only creates certificates using RSA keypairs. It should at least have an option to use Elliptic Curve keypairs. It probably also needs options to specify other signature algorithms other than the default of SHA256. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10086] New: test059 does not set up valid cn=config replication
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10086 Issue ID: 10086 Summary: test059 does not set up valid cn=config replication Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For cn=config replication to be valid, the entryUUIDs must match throughout the config database. However, this is not the case when test059 executes. The entryUUID for 'dn: cn=config' differs between the two. Example: quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: cfcon.d/cn\=config.ldif entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372 quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: db.1.a/cn\=config\,cn\=consumer.ldif entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22 -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9584] New: cn=config replication ops/refresh should pause server
by openldap-its＠openldap.org 08 Dec '25

08 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9584 Issue ID: 9584 Summary: cn=config replication ops/refresh should pause server Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Looking into this crash: https://git.openldap.org/openldap/openldap/-/jobs/7286 The thread in question is running a plain syncrepl refresh while another thread seems to have done the same. This thread fetched the entryUUID attribute of the 'cn=config' entry as 'a' and in the meantime, that entry has been rewritten, with 'a' presumably cleaned up and returned to the pool, so addressing a->a_nvals[0] is a NULL-dereference now. This might or might not be related to the fix in ITS#8102. -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9881] New: Ability to track last authentication for database objects
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9881 Issue ID: 9881 Summary: Ability to track last authentication for database objects Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For simple binds, we have the ability to track the last success via the lastbind functionality (pwdLastSuccess attribute). However this doesn't allow one to see when an object that exists in a database last authenticated via SASL. It would be useful to add similar functionality for SASL binds. This can be useful information that allows one to tell if an object is being actively authenticated to (generally, users and system accounts, etc). Obviously if something is directly mapped to an identity that doesn't exist in the underlying DB, that cannot be tracked. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9829] New: set timeouts in remoteauth overlay
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9829 Issue ID: 9829 Summary: set timeouts in remoteauth overlay Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Currently, it seems there is no way to configure timeouts in the remoteauth overlay. For example, if I define a remoteauth_mapping with a file containing a list of hostnames, the first one is checked first. After "remoteauth_retry_count" * "connect_timeout" seconds, (210s on my system), remoteauth test the second server in the list. In some circumstances, it could be nice to set the connect timeout lower (or higher). -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9782] New: regression test its8752 failure
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9782 Issue ID: 9782 Summary: regression test its8752 failure Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a contextCSN update (new cookie) goes from server A through server B to server C, server C will use that CSN to update entryCSN as well (which neither A nor B did). This fails the initial replication check. The issue has likely existed since deltasync was made possible, a version of this is confirmed at least in 2.4.60 onwards to current master. In principle, it is related to concerns raised in ITS#9580. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9652] New: Add "tee" capability to load balancer
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9652 Issue ID: 9652 Summary: Add "tee" capability to load balancer Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- This is a request for an enhancement that would add a "tee" or "fan-out" capability to load balancer, where received operations are sent to two or more destinations simultaneously. The primary goal or the enhancement is to make it possible to keep multiple independent and likely dissimilar directory systems in lock-step with each other over hours, days, or possibly even weeks. The enhancement would not necessarily need to include a mechanism for converging the target systems should they become out of sync. This is not intended to be a replication solution, rather it is viewed more as a "copy" solution intended to be used for specific short-term tasks that need multiple directory systems to be exactly synchronized but where replication is not desirable or even possible. At least two uses come to mind: 1. Test harnesses, evaluating side-by-side operation of separate directory systems over time 2. Directory system transition validation harnesses 3. (maybe) Part of a test harness to record or replay LDAP workloads * Other uses? -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9303] New: Add support for WolfSSL as an alternative to OpenSSL
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9303 Issue ID: 9303 Summary: Add support for WolfSSL as an alternative to OpenSSL Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For OpenLDAP 2.6, we should investigate adding support for WolfSSL as an alternative to OpenSSL. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9284] New: Need man page for vc contrib overlay
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9284 Issue ID: 9284 Summary: Need man page for vc contrib overlay Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The verified credentials overlay in contrib is missing a man page describing its purpose -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9272 Issue ID: 9272 Summary: Invalid search results for subordinate/glued database Product: OpenLDAP Version: 2.4.47 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Here is a trivial test case. Look at the following bunch of glued dit's/databases, declared in this order: | suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=2,ou=T # subordinate; contains only one (top-level) entry | suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=T # master database, has two entries, top-level | ` ou=1 # ... and this child entry let's query the united database: | $ ldapsearch -b ou=1,ou=T -s sub '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | dn: ou=b,ou=1,ou=T Nice! But wait, what if ... | $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | | # pagedresults: cookie=//////////8= ... BANG! ... | Server is unwilling to perform (53) The problem is the glue_op_search(), which has issues * different parts of code make different assumptions about data structures * different parts of code track state inconsistently * code that looks like a highly probably dead code I mean that likely possible to build another bug-triggering test cases, and glue_op_search() needs not just a fix of the bug above, but intense cleaning and structuring. -- You are receiving this mail because: You are on the CC list for the issue.

1 16

[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9256 Bug ID: 9256 Summary: The ACLs required for SASL binding are not fully documented Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 727 --> https://bugs.openldap.org/attachment.cgi?id=727&action=edit Patch massaging the SASL binding requirement docs While some ACL requirements for SASL binding are documented, some are not. E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is not documented. Other requirements can be reasoned out based on the existing documentation, but this can be very difficult when unfamiliar with all the moving parts and the places they are documented. E.g. knowing that (objectClass=*) is the default filter, and that there's _always_ _some_ filter, and connecting this with ACLs required to do search-based SASL mapping. The attached patch brings all the SASL binding requirements together in one place in the docs and makes everything explicit. The word "SASL" is included, for those searching for that keyword. I, Karl O. Pinc, 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. -- You are receiving this mail because: You are on the CC list for the bug.

1 28

[Bug 9220] New: Rewrite Bind and Exop result handling
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9220 Bug ID: 9220 Summary: Rewrite Bind and Exop result handling Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Bind and Exop result handling needs a rewrite so it is no longer a special case for overlays. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Issue 9022] Force slapadd to rewrite all entryCSN values
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9022 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |2.7.1 -- You are receiving this mail because: You are on the CC list for the issue.

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