openldap-technical June 2025

openldap-technical@openldap.org

10 participants
12 discussions

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

23 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 1

MDB monitoring: How many free pages actually?
by Windl, Ulrich 20 Jun '25

20 Jun '25

Hi, Considering this monitoring information, I wonder: olmMDBPagesMax: 12800 olmMDBPagesUsed: 9229 olmMDBPagesFree: 3810 Is the number of actual free pages 12800 - 9229 + 3810, i.e. "unallocated (12800 - 9229)" plus "usable" (3810)? How many free pages are needed before updates stop working? Kind regards, Ulrich Windl

3 5

Translucent/back_ldap and controls
by Bergmann, Clemens 19 Jun '25

19 Jun '25

Hi, we currently configuring openLDAP with translucent overlay to put in front of some legacy non-openLDAP LDAP servers. The translucent configuration is as follows: dn: olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcTranslucentConfig objectClass: top olcOverlay: {3}translucent olcDisabled: FALSE olcTranslucentBindLocal: TRUE dn: olcDatabase={0}ldap,olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config objectClass: olcConfig objectClass: olcDatabaseConfig objectClass: olcLDAPConfig objectClass: olcTranslucentDatabase objectClass: top olcDatabase: {0}ldap olcDbACLBind: bindmethod=simple binddn=cn=hidden credentials=secret tls_cacert=/etc/ssl/certs/ca-bundle.crt olcDbStartTLS: ldaps tls_cacert=/etc/ssl/certs/ca-bundle.crt olcDbURI: ldaps://legacy-ldap-sever/ olcDbUseTemporaryConn: TRUE Searching via ldapsearch and apache directory studio works fine. When testing with some other clients we got empty results. Looking into the requests with trace debugLevel we see that some of the clients use different controls in the requests. One of the clients used paging and only got some of the entries back. We could prevent this behavior by filtering the value from the rootDSE by adding the following olcAccess ‘{1}to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.319 by * none’. This “fixed” the problem for this client. Another client seems to use the manageDSAIT (2.16.840.1.113730.3.4.2) control. That seems to receive empty results. We can reproduce the results by adding ‘-E "2.16.840.1.113730.3.4.2"’ to the ldapsearch command. This will also result in an empty result. Unfortunately filtering the control in the same way did not work neither for ldapsearch nor for the other client. Had someone seen this seeming incompatibility of back_ldap with some or all controls. Mit freundlichen Grüßen Clemens (Bergmann) -- Clemens Bergmann [er/ihm; he/him] Gruppe Nutzermanagement und Entwicklung Technische Universität Darmstadt Hochschulrechenzentrum, Alexanderstraße 2, 64283 Darmstadt Tel. +49 6151 16 71184 <http://www.hrz.tu-darmstadt.de/> http://www.hrz.tu-darmstadt.de/

3 3

olcPPolicyForwardUpdates not working
by Benjamin Renard 18 Jun '25

18 Jun '25

Hello, I have problem with the olcPPolicyForwardUpdates option that seem not working : On master and slave, I configured Ppolicy with pwdLockout. When I try to connect on master with a bad password, the pwdFailureTime attribute of the entry is successfully updated, but not if I do the same on the slave. On slave, my ppolicy configuration is exactly the same as on master but I add olcPPolicyForwardUpdates=TRUE. I also configured the chain overlay and the updateref parameter on the database. Extract of my slave configuration : olcDatabase={1}mdb,cn=config [...] olcSyncrepl: [...] olcUpdateRef: ldaps://ldap-master olcOverlay={0}chain,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig objectClass: top olcOverlay: {0}chain olcChainReturnError: TRUE olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}mdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase objectClass: top olcDatabase: {0}ldap olcDbURI: ldaps://ldap-master olcDbIDAssertBind: bindmethod=simple binddn="[same user used in olcSyncrepl of the database]" credentials="secret" mode=self olcDbRebindAsUser: TRUE olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig objectClass: top olcOverlay: {1}ppolicy olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE olcPPolicyForwardUpdates: TRUE Do you have any idea of what I doing wrong ? Thanks, -- Benjamin Renard - Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com

3 20

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

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

(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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2025