openldap-technical May 2025

openldap-technical@openldap.org

17 participants
21 discussions

using refint overlay for pwdPolicySubentry
by Windl, Ulrich 10 Jun '25

10 Jun '25

Hi! Some time ago U had replaced a password policy, and it was quite sme work to replace all occurrences. So I thought reint cul help. I configured: dn: olcOverlay={4}refint,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcRefintAttribute: member olcRefintAttribute: pwdPolicySubentry olcOverlay: {4}refint And I did apply a test rename of the policy used by many users. I got no error from the modify, but slapd said many times: slapd[28826]: ppolicy_get: policy subentry cn=pp-default-2024-05x,...,dc=de missing or invalid at 'pwdPolicySubentry', no policy will be applied! Shouldn't refint have fixed those entries, or is there something special about password policy? The other thing I had noticed was that the MMR consumer did not complain at all, and it even looks as if the update wasn't sent. Did anybody try this before? When I checked for the member attribute by deleting a user, all members containing that user were removed, however. I see "modifiersName: cn=Referential Integrity Overlay", too. Same is true for a rename. Kind regards, Ulrich Windl

2 13

Q: lastbind, pwdLastSuccess, and authTimestamp
by Windl, Ulrich 02 Jun '25

02 Jun '25

Hi! Slapd-config states that pwdLastSuccess (provided by slapd) will be set if olcLastBind is set to true. However to do that the lastbind module/overlay is needed. But the latter sets authTimestamp. Slapo-policy documents that authTimestamp (provided by lastbind module) is set when lastbind is enabled. At it seems pwdLastSuccess and authTimestamp are set to the same value. Can someone explain the logic behind? I'm confused; do I really need the lastbind overlay? I'm using OpenLDAP 2.5.X Kind regards, Ulrich Windl

3 7

delta-syncrepl experience with OpenLDAP 2.5 (from SLES15)
by Windl, Ulrich 02 Jun '25

02 Jun '25

Hi! When upgrading from OpenLDAP 2.4 (SLES12) to OpenLDAP 2.5 (SLES15) I gave delta-syncrepl a try. That was a hard way in several aspects. Meanwhile I think I understand most of the details (docs could be much better IMHO). Where delta-syncrepl has big problems is when sync has been set up, but one database is reloaded and some UUIDs are newly created for entries that exist on the other server(s). Somehow slapd detects that problem and claims that a “content sync” is required, but after some time it seems to start a refresh anyway. When I did the content load on the other server, slapd quit with a core dump. Unfortunately I had quite a lot of core dumps during my testing. So I feel delta-syncrepl is not as solid as it should be (in the version provided with SLES15 SP6). Some of the logs: May 27 13:37:05 v06 slapd[27194]: do_syncrep1: rid=105 starting refresh (sending cookie=rid=105,sid=006,csn=20130708113956.028116Z#000000#000#000000;20240708090039.074592Z#000000#001#0> May 27 13:37:05 v06 slapd[27194]: do_syncrep2: rid=105 LDAP_RES_SEARCH_RESULT May 27 13:37:05 v06 slapd[27194]: do_syncrep2: rid=105 delta-sync lost sync, switching to REFRESH May 27 13:37:05 v06 slapd[27194]: do_syncrep2: rid=105 (4096) Content Sync Refresh Required May 27 13:41:36 v06 slapd[27194]: do_syncrep1: rid=105 starting refresh (sending cookie=rid=105,sid=006,csn=20130708113956.028116Z#000000#000#000000;20240708090039.074592Z#000000#001#0> May 27 13:41:36 v06 slapd[27194]: do_syncrep2: rid=105 LDAP_RES_INTERMEDIATE - SYNC_ID_SET May 27 13:41:36 v06 slapd[27194]: syncrepl_message_to_entry: rid=105 DN: cn=config, UUID: 85353d82-cf3a-103f-9d14-755ae58f92b6 May 27 13:41:36 v06 slapd[27194]: syncrepl_entry: rid=105 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f6b1b7fe6c0 … May 27 13:43:33 v06 slapd[27194]: do_syncrepl: rid=105 rc -1 retrying (4 retries left) May 27 13:43:34 v06 slapd[27194]: conn=1008 op=2 syncprov_op_search: got a persistent search with a cookie=rid=106,sid=005,csn=20130708113956.028116Z#000000#000#000000;20240708090039.0> May 27 13:43:34 v06 slapd[27194]: conn=1008 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1008 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1008 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1008 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_op_search: got a persistent search with a cookie=rid=116,sid=005,csn=20130719093756.074776Z#000000#000#000000;20250217105250.3> May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_op_search: no change, skipping log replay May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_op_search: nothing changed, finishing up initial search early May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1011 op=2 syncprov_op_search: got a persistent search with a cookie=rid=106,sid=005,csn=20130708113956.028116Z#000000#000#000000;20240708090039.0> May 27 13:43:34 v06 slapd[27194]: conn=1011 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1011 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1011 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1011 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_op_search: got a persistent search with a cookie=rid=116,sid=005,csn=20130719093756.074776Z#000000#000#000000;20250217105250.3> May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_op_search: no change, skipping log replay May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_op_search: nothing changed, finishing up initial search early May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_op_search: got a persistent search with a cookie=rid=116,sid=005,csn=20130719093756.074776Z#000000#000#000000;20250217105250.3> May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_op_search: no change, skipping log replay May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_op_search: nothing changed, finishing up initial search early May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1013 op=2 syncprov_op_search: got a persistent search with a cookie=rid=106,sid=005,csn=20130708113956.028116Z#000000#000#000000;20240708090039.0> May 27 13:43:34 v06 slapd[27194]: conn=1013 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1013 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1013 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1013 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1014 op=2 syncprov_op_search: got a persistent search with a cookie=rid=106,sid=005,csn=20130708113956.028116Z#000000#000#000000;20240708090039.0> May 27 13:43:34 v06 slapd[27194]: conn=1014 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1014 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 systemd[1]: Started Process Core Dump (PID 27241/UID 0). May 27 13:43:35 v06 systemd-coredump[27242]: [🡕] Process 27194 (slapd) of user 76 dumped core. Stack trace of thread 27199: #0 0x00007f6b34ca8dfc __pthread_kill_implementation (libc.so.6 + 0xa8dfc) #1 0x00007f6b34c57842 raise (libc.so.6 + 0x57842) #2 0x00007f6b34c3f5cf abort (libc.so.6 + 0x3f5cf) #3 0x00007f6b34c3f4e7 __assert_fail_base.cold (libc.so.6 + 0x3f4e7) #4 0x00007f6b34c4fb32 __assert_fail (libc.so.6 + 0x4fb32) #5 0x00007f6b34787258 n/a (syncprov.so + 0xc258) #6 0x000055765d7e04f3 overlay_op_walk (slapd + 0xb74f3) #7 0x000055765d7e06be n/a (slapd + 0xb76be) #8 0x000055765d76ee54 fe_op_search (slapd + 0x45e54) #9 0x000055765d76e726 do_search (slapd + 0x45726) #10 0x000055765d76c18f n/a (slapd + 0x4318f) #11 0x000055765d76c98d n/a (slapd + 0x4398d) #12 0x00007f6b34ff7da0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #13 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #14 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27194: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca8b83 __pthread_clockjoin_ex (libc.so.6 + 0xa8b83) #2 0x000055765d7691ca slapd_daemon (slapd + 0x401ca) #3 0x000055765d74c88e main (slapd + 0x2388e) #4 0x00007f6b34c40e6c __libc_start_call_main (libc.so.6 + 0x40e6c) #5 0x00007f6b34c40f35 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x40f35) #6 0x000055765d74c90a _start (slapd + 0x2390a) Stack trace of thread 27204: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27198: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27197: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27202: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27200: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27203: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27196: #0 0x00007f6b34d2e796 epoll_wait (libc.so.6 + 0x12e796) #1 0x000055765d76607b n/a (slapd + 0x3d07b) #2 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #3 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) ELF object binary architecture: AMD x86-64 May 27 13:43:35 v06 systemd[1]: systemd-coredump(a)5-27241-0.service: Deactivated successfully. Kind regards, Ulrich Windl

2 2

back-sock module: error "socket connect(<socket_file_name>) failed"
by Gianluca Ramunno 30 May '25

30 May '25

Hello all, I'm a newbie in LDAP/OpenLDAP. I have to implement an LDAP proxy that "simply" authenticates a user against a first LDAP server and, if it fails for invalid credentials, tries to authenticate against a second LDAP server. I've found OpenLDAP and the back-sock backend as a possible way to implement such a scheme, using a python script as a concurrent server listening on the UNIX socket that will be used by the backend back-sock. I'm currently using Ubuntu 22.04 and OpenLDAP 2.5.19 for testing. Now I have a concurrent server in python that works well: it accepts a connection on a UNIX socket, prints what it receives over the connection and closes it. I tested it with a simple python client. On the OpenLDAP side, instead, I have a big issue: I tried to configure the backend using the legacy mode (the slapd.conf config file will follow), but when I try to run the command ldapwhoami -x -D "cn=admin,dc=example,dc=com" -W -H ldap://localhost (with "dc=example,dc=com" replaced with the base DN I used in the configuration during the installation phase) on the same machine where slapd is running, the command returns: ldap_bind: Invalid credentials (49) using the right password input during installation phase, while on the server side in the log I found the error message: socket connect(<socket_file_name>) failed and the server python does not give any sign of accepting a connection. Setting the loglevel to -1 or starting slapd with strace ( strace slapd -d -1 ) does not provide further information. NOTE that the above ldapwhoami command worked fine with the original configuration with the new method in the slapd.d folder. This is the config file I created to use the back-sock backend: modulepath /usr/lib/ldap moduleload back_sock.la include /etc/ldap/schema/core.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args #loglevel 256 loglevel -1 database sock socketpath /tmp/ldsock suffix "dc=proxy,dc=ldap" Any clue? Thanks in advance Gianluca Ramunno

1 1

auditlogs not listed in monitor database
by Windl, Ulrich 27 May '25

27 May '25

Hi! I have an odd effect: Using ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b 'cn=Databases,cn=monitor' -s sub '(monitoredInfo=mdb)' description monitoredInfo monitorCounter I only get two databases: # Database 1, Databases, Monitor dn: cn=Database 1,cn=Databases,cn=Monitor monitoredInfo: mdb ... olmDbDirectory: /var/lib/ldap/ # Database 3, Databases, Monitor dn: cn=Database 3,cn=Databases,cn=Monitor monitoredInfo: mdb ... olmDbDirectory: /var/lib/ldap/audit/ However I have two mode MDB databases used as auditlog/changelog. Why aren't hose displayed? Kind regards, Ulrich Windl

1 1

Cannot connect over TLS/SSL (ldaps) on v2.6.9
by Nick Milas 26 May '25

26 May '25

Hello, I have managed to start the migrated LDAP server on Rocky 9, v2.6.9 LTB. It seems to be working fine but, I cannot connect over ssl (ldaps, port 636). I am trying to connect with Apache Directory Studio but it fails, although I am using the same certificate as on the orignal server (the cert covers both server names). I have enabled conns logging on the server and I see connection coming in, but for some reason it fails (input error=-2): Could you please guide me to troubleshoot this? May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 busy May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: accept() = 14* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: listen=9, new connection on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: added 14r (active) listener=(nil)* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 fd=14 ACCEPT from IP=195.251.xxx.xxx:51334 (IP=0.0.0.0:636)* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 fd=14 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 op=0 BIND dn="uid=userx,ou=people,dc=noa,dc=gr" method=128 May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 op=0 BIND dn="uid=userx,ou=people,dc=noa,dc=gr" mech=SIMPLE bind_ssf=0 ssf=256 May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 op=0 RESULT tag=97 err=0 qtime=0.000034 etime=0.000475 text=* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:44 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:44 ldap1.noa.gr slapd[17512]: May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:44 ldap1.noa.gr slapd[17512]: connection_read(14): input error=-2 id=1002, closing. May 21 11:19:44 ldap1.noa.gr slapd[17512]: connection_closing: readying conn=1002 sd=14 for close May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: removing 14 May 21 11:19:44 ldap1.noa.gr slapd[17512]: conn=1002 fd=14 closed (connection lost)*May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:44 ldap1.noa.gr slapd[17512]: May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL I have tried removing the olcTLSCipherSuite attribute, but it won't work anyway. As a side note, I see that logging is directed to the journal. Could I redirect it to a file instead? I have set olcLogFile, but logging is directed to the journal nevertheless. Thanks a lot, Nick

4 4

Reminder: Long Term Support release series is now OpenLDAP 2.6
by Quanah Gibson-Mount 23 May '25

23 May '25

With the release of OpenLDAP 2.6.10, the OpenLDAP 2.6 release series is now the long term support release. 2.5.20 is the last planned release for the OpenLDAP 2.5 series. Regards, Quanah

1 0

slapadd a 2.4 cn=config ldif into 2.6 fails
by Nick Milas 20 May '25

20 May '25

Hello, I am trying to migrate our 2.4.58 Openldap (LTB on CentOS 7) to 2.6.9 (LTB on Rocky 9). I slapcat'ed the config DIT and data DIT and I am currently trying to import them into the new installation. I have removed ppolicy schema and tried to slapadd, but it fails: [root@ldap1 openldap]# slapadd -vvv -n0 -F /usr/local/openldap/etc/openldap/slapd.d -l /root/work/ldap-mig2/config-dit.ldif added: "cn=config" (00000001) added: "cn=schema,cn=config" (00000001) added: "cn={0}core,cn=schema,cn=config" (00000001) added: "cn={1}cosine,cn=schema,cn=config" (00000001) added: "cn={2}inetorgperson,cn=schema,cn=config" (00000001) added: "cn={3}nis,cn=schema,cn=config" (00000001) added: "cn={4}eduperson,cn=schema,cn=config" (00000001) added: "cn={5}postfix,cn=schema,cn=config" (00000001) added: "cn={6}dyngroup,cn=schema,cn=config" (00000001) added: "cn={7}misc,cn=schema,cn=config" (00000001) added: "cn={8}schac-20090326-1,cn=schema,cn=config" (00000001) added: "cn={9}dnsdomain2,cn=schema,cn=config" (00000001) added: "cn={10}proftpd-quota,cn=schema,cn=config" (00000001) added: "cn={11}kerberos,cn=schema,cn=config" (00000001) added: "cn={12}localemailrecipient,cn=schema,cn=config" (00000001) added: "cn={13}entryaccess,cn=schema,cn=config" (00000001) added: "cn={14}radius,cn=schema,cn=config" (00000001) added: "cn={15}pdns-domaininfo,cn=schema,cn=config" (00000001) added: "olcDatabase={-1}frontend,cn=config" (00000001) added: "olcDatabase={0}config,cn=config" (00000001) <= str2entry: str2ad(olcDbNoSync): attribute type undefined slapadd: could not parse entry (line=2913) Closing DB... If I understand right, the process seems to be disturbed by the olcDbNoSync attribute: <= str2entry: str2ad(olcDbNoSync): attribute type undefined What may be the cause? I have seen in the Internet earlier reports of this error during slapadd but there is no single reason. Please advise. Thanks in advance, Niick

2 3

openldap TLSv1.0 is enabled
by Andre Rodier 16 May '25

16 May '25

Hello, I have configured OpenLDAP using SSL certificate, but I have a few issues. Here the TLS configuration, especially "olcTLSProtocolMin: 3.3" > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > # CRC32 c70363a6 > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/slapd/slapd.args > olcLogLevel: none > olcPidFile: /var/run/slapd/slapd.pid > olcToolThreads: 1 > structuralObjectClass: olcGlobal > entryUUID: 40ee991a-0efe-103d-855a-11ff3a5638b4 > creatorsName: cn=config > createTimestamp: 20221213065102Z > olcPasswordCryptSaltFormat: $6$%.16s > olcTLSCACertificateFile: /etc/ldap/certs/ldap.homebox.world.issuer.crt > olcTLSCertificateKeyFile: /etc/ldap/certs/ldap.homebox.world.key > olcTLSCertificateFile: /etc/ldap/certs/ldap.homebox.world.crt > olcTLSProtocolMin: 3.3 > entryCSN: 20221214054517.926245Z#000000#000#000000 > modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > modifyTimestamp: 20221214054517Z But if I try sslscan: I see TLSv1.0, TLSv1.1 and TLSv1.2 enabled. Why ? > root@main:/etc/ldap/changes# sslscan ldap.homebox.world:636 > Version: 2.0.7 > OpenSSL 1.1.1n 15 Mar 2022 > > Connected to 2001:19f0:7402:86e:5400:4ff:fe38:b9b4 > > Testing SSL server ldap.homebox.world on port 636 using SNI name ldap.homebox.world > > SSL/TLS Protocols: > SSLv2 disabled > SSLv3 disabled > TLSv1.0 enabled > TLSv1.1 enabled > TLSv1.2 enabled > TLSv1.3 enabled > > TLS Fallback SCSV: > Server supports TLS Fallback SCSV > > TLS renegotiation: > Secure session renegotiation supported > > TLS Compression: > OpenSSL version does not support compression > Rebuild with zlib1g-dev package for zlib support > > Heartbleed: > TLSv1.3 not vulnerable to heartbleed > TLSv1.2 not vulnerable to heartbleed > TLSv1.1 not vulnerable to heartbleed > TLSv1.0 not vulnerable to heartbleed > > Supported Server Cipher(s): > Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 128 bits TLS_AES_128_CCM_SHA256 Curve 25519 DHE 253 > Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253 > Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits AES256-GCM-SHA384 > Accepted TLSv1.2 256 bits AES256-CCM > Accepted TLSv1.2 128 bits AES128-GCM-SHA256 > Accepted TLSv1.2 128 bits AES128-CCM > Accepted TLSv1.2 256 bits AES256-SHA > Accepted TLSv1.2 128 bits AES128-SHA > Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 256 bits AES256-SHA > Accepted TLSv1.1 128 bits AES128-SHA > Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 256 bits AES256-SHA > Accepted TLSv1.0 128 bits AES128-SHA > > Server Key Exchange Group(s): > TLSv1.3 128 bits secp256r1 (NIST P-256) > TLSv1.3 192 bits secp384r1 (NIST P-384) > TLSv1.3 260 bits secp521r1 (NIST P-521) > TLSv1.3 128 bits x25519 > TLSv1.3 224 bits x448 > TLSv1.3 112 bits ffdhe2048 > TLSv1.3 128 bits ffdhe3072 > TLSv1.3 150 bits ffdhe4096 > TLSv1.3 175 bits ffdhe6144 > TLSv1.3 192 bits ffdhe8192 > TLSv1.2 128 bits secp256r1 (NIST P-256) > TLSv1.2 192 bits secp384r1 (NIST P-384) > TLSv1.2 260 bits secp521r1 (NIST P-521) > TLSv1.2 128 bits x25519 > TLSv1.2 224 bits x448 > > SSL Certificate: > Signature Algorithm: sha256WithRSAEncryption > RSA Key Strength: 2048 > > Subject: ldap.homebox.world > Altnames: DNS:ldap.homebox.world > Issuer: (STAGING) Artificial Apricot R3 > > Not valid before: Dec 13 05:34:29 2022 GMT > Not valid after: Mar 13 05:34:28 2023 GMT Thanks for your insights. Andre

6 13

RE26 testing call (2.6.10) #1
by Quanah Gibson-Mount 15 May '25

15 May '25

This is the first testing call for OpenLDAP 2.6.10. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.6.10 Engineering Added slapd microsecond timestamp format for local logging (ITS#10140) Fixed libldap ldap_result behavior with LDAP_MSG_RECEIVED (ITS#10229) Fixed lloadd handling of starttls critical (ITS#10323) Fixed slapd syncrepl when used with slapo-rwm (ITS#10290) Fixed slapd regression with certain searches (ITS#10307) Fixed slapo-autoca olcAutoCAserverClass object (ITS#10288) Fixed slapo-pcache caching behaviors (ITS#10270) Minor Cleanup ITS#7080 ITS#7249 ITS#9934 ITS#10020 ITS#10168 ITS#10226 ITS#10279 ITS#10299 ITS#10302 ITS#10309 ITS#10312 ITS#10320 ITS#10325 ITS#10327 ITS#10328 ITS#10331 Regards, Quanah

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2025