openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

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

Re: Multiple memberOf overlays
by Arvid Requate 06 Aug '25

06 Aug '25

1 0

Multiple memberOf overlays
by John C. Pfeifer 05 Aug '25

05 Aug '25

I am in the process of converting an existing LDAP infrastructure to OpenLDAP. I have a case where it would be convenient for two different objectClasses to map into the memberOf attribute. Is it possible to define two overlay configs or will they end up fighting each other over the memberOf attribute? For instance: dn: olcOverlay={5}memberofA,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {5}memberofA olcMemberOfDangling: error olcMemberOfRefInt: FALSE olcMemberOfGroupOC: objectClassA olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf dn: olcOverlay={6}memberofB,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {6}memberofB olcMemberOfDangling: error olcMemberOfRefInt: FALSE olcMemberOfGroupOC: objectClassB olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf // John Pfeifer Division of Information Technology University of Maryland, College Park

4 3

Queries on openLDAP deployment on multi region on Kubernetes cluster
by vithal.akunuri＠tdsynnex.com 05 Aug '25

05 Aug '25

Hi, openldap-stack-ha was deployed as stateful set of 4 on multi region Kubernetes ( micro K8s ) cluster with 2 nodes in each region with multi master configuration. Application connections to LDAP are managed through kubernetes service. Multiple issues are noticed with this setup and would like to seek some guidance and feedback. 1. Frequent replication issues : For monitoring, script is being executed every 1 hour to check the replication status using check_syncrepl_extended command between all the providers and consumers. Is there any better to monitor the replication lag ? To recover from this issue, the pods are being recycled on the provider host which is out of sync. Is there any guidance of deploying LDAP in multi region ? Is multi master recommended in production environment for resiliency and performance? 2. Bulk upload : Is there any guidance on doing bulk upload into LDAP in this current setup? Thanks, Vithal

2 1

pwdMaxIdle does not work as described in OpenLDAP 2.5
by Windl, Ulrich 04 Aug '25

04 Aug '25

Hi! I was playing with olcLastBind and pwdMaxIdle, setting up a test user and a test policy. However when the account should have been expired, nothing happened, i.e.: the user still could log in and change the password. Here are some details from the sample (variables have a different name, but you should be able to correlate them): ACCT_CHANGED = "20250728081545Z" ACCT_MAX_IDLE = "250000" AUTH_TIMESTAMP = "20250728081545Z" CURRENT_TIME_T = "1754049116" POLICY_CHANGED = "20250716131620Z" POLICY_NAME = "PP-Testing" SOURCE_NAME = "LDAP Password Policy" USER_ID = "testuser" I'm using the lastbind overlay and these settings: olcLastBindPrecision: 432000 olcLastBindForwardUpdates: TRUE My program calculated that the account had expired 1.256 days ago. Am I missing something, or is it a bug? Should there be an index on the authTimestamp attribute? Do I have to set olcLastbind to TRUE also? (I avoided that, because in 2.5 I cannot delay updates to the attribute, and some periodic automated logins flood the syncrepl changelog that way.) Kind regards, Ulrich Windl

2 3

Transform glue object to organizationalUnit
by cyril＠stoll.info 29 Jul '25

29 Jul '25

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

4 7

Q: Using sssd authTimestamp isn't updated with lastbind enabled on some clients
by Windl, Ulrich 28 Jul '25

28 Jul '25

Hi! I discovered an odd problem: If a user logs in on some clients, the OpenLDAP 2.5 server does not update authTimestamp, while on other clients the timestamp is updated (and synchronized across all servers). All clients use the same OS (SLES15) and sssd. The only difference I could find was the order of modules: services = pam,nss vs. services = nss, pam Sections for [pam] and [nss] are both empty. Caching credentials is disabled ("false") also. I thought if sssd authenticates using the OpenLDAP server, the server itself would update the authTimestamp. Can anybody enlighten me (e.g. how to debug)? Kind regards, Ulrich Windl

2 1

Use lmdb for lookup of dentries?
by stefbon＠gmail.com 28 Jul '25

28 Jul '25

Hi, I'm writing a fuse fs, and need a method to do a lookup of a direntry. I want to know lmdb is an option here. (much reads, not a lot of writes). A lookup of a dentry is using the parent inode id and the name of the dentry. So you can create the key like: key = (parentino padded left with zeros to 8 positions) | dentry->name (note: a custom locking method is required to not lock the whole db) Now does anybod know this is a good method or are there better methods available? S. Bon

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical