openldap-technical June 2025

openldap-technical@openldap.org

18 participants
20 discussions

Proxy Protocol support for ldap client
by BECOT Jérôme 07 Jul '25

07 Jul '25

Hello, We use the proxy protocol with our openldap 2.5 servers (pldaps). I noticed that client binaries allow pldaps as protocol in the host address option starting with 2.5, but how can I add proxy headers to the request to communicate with my servers ? I think that there might be something with '-o' that I'm not aware of. Thanks for your help. Jerome

3 3

slapadd: could not add entry dn="cn=config" (line=1):
by Nick 01 Jul '25

01 Jul '25

Does anyone know the source and resolution to this installation error? Interestingly, if I use an alternate command I'm able to bring up the server, in which I can see via debug it's responding to the client. I'm following: https://www.openldap.org/doc/admin24/quickstart.html Import the configuration database su root -c /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif and encounter this error. I see many posts on it with no resolution. I'm using MacPorts openldap 2.6.10. Interestingly, if I invoke this suggested command: /opt/local/libexec/slapd -f /opt/local/etc/openldap/slapd.conf -F /opt/local/etc/slapd.d I can invoke slapd and my LDAP server comes up. It responds back to: /opt/local/bin/ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts but without dc=site,dc=com only blank dn: dn: # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 There is nothing in my etc/slapd.d directory. I try: ldapadd -d 3 -x -D "cn=Manager,dc=p0,dc=mac" -W -f file.txt Enter LDAP Password: ldap_bind: Invalid DN syntax (34) additional info: invalid DN Not sure how to approach this and any guidance appreciated.

3 2

Translucent proxy with posix attributes and sssd
by Howard, Christopher 30 Jun '25

30 Jun '25

I currently manage ldap for a subset of users at our organization for some separate systems. The organization also uses ldap for all of its users. My separate ldap server uses different usernames for its users. I've been tasked with getting rid of this separate ldap, migrating all of our systems over to the central ldap and having users use their normal organizational credentials. To that end, I've created a new ldap server as a translucent proxy. The central ldap does not contain posix attributes. I'm not being permitted to create them and they are not willing to add them. I've tested with my new proxy that I can search for a user, retrieve all of their back end ldap attributes and all of my local overlay attributes. The translucent proxy is working. Now I'm to the step of setting up sssd to authenticate users on linux hosts. This is not working because sssd searches using a filter that contains objectclass=posixAccount and uidNumber. I've ensured that those values are in my overlay, but they do not exist in the back end ldap. As a result, I get no user returned from the search. I've changed sssd config to make objectclass=person in the search filter, but that still leaves the uidNumber issue. Is there any way around this? I've exhausted the documentation for sssd and don't see it. Is there a way in the ldap proxy to handle this? Do I need to set olcTranslucentLocal to define the local only attributes? My guess is I'll have the same issue with groups and gidNumber when I get to that step of the process as well. If this is a dead end, are there any other options to do what I need to do? Thank you, -Christopher

2 1

Odd "<= str2entry NULL (smr_normalize createTimestamp 21)" when trying slapadd to cn=config
by Windl, Ulrich 30 Jun '25

30 Jun '25

Hi! Trying to create the initial config from LDIF using "slapadd -v -F /etc/openldap/slapd.d -w -S 3 -n0 -l 0.ldif" inSLES15 I get this: added: "cn=config" (00000001) added: "cn=module{0},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}rfc2307bis,cn=schema,cn=config" (00000001) added: "cn={4}yast,cn=schema,cn=config" (00000001) added: "cn={5}sudo,cn=schema,cn=config" (00000001) added: "olcDatabase={-1}frontend,cn=config" (00000001) <= str2entry NULL (smr_normalize createTimestamp 21) slapadd: could not parse entry (line=2360) Closing DB... I've done that on a different machine without any errors so far. The LDIF entry after "olcDatabase={-1}frontend,cn=config" is "dn: olcDatabase={0}config,cn=config". The timestamps are: creatorsName: cn=config createTimestamp: 20130712083810Z entryCSN: 20160222141054.581517Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20160222141054Z An "interesting" fact I found in /etc/openldap/slapd.d/cn=config/cn=schema.ldif was the end of the file; it reads: ... anslucentNoGlue $ olcTranslucentLocal $ olcTranslucentRemote $ olcTranslucent BindLocal $ olcTranslucentPwModLocal ) )lucent target database configuration' AUXILIARY )lue uniqueness configuration' SUP olcOverlayConfig STRUCTURAL MAY ( olcUniqueBase $ olcUniqueIgnore $ olcUniqueAttribute $ olcUniqueStrict $ o lcUniqueURI ) )g configuration' SUP olcOverlayConfig STRUCTURAL MUST olcValSo rtAttr )LIARY MAY ( olmBDBEntryCache $ olmBDBDNCache $ olmBDBIDLCache $ olmDb Directory ) )NSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )MAN-READABLE 'TRUE' )tion' )DABLE 'TRUE' )ADABLE 'TRUE' )TRANSFER-REQUIRED 'TRUE' X-NOT-HU MAN-READABLE 'TRUE' )NARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE ' )INARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )ficate' X-BINA RY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )ription' )scription' )umber' )ABLE 'TRUE' )DABLE 'TRUE' )ess Points' )tion' )cription' )' )' )ion ' ) ) ) )X-BINARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )tifie r' )on' )n' )on' )) Exact Assertion' ) Assertion' ) ) That doesn't look right for me. CPU here is an "AMD EPYC 9354P 32-Core Processor", while the other machine without problems ran with VMware and "Intel(R) Xeon(R) Gold 6238R CPU @ 2.20GHz"; Looks like the last write to the config database is nor correct in case of errors. Neither option "-c" (continue), nor "-o value-check=no", nor "-o schema-check=no" did help. After some experiments I get a different error like "<= str2entry NULL (smr_normalize creatorsName 21)" Any insights? Kind regards, Ulrich Windl

1 1

Assert failed in ldap_do_free_request()
by radiatejava 29 Jun '25

29 Jun '25

Hello experts We are using OpenLDAP lib ver 2.6.7 on Ubuntu 24.04. When doing LDAP search using ldap_search_ext_s() we are getting assert failure. Any idea what could be going wrong? Appreciate your reply. Here is the stacktrace: #0 0x000071e8baceeb2c in pthread_kill () from /usr/lib/x86_64-linux-gnu/libc.so.6 #1 0x000071e8bac9527e in raise () from /usr/lib/x86_64-linux-gnu/libc.so.6 #2 0x000071e8bac788ff in abort () from /usr/lib/x86_64-linux-gnu/libc.so.6 #3 0x000071e8bac7881b in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6 #4 0x000071e8bac8b517 in __assert_fail () from /usr/lib/x86_64-linux-gnu/libc.so.6 #5 0x000071e8b9684409 in ldap_do_free_request () from /opt/ldap/lib/libldap.so.2 #6 0x000071e8b96b4bf9 in ldap_tavl_free () from /opt/ldap/lib/libldap.so.2 #7 0x000071e8b968359a in ldap_free_connection () from /opt/ldap/lib/libldap.so.2 #8 0x000071e8b9683e9c in ldap_new_connection () from /opt/ldap/lib/libldap.so.2 #9 0x000071e8b9682aa7 in ldap_send_server_request () from /opt/ldap/lib/libldap.so.2 #10 0x000071e8b9685619 in ldap_chase_v3referrals () from /opt/ldap/lib/libldap.so.2 #11 0x000071e8b9667640 in try_read1msg () from /opt/ldap/lib/libldap.so.2 #12 0x000071e8b9666515 in wait4msg () from /opt/ldap/lib/libldap.so.2 #13 0x000071e8b9665f09 in ldap_result () from /opt/ldap/lib/libldap.so.2 #14 0x000071e8b9672a95 in ldap_sasl_bind_s () from /opt/ldap/lib/libldap.so.2 #15 0x000071e8b96740b2 in ldap_simple_bind_s () from /opt/ldap/lib/libldap.so.2 #16 0x000071e8bb737e2a in myapp::getRebindCredentials(ldap*, char const*, unsigned long, int, void*) () from /mgmt/usr/lib/x86_64-linux-gnu/libsvc_myapp.so #17 0x000071e8b9683e0b in ldap_new_connection () from /opt/ldap/lib/libldap.so.2 #18 0x000071e8b9682aa7 in ldap_send_server_request () from /opt/ldap/lib/libldap.so.2 #19 0x000071e8b9685619 in ldap_chase_v3referrals () from /opt/ldap/lib/libldap.so.2 #20 0x000071e8b9667640 in try_read1msg () from /opt/ldap/lib/libldap.so.2 #21 0x000071e8b9666515 in wait4msg () from /opt/ldap/lib/libldap.so.2 #22 0x000071e8b9665f09 in ldap_result () from /opt/ldap/lib/libldap.so.2 #23 0x000071e8b966acf7 in ldap_pvt_search_s () from /opt/ldap/lib/libldap.so.2 #24 0x000071e8b966ac25 in ldap_search_ext_s () from /opt/ldap/lib/libldap.so.2 #25 0x000071e8bb732c15 in myapp::LdapAuthenticationBroker::doLdapAuthenticate() () from /mgmt/usr/lib/x86_64-linux-gnu/libsvc_myapp.so #26 0x000071e8bb732484 in myapp::LdapAuthenticationBroker::start(bool&, void (*)(myapp::ExternalAuthenticationBroker*)) () from /mgmt/usr/lib/x86_64-linux-gnu/libsvc_myapp.so

3 4

Configuring LDAP server and NFS client, login credentials and to mount NFS directories?
by Nick 29 Jun '25

29 Jun '25

Does anyone know the steps to configure a LDAP server to provide login credentials to a client (Linux) and NFS mount points? I think this is some industry standard for authenticating and automatically mounting NFS directories. So far, I have configured: - NFS server (MacOS) - QEMU for VM - DHCP/BootP server to provide NIS/LDAP options (IP of NIS and LDAP servers) - openldap server, tested installation However, I'm looking for the next steps to accomplish such a task. This could include any references to web pages on the topic.

1 0

Another request related to openldap backsock backend
by Gianluca Ramunno 26 Jun '25

26 Jun '25

Hello, I made quite some progress with developing an LDAP proxy using openldap + backsock backend + a python server. The backsock backend and the python server communicate via UNIX socket according to the protocol described here: https://linux.die.net/man/5/slapd-sock The python server at the moment implements the execution of the BIND and of the SEARCH operations against a remote LDAP server and returns back the results to the backsock backend. Using the command ldapsearch I perform some SEARCH operations and I see a weird behaviour when the output is printed out by ldapsearch; I request a number of attributes which are returned correctly by the remote LDAP server to the python server, then the latter prepares an LDIF chunk with the returned entry (with all requested attributes) and sends this chunk back to the openldap backsock backend via UNIX socket. Unfortunately, ldapsearch prints out the received entry with a lower number of attributes. The missing attributes are always the same (at a repeated execution of the same SEARCH), but non necessarily the last one(s). I don't receive back any error. In the python server I also print out the whole LDIF chunk just before sending it back to the backsock backend and all attributes are there. I also checked that the protocol between backsock backend and the python server is correct according to the specifications. Note that if I perform the same SEARCH operations with ldapsearch directly against the remote LDAP server (i.e. without the LDAP proxy in between), all requested attributes are returned and printed correctly. Any clue on what's happening or on how to debug this problem in openldap? Thank you in advance. Best regards Gianluca Ramunno

1 1

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

26 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 3

Q: Unexpected ldapsearch results (result incomplete)
by Windl, Ulrich 26 Jun '25

26 Jun '25

Hi! I thought I had exported a subtree of out OpenLDAP 2.4 server, when I realized that the result is incomplete. So I started investigating (still OpenLDAP 2.4): # ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b "$BASE" -s one -o ldif-wrap=no '(objectClass=ipService)' ### produces a lot of entries but at least one specific entry is missing! When trying to add the entry I get "Already exists (68)" from ldapadd for cn=zip@6/ddp, "$BASE # ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b "$BASE" -s one -o ldif-wrap=no '(cn=zip@6/ddp)' Finds the entry # ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b "$BASE" -s one -o ldif-wrap=no ' (&(objectClass=ipService)(cn=zip@6/ddp))' Also finds the entry # ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b "$BASE" -s one -o ldif-wrap=no '(&(objectClass=ipService))' | grep cn=zip Results in no match I don't have a sizelimit set when searching. Adding options like "-z 99999 -l 30" had no effect. Any ideas? When found the result looks like this: # extended LDIF # # LDAPv3 # base <$BASE> with scope oneLevel # filter: (&(objectClass=ipService)(cn=zip@6/ddp)) # requesting: ALL # # zip@6/ddp, services.net.sap.klinik.uni-regensburg.de dn: cn=zip@6/ddp,$BASE objectClass: ipService ipServicePort: 6 ipServiceProtocol: ddp cn: zip cn: zip@6/ddp description: Zone Information Protocol # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ($BASE was substituted by me) Kind regards, Ulrich Windl

2 2

OpenLDAP BIND requiring privileged DN first
by Carl Waldbieser 24 Jun '25

24 Jun '25

I am using OpenLDAP as the credential backend to an SSO solution. The SSO software attempts a simple BIND with the user DN and the password supplied by the user. This all works as intended. However, there are some legacy web applications that pre-date our SSO solution that use direct LDAP authentication. That is, the web application collects the user password from a form submission, and then it makes its own BIND attempt with the user DN and supplied password. These legacy apps have legitimate reasons to connect to our LDAP service for non-authentication purposes. Is there a way that I can prevent BINDs for normal user DNs from any source other than the SSO software? Network-based solutions do not seem to be an option because all these applications have their private IP addresses assigned dynamically. I had tried setting up access control rules to only allow the "auth" access level to unprivileged user entries by already authenticated users, but that doesn't seem to work. In the OpenLDAP logs, I see the privileged BIND is successful. However, when issuing a second BIND for the unprivileged user, OpenLDAP first logs: BIND anonymous mech=implicit bind_ssf=0 ssf=0 and then the subsequent normal user BIND fails, as anonymous BINDs are not allowed for those entries. I'm not sure if this is part of the LDAP protocol or due to the LDAP client I am using, or something related to the OpenLDAP service. I have tried 2 different clients with similar results. Is my approach to this issue technically possible? Are there other solutions? Thanks, Carl Waldbieser ITS Lafayette College

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2025