openldap-bugs July 2025

openldap-bugs@openldap.org

1 participants
65 discussions

[Issue 10313] New: 3-way multimaster oathHOTPCounter attribute update code missing
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10313 Issue ID: 10313 Summary: 3-way multimaster oathHOTPCounter attribute update code missing Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: agrru01(a)gmail.com Target Milestone: --- I posted on openldap technical mail list and got a response saying I should file a feature request. I am using a 3-way multimaster syncrepl setup with the slapo-otp module. My problem is that when authenticating with a user using HOTP, the attribute oathHOTPCounter only updates the value on the target ldap instance. This means the other two ldap instances do not get the updated HOTP-counter value and therefore will allow authentication using the same HOTP code. Interestingly enough, if I manually edit the oathHOTPCounter value it synchronizes with the other masters. Please see the technical mail list discussion: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10353] New: No TLS connection on Windows because of missing ENOTCONN in socket.h
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10353 Issue ID: 10353 Summary: No TLS connection on Windows because of missing ENOTCONN in socket.h Product: OpenLDAP Version: 2.6.10 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: julien.wadel(a)belledonne-communications.com Target Milestone: --- On Windows, the TLS connection cannot be done and we get the connection error: Can't contact LDAP server. => Connections are done with WSAGetLastError(). After getting WSAEWOULDBLOCK, the connection is not restart because of the state WSAENOTCONN that is not known. OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN is 10057L. Adding #define ENOTCONN WSAENOTCONN like for EWOULDBLOCK resolve the issue. Reference commit on external project: https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10379] New: lastbind change prevents ppolicy response from reaching accesslog
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10379 Issue ID: 10379 Summary: lastbind change prevents ppolicy response from reaching accesslog 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: --- When "lastbind on" and ppolicy are configured together, the pwdLastSuccess update triggers an accesslog entry (using op->o_time, op->o_tincr), then ppolicy_bind_response issues its own modification and since the time was copied in lastbind, an entry of the same name already exists. This means the ppolicy change is lost (and e.g. won't replicate). Note that slapo-lastbind (=the contrib overlay) probably has the same impact. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10169] New: Add support for token only authentication with otp overlay
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=10169 Issue ID: 10169 Summary: Add support for token only authentication with otp overlay Product: OpenLDAP Version: 2.6.6 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: --- Currently the OTP overlay is password + token. It would be nice to be able to configure it so it can run in a token only mode, similar to the slapo-totp overlay in contrib. This would allow us to have a project supported solution and retire that contrib module. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9564] New: Race condition with freeing the spilled pages from transaction
by openldap-its＠openldap.org 04 Nov '25

04 Nov '25

https://bugs.openldap.org/show_bug.cgi?id=9564 Issue ID: 9564 Summary: Race condition with freeing the spilled pages from transaction Product: LMDB Version: 0.9.29 Hardware: Other OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 825 --> https://bugs.openldap.org/attachment.cgi?id=825&action=edit Free the spilled pages and dirty overflows before unlocking the write mutex The spilled pages (a transaction's mt_spill_pgs) is freed *after* a write transaction's mutex is unlocked (in mdb.master3). This can result in a race condition where a second transaction can start and subsequently assign a new mt_spill_pgs list to the transaction structure that it reuses. If this occurs after the first transaction unlocks the mutex, but before it performs the free operation on mt_spill_pgs, then the first transaction will end up calling a free on the same spilled page list as the second transaction, resulting in a double free (and crash). It would seem to be an extremely unlikely scenario to actually happen, since the free call is literally the next operation after the mutex is unlocked, and the second transaction would need to make it all the way to the point of saving the freelist before a page spill list is likely to be allocated. Consequently, this probably has rarely happened. However, one of our users (see https://github.com/DoctorEvidence/lmdb-store/issues/48 for the discussion) has noticed this occurring, and it seems that it may be particularly likely to happen on MacOS on the new M1 silicon. Perhaps there is some peculiarity to how the threads are more likely to yield execution after a mutex unlock, I am not sure. I was able to reproduce the issue by intentionally manipulating the timing (sleeping before the free) to verify that the race condition is technically feasible, and apparently this can happen "in the wild" on MacOS, at least with an M1. It is also worth noting that this is due to (or a regression from) the fix for ITS#9155 (https://github.com/LMDB/lmdb/commit/cb256f409bb53efeda4ac69ee8165a0b4fc1a277) where the free call was moved outside the conditional (for having a parent) that had previously never been executed after the mutex is unlocked, but now is called after the unlock. Anyway, the solution is relatively simple, the free call simply has to be moved above the unlock. In my patch, I also moved the free call for mt_dirty_ovs. I am not sure what OVERFLOW_NOTYET/mt_dirty_ovs is for, but presumably it should be handled the same. This could alternately be solved by saving the reference to these lists before unlocking, and freeing after unlocking, which would slightly decrease the amount of processing within the mutex guarded code. Let me know if you prefer a patch that does that. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10162] New: Fix for binary attributes data corruption in back-sql
by openldap-its＠openldap.org 31 Oct '25

31 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10162 Issue ID: 10162 Summary: Fix for binary attributes data corruption in back-sql Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: dex.tracers(a)gmail.com Target Milestone: --- Created attachment 1006 --> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit Fix for binary attributes corruption on backed-sql I've configured slapd to use back-sql (mariadb through odbc) and observed issues with the BINARY data retrievals from the database. The length of the attributes was properly reported, but the correct data inside was always 16384 bytes and after that point - some junk (usually filled-up with AAAAAAAA and some other attributes data from memory). During the debugging - I've noticed that: - The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for BINARY columns when SQLBindCol is done inside of the "backsql_BindRowAsStrings_x" function - After SQLFetch is done - data in row->cols[i] is fetched up to the specified MAX_ATTR_LEN - After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is represented inside of the row->value_len I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills it with the specified amount of data (MAX_ATTR_LEN), but when forming the actual attribute data - uses the length from row->value_len and so everything from 16384 bytes position till row->value_len is just a junk from the memory (uninitialized, leftovers, data from other variables). After an investigation, I've find-out that: - for BINARY or variable length fields - SQLGetData should be used - SQLGetData supports chunked mode (if length is unknown) or full-read mode if the length is known - it could be used in pair with SQLBindCol after SQLFetch (!) Since we have the correct data length inside of row->value_len, I've just added the code to the backsql_get_attr_vals() function to overwrite the corrupted data with the correct data by issuing SQLGetData request. And it worked - binary data was properly retrieved and reported over LDAP! My current concerns / help needed - I'm not very familiar with the memory allocation/deallocation mechanisms, so I'm afraid that mentioned change can lead to memory corruption (so far not observed). Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and applied on the master branch for easier review/application). -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10274] New: Replication issue on MMR configuration
by openldap-its＠openldap.org 28 Oct '25

28 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10274 Issue ID: 10274 Summary: Replication issue on MMR configuration Product: OpenLDAP Version: 2.5.14 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: falgon.comp(a)gmail.com Target Milestone: --- Created attachment 1036 --> https://bugs.openldap.org/attachment.cgi?id=1036&action=edit In this attachment you will find 2 openldap configurations for 2 instances + slamd conf exemple + 5 screenshots to show the issue and one text file to explain what you see Hello we are openning this issue further to the initial post in technical : https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Issue : We are working on a project and we've come across an issue with the replication after performance testing : *Configuration :* RHEL 8.6 OpenLDAP 2.5.14 *MMR-delta *configuration on multiple servers attached 300,000 users configured and used for tests *olcLastBind: TRUE* Use of SLAMD (performance shooting) *Problem description:* We are currently running performance and resilience tests on our infrastructure using the SLAMD tool configured to perform BINDs and MODs on a defined range of accounts. We use a load balancer (VIP) to poll all of our servers equally. (but it is possible to do performance tests directly on each of the directories) With our current infrastructure we're able to perform approximately 300 MOD/BIND/s. Beyond that, we start to generate delays and can randomly come across one issue. However, when we run performance tests that exceed our write capacity, our replication between servers can randomly create an incident with directories being unable to catch up with their replication delay. The directories update their contextCSNs, but extremely slowly (like freezing). From then on, it's impossible for the directories to catch again. (even with no incoming traffic) A restart of the instance is required to perform a full refresh and solve the incident. We have enabled synchronization logs and have no error or refresh logs to indicate a problem ( we can provide you with logs if necessary). We suspect a write collision or a replication conflict but this is never write in our sync logs. We've run a lot of tests. For example, when we run a performance test on a single live server, we don't reproduce the problem. Anothers examples: if we define different accounts ranges for each server with SALMD, we don't reproduce the problem either. If we use only one account for the range, we don't reproduce the problem either. ______________________________________________________________________ I have add some screenshots on attachement to show you the issue and all the explanations. ______________________________________________________________________ *Symptoms :* One or more directories can no longer be replicated normally after performance testing ends. No apparent error logs. Need a restart of instances to solve the problem. *How to reproduce the problem:* Have at least two servers in MMR mode Set LastBind to TRUE Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple SLAMD test on same time for each server with the same account range. Exceed the maximum write capacity of the servers. *SLAMD configuration :* authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \ --useSSL --trustStorePath ${CACERTJKS} \ --trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \ --bindPassword ${BINDPW} --baseDN "${BASEDN}" \ --filter "(uid=[${RANGE}])" --credentials ${USERPW} \ --warmUpIntervals ${WARMUP} \ --numThreads ${NTHREADS} ${ARGS} -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 10191] New: backend searches should respond to pause requests
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10191 Issue ID: 10191 Summary: backend searches should respond to pause requests Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- A long running search will cause mods to cn=config to wait a long time. Search ops should periodically check for threadpool pause requests. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10372] New: support lastbind_forward_updates outside of the lastbind overlay
by openldap-its＠openldap.org 14 Oct '25

14 Oct '25

https://bugs.openldap.org/show_bug.cgi?id=10372 Issue ID: 10372 Summary: support lastbind_forward_updates outside of the lastbind overlay Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: lklement(a)symas.com Target Milestone: --- according to the documentation for the LastBind overlay (slapo-lastbind) this overlay is no longer recommended unless lastbind_forward_updates is used. Can this functionality be added to the current lastbind configuration recommendation? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10373] New: pcache SEGV with pcacheTemplate ttr
by openldap-its＠openldap.org 23 Sep '25

23 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10373 Issue ID: 10373 Summary: pcache SEGV with pcacheTemplate ttr Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: bertrand(a)jacquin.bzh Target Milestone: --- Hi, I am currently setting up OpenLDAP with pcache to circumvent aggressive LDAP queries from an application and thus reduce load to the SQL database used in the backend through back-sql.so. The setup is incomplete and likely not currently implemented properly, please don't pay too much attention in configuration details from below, however I'm noticing SEGV when pcacheTemplate are configured with ttr: refresh_purge() attempts to dereference NULL pointer *a, leading to the SEGV: ``` $ gdb --args /usr/lib64/openldap/slapd -u ldap -h "ldapi:/// ldap:/// ldaps:///" -f /etc/openldap/slapd.conf -d stats -d pcache 688224ea.1e5f48d7 0x7fffedffb6c0 conn=1020 op=2 SEARCH RESULT tag=101 err=0 qtime=0.000166 etime=0.012879 nentries=0 text= 688224ea.1e633093 0x7fffedffb6c0 conn=1020 op=3 SRCH base="ou=<redacted>,dc=<redacted>,dc=<redacted>" scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(&(jpegPhoto=*)(|(mail=<redacted>))))" 688224ea.1e64fd20 0x7fffedffb6c0 conn=1020 op=3 SRCH attr=dn 688224ea.1e65fb45 0x7fffedffb6c0 query template of incoming query = (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 688224ea.1e660563 0x7fffedffb6c0 Entering QC, querystr = (&(objectClass=inetOrgPerson)(&(jpegPhoto=*)(|(mail=<redacted>)))) 688224ea.1e660de7 0x7fffedffb6c0 Lock QC index = 0x555555828190 688224ea.1e6616cf 0x7fffedffb6c0 Not answerable: Unlock QC index=0x555555828190 688224ea.1e66209d 0x7fffedffb6c0 QUERY NOT ANSWERABLE 688224ea.1e6627c3 0x7fffedffb6c0 QUERY CACHEABLE 688224ea.1ed69d89 0x7fffedffb6c0 conn=1020 op=3 SEARCH RESULT tag=101 err=32 qtime=0.000009 etime=0.007587 nentries=0 text= 688224ea.1ef64669 0x7ffff4dfe6c0 conn=1020 op=4 UNBIND 688224ea.1efab72d 0x7fffedffb6c0 conn=1020 fd=30 closed Thread 7 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffee7fc6c0 (LWP 136445)] refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3392 3392 dnl->delete = ( a->a_numvals == 1 ); (gdb) bt #0 refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3392 #1 refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3367 #2 0x00005555555a6098 in slap_response_play (op=op@entry=0x7fffee7fb610, rs=rs@entry=0x7fffee7fb290) at result.c:573 #3 0x00005555555a7ddd in slap_send_search_entry (op=0x7fffee7fb610, rs=0x7fffee7fb290) at result.c:1078 #4 0x000055555562e007 in mdb_search (op=<optimized out>, rs=<optimized out>) at search.c:1110 #5 0x00007ffff73a6509 in refresh_query (op=0x7fffee7fb610, query=0x7fffd8131830, on=0x55555577c350) at pcache.c:3464 #6 consistency_check (ctx=<optimized out>, arg=0x5555559429a0) at pcache.c:3644 #7 0x00007ffff7f9e09d in ldap_int_thread_pool_wrapper (xpool=0x5555557aed80) at tpool.c:1059 #8 0x00007ffff7d3b86b in ?? () from /usr/lib64/libc.so.6 #9 0x00007ffff7dbc858 in ?? () from /usr/lib64/libc.so.6 (gdb) fr 0 #0 refresh_purge (op=0x7fffee7fb610, rs=0x7fffee7fb290) at pcache.c:3392 3392 dnl->delete = ( a->a_numvals == 1 ); (gdb) p *dnl $17 = { next = 0x0, dn = { bv_len = 40, bv_val = 0x7fffe403cb70 "uid=john,ou=<redacted>,dc=<redacted>,dc=<redacted>" }, delete = 80 'P' } (gdb) p a $10 = (Attribute *) 0x0 (gdb) p ad_queryId $14 = (AttributeDescription *) 0x555555819580 (gdb) p *rs $11 = { sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = { r_entry = 0x7fffe403c5a0, r_attr_flags = 17, r_operational_attrs = 0x0, r_attrs = 0x7fffee7fb320, r_nentries = 0, r_v2ref = 0x0 }, sru_sasl = { r_sasldata = 0x7fffe403c5a0 }, sru_extended = { r_rspoid = 0x7fffe403c5a0 "!", r_rspdata = 0x11 } }, sr_flags = 0 } (gdb) p *rs->sr_entry $12 = { e_id = 33, e_name = { bv_len = 40, bv_val = 0x7fffe403cae0 "uid=john,ou=<redacted>,dc=<redacted>,dc=<redacted>" }, e_nname = { bv_len = 40, bv_val = 0x7fffe403cb18 "uid=john,ou=<redacted>,dc=<redacted>,dc=<redacted>" }, e_attrs = 0x7fffe403c5f0, e_ocflags = 256, e_bv = { bv_len = 0, bv_val = 0x0 }, e_private = 0x7fffe403c5a0 } (gdb) p *rs->sr_entry->e_attrs $13 = { a_desc = 0x555555781be0, a_vals = 0x7fffe403c7f8, a_nvals = 0x7fffe403c7f8, a_numvals = 1, a_flags = 12, a_next = 0x7fffe403c618 } ``` Looking further I can see that attr_find() can return NULL, however NULL are not verified in refresh_purge() after call to attr_find(). Note that I am using 2.6.8 that includes all the changes from ITS#9966 and I can't find any noticeable changes on that area between 2.6.8. and latest 2.6.9. OpenLDAP is built on gentoo with hardened profile: ``` $ /usr/lib64/openldap/slapd -V @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2025 23:10:57) $ @localhost:/var/tmp/portage/net-nds/openldap-2.6.8-r1/work/openldap-OPENLDAP_REL_ENG_2_6_8-abi_x86_64.amd64/servers/slapd $ /usr/lib64/libc.so.6 -V GNU C Library (Gentoo 2.41-r4 (patchset 6)) stable release version 2.41. Copyright (C) 2025 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 14.3.0. libc ABIs: UNIQUE IFUNC ABSOLUTE Minimum supported kernel: 3.2.0 For bug reporting instructions, please see: <https://bugs.gentoo.org/>. ``` Configuration is as follow: ``` pidfile /run/openldap/slapd.pid argsfile /run/openldap/slapd.args include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc8284.schema # From https://raw.githubusercontent.com/jirutka/ssh-ldap-pubkey/refs/heads/master… include /etc/openldap/schema/openssh-lpk.schema #loglevel stats stats2 loglevel stats # Load dynamic modules moduleload argon2.so moduleload pw-pbkdf2.so moduleload pw-sha2.so moduleload back_sql.so moduleload pcache.so # Transport Layer Security TLSCertificateFile /etc/ssl/ldap/openldap.crt TLSCertificateKeyFile /etc/ssl/ldap/openldap.key TLSProtocolMin 3.4 TLSCipherSuite ECDHE+CHACHA20:ECDHE+AESGCM TLSECName X448:P-384:X25519:P-256 # Default search base to use when client submits a non-base search request with an empty base DN defaultsearchbase dc=<redacted>,dc=<redacted> # Hashes to be used in generation of user passwords password-hash {ARGON2ID} # Specify a set of conditions to require require LDAPv3 strong disallow bind_anon # Set of security strength factors to require security ssf=128 localSSF 256 # SASL security properties sasl-secprops noanonymous,noplain # SASL mapping authz-regexp uid=([^@]+)@([^,]+),cn=login,cn=auth uid=$1,ou=$2,dc=<redacted>,dc=<redacted> authz-regexp uid=([^@]+)@([^,]+),cn=plain,cn=auth uid=$1,ou=$2,dc=<redacted>,dc=<redacted> # Allow access to root over SASL access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * break # Allow service authentication from UNIX socket only access to dn.subtree="dc=local" attrs=userPassword by sockname="PATH=/var/run/ldapi" auth by anonymous auth by * none # Allow access to top level objects access to dn.base="dc=local" by users read by * break # Allow access to service CN access to dn.subtree="dc=local" by set.exact="this/cn & user/cn" read by * break # Allow user authentication access to dn.subtree="dc=<redacted>,dc=<redacted>" attrs=userPassword by anonymous auth by * none # Allow access to top level objects access to dn.base="dc=<redacted>,dc=<redacted>" by users read by * break # Allow access to users OU access to dn.subtree="dc=<redacted>,dc=<redacted>" by set.exact="this/ou & user/ou" read by * break # Allow services to access directory access to dn.subtree="dc=<redacted>,dc=<redacted>" by dn.exact="cn=<redacted>,dc=local" read by dn.exact="cn=<redacted>,dc=local" read by * break # Deny everything else access to * by * none # The config backend manages all of the configuration information for the slapd(8) daemon. database config # Access control policy access to dn.subtree="cn=config" by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none # Database instance definition database mdb directory /var/lib/openldap-data/dc=local # DN suffix of queries that will be passed to this backend database suffix dc=local # Database instance definition database sql dbname openldap dbuser openldap dbpasswd <redacted> # DN suffix of queries that will be passed to this backend database suffix dc=<redacted>,dc=<redacted> rootdn "uid=root,dc=<redacted>,dc=<redacted>" # Put the database into "read-only" mode readonly yes subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)" children_cond "ldap_entries.dn LIKE CONCAT('%,',?)" dn_match_cond "ldap_entries.dn=?" oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" id_query "SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" delentry_stmt "DELETE FROM ldap_entries WHERE id=?" renentry_stmt "UPDATE ldap_entries SET dn=?,parent=?,keyval=? WHERE id=?" delobjclasses_stmt "DELETE FROM ldap_entry_objclasses WHERE entry_id=?" # Do not use DN in reverse uppercased form has_ldapinfo_dn_ru no # Caching of LDAP search requests in a local databas overlay pcache pcache mdb 65536 16 1024 60 directory /var/lib/openldap-data/pcache pcacheMaxQueries 1024 # Cache DN pcacheAttrset 0 1.1 pcacheTemplate (objectClass=) 0 3600 60 0 15 pcacheTemplate (objectClass=*) 0 3600 60 0 15 pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 0 3600 60 0 15 pcacheAttrset 1 jid pcacheTemplate (jid=) 1 3600 60 0 15 pcacheAttrset 2 ou cn givenname sn mail telephonenumber jid description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 2 3600 60 0 15 pcacheTemplate (objectClass=*) 2 3600 60 0 15 pcacheTemplate (objectClass=) 2 3600 60 0 15 pcacheAttrset 3 ou cn givenname sn mail telephonenumber description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 3 3600 60 0 pcacheTemplate (objectClass=*) 3 3600 60 0 pcacheTemplate (objectClass=) 3 3600 60 0 pcacheAttrset 4 mail pcacheTemplate (objectClass=*) 4 3600 60 0 pcacheAttrset 5 * + pcacheTemplate (objectClass=*) 5 3600 60 0 15 pcacheTemplate (mail=) 5 3600 60 0 15 ``` Cheers, Bertrand -- You are receiving this mail because: You are on the CC list for the issue.

1 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2025