openldap-technical August 2025

openldap-technical@openldap.org

9 participants
14 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

Removing AutoCA overlay, objectClass, etc
by Brendan Kearney 06 Nov '25

06 Nov '25

list members, i have a multi-provider footprint that i want to remove the AutoCA functionality from. when i loaded the overlay, i set it to disabled, per the below: dn: olcOverlay={5}autoca objectClass: olcOverlayConfig objectClass: olcAutoCAConfig objectClass: top olcOverlay: {5}autoca structuralObjectClass: olcAutoCAConfig entryUUID: 739501f2-49ad-103e-911a-3dc9b40470bf creatorsName: uid=brendan,ou=domainusers,ou=users,dc=bpk2,dc=com createTimestamp: 20240117175614Z olcAutoCADays: 3650 olcAutoCAKeybits: 2048 olcDisabled: TRUE olcAutoCAserverKeybits: 2048 olcAutoCAuserClass: inetOrgPerson olcAutoCAserverClass: device olcAutoCAserverDays: 1826 olcAutoCAuserDays: 365 olcAutoCAuserKeybits: 2048 entryCSN: 20240117192443.210024Z#000000#001#000000 modifiersName: uid=brendan,ou=domainusers,ou=users,dc=bpk2,dc=com modifyTimestamp: 20240117192443Z note, olcDisabled is set to true. it seems that something went awry and even though i didn't want the capability active, i wound up with some caCertificate and caPrivateKey objects created in the DIT. it looks like i may have added the overlay in an active state and disabled it after the caCertificate/PrivateKey objects were created. i want to clean up things and remove the AutoCA pieces until i can test them better. what process is needed to remove the objects and overlay, as replication may play a part in some of the effort? i could imagine that deleting the caCertificate and caPrivateKey objects would be relatively straight forward, but the overlay may prove a bit more complicated. i found a message on this list from some time ago, https://www.openldap.com/lists/openldap-technical/201811/msg00075.html, that says i can stop the slapd instance, remove the overlay ldif files and restart the instance, to accomplish this task. the issue that i am trying to avoid is having to take down the entire fully replicated DIT, in order to delete the overlay and not have replication recreate it because one active node "didn't get the memo". are there any insights into how i can delete overlays without having replication recreate the objects i want to remove, all while still providing at least one instance to service requests? if it clarifies things, i am running 3 slapd instances behind a load balancer and both the config DB and DIT are replicated between all nodes. if it comes to it, i could take down all instances to perform this work, but i would like to avoid it if possible. thanks in advance, brendan kearney

3 9

Use lmdb for lookup of dentries?
by stefbon＠gmail.com 03 Nov '25

03 Nov '25

Hi, I'm writing FUSE fs's, and need a method for doing lookups for of dentries and inodes. To start with dentries, a FUSE lookup uses the parent inode ino (an uint64_t) and the name. Now I've expirmented a lttle creating a key like: - first 8 bytes used by parent inode ino, left padded with zeros. - rest the name of the entry like 00000001dexample which is the directory dexample in directory with ino 1. (to make this work custom locking is required) It works, but is it a good idea to do? Or are there other methods better? S.Bon

3 5

RE: [EXT] Re: Re: Understanding ldappasswd: ldap_bind: Invalid credentials (49)
by Windl, Ulrich 22 Aug '25

22 Aug '25

(shame!) Bastian, you are right! One should never do a "quick hack" to existing scripts: In the original version the MAANGER was specified without the common CONTEXT, so the script used -D "$MANAGER","$CONTEXT". The DN however was including the CONTEXT (maybe to shorten the script line that uses it). When using MANAGER="$DN" I got a MANAGER that includes the CONTEXT already. The idea was "use the user name as manager, so the user will change its own password". The idea was correct, but "MANAGER=$DN was not. 8-( Kind regards, Ulrich Windl > -----Original Message----- > From: btwe(a)eva05.jsc.fz-juelich.de <btwe(a)eva05.jsc.fz-juelich.de> On > Behalf Of Bastian Tweddell > Sent: Friday, August 22, 2025 8:58 AM > To: Windl, Ulrich <u.windl(a)ukr.de> > Subject: [EXT] Re: Re: Understanding ldappasswd: ldap_bind: Invalid > credentials (49) > > > Hi Ulrich, > > Given that ldappasswd basically works, maybe check your variables. > I think you append `$CONTEXT` two times: > > On 22Aug25 06:43+0000, Windl, Ulrich wrote: > > > > CONTEXT='dc=...' > > > > if [ -n "$1" ]; then > > > > DN="uid=${1},ou=people,$CONTEXT" > > => DN="uid=username_from_arg1,ou=people,dc=..." > ^^^^^^ > > > > > MANAGER="$DN" > > => MANAGER="uid=username_from_arg1,ou=people,dc=..." > ^^^^^^ > > > > > echo "$MANAGER changing password for $DN" > > > > ldappasswd -H "$SERVER" -x -ZZ -D "$MANAGER","$CONTEXT" -W > ${2:+-S > > => -D "uid=username_from_arg1,ou=people,dc=...","dc=..." > ^^^^^^ ^^^^^^ > > This would be wrong, wouldn't it? > > In general, think about using `set -euo pipefail` in bash scripts, and > in this case also use `set -x`. So you could spot that easily. > Also ldap cmdline tools usually take `-d -1` to print all debug info, > but you know that. > > > Das hätte ich wohl auch auf Deutsch schreiben können :) > Ich habs nicht an die Liste geschickt. > > > Viele Grüße, > -- > 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 > --------------------------------------------------------------------------------------------- > ---------------------------------------------------------------------------------------------

1 0

Understanding ldappasswd: ldap_bind: Invalid credentials (49)
by Windl, Ulrich 21 Aug '25

21 Aug '25

Hi! I have a question: A user can change its password using the standard SSH Login. However one user with an expired password has a special shell that does not allow login (the user is logged out immediately). So I tried to use ldappasswd to change the password using this helper script: #!/bin/sh SERVER='ldap://...' CONTEXT='dc=...' if [ -n "$1" ]; then DN="uid=${1},ou=people,$CONTEXT" MANAGER="$DN" echo "$MANAGER changing password for $DN" ldappasswd -H "$SERVER" -x -ZZ -D "$MANAGER","$CONTEXT" -W ${2:+-S }"$DN" else echo "$0: missing or empty username" >&2 exit 1 fi So here the one to change the password is the user itself. When I use the script with just the username (set random password), I see: Enter LDAP Password: ldap_bind: Server is unwilling to perform (53) additional info: unauthenticated bind (DN with no password) disallowed And when I call it with a second parameter (ask for password), I see: New password: Re-enter new password: Enter LDAP Password: ldap_bind: Invalid credentials (49) I'm trying to understand: Does the user need special ACLs, or to I need additional parameters? The essential ACLs for userPassword are: ... olcAccess: {4}to attrs=shadowLastChange,userPassword,userPKCS12 by dn.exact="uid=PW-Admin,ou=system,dc=..." write by * break ... olcAccess: {6}to attrs=userPassword,userPKCS12 by self write by * auth ... olcAccess: {8}to * by * read If I use the PW-Admin account, I can change the password, however. Kind regards, Ulrich Windl

2 2

bind to LDAP server produces "invalid credentials" error
by Travis Bean 20 Aug '25

20 Aug '25

When starting the krb5-admin service, I receive the following error: “Cannot bind to LDAP server ldapi:/// as ‘cn=kdc-srv,cn=krbContainer,dc=example,dc=local’: Invalid credentials - while initializing database.” cn=kdc=srv,cn=krbContainer,dc=example,dc=local is referenced in my krb5.conf as ldap_kdc_dn. It is also referenced in my password stashes as the following: echo -ne "$ADMIN_PASSWORD\n$ADMIN_PASSWORD\n" | kdb5_ldap_util \ -D uid=admin,ou=people,dc=example,dc=local -w "$ADMIN_PASSWORD" stashsrvpw \ -f /etc/krb5kdc/service.keyfile cn=kdc-srv,cn=krbContainer,dc=example,dc=local It is also referenced via ldappasswd: ldappasswd -H ldapi:/// -D uid=admin,ou=people,dc=example,dc=local \ -w "$ADMIN_PASSWORD" -s "$ADMIN_PASSWORD" cn=kdc-srv,cn=krbContainer,dc=example,dc=local It is also referenced in my following ACL: olcAccess: to dn.subtree="cn=krbContainer,dc=example,dc=local" by dn.exact="cn=adm-srv,cn=krbContainer,dc=example,dc=local" write by dn.exact="cn=kdc-srv,cn=krbContainer,dc=example,dc=local" read I thought it was one of my ACLs, but when I modified/removed my ACLs, the problem persisted. I followed this previous post about ACLs ( serverfault.com/questions/869585/kerberos-kdc-wont-start-invalid-credentials), but to no avail. Here is the Bash script I am using for testing: https://drive.google.com/file/d/1PWNAxH6Y0Sk3vBWd85JheG6DOSjmCFbq/view?usp=… Kind regards, Travis Bean

1 0

Converting syncrepl consumer to cn=confg
by Nick Milas 20 Aug '25

20 Aug '25

Hello, I am trying to migrate from a syncrepl consumer 2.4.58 on (CentOS 7) to openldap 6.10 (on Rocky 9). All RPMs are LTB. The initial config is text based (slapd.conf). I added lines for the config database in slapd.conf: database config rootdn "cn=admin,cn=config" rootpw {SSHA}*************************** and then: slaptest -f /usr/local/openldap/etc/openldap/slapd.conf -F /usr/local/openldap/etc/openldap/slapd.d and then: slapcat -F /usr/local/openldap/etc/openldap/slapd.d -n0 -l /root/migration-file.ldif Finally a/ I added modules, b/ I changed syncrepl id (to 182 so that it is unique) and c/ I changed olcMirrorMode to olcMultiProvider The result is here (full file, passwords removed): https://pastebin.com/24bvSKkp <https://pastebin.com/24bvSKkp> Eventually, I slapadd'ed the above into slapd.d on the new server: [root@vmail4 openldap]# slapadd -vvv -n0 -F /usr/local/openldap/etc/openldap/slapd.d -l /root/migration-file.ldif 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}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}pdns-domaininfo,cn=schema,cn=config" (00000001) added: "cn={11}proftpd-quota,cn=schema,cn=config" (00000001) added: "cn={12}kerberos,cn=schema,cn=config" (00000001) added: "cn={13}localemail,cn=schema,cn=config" (00000001) added: "cn={14}entryaccess,cn=schema,cn=config" (00000001) added: "cn={15}radius,cn=schema,cn=config" (00000001) added: "olcDatabase={-1}frontend,cn=config" (00000001) added: "olcDatabase={0}config,cn=config" (00000001) added: "olcDatabase={1}mdb,cn=config" (00000001) added: "olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config" (00000001) added: "olcDatabase={2}monitor,cn=config" (00000001) Closing DB... but it won't start: Aug 19 16:13:04 vmail4.noa.gr slapd-cli[14959]: [INFO] Using /usr/local/openldap/etc/openldap/slapd-cli.conf for configuration Aug 19 16:13:04 vmail4.noa.gr slapd-cli[14950]: slapd-cli: [INFO] Using /usr/local/openldap/etc/openldap/slapd-cli.conf for configuration Aug 19 16:13:04 vmail4.noa.gr slapd-cli[14961]: [INFO] Launching OpenLDAP configuration test... Aug 19 16:13:04 vmail4.noa.gr slapd-cli[14950]: slapd-cli: [INFO] Launching OpenLDAP configuration test... Aug 19 16:13:04 vmail4.noa.gr slapd-cli[14963]: [ALERT] OpenLDAP configuration test failed Aug 19 16:13:04 vmail4.noa.gr slapd-cli[14950]: slapd-cli: [ALERT] OpenLDAP configuration test failed Aug 19 16:13:04 vmail4.noa.gr systemd[1]: slapd-ltb.service: Control process exited, code=exited, status=1/FAILURE How can I identify the problem with the configuration? I tried setting: DEBUG_LEVEL="-1" in /usr/local/openldap/etc/openldap/slapd-cli.conf but I don't see any additional details. Can you please provide some guidance on troubleshooting what is wrong? Thanks in advance, Nick

2 2

Reduced performance after restart because of replication inconsistency
by Bergmann, Clemens 18 Aug '25

18 Aug '25

Hi, since some weeks we operate an openldap deployment in N-Way Multi-Provider Delta-syncrepl Replication. There are around 130000 entries in the main database, and it is around 635 MB in size. Currently the replication contains two VMs each with 4Gb of RAM and 2 CPUs. The VMs are running slapd 2.6.10. I posted the configuration on [1]. I only removed the credentials and some user specific ACLs. This setup worked flawlessly for some time until both servers rebooted during a scheduled patch circle. Since then, we see drastically increased response times and CPU utilization on both VMs. On one of the servers (ldap08) I see the following Log entry every few seconds: do_syncrep2: rid=910 (4096) Content Sync Refresh Required When I try to compare the contextCSN of both servers they differ a little but only less then 5 seconds at max. The however change constantly because these servers are used for login and store the last login and Intruder detection information which must be replicated. Most of the other data is static but there are some changes (changed passwords, Name changes) every few minutes or so. For Example a few minutes ago we had the following values: 20250717103207.135309Z#000000#000#000000 20250717115153.689217Z#000000#06a#000000 20250814105455.935611Z#000000#06b#000000 20250814105522.282937Z#000000#06c#000000 I understand that the 000 entry is from before enabling replication and the 06a value is from an old server no longer belonging to this replication (ldap05). When I last had a situation like this the servers where not in production and I shut both down, copied the database over and started them up again. This is not an option now as they are in production and needed for login. Also preventing updates for longer than a few minutes is not an option an even this has to be announced ahead of time. When I last tried adding a brand new Server cluster configured in a similar way in testing it took multiple hours to get the new server up to speed. I fear that removing one of the two servers for multiple hours would overwhelm the remaining server with requests. In the future the plan is to have at least 3 Servers in this replication but currently we only have two. It is however an option to prepare new server(s) and add them to the replication if that might help somehow. One other information is that currently the accesslog database is around 2 GB of size. What would be the best approach to remediate this situation? [1] https://next.hessenbox.de/index.php/s/jFX9gAEWXoqoxNS 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/

4 5

Certificate authentication through LDAP Proxy (back_ldap)
by BECOT Jérôme 12 Aug '25

12 Aug '25

Hello, We have a working setup with two mirror master and two slaves: * Syncrepl uses a certificate on each node to fetch data, with an olcAuthzRegexp rule to map it to a DSA (simpleSecurityObject). * Client SSSD servers also use a dedicated certificate to authenticate on the slaves, with another olcAuthzRegexp to map them to a "per project" DSA. * We use different ACL on the main db because some DSA have privileged access to some branches We want to expose data on another subnets through proxies, and cyber ask to use OpenLDAP with back_ldap. How should we configure them to use client certificate authentication to the backend slaves ? Any thoughts appreciated Regards Jerome

2 5

slapd 2.5 dumping core on delta-synrepl issues
by Windl, Ulrich 12 Aug '25

12 Aug '25

Hi! I have a support case from SUSE's version of slapd open, and I wonder about one specific statement from support: A core dump is triggered by syncprov.c:2360: assert( !BER_BVISEMPTY( &oldestcsn ) && !BER_BVISEMPTY( &newestcsn ) && ber_bvcmp( &oldestcsn, &newestcsn ) < 0 ); Support explained: "Any of these indicates the changelog (accesslog) is in a completely inconsistent or corrupted state." The support recommends to reset the CSNs by disabling any replication (which doesn't remove those IMHO) and "either using syncrepl or delta-syncrepl, but not mixing both.": I don't see a problem if one dependent server gets the changed through "classic methods" (e.g. Refresh), and another server gets updates through delte-syncrepl. Am I wrong? Finally support concludes: "Please note that these types of replication integrity issues do not affect 389 Directory Server, which uses a more robust mechanism for change tracking and includes a proper Lamport clock implementation." Well, I actually tried 389DS, but the conversion tool was highly incomplete, the schemata and ACL mechanism were completely different, and there was not a single current book for it available, so I resigned. Feel free to comment. Kind regards, Ulrich Windl

2 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2025