openldap-technical

openldap-technical@openldap.org

5 participants
9888 discussions

Needed help with openldap backsock backend
by Gianluca Ramunno 16 Jun '25

16 Jun '25

Hello, I would need help with the openldap backsock backend. In the company I work for, we have a portal for authentication (Authelia) that uses an LDAP server to actually authenticate the users and to retrieve the information about the groups they belong to. In a short time, we will need to change the LDAP server which contains the users' database. To have a smooth transition between the old and the new LDAP server we are trying to implement an LDAP proxy using openldap+backsock backend + a python concurrent server that listens on the UNIX socket what will be used by the backsock backend. The LDAP proxy should try to authenticate to the new LDAP server and in case of failure with error 49 should try to authenticate to the old one. In case of another failure with error code 49 the LDAP proxy should return error 49 to Authelia. Otherwise it would return 0 and the list of groups the user belongs to. Now the issue. We noticed that the backsock backend closes the UNIX socket after every operation (bind, search, unbind...). We implemented a prototype of the python concurrent server that serves each request on the socket by forking a new child. When we started writing this server, we thought that the UNIX socked would have been kept open from the bind operation through other ops like a search until the final unbind. Instead, the actual behaviour of the backsock backend prevents establishing a correlation between a (successful) bind - i.e. a successful authentication - and a subsequent operation (e.g., a search). How to fix this? Did we miss something? If we modify the backsock backend to keep open the UNIX socket at the end of the bind op until the next bind or unbind and to use the open socket with the search op, would this be a (thread) safe modification? Thanks in advance. Best regards Gianluca Ramunno

2 2

(Stupid?) idea: Adding a scope option to ldapdelete
by Windl, Ulrich 16 Jun '25

16 Jun '25

A part of our DIT is imported from an external source, and that part needs to be refreshed. Those are several thousand entries. So I would like to delete all of the subtree's children, but not the base node (for some puristic motivation), and then I would import the new children (using a different naming schema possibly). As I understand it, there is no standard tool to do that (I could pipe the output of an ldapsearch into ldapdelete, maybe with some filtering between). As ldapdelete has no scope option (-s), I wonder whether it wouldn't be a nice addition, like this: -s base: deletes the entry if it has no children only (this is the default as I understand it) - s one: deletes all children of the entry that don't have children themselves - s sub: delete the entry and all it's children recursively (this is what "-r" enables as I understand it) What do you think? IMHO the logic needed is probably present in the code already, so it shouldn't be difficult to implement. Kind regards, Ulrich Windl

2 1

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

failure when trying to delete an entry found
by Windl, Ulrich 06 Jun '25

06 Jun '25

Hi! Trying to delete the result of an LDAP search, I have a problem: Using ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b "dc=services,dc=net,$DIT_BASE" \ -s one -z $SIZE_LIMIT '(objectClass=ipService)' dn | awk ' /^dn: / { # sub(/^dn: /, ""); print; } ' | ldapdelete -v -Y EXTERNAL -H ldapi:/// I get "deleting entry "dn: cn=1ci-smcs@3091/tcp,dc=services,dc=net,..." ldap_delete: Invalid DN syntax (34) additional info: invalid DN" And when I remove the "dn " in front I get "ldap_delete: Server is unwilling to perform (53) additional info: no global superior knowledge" What do I miss? Kind regards, Ulrich Windl

1 1

Q: CRL handling for multiple CAs
by Windl, Ulrich 05 Jun '25

05 Jun '25

Hi! I have a question: olcTLSCRLFile is SINGLE-VALUE in OpenLDAP 2.5 When I have different Sub-Cas (say one issuing host certificates, while another issues user certificates) I can handle only one CRL file obviously. Can this scenario be handled in OpenLDAP 2.5 (maybe like concatenating multiple CRLs)? What if the restriction SINGLE-VALUE is dropped? What about the idea adding a second token to olcTLSCRLFile that specifies a regex that must match the certificates subject to use that CRL? Kind regards, Ulrich Windl

2 2

Clarification on RDN Length Limit in MDB Backend (Symas/OpenLDAP 2.6.7)
by anilkumar.pathuri7＠gmail.com 05 Jun '25

05 Jun '25

Hi Team, I'm currently working with OpenLDAP (Symas 2.6.7) using the MDB backend, and we've encountered limitations with the length of a single RDN component while importing LDIFs. **Observed Behavior:** While `MDB_MAXKEYSIZE` is defined as 511 bytes, we found through testing that: - An RDN component (like `uid=...`) of **241 bytes** works - An RDN component of **242 bytes or more** consistently fails with: ldap_add: Other (e.g., implementation specific) error (80) - The full DN length is far below the 8192-byte DN limit, and only the RDN seems to be affected **Test Environment:** - OpenLDAP version: `Symas 2.6.7` - Backend: `mdb` - OS: `RHEL8` We confirmed this limit by iteratively creating entries with increasing `uid` lengths and saw consistent breakage at 242 bytes. **Questions:** 1. Is 241 & below bytes the *officially safe practical limit* for a single RDN in LMDB-based OpenLDAP setups? 2. Can we increase the limit? Reference link: https://www.openldap.org/lists/openldap-technical/201401/msg00239.html Regards, Anil P

3 2

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical