openldap-technical February 2026

openldap-technical@openldap.org

9 participants
6 discussions

Transform glue object to organizationalUnit
by cyril＠stoll.info 23 Mar '26

23 Mar '26

Hi For some reason (probably after update to openldap-ltb 2.6.10, or after reload due to renewed certificate) we lost one organizationalUnit object on one of our two provider servers. However there are still two user objects that belong to this lost organzationalUnit. Therefore openldap created a glue object for the lost organizationalUnit. On the second provider server (setup as multiprovider with the first one) the organzationalUnit object is still present and all looks like it should. I have no idea why one of the providers is still ok and the other is not since they are otherwise in sync as far as I can tell. Unfortunately I did not find clear instructions on how to handle this situation. The best instructions I found are 15 years old: http://blog.mycroes.nl/2010/06/recovering-from-glue-objects-in.html I have no experience with dumping everything with slapcat, deleting the whole database directory (scary) and importing everything again and it does sound a bit brutish. So I asked some AI and it suggested to use ldapmodify to replace the glue object with an ldif like this: dn: ou=serviceusers,dc=example,dc=com changetype: modify add: objectClass objectClass: organizationalUnit - add: ou ou: serviceusers However that did not work as I got the following error message: modifying entry "ou=serviceusers,dc=example,dc=com" ldap_modify: No such object (32) matched DN: ou=serviceusers,dc=example,dc=com So my question is do I have to use the method of dumping everything with slapcat and then changeing the ldif (rewrite glue to organziationalUnit, etc.) and importing it all again? Or is there a more elegant solution to get the organizationalUnit back? Thanks already in advance for every helping suggestion/link/explanation! Best regards, Cyril

6 12

RE26 testing call (2.6.13) #1
by Quanah Gibson-Mount 24 Feb '26

24 Feb '26

his is the first testing call for OpenLDAP 2.6.13. 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.13 Engineering Fixed liblber ber_bvreplace_x potential NULL dereference (ITS#10438) Fixed libldap heap buffer overflow in parse_whsp (ITS#10430) Fixed slap(add|modify) to not recreate config frontend (ITS#10414) Fixed slapd authzPrettyNormal function memory leak (ITS#10446) Fixed slapd memory leak in get_mra function (ITS#10445) Fixed slapd memory leak in parseAssert and parseReturnFilter functions (ITS#10450) Fixed slapd memory leak in parseReadAttrs function (ITS#10449) Fixed slapd slapd_sasl_mechs race condition (ITS#10443) Fixed slapd syncrepl to be more efficient with refresh task (ITS#10413) Fixed slapd unbind/close race condition (ITS#10258) Fixed slapd-ldap memory leak in ldap_chain_parse_ctrl function (ITS#10447) Fixed slapd-mdb always initialize pausepoll (ITS#10191) Fixed slapo-constraint to not propagate request controls to internal ops (ITS#10440) Fixed slapo-dds minttl incorrectly set in certain scenarios (ITS#10442) Fixed slapo-memberof to not propagate request controls to internal ops (ITS#10440) Fixed slapo-nestgroup to not propagate request controls to internal ops (ITS#10440) Fixed slapo-retcode to not propagate request controls to internal ops (ITS#10440) Fixed slapo-syncprov to not propagate request controls to internal ops (ITS#10440) Fixed slapo-syncprov memory leak in syncprov_parseCtrl (ITS#10448) Fixed slapo-translucent to not propagate request controls to internal ops (ITS#10440) Contrib Fixed slapo-autogroup to not propagate request controls to internal ops (ITS#10440) Minor Cleanup ITS#10427 ITS#10425 ITS#10451 --Quanah

4 4

Adding and stating syncrepl via olc
by Bastian Tweddell 19 Feb '26

19 Feb '26

Hi all, I have a question, if there is way that slapd automatically starts syncreplication after it was added to OLC. When installing a fresh slapd with olc config, it starts up with a bootstrap-olc. In the following step the bootstrap process (ansible) reconfigures mostly everything in cn=config, adding globals, ALCs, schema and the main MDB. As soon as the MDB database gets its syncrepl config, the log states it was successful: ``` Config: ** successfully added syncrepl rid=001 "ldaps://PROVIDER01.HOST" Config: ** successfully added syncrepl rid=002 "ldaps://PROVIDER02.HOST" ``` But after that the connections to the providers are not established. Even after waiting way longer then the configured timeout: ``` olcSyncrepl: {0}rid="001" provider="ldaps://PROVIDER01.HOST bind dn="DN_CONSUMER" bindmethod="simple" creden tials="SECRET" filter="(objectclass=*)" keepalive="180:9:75" retry= "20 3 60 10 300 +" schemachecking="on" searchbase="BASEDN " type="refreshAndPersist" olcSyncrepl: {1}rid="002" provider="ldaps://PROVIDER01.HOST bind dn="DN_CONSUMER" bindmethod="simple" creden tials="SECRET" filter="(objectclass=*)" keepalive="180:9:75" retry= "20 3 60 10 300 +" schemachecking="on" searchbase="BASEDN " type="refreshAndPersist" ``` I have to either restart the service or send slapd a SIGUSR1. Is there a way to configure the syncrepl via OLC so that the syncrepl process is initiated automatically when it was added? Many thanks, -- Bastian Tweddell Juelich Supercomputing Centre phone: +49 (2461) 61-6586 --------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Dr. Stephanie Bauer (stellvertretende Vorsitzende), Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers --------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------

2 8

Stupid question about accesslog, delta-syncrepl and efficiency
by Windl, Ulrich 17 Feb '26

17 Feb '26

Hi! Sorry for this stupid question: One argument for delta-syncrepl is that changing a small part of a large object is much more efficient, because pnly the changed data is logged and transferred. However with a multi-valued attributer like pwdHistory the accesslog entry contains all the unchanged values also. E.g.: … reqMod: pwdHistory:+ 20260207170142Z#1.3.6.1.4.1.1466.115.121.1.40#65#{SSHA256 }i56N/G7DutJ3OWdRXDBlSa/7CFN8XLM9X92RwUWohvQiQIEx+cVu9Q== … reqMod: modifyTimestamp:= 20260207170142Z reqOld: pwdHistory: 20240528115526Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}caF 961AUsh/ECAMdR2i/Iu+DS9Wi22z2 reqOld: pwdHistory: 20240528115715Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}RSu 8pPgFNIuDP/lBK1qylW+z5aEsr9hD reqOld: pwdHistory: 20240902115523Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}B8H FVqRKEheQWDonlsu6cyyMH4SNaQOz reqOld: pwdHistory: 20241018115412Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}9/R BrtPynf5D0cU+R1OGt+ZrdIK4mo0N reqOld: pwdHistory: 20241203075815Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}raC wwHLscnDFG0SwoH9MBbqI2CCfMlzX reqOld: pwdHistory: 20250115093324Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}iMd Qy6jvjwtQQXp5JZmAbLovyFsN1b8J reqOld: pwdHistory: 20250124090328Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}2wQ 4+aXKqOZC1w3uKULFeJ8kleum4Iy6 reqOld: pwdHistory: 20250306085113Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}aXQ 4DutidnaPGBiitGVAMv8Ebb8YMOOc reqOld: pwdHistory: 20250528131341Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}YDh Hw94sp0wdjWu9xzm4DKzpUioi5Wqf reqOld: pwdHistory: 20250822074239Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}Nog FGndg4AiHJEN59Is0JjLgFEx6TQr1 reqOld: pwdHistory: 20250924074514Z#1.3.6.1.4.1.1466.115.121.1.40#65#{SSHA256} lV7mACHa1hPG0RT7EzKM47+EzTz+xamL8+hx72FIG390xyRdnIqkwg== reqOld: pwdHistory: 20250929123923Z#1.3.6.1.4.1.1466.115.121.1.40#65#{SSHA256} kF37AmFjBZFrKeLVjQdemDTi6joE96s4FBhiSqejdSPLdosJVz2YZw== reqOld: pwdHistory: 20251118085003Z#1.3.6.1.4.1.1466.115.121.1.40#65#{SSHA256} f3eB5YSh/xdak80b/eVARKlo/f+vsbD4EbNFv/sfrpbSo2bGfNct6Q== Doesn’t that “cancel” the gain in efficiency? Kind regards, Ulrich Windl

3 4

About Translucent Overlay
by zacc_lxy 12 Feb '26

12 Feb '26

Dear openldap experts, Recently, we are trying to setup a Openldap proxy using translucent overlay. The proxy was configured successfully and we can read remote ldap contents through local proxy. Following the official instruction: https://www.openldap.org/doc/admin24/overlays.html?spm=5176.28103460.0.0.38…, we could see that for the basic attributes we fetched them from remote ldap server, whereas for the new attributes we fetched them from local mdb database. However, we met a special scenario that the instruction didn't mention, and we didn't know how to fulfill it : (1) Assuming there is a user stored in remote ldap server user.ldif dn:uid=user1,ou=People,dc=mydomain,dc=com uid:user1 cn:user1 objectClass:account objectClass:posixAccount objectClass:top objectClass:shadowAccount (2) We would like to add a new attribute in proxy (local mdb database) user_new.ldif dn:uid=user1,ou=People,dc=mydomain,dc=com changetype: modify add: objectClass objectClass: sambaSamAccount The difference was that: the objectClass consists of multiple lines, and account/posixAccount/top/shadowAccount was stored in remote, we just wanted to add a new lines for sambaSamAccount in local mdb. If I execute user_new.ldif then the user1 became that only contained objectClass: sambaSamAccount and account/posixAccount/top/shadowAccount was disappeared. Is there a way to fulfill that ? Thanks, Adrian Liu

2 1

Request for comment: allow ACLs to trigger based on op/controls
by Ondřej Kuzník 12 Feb '26

12 Feb '26

Dear community, for the next release, I've been preparing extensions to the ACL syntax to address a feature request that comes up relatively often - restrict access to data/actions based on what controls are involved. My thinking is that we could allow the following stanzas in the "access to <what>" part: - op=<operation name> or op=<OID> for extended requests - control=<OID> In here, we would probably provide a shorthand for known OIDs using the OID macro in schemas, so you could write something like this: ---- 8< ---- access to dn.subtree=ou=people,dc=example,dc=com attrs=userPassword control=ppolicy by anonymous auth access to dn.subtree=ou=people,dc=example,dc=com attrs=userPassword by group=cn=admin,ou=groups,dc=example,dc=com write by * none ---- 8< ---- As this is a deep change in how people work with ACLs, I'd like some feedback from the community at large before we commit to changing the syntax in a way that we have to live with for a long time. Have you needed something like this? Does the proposed addition solve your use-case? Can you see issues that are not covered or new ones that could crop up when used like this and might not be desirable? Any other feedback or proposals for how this could be expressed are also welcome. I'd like to add that this is unlikely to land until consensus has been achieved in the first place. For those happy to test actual code, the above proposal lives in a merge request: https://git.openldap.org/openldap/openldap/-/merge_requests/720 Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2026