openldap-technical March 2025

openldap-technical@openldap.org

26 participants
34 discussions

accesslog with delta syncrepl: Why wouldn't contebnt be synced?
by Windl, Ulrich 27 Mar '25

27 Mar '25

Hi! I had just asked https://serverfault.com/q/1177576/407952, but I'll summarize here: I think I configured delta-syncrepl for a MMR correctly using OpenLDAP >= 2.5.18 (cn=config also synced). However when I offlined one node and updated the main DIT via slapadd, the other node wouldn't update its DIT when the offlined node is online again. I wonder whether I have to empty or delete the corresponding accesslog, or is there some other step to perform? Is delta syncrepl looking at the accesslog only to detect changes? The syncrepl configs look like this for the DIT: olcSyncrepl: {0}rid=115 provider="ldap://server5/\ " searchbase="dc=..." type=refreshAndPersist \ retry="60 5 300 5 1800 +" logbase="cn=changelog-1" logfilter="(&(objectClass=au\ ditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog starttls=cr\ itical tls_reqcert=demand bindmethod=sasl saslmech=external tls_cert="/etc/ssl/\ servercerts/syncrepl.pem" tls_key="/etc/ssl/serverkeys/syncrepl.key" tls_cacert\ ="/etc/ssl/servercerts/ CA-bundle.pem" olcSyncrepl: {1}rid=116 provider="ldap://server6/\ " searchbase="dc=..." type=refreshAndPersist \ retry="60 5 300 5 1800 +" logbase="cn=changelog-1" logfilter="(&(objectClass=au\ ditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog starttls=cr\ itical tls_reqcert=demand bindmethod=sasl saslmech=external tls_cert="/etc/ssl/\ servercerts/syncrepl.pem" tls_key="/etc/ssl/serverkeys/syncrepl.key" tls_cacert\ ="/etc/ssl/servercerts/ CA-bundle.pem" Kind regards, Ulrich Windl

2 5

Upgrade from 2.4.45 to 2.4.49 and beyond
by justin＠1707.io 27 Mar '25

27 Mar '25

Hey Everyone, I've inherited some rather unmaintained servers as part of a new job and I'm looking to get them all up to date. We have a server for auth for satellite services that uses slapd/openLDAP. It's on a rather old version, and I'm wanting to upgrade it. I would like to see if anyone has advice on how to upgrade from Ubuntu 18.04.6 with the current 2.4.45 slapd/OpenLDAP to Ubuntu 24.04. I've looked around to try and find guides that show upgrades notes between versions but haven't found anything relevant. All advice appreciated! Regards, Justin

3 2

Notes on https://kb.symas.com/en_US/configuration/configure-delta-syncrepl
by Windl, Ulrich 24 Mar '25

24 Mar '25

Hi! Reading https://kb.symas.com/en_US/configuration/configure-delta-syncrepl I found some issues: 1. In "Chaining Overlay" there is a an extra "i" in "dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config i" 2. The syncrepl for "Multi-Master Replication (MMR)" still uses "mirrormode" 3. "Syncrepl" for MMR and cn=config is formatted badly (compared to slapd.conf version) Also for MMR there is a syncprov defined for the database to sync and the accesslog for that database. Why is syncprov for accesslog needed? Kind regards, Ulrich Windl

2 2

Overlay for alternate authentication
by BuzzSaw Code 20 Mar '25

20 Mar '25

We have an existing set of RHEL8 servers running the 2.4.x version of OpenLDAP - we can't upgrade to the latest version due to other dependencies. I'm trying to solve a problem where we want to use our 2FA authentication (which is OTP based on RADIUS) with some devices and applications that don't support RADIUS at all, but they *do* support LDAP authentication. I've read about using the SASL, but since that requires replacing the userPassword attribute for each user it won't work as I have to do this without breaking straight username/password binds for users. I looked into using overlays to create a new OU of users that was a translucent overlay of the existing ou=People (something like ou=rPeople), but searching this list archive and others says that won't work as I can't overlay/rewrite the userPassword attribute ? Is that correct? I'm trying to avoid duplicating the entire directory to new servers or even duplicating the existing ou=People structure just to create a new 'userPassword' attribute that can be used for SASL.

5 4

Feature Requests; where to go? (diff-friendly slapcat/ldapsearch)
by Windl, Ulrich 20 Mar '25

20 Mar '25

Hi! I had an idea for a new feature of slapcat (maybe ldapsearch, too), but I don't know where to file such. So I'm presenting the idea here: "Diff-friendly output format" The order of LDAP attributes is not determined, so after a change to an entry the order of attributes may vary. If you diff the older with the current output, there are more differences than actually there were changes. For example consider this diff (partial output): +entryCSN: 20250319115404.360112Z#000000#005#000000 +modifiersName: cn=config +modifyTimestamp: 20250319115404Z contextCSN: 20130722065709.189194Z#000000#000#000000 contextCSN: 20241204070658.632888Z#000000#001#000000 contextCSN: 20200721123717.002866Z#000000#002#000000 contextCSN: 20181031083258.073732Z#000000#003#000000 -contextCSN: 20250319114038.822575Z#000000#005#000000 +contextCSN: 20250319140809.186543Z#000000#005#000000 contextCSN: 20250227092006.790591Z#000000#006#000000 -entryCSN: 20250319115404.360112Z#000000#005#000000 -modifiersName: cn=config -modifyTimestamp: 20250319115404Z The modifiersName did not change, but its position had moved in output. In a diff-friendly format the position would not change. Obviously that could be done by sorting the output by attribute names (which would also help to locate a specific attribute), but it would have performance impacts, obviously. Another related option is attributes with a list of sub-attributes (name-value pairs), like syncrepl: In standard format the lines are wrapped, and with "-o ldif-wrap=no" you get one long line. For diff-friendliness may idea was to optionally wrap such name-value pairs after each pair, and if a single one exceeds the standard lengh, it would be wrapped still. So the idea could be like this: Use option -D for diff-friendly output format (sorting of attributes), and when doubled, also enable wrapping of name-value pairs. With "-o ldif-wrap=no" given also, single name-value pairs would end up on a separate line, but such lines wouldn't be wrapped themselves. Alternatively one could use "-odiff-friendly=X" where X is 1 or 2. (In case of contextCSN one could even think of X=3 activating sort of the same attribute by attribute value) Do you think it's a useful enhancement? I must admit I played with the idea implementing it myself, but after having had a look at the source of slapcat, it looked more low-level than I had expected, so I had no idea where to start... Kind regards, Ulrich Windl

3 2

Q: DN of a user certificate
by Windl, Ulrich 19 Mar '25

19 Mar '25

Hi! I'm playing with mapping the DN of user certificates to (the DN of) LDAP users. Maybe I'm missing something, but it seems openLDAP appends the certificate DN to the LDAP context for authentication. That way the names can get really long, just as the olcAuthzRegexp will. So can anybody give a real-life example which DN to use for the user certificates? I mean certificate DN, LDAP user context and olcAuthzRegexp. Kind regards, Ulrich Windl

2 1

Q: Using SASL EXTERNAL with certificates for syncrepl
by Windl, Ulrich 19 Mar '25

19 Mar '25

Hi! I'm trying to convert out rencreplc configurtation using plain authentication over TLS to external authentication using a user certificate. It almost works, but slapd is reporting "connection_read(11): TLS accept failure error=-1 id=1002, closing" and "conn=1002 fd=11 closed (TLS negotiation failure)" while I can connect using the certificate and peer with openssl s_client Openssl reports: ... Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1 Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 20974 bytes and written 5070 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2400 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ... Somehow I suspect that the certificate being a user certificate (DN mapped to a user entry) is not acceptable in syncrepl's tls_cert; can anybody confirm? The problem is that I'd like to trust a user certificate more than a host certificate for replication. And if I'd use a host certificate, how could I authenticate the user being used to get the changes? I looked a lot around using popular search engines, but could not find a useful example that is complete enough. Let me remark at this point that the description of tls_reqsan is quite poor in {SLAPD-CONFIG(5); it was not obvious to me that i9s is about "Subject Alternate Name". The other thing I noticed was a capitalized "Binding" in "...to establish a TLS session before Binding to the provider." (also in SLAPD-CONFIG(5)) Kind regards, Ulrich Windl

2 2

accesslog seemingly needs a lot of space
by Windl, Ulrich 19 Mar '25

19 Mar '25

Hi! Trying to convert my syncrepl configuration to a delta syncrepl configuration, the slave runs out of accesslog space during initial sync. For the main database about 30MB should be enough, but I configured 50MB, also for the accesslog files. It seems sync continues even if accesslog periodically complains like this: slapd[13951]: => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792) slapd[13951]: conn=-1 op=0 accesslog_response: got result 0x50 adding log entry reqStart=20250314110032.000187Z,cn=changelog-1 From stat I guess that accesslog needs at least three times as much space as the main database does: # stat /var/lib/ldap/data.mdb /var/lib/ldap/changelog-1/data.mdb File: /var/lib/ldap/data.mdb Size: 22888448 Blocks: 44704 IO Block: 4096 regular file Device: 33h/51d Inode: 259467 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 11:57:46.303713632 +0100 Modify: 2025-03-14 12:01:08.417328586 +0100 Change: 2025-03-14 12:01:08.417328586 +0100 Birth: 2025-03-14 11:57:46.303713632 +0100 File: /var/lib/ldap/changelog-1/data.mdb Size: 52424704 Blocks: 102392 IO Block: 4096 regular file Device: 33h/51d Inode: 259471 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 11:57:46.323713395 +0100 Modify: 2025-03-14 12:01:08.425328492 +0100 Change: 2025-03-14 12:01:08.425328492 +0100 Birth: 2025-03-14 11:57:46.323713395 +0100 Shouldn't (assuming the sync happens entry-by-entry) the accesslog have about the same size as the main database after initial sync (when all databases were empty)? When setting the size of the accesslog database to twice the size of the database it succeeded which stats like this: # stat /var/lib/ldap/data.mdb /var/lib/ldap/changelog-1/data.mdb File: /var/lib/ldap/data.mdb Size: 22888448 Blocks: 44704 IO Block: 4096 regular file Device: 33h/51d Inode: 259514 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 12:39:01.278545521 +0100 Modify: 2025-03-14 12:45:03.558274733 +0100 Change: 2025-03-14 12:45:03.558274733 +0100 Birth: 2025-03-14 12:39:01.278545521 +0100 File: /var/lib/ldap/changelog-1/data.mdb Size: 89657344 Blocks: 175112 IO Block: 4096 regular file Device: 33h/51d Inode: 259518 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 12:39:01.298545286 +0100 Modify: 2025-03-14 12:45:03.566274639 +0100 Change: 2025-03-14 12:45:03.566274639 +0100 Birth: 2025-03-14 12:39:01.298545286 +0100 So the blocks in the accesslog are roughly four times (3.91 ) as much as in the original database. Is there any doc making statements about the proportion? (I'm a fan of "small is beautiful" instead of "bigger is better") Kind regards, Ulrich Windl

3 8

invalid olcAuthzRegexp crashed openLDAP server in SLES15 SP6
by Windl, Ulrich 17 Mar '25

17 Mar '25

Hi! At work I have to connect to our SLES servers via Windows RDP and a Windows server. Unfortunately RDP is not working reliably, and it sometimes misses key presses, and at other times it duplicates them. That way I ended up adding an olcAuthzRegexp that lacked a backspace. Unfrtunately when trying to ldapmodify the server I just got: modifying entry "cn=config" ldap_result: Can't contact LDAP server (-1) the regex in question is: olcAuthzRegexp: {3} "^dn:dnQualifier=uid\3D(^,)\\2Cou\\3Dpeople\\2Cdc\\3DXXX \\2Cdc\\3Dde$" "dn: uid=$1,ou=people,dc=XXX=de" As it turned out the server dumped core (100% reproducible). I know the regex is bad, but maybe it shouldn’t kill the server. The server is SUSE’s version that corresponds to some 2.5.x with patches. Anyway the backtrace is: Mar 17 14:36:23 v05 slapd[15911]: conn=1000 op=1 syncprov_matchops: recording uuid for dn=cn=config on opc=0x7fcfe0000d58 Mar 17 14:36:23 v05 slapd[15911]: slap_get_csn: conn=1000 op=1 generated new csn=20250317133623.651964Z#000000#005#000000 manage=1 Mar 17 14:36:23 v05 slapd[15911]: slap_queue_csn: queueing 0x7fcfe0106c70 20250317133623.651964Z#000000#005#000000 Mar 17 14:36:23 v05 kernel: slapd[15919]: segfault at 7fc81ceea633 ip 00007fcff658553e sp 00007fcfe9ff4e40 error 4 in libldap-2.5.releng.so.0.1.13[7fcff653b000+5c000] likely on CPU 1 (core 0, socket 2) Mar 17 14:36:23 v05 kernel: Code: 7f 08 4d 85 ff 75 9e 48 83 c4 18 b8 fa ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 90 48 85 ff 74 3b 41 54 55 31 ed 53 48 89 fb <48> 8b 7f 08 49 89 f4 48 85 ff 75 3e 48 8b 7b 10 48 85 ff 75 25 4d … Mar 17 14:36:23 v05 systemd[1]: Started Process Core Dump (PID 15922/UID 0). Mar 17 14:36:23 v05 systemd-coredump[15923]: [🡕] Process 15911 (slapd) of user 1000 dumped core. Stack trace of thread 15919: #0 0x00007fcff658553e ldap_avl_free (libldap-2.5.releng.so.0 + 0x4a53e) #1 0x0000555fb6ca9b42 rewrite_info_delete (slapd + 0xd6b42) #2 0x0000555fb6c64bae slap_sasl_regexp_config (slapd + 0x91bae) #3 0x0000555fb6c03a09 n/a (slapd + 0x30a09) #4 0x0000555fb6c091d3 config_set_vals (slapd + 0x361d3) #5 0x0000555fb6c0a14f config_parse_add (slapd + 0x3714f) #6 0x0000555fb6bfcdcc n/a (slapd + 0x29dcc) #7 0x0000555fb6bfdc96 n/a (slapd + 0x2ac96) #8 0x0000555fb6c8a523 overlay_op_walk (slapd + 0xb7523) #9 0x0000555fb6c8a6ae n/a (slapd + 0xb76ae) #10 0x0000555fb6c2dbd2 fe_op_modify (slapd + 0x5abd2) #11 0x0000555fb6c2f941 do_modify (slapd + 0x5c941) #12 0x0000555fb6c1618f n/a (slapd + 0x4318f) #13 0x0000555fb6c1698d n/a (slapd + 0x4398d) #14 0x00007fcff6583da0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #15 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #16 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15915: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15917: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15911: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a91a3 __pthread_clockjoin_ex (libc.so.6 + 0xa91a3) #2 0x0000555fb6c131ca slapd_daemon (slapd + 0x401ca) #3 0x0000555fb6bf688e main (slapd + 0x2388e) #4 0x00007fcff6240e6c __libc_start_call_main (libc.so.6 + 0x40e6c) #5 0x00007fcff6240f35 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x40f35) #6 0x0000555fb6bf690a _start (slapd + 0x2390a) Stack trace of thread 15913: #0 0x00007fcff632ee86 epoll_wait (libc.so.6 + 0x12ee86) #1 0x0000555fb6c1007b n/a (slapd + 0x3d07b) #2 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #3 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15918: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15914: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) ELF object binary architecture: AMD x86-64 Mar 17 14:36:23 v05 ldapmodify[15921]: DIGEST-MD5 common mech free Mar 17 14:36:23 v05 systemd[1]: slapd.service: Main process exited, code=dumped, status=11/SEGV Mar 17 14:36:23 v05 systemd[1]: slapd.service: Failed with result 'core-dump'. Mar 17 14:36:23 v05 systemd[1]: systemd-coredump(a)3-15922-0.service: Deactivated successfully. Kind regards, Ulrich Windl

2 1

Trying to set 'olcPasswordHash' I get "ldap_modify: Object class violation (65) additional info: attribute 'olcPasswordHash' not allowed"
by Windl, Ulrich 17 Mar '25

17 Mar '25

Hi! After having loaded pw-sha2 in oOpenmLDAp 2.5, I tried to set a new default hashing schema, but I fail to do so using dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcPasswordHash olcPasswordHash: {SSHA256} olcPasswordHash: {SSHA} ---- modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Object class violation (65) additional info: attribute 'olcPasswordHash' not allowed Before I had tried "replace" instead of "add", and I tried to place both values in one line as suggested by slapd-config: olcPasswordHash: <hash> [<hash>...] This option configures one or more hashes to be used in generation of user passwords stored in the userPassword attribute during processing of LDAP Password Modify Extended Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA}, {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}. The manual page also states: This setting is only allowed in the frontend entry. I'm running out of ideas. Kind regards, Ulrich Windl

3 11

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2025