- openldap-technical - openldap.org

Request rate limiting
by BECOT Jérôme 24 Sep '25

24 Sep '25

Hello, Is there any way to limit bind query rates or any operation rate in OpenLDAP or in conjunction of another proxy ? Any advice appreciated Regards Jerome

5 5

logs on stderr don't enforce olcLogFileFormat
by David Coutadeur 18 Sep '25

18 Sep '25

Hi everyone! I don't know if this is intended or not, but when I run OpenLDAP with logs attached on stderr, like: ./slapd -h 'ldap://*:389 ldaps://*:636' -F ./slapd.d -u ldap -g ldap -d 256 the logs do not enforce olcLogFileFormat. For example: 68b6fe23.27b26379 0x7fe756a70e40 @(#) $OpenLDAP: slapd 2.6.10 (May 21 2025 22:00:00) $ instead of: Sep 02 16:21:50 hostname slapd[12345]: slapd starting Is this the expected behaviour? If so, are there any plans for having an option to set the date in stderr logs? Thanks in advance for any response! Regards, -- David Coutadeur | IAM integrator david.coutadeur(a)worteks.com +33 7 88 46 85 34 16 avenue Hoche, Paris 75008 Worteks | https://www.worteks.com

2 4

slapcat dump seems incomplete (attributes missing)
by Windl, Ulrich 15 Sep '25

15 Sep '25

Hi! After a long time I checked the database dump I had created with slapcat in OpenLDAP 2.5. I always thought that all attributes from the database were saved, but it seems some attributes related to password policy aren't: Specifically I cannot find the pwdChangedTime that is there when searching for it. I also miss the pwdHistory, but the pwdPolicySubentry attribute is there. When I compare the dump with the last one created with OpenLDAP 2.4, I see that those attributes (pwdChangedTime, pwdHistory) are still there. That makes me wonder: Is it a bug in OpenLDAP, or is it a bug in my configuration? As I understand it, ACLs should not play a role for slapcat, right? The command I'm using is "slapcat -o ldif-wrap=no -n $DBNUM -F $CONFDIR -g -l "$TMPFILE1" Module load order is: olcModuleLoad: {0}back_mdb.so olcModuleLoad: {1}syncprov.so olcModuleLoad: {2}accesslog.so olcModuleLoad: {3}ppolicy.so olcModuleLoad: {4}refint.so olcModuleLoad: {5}pw-sha2.so olcModuleLoad: {6}lastbind.so Mit freundlichen Grüßen Ulrich Windl Klinikum der Universität Regensburg IT / Infrastruktur Franz-Josef-Strauß-Allee 11 D-93053 Regensburg Tel: +49 941 944-13816 Softphone: +49 941 944-801142 FAX: +49 941 944-5882

2 2

LDAP race condition with ldap_initialize API in OpenLDAP 2.6.7
by venugopal chinnakotla 09 Sep '25

09 Sep '25

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code. We are using OpenLDAP 2.6.7. As part of this migration activity,we used ldap_initialize() API for initializing and getting LDAP Handle. Our application supports multi threading. So, ldap_initialize() API will be called from multi threaded code. For example, 2 threads will call ldap_initialize() at same time/simultaneously. When 2 threads call ldap_initialize() at same time, sometimes observed a race condition during this API call. Due to this, the next api calls ldap_simple_bind_s or ldap_start_tls_s are getting failed for 2 threads and it is not recovered automatically until restarts our applications. We observed this race condition multiple times. Because of this issue, we are unable to start our application and it becomes a blocker for us to proceed further. After checking ldap_initialze() API code from openldap source code, noticed that race condition happened while initializing/setting global options. Are there any known issues with OpenLDAP when we use it in multi thread supported applications? Could you please check and provide a solution. Thank you for your help.

2 1

Need information related to multi thread support in OpenLDAP c sdk client
by venugopal chinnakotla 09 Sep '25

09 Sep '25

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP c sdk for our application client code. As part of this activity, replacing API one by one and also looking for constant replacement. In NSLDAP C SDK: /* * Thread function callbacks (an API extension -- * LDAP_API_FEATURE_X_THREAD_FUNCTIONS). */ #define LDAP_OPT_THREAD_FN_PTRS 0x05 /* 5 - API extension */ /* * Thread callback functions: */ typedef void *(LDAP_C LDAP_CALLBACK LDAP_TF_MUTEX_ALLOC_CALLBACK)( void ); typedef void (LDAP_C LDAP_CALLBACK LDAP_TF_MUTEX_FREE_CALLBACK)( void *m ); typedef int (LDAP_C LDAP_CALLBACK LDAP_TF_MUTEX_LOCK_CALLBACK)( void *m ); typedef int (LDAP_C LDAP_CALLBACK LDAP_TF_MUTEX_UNLOCK_CALLBACK)( void *m ); typedef int (LDAP_C LDAP_CALLBACK LDAP_TF_GET_ERRNO_CALLBACK)( void ); typedef void (LDAP_C LDAP_CALLBACK LDAP_TF_SET_ERRNO_CALLBACK)( int e ); typedef int (LDAP_C LDAP_CALLBACK LDAP_TF_GET_LDERRNO_CALLBACK)( char **matchedp, char **errmsgp, void *arg ); typedef void (LDAP_C LDAP_CALLBACK LDAP_TF_SET_LDERRNO_CALLBACK)( int err, char *matched, char *errmsg, void *arg ); /* * Structure to hold thread function pointers: */ struct ldap_thread_fns { LDAP_TF_MUTEX_ALLOC_CALLBACK *ltf_mutex_alloc; LDAP_TF_MUTEX_FREE_CALLBACK *ltf_mutex_free; LDAP_TF_MUTEX_LOCK_CALLBACK *ltf_mutex_lock; LDAP_TF_MUTEX_UNLOCK_CALLBACK *ltf_mutex_unlock; LDAP_TF_GET_ERRNO_CALLBACK *ltf_get_errno; LDAP_TF_SET_ERRNO_CALLBACK *ltf_set_errno; LDAP_TF_GET_LDERRNO_CALLBACK *ltf_get_lderrno; LDAP_TF_SET_LDERRNO_CALLBACK *ltf_set_lderrno; void *ltf_lderrno_arg; }; nsldap c sdk has thread function pointers option to support multi thread functionality for client programs. In our existing code, we are using 'LDAP_OPT_THREAD_FN_PTRS' option with ldap_set_option API like "Client code usage: ldap_set_option(hLDAP, LDAP_OPT_THREAD_FN_PTRS, &tfns);". Now, we are looking for similar functionality within OpenLDAP to use it in our client program. I Went through OpenLDAP documents and source code, but to my knowledge, did not get any equivalent one. Could you please provide more details on this to achieve equivalent functionality of LDAP_OPT_THREAD_FN_PTRS with OpenLDAP? Thank you

2 1

Stale objects in mdb backend
by Matwey Kornilov 03 Sep '25

03 Sep '25

Hello, I am running OpenLDAP (slapd 2.4.49) on Ubuntu with an MDB backend configured for the suffix o=bar,dc=foo. With a help of slapcat, I have discovered stale data: several objects with the suffix dc=bar,dc=foo are physically present in the same MDB database files. These were likely created by the default Ubuntu installer before the entire configuration was manually replaced. However, /var/lib/ldap remained unnoticed at that time, and then production data were appended to this initial one. Is there a method to delete these specific dc=bar,dc=foo entries without taking the server offline and rebuilding the entire database from an LDIF export with slapcat+slapadd? ldapsearch seems to be uncapable to deal with this stale data. Thanks in advance.

1 0

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

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

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

30 Jul '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

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

Question about lmdb.
by Stef Bon 27 Jul '25

27 Jul '25

Hi, can I ask a question about lmdb here? I've got a question about it and I cannot find another place. S. Bon

1 0

Re: Queries on openLDAP deployment on multi region on Kubernetes cluster
by Akunuri, Vithal 25 Jul '25

25 Jul '25

Hi Team, Can you please share your inputs on Queries on openLDAP deployment on multi region on Kubernetes cluster - openldap-technical - openldap.org<https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…> ? Vithal Akunuri

1 0

openldap-technical return-exact-case is set to "on"
by JM Lacombe 17 Jul '25

17 Jul '25

openldap to the "openldap-technical" mailing list openldap-technical(a)openldap.org hello like on SUN (odsee) : set config nsslapd-return-exact-case is set to "on" or off with openldap v2.6.6.3, how to get same feature ? and force return entryDN to lower case. best regards JM Lacombe email: jmlacombe(a)hotmail.com

3 6

Two questions understanding delta-syncrepl
by Windl, Ulrich 17 Jul '25

17 Jul '25

Hi! I'm getting more experience with delta-syncrepl, but I still have two questions I'm unsure about: 1. In contrast to plan syncrepl, is it true that plain syncrepl will sync contents "from the past" (i.e. content changed before syncrepl had been activated), whereas delta-syncrepl will nor sync changes that were made before delta-syncrepl had been activated (i.e. sync only "new changes"" mad after the delta-syncrepl configuration? (see below, also) 2. Is it expected that the entryCSNs are identical for a synced entry on each server? I use a check that compare the UUID and the CSN for each entry to verify synchronization, but I see small differences (example below) For question #1: Specifically I have these messages (from today when establishing a new RID) in mind: slapd[22664]: conn=35370 op=2 syncprov_findbase: searching slapd[22664]: conn=35370 op=2 syncprov_op_search: registered persistent search slapd[22664]: conn=35370 op=2 syncprov_play_accesslog: accesslog information inadequate for log replay on csn=20250707100648.450369Z#000000#001#000000 slapd[22664]: conn=35370 op=2 syncprov_findcsn: mode=FIND_CSN csn=20250707100648.450369Z#000000#001#000000 slapd[22664]: conn=35370 op=2 syncprov_findcsn: csn==20250707100648.450369Z#000000#001#000000 not found slapd[22664]: conn=35370 op=2 syncprov_findcsn: csn<=20250707100648.450369Z#000000#001#000000 found slapd[22664]: conn=35370 op=2 syncprov_findcsn: mode=FIND_PRESENT csn= slapd[22664]: conn=35370 op=2 syncprov_sendinfo: present syncIdSet cookie= (and actually some changes made on that server recently were not synced to the other servers that should "pull" from this one) For question #2: On example I found (comparing server #2 with server #3) was: -uid=... (c3e62200-55af-1038-9b76-9916ef1a4822): 20250716105944.785857Z#000000#002#000000 +uid=... (c3e62200-55af-1038-9b76-9916ef1a4822): 20250716105944.780532Z#000000#002#000000 So there's a difference in the 5ms area, and (AFAIK) both changes originate from server #2. The corresponding changelog looks like this: dn: reqStart=20250716105944.000001Z,cn=changelog-1 objectClass: auditModify structuralObjectClass: auditModify reqStart: 20250716105944.000001Z reqEnd: 20250716105944.000003Z ... entryCSN: 20250716105944.780532Z#000000#002#000000 ... And that change is the only change made that second. Server #2 logged for sending the change to server #3: slapd[1811445]: conn=1020 op=2 syncprov_sendresp: to=003, cookie=rid=112,sid=002,csn=20250716105944.780532Z#000000#002#000000 Server #3 logged for receiving the change: slapd[2528537]: conn=-1 op=0 syncprov_add_slog: adding csn=20250716105944.780532Z#000000#002#000000 to sessionlog, uuid=c3e62200-55af-1038-9b76-9916ef1a4822 slapd[2528537]: slap_queue_csn: queueing 0x7f2d4816df90 20250716105944.780532Z#000000#002#000000 slapd[2528537]: slap_graduate_commit_csn: removing 0x7f2d4816df90 20250716105944.780532Z#000000#002#000000 slapd[2528537]: slap_queue_csn: queueing 0x7f2d4818bf70 20250716105944.780532Z#000000#002#000000 slapd[2528537]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=reqStart=20250716105944.000001Z,cn=changelog-1 on opc=0x7f2d48002be0 slapd[2528537]: conn=1008 op=2 syncprov_qresp: set up a new syncres mode=1 csn=20250716105944.780532Z#000000#002#000000 ... slapd[2528537]: do_syncrep2: rid=113 cookie=rid=113,sid=003,csn=20250716105944.780532Z#000000#002#000000 slapd[2528537]: do_syncrep2: rid=113 CSN too old, ignoring 20250716105944.780532Z#000000#002#000000 (reqStart=20250716105944.000001Z,cn=changelog-1) slapd[2528537]: slap_graduate_commit_csn: removing 0x7f2d4814fd10 20250716105944.780532Z#000000#002#000000 (next change was several minutes later; rid113 would mean server #3 (sid 3) would try sync to itself (MMR on cn=config artefact)) Kind regards, Ulrich Windl

1 0

Advice / Rex on performance test
by BECOT Jérôme 16 Jul '25

16 Jul '25

Hi there, We want to run performance and load testing on our servers. Which tool fits the best for OpenLDAP (we are running servers behing haproxies as well).? Is there a specific tool for Openldap? Do you have any recommendation with other tools? We want to run tests through CI pipelines. Thank you

3 2

Q: Uniqueness ofSyncRepl RIDs, replicating cn=config
by Windl, Ulrich 11 Jul '25

11 Jul '25

Hi! I always wondered about the scope within SyncRepl RIDs have to be unique: * Per database * Per server * Within all servers For a support case covering MMR replication including cn=config I got this response: "One cannot copy the config between machines. Syncrepl configuration includes the RID parameter. That RID must be UNIQUE on all servers. By copying the config, one now has two machines with the same RID." I think it's OK to do so, however. Slapd handles the situation where a server is asked to sync from itself correctly ARAIK. We have three servers, says s1 (sid=1), s2 (sid=2), and s3 (sid=3). And there are three syncrepl statements making each server to syn from each of the three servers. So effectively s1 will sync from s2 and s3, s2 will sync from s1 and s3, and s3 will sync from s1 and s2 (each server ignoring the sync from itself). The log message may be like this for s2: slapd[1811445]: conn=1001 op=2 syncprov_matchops: skipping original sid 002 Am I correct, or is the support's answer correct? Kind regards, Ulrich Windl

2 1

Openldap unable to start after upgrading from 2.4 to 2.5
by Kaya Saman 11 Jul '25

11 Jul '25

Hi all, I've just performed an upgrade on my FreeBSD servers to get them all to version 13.5 and am now in the process of updating various @ports. OpenLDAP was upgraded from the 24 version port to the 25 (or version 2.5 in real terms) but for some reason the service does not want to start. I have checked the "upgrading" information here: https://openldap.org/doc/admin25/appendix-upgrading.html and tried to read around the issue, but I can't really understand what is going on. This is the output from the ldap.log file: Jul 8 23:48:03 ldap slapd[1302]: @(#) $OpenLDAP: slapd 2.5.20 (Jul 8 2025 21:55:10) $ @ldap.FQDN:/usr/ports/net/openldap25-server/work/openldap-2.5.20/servers/slapd Jul 8 23:48:03 ldap slapd[1302]: daemon_init: <null> Jul 8 23:48:03 ldap slapd[1302]: daemon: SLAP_SOCK_INIT: dtblsize=231210 Jul 8 23:48:03 ldap slapd[1302]: daemon_init: listen on ldap:/// Jul 8 23:48:03 ldap slapd[1302]: daemon_init: 1 listeners to open... Jul 8 23:48:03 ldap slapd[1302]: daemon: listener initialized ldap:/// Jul 8 23:48:03 ldap slapd[1302]: daemon_init: 1 listeners opened Jul 8 23:48:03 ldap slapd[1302]: slapd init: initiated server. Jul 8 23:48:03 ldap slapd[1302]: slap_sasl_init: initialized! Jul 8 23:48:03 ldap slapd[1302]: mdb_back_initialize: initialize MDB backend Jul 8 23:48:03 ldap slapd[1302]: mdb_back_initialize: LMDB 0.9.33: (May 21, 2024) Jul 8 23:48:03 ldap slapd[1302]: backend_startup_one: starting "cn=config" Jul 8 23:48:03 ldap slapd[1302]: ldif_read_file: no entry file "/usr/local/etc/openldap//cn=config.ldif" Jul 8 23:48:03 ldap slapd[1302]: send_ldap_result: conn=-1 op=0 p=0 Jul 8 23:48:03 ldap slapd[1302]: send_ldap_result: err=32 matched="" text="" Jul 8 23:48:03 ldap slapd[1302]: slapd destroy: freeing system resources. Jul 8 23:48:03 ldap slapd[1302]: slapd stopped. Jul 8 23:48:03 ldap slapd[1302]: connections_destroy: nothing to destroy. Has something with the configuration file changed in the meantime, or based off this line: "ldif_read_file: no entry file "/usr/local/etc/openldap//cn=config.ldif"" is it something to do with the slapd.ldif file in the openldap directory? If need be I can post my slapd.conf file too.... any pointers would be great or at least if there was somewhere to increase the logging to say exactly what and where is wrong would be great. Many thanks. Kaya

4 6

The infamous "main: TLS init def ctx failed: -1" and a solution
by Windl, Ulrich 10 Jul '25

10 Jul '25

Hi! When trying to start slapd, I got "main: TLS init def ctx failed: -1" before slapd quit. So I got the clue that something with TLS, probably certificates is wrong. I spend half of a day to examine the certificates used, found something, fixed that, but it did not help. Eventually I found some article (https://apple.stackexchange.com/questions/107130/slapd-daemon-cant-start-tl…) explaining that starting slapd with option -d1" would provide some more reasonable error details. So I tried that, and I found "TLS: could not load client CA list (file:`',dir:`/etc/ssl/certs')." That's much more helpful than the original message, so I examined the directory. Interestingly the issue was that there wre four stale links to centificate files that did not longer exist (those were not used any more, however, because they expired several years ago). Deleting those links by calling c_rehash fixed the problem. So at the very least I'm suggesting to provide the more useful error message also in non-debug mode. I'm not saying that the better error message couldn't be improved also. Kind regards, Ulrich Windl

1 0

LMDB and Disk fragmentation
by hubouvie＠microsoft.com 07 Jul '25

07 Jul '25

Hi everyone, We’ve been stress‑testing an LMDB database by continually inserting and deleting records ranging from 4 KB to 5 MB. To track utilization, we rely on two independent metrics: Application index – we track the sum of the payload bytes of keys currently present. mdb_stat output – pages in use /overlay etc.... The two figures agree closely. Despite this, we repeatedly hit MDB_MAP_FULL when both metrics say the map is only ≈ 50 % occupied (on both metrics). Our tentative conclusion is heavy page fragmentation: LMDB can’t find a sufficiently large contiguous run of free pages even though half of the map is nominally free. Questions - Is it normal to lose that much effective capacity with an insert/delete workload like ours? - How far can we realistically fill the map before hitting fragmentation limits? - Are there recommended ways to mitigate or “defragment”? Any advice would be greatly appreciated! Thanks! Hugues

3 4

Proxy Protocol support for ldap client
by BECOT Jérôme 07 Jul '25

07 Jul '25

Hello, We use the proxy protocol with our openldap 2.5 servers (pldaps). I noticed that client binaries allow pldaps as protocol in the host address option starting with 2.5, but how can I add proxy headers to the request to communicate with my servers ? I think that there might be something with '-o' that I'm not aware of. Thanks for your help. Jerome

3 3

Q: sync provider: "additional info: <olcUpdateRef> must appear after syncrepl or updatedn"
by Windl, Ulrich 04 Jul '25

04 Jul '25

Hi! I tried to set up a sync provider to have a UpdateRef pointing to itself, while not pulling any changes from anywhere. The idea was that the sync consumers will copy that UpdateRef and direct updates to the provider that way. This is a MMR scenario during migration where config is synced, too. So the current scenario is like this: P1 (provider, OpenLDAP 2.4) | | V v C1 <--> C2 (consumer, OpenLDAP 2.5) I could ldapmodify the change, but when doing a" slapcat -n0" now, I get the error: 68679fc8 olcUpdateRef: value #0: <olcUpdateRef> must appear after syncrepl or updatedn 68679fc8 config error processing olcDatabase={0}config,cn=config: <olcUpdateRef> must appear after syncrepl or updatedn slapcat: bad configuration file! Adding up to three "-c" options did not help (in old OpenLDAP 2.4) Should there be an exception if UpdateRef is pointing to the local server? Kind regards, Ulrich Windl

1 0

Q: "monitor_back_register_entry("cn=Consumer 112,cn=Database 1,cn=Databases,cn=Monitor"): entry exists"
by Windl, Ulrich 04 Jul '25

04 Jul '25

Hi! For openldap-2.5 and an MMR configuration I see the message monitor_back_register_entry("cn=Consumer 112,cn=Database 1,cn=Databases,cn=Monitor"): entry exists during startup. I'm wondering what the messages actually says, and what causes it. Could it be some bug in OpenLDAP? The machine in question is real hardware (no VM) and it has a *lot* of RAM (500G) and CPUs (64). If I query the monitoring database, I see no such connection. Kind regards, Ulrich Windl

2 5

many connections in proxy setup
by Bergmann, Clemens 04 Jul '25

04 Jul '25

Hi, we have two openLDAP Servers configured with back_ldap. Each server has one non-OpenLDAP-Server as “target”. I passed a redacted copy of my configuration below. At any given time we have around 100 connections from clients to the openLDAP Server. I noticed that there are a lot more connections open from the ldap Server to the “target” Servers. Sometimes close to 1000. As this is a temporary setup I did not investigate any more. In the last days we sometimes see the following errors in log: “daemon: accept(10) failed errno=24 (Too many open files)” “connection_input: conn=1799 deferring operation: too many executing” “connection_read(446): no connection!” I suspect that this is because there are more than 1024 connections open and the OS is preventing opening more FDs. I am not sure why we have so many open connections to the “target” servers. Maybe someone can spot my config error. Thanks in advance. dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/lib/openldap/slapd.args olcIdleTimeout: 15 olcLocalSSF: 256 olcLogLevel: none olcPidFile: /var/lib/openldap/slapd.pid olcRootDSE: /etc/openldap/rootDSE.ldif olcSaslSecProps: noplain,noanonymous olcSecurity: simple_bind=256 ssf=256 tls=0 olcTLSCACertificateFile: /etc/ssl/certs/ca-bundle.crt olcTLSCertificateFile: /etc/openldap/certs/server.pem olcTLSCertificateKeyFile: /etc/openldap/certs/server.key olcTLSCipherSuite: DEFAULT:-SHA1:-CBC olcTLSDHParamFile: /etc/openldap/dhparam.pem olcTLSProtocolMin: 3.3 dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcAccess: redacted olcDbACLBind: bindmethod=simple binddn=cn=proxy,ou=admin,o=tu-darmstadt credentials=redacted tls_cacert=/etc/ssl/certs/ca-bundle.crt olcDbStartTLS: ldaps tls_cacert=/etc/ssl/certs/ca-bundle.crt olcDbURI: ldaps://backend-server01.example.com/ olcRootDN: cn=admin,ou=admin,o=tu-darmstadt olcSizeLimit: unlimited olcSuffix: o=tu-darmstadt olcTimeLimit: 90 Kind regards 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 4

Re: slapadd: could not add entry dn="cn=config" (line=1):
by Nick 03 Jul '25

03 Jul '25

I figured it out. I needed to only include the slapd.conf file in the directory, not slapd.ldif. Also generated rfc2307bis files and populated the database. Very cool! Thanks to the developers here! On Tue, Jul 1, 2025 at 7:10 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Sunday, June 29, 2025 2:49 AM -0400 Nick <atod101101(a)gmail.com> > wrote: > > > > Import the configuration database > > su root -c /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l > > /usr/local/etc/openldap/slapd.ldif > > What is the contents of slapd.ldif? And I assume the > /usr/local/etc/slapd.d/ directory exists and has no contents. > > --Quanah > > > >

1 0

slapadd: could not add entry dn="cn=config" (line=1):
by Nick 01 Jul '25

01 Jul '25

Does anyone know the source and resolution to this installation error? Interestingly, if I use an alternate command I'm able to bring up the server, in which I can see via debug it's responding to the client. I'm following: https://www.openldap.org/doc/admin24/quickstart.html Import the configuration database su root -c /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif and encounter this error. I see many posts on it with no resolution. I'm using MacPorts openldap 2.6.10. Interestingly, if I invoke this suggested command: /opt/local/libexec/slapd -f /opt/local/etc/openldap/slapd.conf -F /opt/local/etc/slapd.d I can invoke slapd and my LDAP server comes up. It responds back to: /opt/local/bin/ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts but without dc=site,dc=com only blank dn: dn: # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 There is nothing in my etc/slapd.d directory. I try: ldapadd -d 3 -x -D "cn=Manager,dc=p0,dc=mac" -W -f file.txt Enter LDAP Password: ldap_bind: Invalid DN syntax (34) additional info: invalid DN Not sure how to approach this and any guidance appreciated.

3 2

Translucent proxy with posix attributes and sssd
by Howard, Christopher 30 Jun '25

30 Jun '25

I currently manage ldap for a subset of users at our organization for some separate systems. The organization also uses ldap for all of its users. My separate ldap server uses different usernames for its users. I've been tasked with getting rid of this separate ldap, migrating all of our systems over to the central ldap and having users use their normal organizational credentials. To that end, I've created a new ldap server as a translucent proxy. The central ldap does not contain posix attributes. I'm not being permitted to create them and they are not willing to add them. I've tested with my new proxy that I can search for a user, retrieve all of their back end ldap attributes and all of my local overlay attributes. The translucent proxy is working. Now I'm to the step of setting up sssd to authenticate users on linux hosts. This is not working because sssd searches using a filter that contains objectclass=posixAccount and uidNumber. I've ensured that those values are in my overlay, but they do not exist in the back end ldap. As a result, I get no user returned from the search. I've changed sssd config to make objectclass=person in the search filter, but that still leaves the uidNumber issue. Is there any way around this? I've exhausted the documentation for sssd and don't see it. Is there a way in the ldap proxy to handle this? Do I need to set olcTranslucentLocal to define the local only attributes? My guess is I'll have the same issue with groups and gidNumber when I get to that step of the process as well. If this is a dead end, are there any other options to do what I need to do? Thank you, -Christopher

2 1

Odd "<= str2entry NULL (smr_normalize createTimestamp 21)" when trying slapadd to cn=config
by Windl, Ulrich 30 Jun '25

30 Jun '25

Hi! Trying to create the initial config from LDIF using "slapadd -v -F /etc/openldap/slapd.d -w -S 3 -n0 -l 0.ldif" inSLES15 I get this: 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}rfc2307bis,cn=schema,cn=config" (00000001) added: "cn={4}yast,cn=schema,cn=config" (00000001) added: "cn={5}sudo,cn=schema,cn=config" (00000001) added: "olcDatabase={-1}frontend,cn=config" (00000001) <= str2entry NULL (smr_normalize createTimestamp 21) slapadd: could not parse entry (line=2360) Closing DB... I've done that on a different machine without any errors so far. The LDIF entry after "olcDatabase={-1}frontend,cn=config" is "dn: olcDatabase={0}config,cn=config". The timestamps are: creatorsName: cn=config createTimestamp: 20130712083810Z entryCSN: 20160222141054.581517Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20160222141054Z An "interesting" fact I found in /etc/openldap/slapd.d/cn=config/cn=schema.ldif was the end of the file; it reads: ... anslucentNoGlue $ olcTranslucentLocal $ olcTranslucentRemote $ olcTranslucent BindLocal $ olcTranslucentPwModLocal ) )lucent target database configuration' AUXILIARY )lue uniqueness configuration' SUP olcOverlayConfig STRUCTURAL MAY ( olcUniqueBase $ olcUniqueIgnore $ olcUniqueAttribute $ olcUniqueStrict $ o lcUniqueURI ) )g configuration' SUP olcOverlayConfig STRUCTURAL MUST olcValSo rtAttr )LIARY MAY ( olmBDBEntryCache $ olmBDBDNCache $ olmBDBIDLCache $ olmDb Directory ) )NSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )MAN-READABLE 'TRUE' )tion' )DABLE 'TRUE' )ADABLE 'TRUE' )TRANSFER-REQUIRED 'TRUE' X-NOT-HU MAN-READABLE 'TRUE' )NARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE ' )INARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )ficate' X-BINA RY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )ription' )scription' )umber' )ABLE 'TRUE' )DABLE 'TRUE' )ess Points' )tion' )cription' )' )' )ion ' ) ) ) )X-BINARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )tifie r' )on' )n' )on' )) Exact Assertion' ) Assertion' ) ) That doesn't look right for me. CPU here is an "AMD EPYC 9354P 32-Core Processor", while the other machine without problems ran with VMware and "Intel(R) Xeon(R) Gold 6238R CPU @ 2.20GHz"; Looks like the last write to the config database is nor correct in case of errors. Neither option "-c" (continue), nor "-o value-check=no", nor "-o schema-check=no" did help. After some experiments I get a different error like "<= str2entry NULL (smr_normalize creatorsName 21)" Any insights? Kind regards, Ulrich Windl

1 1

Assert failed in ldap_do_free_request()
by radiatejava 29 Jun '25

29 Jun '25

Hello experts We are using OpenLDAP lib ver 2.6.7 on Ubuntu 24.04. When doing LDAP search using ldap_search_ext_s() we are getting assert failure. Any idea what could be going wrong? Appreciate your reply. Here is the stacktrace: #0 0x000071e8baceeb2c in pthread_kill () from /usr/lib/x86_64-linux-gnu/libc.so.6 #1 0x000071e8bac9527e in raise () from /usr/lib/x86_64-linux-gnu/libc.so.6 #2 0x000071e8bac788ff in abort () from /usr/lib/x86_64-linux-gnu/libc.so.6 #3 0x000071e8bac7881b in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6 #4 0x000071e8bac8b517 in __assert_fail () from /usr/lib/x86_64-linux-gnu/libc.so.6 #5 0x000071e8b9684409 in ldap_do_free_request () from /opt/ldap/lib/libldap.so.2 #6 0x000071e8b96b4bf9 in ldap_tavl_free () from /opt/ldap/lib/libldap.so.2 #7 0x000071e8b968359a in ldap_free_connection () from /opt/ldap/lib/libldap.so.2 #8 0x000071e8b9683e9c in ldap_new_connection () from /opt/ldap/lib/libldap.so.2 #9 0x000071e8b9682aa7 in ldap_send_server_request () from /opt/ldap/lib/libldap.so.2 #10 0x000071e8b9685619 in ldap_chase_v3referrals () from /opt/ldap/lib/libldap.so.2 #11 0x000071e8b9667640 in try_read1msg () from /opt/ldap/lib/libldap.so.2 #12 0x000071e8b9666515 in wait4msg () from /opt/ldap/lib/libldap.so.2 #13 0x000071e8b9665f09 in ldap_result () from /opt/ldap/lib/libldap.so.2 #14 0x000071e8b9672a95 in ldap_sasl_bind_s () from /opt/ldap/lib/libldap.so.2 #15 0x000071e8b96740b2 in ldap_simple_bind_s () from /opt/ldap/lib/libldap.so.2 #16 0x000071e8bb737e2a in myapp::getRebindCredentials(ldap*, char const*, unsigned long, int, void*) () from /mgmt/usr/lib/x86_64-linux-gnu/libsvc_myapp.so #17 0x000071e8b9683e0b in ldap_new_connection () from /opt/ldap/lib/libldap.so.2 #18 0x000071e8b9682aa7 in ldap_send_server_request () from /opt/ldap/lib/libldap.so.2 #19 0x000071e8b9685619 in ldap_chase_v3referrals () from /opt/ldap/lib/libldap.so.2 #20 0x000071e8b9667640 in try_read1msg () from /opt/ldap/lib/libldap.so.2 #21 0x000071e8b9666515 in wait4msg () from /opt/ldap/lib/libldap.so.2 #22 0x000071e8b9665f09 in ldap_result () from /opt/ldap/lib/libldap.so.2 #23 0x000071e8b966acf7 in ldap_pvt_search_s () from /opt/ldap/lib/libldap.so.2 #24 0x000071e8b966ac25 in ldap_search_ext_s () from /opt/ldap/lib/libldap.so.2 #25 0x000071e8bb732c15 in myapp::LdapAuthenticationBroker::doLdapAuthenticate() () from /mgmt/usr/lib/x86_64-linux-gnu/libsvc_myapp.so #26 0x000071e8bb732484 in myapp::LdapAuthenticationBroker::start(bool&, void (*)(myapp::ExternalAuthenticationBroker*)) () from /mgmt/usr/lib/x86_64-linux-gnu/libsvc_myapp.so

3 4

Configuring LDAP server and NFS client, login credentials and to mount NFS directories?
by Nick 29 Jun '25

29 Jun '25

Does anyone know the steps to configure a LDAP server to provide login credentials to a client (Linux) and NFS mount points? I think this is some industry standard for authenticating and automatically mounting NFS directories. So far, I have configured: - NFS server (MacOS) - QEMU for VM - DHCP/BootP server to provide NIS/LDAP options (IP of NIS and LDAP servers) - openldap server, tested installation However, I'm looking for the next steps to accomplish such a task. This could include any references to web pages on the topic.

1 0

Another request related to openldap backsock backend
by Gianluca Ramunno 26 Jun '25

26 Jun '25

Hello, I made quite some progress with developing an LDAP proxy using openldap + backsock backend + a python server. The backsock backend and the python server communicate via UNIX socket according to the protocol described here: https://linux.die.net/man/5/slapd-sock The python server at the moment implements the execution of the BIND and of the SEARCH operations against a remote LDAP server and returns back the results to the backsock backend. Using the command ldapsearch I perform some SEARCH operations and I see a weird behaviour when the output is printed out by ldapsearch; I request a number of attributes which are returned correctly by the remote LDAP server to the python server, then the latter prepares an LDIF chunk with the returned entry (with all requested attributes) and sends this chunk back to the openldap backsock backend via UNIX socket. Unfortunately, ldapsearch prints out the received entry with a lower number of attributes. The missing attributes are always the same (at a repeated execution of the same SEARCH), but non necessarily the last one(s). I don't receive back any error. In the python server I also print out the whole LDIF chunk just before sending it back to the backsock backend and all attributes are there. I also checked that the protocol between backsock backend and the python server is correct according to the specifications. Note that if I perform the same SEARCH operations with ldapsearch directly against the remote LDAP server (i.e. without the LDAP proxy in between), all requested attributes are returned and printed correctly. Any clue on what's happening or on how to debug this problem in openldap? Thank you in advance. Best regards Gianluca Ramunno

1 1

delta-syncrepl experience with OpenLDAP 2.5 (from SLES15)
by Windl, Ulrich 26 Jun '25

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

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

26 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 2

OpenLDAP BIND requiring privileged DN first
by Carl Waldbieser 24 Jun '25

24 Jun '25

I am using OpenLDAP as the credential backend to an SSO solution. The SSO software attempts a simple BIND with the user DN and the password supplied by the user. This all works as intended. However, there are some legacy web applications that pre-date our SSO solution that use direct LDAP authentication. That is, the web application collects the user password from a form submission, and then it makes its own BIND attempt with the user DN and supplied password. These legacy apps have legitimate reasons to connect to our LDAP service for non-authentication purposes. Is there a way that I can prevent BINDs for normal user DNs from any source other than the SSO software? Network-based solutions do not seem to be an option because all these applications have their private IP addresses assigned dynamically. I had tried setting up access control rules to only allow the "auth" access level to unprivileged user entries by already authenticated users, but that doesn't seem to work. In the OpenLDAP logs, I see the privileged BIND is successful. However, when issuing a second BIND for the unprivileged user, OpenLDAP first logs: BIND anonymous mech=implicit bind_ssf=0 ssf=0 and then the subsequent normal user BIND fails, as anonymous BINDs are not allowed for those entries. I'm not sure if this is part of the LDAP protocol or due to the LDAP client I am using, or something related to the OpenLDAP service. I have tried 2 different clients with similar results. Is my approach to this issue technically possible? Are there other solutions? Thanks, Carl Waldbieser ITS Lafayette College

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 18 Jun '25

18 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

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

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

Cannot connect over TLS/SSL (ldaps) on v2.6.9
by Nick Milas 26 May '25

26 May '25

Hello, I have managed to start the migrated LDAP server on Rocky 9, v2.6.9 LTB. It seems to be working fine but, I cannot connect over ssl (ldaps, port 636). I am trying to connect with Apache Directory Studio but it fails, although I am using the same certificate as on the orignal server (the cert covers both server names). I have enabled conns logging on the server and I see connection coming in, but for some reason it fails (input error=-2): Could you please guide me to troubleshoot this? May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 busy May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: accept() = 14* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: listen=9, new connection on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: added 14r (active) listener=(nil)* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 fd=14 ACCEPT from IP=195.251.xxx.xxx:51334 (IP=0.0.0.0:636)* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 fd=14 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 op=0 BIND dn="uid=userx,ou=people,dc=noa,dc=gr" method=128 May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 op=0 BIND dn="uid=userx,ou=people,dc=noa,dc=gr" mech=SIMPLE bind_ssf=0 ssf=256 May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 op=0 RESULT tag=97 err=0 qtime=0.000034 etime=0.000475 text=* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:44 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:44 ldap1.noa.gr slapd[17512]: May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:44 ldap1.noa.gr slapd[17512]: connection_read(14): input error=-2 id=1002, closing. May 21 11:19:44 ldap1.noa.gr slapd[17512]: connection_closing: readying conn=1002 sd=14 for close May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: removing 14 May 21 11:19:44 ldap1.noa.gr slapd[17512]: conn=1002 fd=14 closed (connection lost)*May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:44 ldap1.noa.gr slapd[17512]: May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL I have tried removing the olcTLSCipherSuite attribute, but it won't work anyway. As a side note, I see that logging is directed to the journal. Could I redirect it to a file instead? I have set olcLogFile, but logging is directed to the journal nevertheless. Thanks a lot, Nick

4 4

Reminder: Long Term Support release series is now OpenLDAP 2.6
by Quanah Gibson-Mount 22 May '25

22 May '25

With the release of OpenLDAP 2.6.10, the OpenLDAP 2.6 release series is now the long term support release. 2.5.20 is the last planned release for the OpenLDAP 2.5 series. Regards, Quanah

1 0

slapadd a 2.4 cn=config ldif into 2.6 fails
by Nick Milas 20 May '25

20 May '25

Hello, I am trying to migrate our 2.4.58 Openldap (LTB on CentOS 7) to 2.6.9 (LTB on Rocky 9). I slapcat'ed the config DIT and data DIT and I am currently trying to import them into the new installation. I have removed ppolicy schema and tried to slapadd, but it fails: [root@ldap1 openldap]# slapadd -vvv -n0 -F /usr/local/openldap/etc/openldap/slapd.d -l /root/work/ldap-mig2/config-dit.ldif added: "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}proftpd-quota,cn=schema,cn=config" (00000001) added: "cn={11}kerberos,cn=schema,cn=config" (00000001) added: "cn={12}localemailrecipient,cn=schema,cn=config" (00000001) added: "cn={13}entryaccess,cn=schema,cn=config" (00000001) added: "cn={14}radius,cn=schema,cn=config" (00000001) added: "cn={15}pdns-domaininfo,cn=schema,cn=config" (00000001) added: "olcDatabase={-1}frontend,cn=config" (00000001) added: "olcDatabase={0}config,cn=config" (00000001) <= str2entry: str2ad(olcDbNoSync): attribute type undefined slapadd: could not parse entry (line=2913) Closing DB... If I understand right, the process seems to be disturbed by the olcDbNoSync attribute: <= str2entry: str2ad(olcDbNoSync): attribute type undefined What may be the cause? I have seen in the Internet earlier reports of this error during slapadd but there is no single reason. Please advise. Thanks in advance, Niick

2 3

openldap TLSv1.0 is enabled
by Andre Rodier 16 May '25

16 May '25

Hello, I have configured OpenLDAP using SSL certificate, but I have a few issues. Here the TLS configuration, especially "olcTLSProtocolMin: 3.3" > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > # CRC32 c70363a6 > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/slapd/slapd.args > olcLogLevel: none > olcPidFile: /var/run/slapd/slapd.pid > olcToolThreads: 1 > structuralObjectClass: olcGlobal > entryUUID: 40ee991a-0efe-103d-855a-11ff3a5638b4 > creatorsName: cn=config > createTimestamp: 20221213065102Z > olcPasswordCryptSaltFormat: $6$%.16s > olcTLSCACertificateFile: /etc/ldap/certs/ldap.homebox.world.issuer.crt > olcTLSCertificateKeyFile: /etc/ldap/certs/ldap.homebox.world.key > olcTLSCertificateFile: /etc/ldap/certs/ldap.homebox.world.crt > olcTLSProtocolMin: 3.3 > entryCSN: 20221214054517.926245Z#000000#000#000000 > modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > modifyTimestamp: 20221214054517Z But if I try sslscan: I see TLSv1.0, TLSv1.1 and TLSv1.2 enabled. Why ? > root@main:/etc/ldap/changes# sslscan ldap.homebox.world:636 > Version: 2.0.7 > OpenSSL 1.1.1n 15 Mar 2022 > > Connected to 2001:19f0:7402:86e:5400:4ff:fe38:b9b4 > > Testing SSL server ldap.homebox.world on port 636 using SNI name ldap.homebox.world > > SSL/TLS Protocols: > SSLv2 disabled > SSLv3 disabled > TLSv1.0 enabled > TLSv1.1 enabled > TLSv1.2 enabled > TLSv1.3 enabled > > TLS Fallback SCSV: > Server supports TLS Fallback SCSV > > TLS renegotiation: > Secure session renegotiation supported > > TLS Compression: > OpenSSL version does not support compression > Rebuild with zlib1g-dev package for zlib support > > Heartbleed: > TLSv1.3 not vulnerable to heartbleed > TLSv1.2 not vulnerable to heartbleed > TLSv1.1 not vulnerable to heartbleed > TLSv1.0 not vulnerable to heartbleed > > Supported Server Cipher(s): > Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 128 bits TLS_AES_128_CCM_SHA256 Curve 25519 DHE 253 > Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253 > Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits AES256-GCM-SHA384 > Accepted TLSv1.2 256 bits AES256-CCM > Accepted TLSv1.2 128 bits AES128-GCM-SHA256 > Accepted TLSv1.2 128 bits AES128-CCM > Accepted TLSv1.2 256 bits AES256-SHA > Accepted TLSv1.2 128 bits AES128-SHA > Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 256 bits AES256-SHA > Accepted TLSv1.1 128 bits AES128-SHA > Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 256 bits AES256-SHA > Accepted TLSv1.0 128 bits AES128-SHA > > Server Key Exchange Group(s): > TLSv1.3 128 bits secp256r1 (NIST P-256) > TLSv1.3 192 bits secp384r1 (NIST P-384) > TLSv1.3 260 bits secp521r1 (NIST P-521) > TLSv1.3 128 bits x25519 > TLSv1.3 224 bits x448 > TLSv1.3 112 bits ffdhe2048 > TLSv1.3 128 bits ffdhe3072 > TLSv1.3 150 bits ffdhe4096 > TLSv1.3 175 bits ffdhe6144 > TLSv1.3 192 bits ffdhe8192 > TLSv1.2 128 bits secp256r1 (NIST P-256) > TLSv1.2 192 bits secp384r1 (NIST P-384) > TLSv1.2 260 bits secp521r1 (NIST P-521) > TLSv1.2 128 bits x25519 > TLSv1.2 224 bits x448 > > SSL Certificate: > Signature Algorithm: sha256WithRSAEncryption > RSA Key Strength: 2048 > > Subject: ldap.homebox.world > Altnames: DNS:ldap.homebox.world > Issuer: (STAGING) Artificial Apricot R3 > > Not valid before: Dec 13 05:34:29 2022 GMT > Not valid after: Mar 13 05:34:28 2023 GMT Thanks for your insights. Andre

6 13

RE26 testing call (2.6.10) #1
by Quanah Gibson-Mount 15 May '25

15 May '25

This is the first testing call for OpenLDAP 2.6.10. 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.10 Engineering Added slapd microsecond timestamp format for local logging (ITS#10140) Fixed libldap ldap_result behavior with LDAP_MSG_RECEIVED (ITS#10229) Fixed lloadd handling of starttls critical (ITS#10323) Fixed slapd syncrepl when used with slapo-rwm (ITS#10290) Fixed slapd regression with certain searches (ITS#10307) Fixed slapo-autoca olcAutoCAserverClass object (ITS#10288) Fixed slapo-pcache caching behaviors (ITS#10270) Minor Cleanup ITS#7080 ITS#7249 ITS#9934 ITS#10020 ITS#10168 ITS#10226 ITS#10279 ITS#10299 ITS#10302 ITS#10309 ITS#10312 ITS#10320 ITS#10325 ITS#10327 ITS#10328 ITS#10331 Regards, Quanah

2 2

changing password with otp active
by Stefan Kania 09 May '25

09 May '25

Hello to all When I activate the otp-overlay I can login with my userpassword and the 6 digit token. But how can I change the password with otp activ? Without otp I do "passwd" then giving the old password and then the new password twice and the password is changed With opt I have to give the old password+6-digit. If I only giving the password the server complains immediately that the password is wrong. When I'm giving the old password plus the 6-digit, the server accepts the password. Then I can give the new password twice, but then I'm getting the massage: Server-message: Old password not accepted. So how can an user change his password via commandline with otp active? Thanks Stefan

3 13

Q: The role of accesslog with delta syncrepl in OpenLDAP 2.5
by Windl, Ulrich 09 May '25

09 May '25

Hi! I think I converted my syncreply configuration (that wasn't perfect) to a delta syncrepl configuration (that I think is correct). However I'm not very confident whether everything is working as expected, also whether I'm using the correct procedures. In the process of configuring I had hanging processes (adding the syncrepl overlay) and crasing processes (adding the syncprov). Then I had noticed that slapd did empty the local accesslog (which I named changelog, because that is what it is). I had expected that slapd would only "append" new entries, and old entries would be expired as specified only. Also I wonder whether the local accesslog has some meaning when slapd start up: Does slapd consider its contents at all, and if so: In which way? I had repeatable crashes when starting slapd until I deleted the changelogs. Kind regards, Ulrich Windl

2 2

Poor OpenSSL performance
by Howard Chu 09 May '25

09 May '25

I've noticed that OpenSSL 3.x performs much worse than OpenSSL 1.x. The analysis in this blog post is pretty revealing. https://www.haproxy.com/blog/state-of-ssl-stacks Anyone up for adding WolfSSL support to libldap? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

RE25 testing call (2.5.20) #1
by Quanah Gibson-Mount 08 May '25

08 May '25

This is the first testing call for OpenLDAP 2.5.20. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/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.5.20 Engineering Fixed lloadd handling of starttls critical (ITS#10323) Fixed slapd regression with certain searches (ITS#10307) Fixed slapo-pcache caching behaviors (ITS#10270) Minor Cleanup ITS#9934 ITS#10020 ITS#10226 ITS#10279 ITS#10309 ITS#10320 ITS#10327 ITS#10328 ITS#10331 Regards, Quanah

1 0

Translucent and Syncreplication
by Bergmann, Clemens 08 May '25

08 May '25

Hi, We are currently setting up a new openLDAP service and face Problems when combining slapo-translucent and syncreplication. To increase reliability and performance the new new openldap Server is behind a Loadbalancer which redirects requests to three instances. These three instances sync config and data via syncrepl. This works fine. We also have a legacy LDAP Server that some of the data has to be stored and updated in during migration of other services. For this we use the slapo-translucent functionality and that also works fine. We now face problems when combing these two concepts. When stacking the syncrepl and translucent overlays the server is not starting because slapo-translucent/slapd-ldap is setting olcLastMod to false. This has come up many times in this list but I was unable to find a solution. Is there another setup to combine translucent with high availability? 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 2

[Seeking Help] - When there is no entry in ldap db getting success response instead of noSuchObject
by Niranjan Ganjikunta 07 May '25

07 May '25

Hi Gentlemen, We are hosting an LDAP server on an Ubuntu Linux system, and our requirement is to return a noSuchObject error in the LDAP response when a search yields no results, instead of returning a success response. we are using below search command. ldapsearch -b "ou=Subscribers,ou=sda,o=centertel.pl" -D "cn=admin" -w "XXXXX" -H ldap://ip:389 -v -s sub "ptkSubscriberIMSI=26003123456789" This command is trying to search for the imsi under the base dn by using the filter. in this case if there is no entry present in db we are expecting noSuchObject (32) response from ldap. We tried to build overlay by using below c++ script to modify the default ldap behaviour to get nosuchobject when there is no entry in db. #include "portable.h" // Required for OpenLDAP build environment #include <stdio.h> #include <ac/string.h> // OpenLDAP-specific replacements #include <ac/regex.h> // Brings in regex_t, regmatch_t #include <ldap.h> #include "slap.h" #include <stdio.h> #include <ldap.h> #include <slap.h> int my_overlay_search(Operation *op, SlapReply *rs) { // Correct call to next overlay/backend int rc = overlay_op_walk(op, rs, SLAP_OP_SEARCH, (slap_overinfo *)op->o_bd->bd_info, NULL); if (rs->sr_err == LDAP_SUCCESS && rs->sr_entry == NULL) { rs->sr_err = LDAP_NO_SUCH_OBJECT; rs->sr_text = "No such object found"; Debug(LDAP_DEBUG_ANY, "Custom overlay: noSuchObject error triggered\n"); } return rc; } and by using below command build .so file gcc -fPIC -shared \ -I "$OPENLDAP_SRC/include" \ -I "$OPENLDAP_SRC/servers/slapd" \ -I "$OPENLDAP_SRC/libraries/libldap" \ -I "$OPENLDAP_SRC/libraries/liblber" \ -o "my_overlay.c" "noSuchobject_overlay.so" \ -lldap we didnt get any error while building the .so file. but while loading the module by using below ldif file content getting error dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: /usr/lib/ldap/noSuchobject_overlay.so config="/etc/ldap/ldap.conf" root@lodsto-essvt:~# ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f new_load_overlay.ldif modifying entry "cn=module{0},cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcModuleLoad> handler exited with 1 and we got stuck in this module load. May be can you review and propose proper steps and script to build the required module to get expected ldap behaviour. Thanks in advance. RGds, Niranjan Kumar [cid:image001.png@01DBBF8D.9A9631F0]

2 1

ldap proxy
by fred750164＠gmail.com 06 May '25

06 May '25

I want to set up an architecture that allows a client to query an LDAP backend via an LDAP proxy. I want the query from the client to be unsecured, but the proxied communication between the LDAP proxy and the LDAP backend to be secured through mutual TLS authentication via SASL EXTERNAL. What configurations need to be implemented on the LDAP proxy and the LDAP backend? I saw in the slapd-ldap(5) documentation that the idassert-bind parameter could be used on the LDAP proxy for the TLS connection via SASL EXTERNAL, and in the slapd.conf(5) documentation that the authz-regexp parameter could be used on the LDAP backend to allow querying with a DN extracted from the certificate on this LDAP backend. However, I am struggling to set it up. I use openldap 2.4. slapd.conf on proxy server: [...] Database ldap suffix dc=test,dc=com uri ldaps://mytest.com:636 idassert-bind mode=self bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/certs/server.crt tls_key=/etc/openldap/certs/server.key tls_cacert=/etc/ssl/certs/ca-bundle.crt tls_cacertdir=/etc/ssl/certs tls_crlcheck=none tls_reqcert=allow [...] slapd.conf on backend server: [...] # Modules moduleload back_mdb moduleload authz-regexp # TLS TLSCACertificateFile /opt/openldap/etc/openldap/certs/ca-certificates.crt TLSCertificateFile /opt/openldap/etc/openldap/certs/backend.crt TLSCertificateKeyFile /opt/openldap/etc/openldap/certs/backend.key TLSCipherSuite HIGH TLSVerifyClient demand sasl-Host mytest.com sasl-realm EXTERNAL authz-regexp ".*" "cn=user1,dc=test,dc=com" [...] proxy: ldapsearch -H ldaps://mytest.com -b "dc=appli,dc=test,dc=com" -Y EXTERNAL -ZZ ldap_start_tls: Can't contact LDAP server (-1) backend: 67895427.2b4074ce 0x7f7e6bffe6c0 TLS: can't accept: error:0A0000C7:SSL routines::peer did not return a certificate. Any help would be appreciated.

7 44

Match certificate subject with escaped characters using olcAuthzRegexp
by Windl, Ulrich 06 May '25

06 May '25

Hi! Trying to match the (som,e experimental) certificate subject to assign it LDAP users, I have some problems: Escaping of the subject seems to make regexp matching even harder. For example "CN = "uid=windl+email=u.windl(a)ukr.de", GN = Ulrich, SN = Windl" (as displayed by OpenSSL) is converted to "dn:sn=windl,givenName=ulrich,cn=uid\3Dwindl\2Bemail\3Du.windl@ukr.de" As I understand it uid=windl+email=u.windl(a)ukr.de<mailto:uid=windl+email=u.windl@ukr.de>" and email=u.windl(a)ukr.de<mailto:uid=windl+email=u.windl@ukr.de>+uid=windl" would be equivalent. So when I want to match just the uid part I could use "uid\\3D([^,]+)", but that would include "\2Bemail\3Du...". If I'd use uid\\3D([^,\]+)", instead, any escaped character inside the uid would terminate the match. How do the experts handle it? Use very simplistic CNs in certificates? Kind regards, Ulrich Windl

2 5

Re: [EXT] Re: Q: lastbind, pwdLastSuccess, and authTimestamp
by Ondřej Kuzník 06 May '25

06 May '25

On Mon, May 05, 2025 at 08:00:42AM +0000, Windl, Ulrich wrote: > And "core lastbind" means the "lastbind" module? Starting with 2.5 there are two "lastbind" implementations: - the old contrib/ overlay - OpenLDAP's own (what I mean by "core") implementation that doesn't require an overlay > From a user's perspective it's hard to tell why the "lastbind" module > would be "core" while "policy" module would not (if I undertood it > correctly). > Is it due to the progress of standardization? No it is just to make it possible to implement the latest ppolicy drafts. AFAIR the contrib/ overlay was incapable of this. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Message "slapd[2734]: config error processing olcDatabase={0}config,cn=config: <olcMultiProvider> database is not a shadow"
by Windl, Ulrich 29 Apr '25

29 Apr '25

Hi! While setting up an OpenLDAP-2.5-based MMR configuration I had set up the master node, then dumped the config database, copied the LDIF to the other node. However when starting slapd, it failed with the message slapd[2734]: config error processing olcDatabase={0}config,cn=config: <olcMultiProvider> database is not a shadow See also https://stackoverflow.com/q/6792212/6607497 The context of olcMultiProvider is: dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config ... olcMultiProvider: TRUE On the first node I had updated the config using this LDIF: dn: olcDatabase=${db},cn=config changetype: modify delete: olcMirrorMode olcMirrorMode: TRUE - add: olcMultiProvider olcMultiProvider: TRUE So I don't understand why this won't work on the second node. Specifically I can restart the first node without an issue. The only difference is that the primary node has a patch against crashing on an invalid olcAuthzRegexp (I had reported). Well can anybody explain what this message means? Update: Reading https://www.openldap.com/lists/openldap-technical/201807/msg00051.html ("Do you have a unique olcServerID set in cn=config for both masters")I realized that I forgot to specify "-S SID" for slapadd. Unfortunately even after using option -S, the error message remains the same. Kind regards, Ulrich Windl

2 3

Q: odd accesslog entry and unchanged attributes
by Windl, Ulrich 29 Apr '25

29 Apr '25

Hi! Debugging issues with my OpenLDAP configuration I inspected the changelog. One entry had some "odd" values (IMHO). Consider this example: dn: reqStart=20250423131324.000185Z,cn=audit objectClass: auditModify structuralObjectClass: auditModify reqStart: 20250423131324.000185Z reqEnd: 20250423131324.000188Z reqType: modify reqSession: 1024 reqAuthzID: cn=config reqDN: olcDatabase={4}mdb,cn=config reqResult: 0 reqMod: olcRootPW:= {SSHA256}REDACTED agNLQ== reqMod: entryCSN:= 20250423131324.377585Z#000000#005#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20250423131324Z reqOld: olcRootPW: REDACTED reqOld: entryCSN: 20250423131324.038419Z#000000#005#000000 reqOld: modifiersName: cn=config reqOld: modifyTimestamp: 20250423131324Z reqEntryUUID: 7b0b106c-b490-103f-8f46-3bae5e23549d entryUUID: 7b40af6a-b490-103f-8f7d-3bae5e23549d creatorsName: cn=audit createTimestamp: 20250423131324Z entryCSN: 20250423131324.377585Z#000000#005#000000 modifiersName: cn=audit modifyTimestamp: 20250423131324Z The change in entryCSN and modifyTimestamp are: OLD: 20250423131324.038419Z#000000#005#000000 NEW: 20250423131324.377585Z#000000#005#000000 OLD: 20250423131324Z NEW: 20250423131324Z So the change happened within the same second, and modifyTimestamp did not actually change. So the question is kind of philosophical: Are attibutes logged as changed when actually they did not change? This would apply to modifyTimestamp and modifyTimestamp in this case. Kind regards, Ulrich Windl

2 1

LDAP URI for slapcat -H
by Windl, Ulrich 29 Apr '25

29 Apr '25

Hi! After reading the manual of slapcat (for 2.5) it recommends using option -H and an URI instead of other obsolete options. So I tried it, but all I get is a usage message, even with "-v" and "-d9". Like this: # slapcat -d9 -H 'ldap:///?entryCSN?sub?(objectClass=*)' usage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]] [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] However when I use # slapcat -H 'ldap://?entryCSN?dc=...,dc=de?sub?(objectClass=*)' I get output. The URI should be: scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION extensions]]]]] Do I have tomatoes on my eyes? Anyway I think slapcat could provide a better error message. Even an ltrace did not enlighten me: # ltrace slapcat -d9 -H 'ldap:///?entryCSN?sub?(objectClass=*)?' ber_set_option(0, 0x8002, 0x55ad287ce980, 0x7f7d383ff680) = 0 ldap_pvt_thread_initialize(0x7f7d3862c1c0, 0x55ad287ce980, 32, 0x55ad287ce980) = 0 ldap_create(0x55ad287d6a78, 0, 0, 0) = 0 ldap_pvt_tls_set_option(0x55ad56df1a50, 0x6006, 0x7ffd5d8d1f6c, 48) = 0 strrchr("slapcat", '/') = nil strcmp("slapcat", "slapd") = -1 strcmp("slapcat", "slapadd") = 2 strcmp("slapcat", "slapcat") = 0 ldap_set_option(0, 0x5001, 0x55ad287d12d0, 0x7ffd5d8d2158) = 0 getopt(4, 0x7ffd5d8d2158, "a:b:cd:f:F:gH:l:n:o:s:v") = 100 __ctype_b_loc() = 0x7f7d384c1d60 strtoul(0x7ffd5d8d36a9, 0x7ffd5d8d1bb0, 0, 0) = 9 getopt(4, 0x7ffd5d8d2158, "a:b:cd:f:F:gH:l:n:o:s:v") = 72 ldap_url_parse_ext(0x7ffd5d8d36ae, 0x7ffd5d8d1cb0, 5, 0) = 10 __fprintf_chk(0x7f7d384004e0, 1, 0x55ad2877a9f0, 0x55ad2875c4ddusage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]]) = 88 fputs(" [-c]\n\t[-g] [-n databasenumber |"..., 0x7f7d384004e0 [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] ) = 1 exit(1 <no return ...> +++ exited (status 1) +++ Kind regards, Ulrich Windl

2 3

SBOM required!
by Sahil Sharma D 29 Apr '25

29 Apr '25

Hi team, Could you please provide the SBOM for OpenLDAP version REL_ENG_2_6_4 , or advise me on where I can locate the SBOMs for all versions? Regards, Sahil

2 1

core dump when using olcSpSessionlogSource
by Windl, Ulrich 24 Apr '25

24 Apr '25

Hi! Configuring delta-syncrepl, I tried olcSpSessionlogSource instead of olcSPSessionlog. After slapd war started, it dumped core like this: … Apr 24 11:25:41 v05 slapd[5030]: syncprov_db_open: starting syncprov for suffix cn=config Apr 24 11:25:41 v05 slapd[5030]: conn=-1 op=0 syncprov_findcsn: mode=FIND_MAXCSN csn= Apr 24 11:25:41 v05 slapd[5030]: syncprov_db_open: starting syncprov for suffix dc=sap,dc=klinik,dc=uni-regensburg,dc=de Apr 24 11:25:41 v05 slapd[5030]: slapd starting Apr 24 11:25:41 v05 start[5017]: Starting ldap-server Apr 24 11:25:41 v05 systemd[1]: Started OpenLDAP Server Daemon. Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1000 op=1 generated new csn=20250424092541.888430Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a01217d0 20250424092541.888430Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a01217d0 20250424092541.888430Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5035]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1001 op=1 generated new csn=20250424092541.896113Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0122df0 20250424092541.896113Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: conn=1001 op=1 syncprov_checkpoint: running checkpoint Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0122df0 20250424092541.896113Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5037]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1002 op=1 generated new csn=20250424092541.900818Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0128240 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a012b820 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a012b820 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0128240 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5039]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1003 op=1 generated new csn=20250424092541.920778Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c106d00 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c107760 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c107760 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c106d00 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5041]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1004 op=1 generated new csn=20250424092541.937140Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c10c9f0 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c11c110 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c11c110 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c10c9f0 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5043]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1005 op=1 generated new csn=20250424092541.989098Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a012b920 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0107320 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0107320 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a012b920 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5044]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 slapd[5030]: slap_get_csn: conn=1006 op=1 generated new csn=20250424092542.004124Z#000000#005#000000 manage=1 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a01277f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: index objectClass 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index entryCSN 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqEnd 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqResult 0x0004 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a02376f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a02376f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a01277f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 ldapmodify[5046]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 slapd[5030]: slap_get_csn: conn=1007 op=1 generated new csn=20250424092542.020297Z#000000#005#000000 manage=1 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a010a230 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: index objectClass 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index entryCSN 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqEnd 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqResult 0x0004 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0117770 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0117770 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a010a230 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 ldapmodify[5048]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 slapd[5030]: slap_get_csn: conn=1008 op=1 generated new csn=20250424092542.036954Z#000000#005#000000 manage=1 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0237570 20250424092542.036954Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: syncprov_db_open: starting syncprov for suffix cn=changelog-0 Apr 24 11:25:42 v05 slapd[5030]: [71B blob data] Apr 24 11:25:42 v05 slapd[5030]: olcSpSessionlogSource: value #0: <olcSpSessionlogSource> failed startup (cn=changelog-0)! Apr 24 11:25:42 v05 systemd[1]: Started Process Core Dump (PID 5051/UID 0). Apr 24 11:25:42 v05 systemd-coredump[5052]: [🡕] Process 5030 (slapd) of user 1000 dumped core. Stack trace of thread 5034: #0 0x00007fd1b82a8dfc __pthread_kill_implementation (libc.so.6 + 0xa8dfc) #1 0x00007fd1b8257842 raise (libc.so.6 + 0x57842) #2 0x00007fd1b823f5cf abort (libc.so.6 + 0x3f5cf) #3 0x00007fd1b8240497 __libc_message.cold (libc.so.6 + 0x40497) #4 0x00007fd1b82b34b7 malloc_printerr (libc.so.6 + 0xb34b7) #5 0x00007fd1b82b5a69 _int_free (libc.so.6 + 0xb5a69) #6 0x00007fd1b82b81df free (libc.so.6 + 0xb81df) #7 0x00007fd1b8159bee n/a (syncprov.so + 0x3bee) #8 0x000056122f1a02ee overlay_destroy_one (slapd + 0xb82ee) #9 0x000056122f1156bd n/a (slapd + 0x2d6bd) #10 0x000056122f115fb0 n/a (slapd + 0x2dfb0) #11 0x000056122f19f533 overlay_op_walk (slapd + 0xb7533) #12 0x000056122f19f6be n/a (slapd + 0xb76be) #13 0x000056122f1319ad fe_op_add (slapd + 0x499ad) #14 0x000056122f1328d9 do_add (slapd + 0x4a8d9) #15 0x000056122f12b18f n/a (slapd + 0x4318f) #16 0x000056122f12b98d n/a (slapd + 0x4398d) #17 0x00007fd1b86bcda0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #18 0x00007fd1b82a6f6c start_thread (libc.so.6 + 0xa6f6c) #19 0x00007fd1b832e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 5030: #0 0x00007fd1b82a3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007fd1b82a8b83 __pthread_clockjoin_ex (libc.so.6 + 0xa8b83) #2 0x000056122f1281ca slapd_daemon (slapd + 0x401ca) #3 0x000056122f10b88e main (slapd + 0x2388e) #4 0x00007fd1b8240e6c __libc_start_call_main (libc.so.6 + 0x40e6c) #5 0x00007fd1b8240f35 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x40f35) #6 0x000056122f10b90a _start (slapd + 0x2390a) Stack trace of thread 5038: #0 0x00007fd1b82a3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007fd1b82a6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007fd1b86bce40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fd1b82a6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007fd1b832e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 5032: #0 0x00007fd1b832e796 epoll_wait (libc.so.6 + 0x12e796) #1 0x000056122f12507b n/a (slapd + 0x3d07b) #2 0x00007fd1b82a6f6c start_thread (libc.so.6 + 0xa6f6c) #3 0x00007fd1b832e338 __clone3 (libc.so.6 + 0x12e338) ELF object binary architecture: AMD x86-64 Apr 24 11:25:42 v05 ldapmodify[5050]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 systemd[1]: slapd.service: Main process exited, code=dumped, status=6/ABRT Apr 24 11:25:42 v05 systemd[1]: slapd.service: Failed with result 'core-dump'. Apr 24 11:25:42 v05 systemd[1]: systemd-coredump(a)1-5051-0.service: Deactivated successfully. Looks a bit like a bad free() to me. I was adding the syncprov overlay with the accesslog DB being defined, but the accesslog overlay to set “olcAccessLogDB: cn=changelog-0” wasn’t done yet. The changelog-0 database may have contained outdated entries. Kind regards, Ulrich Windl

1 2

opt attribute oathHMACAlgorithm
by Stefan Kania 23 Apr '25

23 Apr '25

Hi to all, I would like to add the otp-attributes with the following LDIF: --------------- dn: ou=users,dc=example,dc=net changetype: modify add: objectClass objectClass: oathTOTPParams - add: oathOTPLength oathOTPLength: 6 - add: oathHMACAlgorithm oathHMACAlgorithm: 1.2.840.113549.2.11 - add: oathTOTPTimeStepPeriod oathTOTPTimeStepPeriod: 30 - add: oathTOTPTimeStepWindow oathTOTPTimeStepWindow: 3 --------------- But I'm getting: ----------- modifying entry "ou=users,dc=example,dc=net" ldap_modify: Invalid syntax (21) additional info: oathHMACAlgorithm: value #0 invalid per syntax ----------- If I switch to SHA1: ----------- oathHMACAlgorithm: 1.2.840.113549.2.7 ----------- it works. The manpage is telling me: ----------- oathHMACAlgorithm: <OID> The OID of the hash algorithm to use as defined in RFC 8018. Supported algorithms include SHA1, SHA224, SHA256, SHA384 and SHA512. ----------- and .11 is SHA512. Why is it not working? Do I have to give the OID in a different way? Stefan

3 4

slapcat compains "scheme not available" after using "olcPasswordHash: sha256"
by Windl, Ulrich 23 Apr '25

23 Apr '25

Hi! Using OpenLDAP 2.5 from SLES15 SP6 I added "olcPasswordHash: sha256" ("olcPasswordHash: {sha256}") to cn=config (I wanted to add it to the {-1}frontend database, but slapd refused. I was able to set {SHA256} RootPWs, but now when I try slapcat, I get an error saying: slapcat -n0 olcPasswordHash: value #0: <olcPasswordHash> scheme not available ({SSHA256}) olcPasswordHash: value #0: <olcPasswordHash> no valid hashes found config error processing cn=config: <olcPasswordHash> no valid hashes found slapcat: bad configuration file! For slapppasswd I can use option "-o module-load=pw-sha2", but slapcat does not have it: # slapcat -o module-load=pw-sha2 -n0 usage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]] [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] Is it my error, or slapcat's? Regards, Ulrich

2 2

Adding syncprov overlay to cn=config seems to freeze the server
by Windl, Ulrich 22 Apr '25

22 Apr '25

Hi! I'm trying to script a reconfiguration of out OpenLDAP servers, also changing the replication details. After dropping the old syncrepl overlay, I tried to add a new one like this: dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig I deliberately did not add more specific attributes, because I wanted to add them later. However I forgot to set olcOverlay. The point is that both, ldapmodify and slapd become unresponsive using that LDIF, at least when provided as ldapmodify -Y EXTERNAL -H ldapi:/// <<LDIF ... LDIF Is this a bug? Seen in OpenLDAP 2.5 provided by SLES15 SP6. From a coredump I forced, I see that the threads are all waiting, using one of these: __pthread_clockjoin_ex pthread_cond_wait __pthread_clockjoin_ex Kind regards, Ulrich Windl

2 4

Search performance pretty bad when result from index > 1
by Norbert 17 Apr '25

17 Apr '25

Hi, Used version 2.5.19.1 (ltb) We have a LDAP with about 4.6 million entries and an indexed attribute which occurs around 3.9 million times. We typicall filter for that attribute with a specific value (eq). Which is typicall very fast and no problems. As soon as the same value used twice the execution time for that filter is becoming really slow even when additional criteria of the filter limits the result to exact 1 entry. Search time is at ~5% for single entry results compared to potential 2 entry results. Some more details how this was determined: 1) enable "stats" logging on production server for 5 minutes. 2) collect the slowest ~1200 from several thousand searches within the 5 minutes from the log 3) create a separate ldap server with exact same data and configuration (imported with slapadd) 4) use a script running locally on the extra server which executes the 1200 filters one after the other and measure complete execution time of script With production data I measure around 11s for the ~1200 searches. For all these searches one attribute in the filter could have 2 hits, but it is actually limited to 1 hit because of following filter "(&(objectClass=value)(almost_uniqe_attr=value)(another_attr=*))" Means searching with only "almost_uniqe_attr=value" as filter it would return 2 results, but objectClass and another_attr limit it to exact 1 entry. When I now remove the second entry from the ldap server for these exact ~1200 filters the script run time will be ~0.5s . If re-add those ~1200 entries the runtime will be around 5s (and with a complete recreate of the db it will be 11s again.) Limiting the search scope by using a more specific base dn for the search does not change anything in regards to the execution time. So the question is: 1) can I change anything on the server side to speed up the execution time of these searches? Regards, Norbert

3 8

openldap 2.5: core dump in slap_tool_update_ctxcsn_check of lsapmodify when deleting syncprov overlay
by Windl, Ulrich 16 Apr '25

16 Apr '25

Hi! I'm trying to batch-convert an openLDAP 2.4 MMR configuration to an configuration using openLDAP 2.5, also using MMR, but on different hosts (SLES15 SP6 on x86_64). When my script tried to drop the syncprov overlay, slapmodify dumps core in function slap_tool_update_ctxcsn_check, like this: kernel: slapmodify[24757]: segfault at 28 ip 000055d656ea7526 sp 00007ffe9e0875f0 error 4 in slapd[55d656dea000+149000] likely on CPU 1 (core 0, socket 2) kernel: Code: 48 33 0c 25 28 00 00 00 48 c7 c0 ff ff ff ff 0f 85 74 01 00 00 48 83 c4 28 5b 5d 41 5c 41 5d c3 0f 1f 40 00 49 89 fd 48 89 f3 <48> 8b 7e 28 48 8b 35 cf fa 09 00 e8 1a f5 f8 ff 48 85 c0... Dump of assembler code for function slap_tool_update_ctxcsn_check: 0x000055d656ea74d0 <+0>: push %r13 0x000055d656ea74d2 <+2>: push %r12 0x000055d656ea74d4 <+4>: push %rbp 0x000055d656ea74d5 <+5>: push %rbx 0x000055d656ea74d6 <+6>: sub $0x28,%rsp 0x000055d656ea74da <+10>: mov 0x9fdd3(%rip),%r8d # 0x55d656f472b4 <tool_globals+20> 0x000055d656ea74e1 <+17>: mov %fs:0x28,%rax 0x000055d656ea74ea <+26>: mov %rax,0x18(%rsp) 0x000055d656ea74ef <+31>: xor %eax,%eax 0x000055d656ea74f1 <+33>: test %r8d,%r8d 0x000055d656ea74f4 <+36>: jne 0x55d656ea7520 <slap_tool_update_ctxcsn_check+80> 0x000055d656ea74f6 <+38>: mov 0x18(%rsp),%rcx 0x000055d656ea74fb <+43>: xor %fs:0x28,%rcx 0x000055d656ea7504 <+52>: mov $0xffffffffffffffff,%rax 0x000055d656ea750b <+59>: jne 0x55d656ea7685 <slap_tool_update_ctxcsn_check+437> 0x000055d656ea7511 <+65>: add $0x28,%rsp 0x000055d656ea7515 <+69>: pop %rbx 0x000055d656ea7516 <+70>: pop %rbp 0x000055d656ea7517 <+71>: pop %r12 0x000055d656ea7519 <+73>: pop %r13 0x000055d656ea751b <+75>: ret 0x000055d656ea751c <+76>: nopl 0x0(%rax) 0x000055d656ea7520 <+80>: mov %rdi,%r13 0x000055d656ea7523 <+83>: mov %rsi,%rbx => 0x000055d656ea7526 <+86>: mov 0x28(%rsi),%rdi 0x000055d656ea752a <+90>: mov 0x9facf(%rip),%rsi # 0x55d656f47000 <slap_schema+192> 0x000055d656ea7531 <+97>: call 0x55d656e36a50 <attr_find> ... Slapmodify had been started with "slapmodify -F /etc/openldap/slapd.d -g -n0 -S 5 -w", and the input was: dn: olcOverlay= {0}syncprov, olcDatabase={0}config,cn=config changetype: delete The version I'm using was provided by SLES support as openldap2_5-2.5.18+31-150500.11.12.1.29527.34.PTF.1239787.x86_64 If I run slapmodify without "-w", no core dump happens. Kind regards, Ulrich Windl

2 1

Using olcAuthRegexpr with Kerberos principalname
by Stefan Kania 14 Apr '25

14 Apr '25

Hi all, I want to rewrite the gssapi user name after authentication using olcAuthzRegex, but I want to rewrite the krbPrincipalName. If a principal is getting a ticket and then test the authentication with "ldapwhoami" I see: uid=my-principal,cn=gssapi,cn=auth So now I want to rewrite the uid to: krbPrincipalName=my-principal@REALM,cn=REALM,cn=kerberos,dc=example,dc=net the real object name. My first try was olcAuthzRegexp: {0}uid=(.+),cn=gssapi,cn=auth krbPrincipalName=$1@REALM,cn=REALM,cn=kerberos,dc=example,dc=net That is working. Now "ldapwhoami" is showing krbPrincipalName=my-principal@REALM,cn=realm,cn=kerbers,dc=example,dc=net then I changed olcAuthzRegexp to uid=(.+),cn=gssapi,cn=auth ldap:///cn=kerberos,dc=example,dc=net??sub?(krbPrincipalName=$1@REALM) I also tried: (krbPrincipalName=$1) (krbPrincipalName=$1@REALM,cn=REALM,cn=kerberos,dc=example,dc=net) but non of the filters is working. How do I have to configure the filter to rewrite the krbPrincipalName with in the search? Stefan

2 2

Usage of slapo-constraint to ensure existence of object
by Adrian Nöthlich 14 Apr '25

14 Apr '25

Hello all, we want to ensure that all entries added to the member and manager attributes are valid DNs and point to existing objects in our LDAP. We had the refint overlay do this on version 2.2 but as it seems 2.3 removed this undocumented feature. We lately moved to 2.5 and have issues with faulty entries. When I tried to configure the overlay with: olcConstraintAttribute: member uri ldap:///dc=example,dc=com?dn?sub?(objectClass=*) or olcConstraintAttribute: member uri ldap:///dc=example,dc=com??sub?(objectClass=*) or both URIs with an actual objectClass specified, my slapd (2.5.19) crashes on the URI verification step as it seems. Is my usage of the overlay itself correct (including the URI) or is there a better way to ensure the existence of an referenced object? Thanks a lot! Best, Adrian

2 2

Q: "olcDatabase: {1}mdb" from slapcat: why "{1}"?
by Windl, Ulrich 03 Apr '25

03 Apr '25

I have an amost philosophical question about LDIF and OenLDAP: Considering dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb # ... I wonder why olcDatabase needs the "{1}" when olcDatabase is a single-valued attribute. I understand that "olcDatabase={1}mdb" is needed for ordering the databases within cn=config, But why is the "{1}" repeated for the actual attribute? When I tried to remove it, I saw that after a slapcat it's there again. Kind regards, Ulrich

2 6

Re: [EXT] Re: Re: Re: accesslog with delta syncrepl: Why wouldn't contebnt be synced?
by Ondřej Kuzník 31 Mar '25

31 Mar '25

On Mon, Mar 31, 2025 at 06:31:30AM +0000, Windl, Ulrich wrote: > Ondřej, > > I must admit that I loaded the same LDIF using -w on both servers > (whenever the automatic sync would not work, or the server would not > start). However the LDIFs should have contained some entryCSN for each > entry, and if I had edited an entry, incremented the entryCSN "a bit". > In my understanding the contextCSN would be adjusted to be the latest > entryCSN, right? Hi Ulrich, `-w` will replace all CSNs from the LDIF with freshly generated ones, that's why I say you should only do that on a manual reload on *one* replica and then use their DB to reload everyone else with. You are rewriting the whole DB from scratch after all. > Still I'm surprised that some "Odd" CSN would cause a huge memory > allocation that causes the server to crash. Until it happens again, > I'll ignore it for now (as I have much more work to do) I'm not saying for sure it's causing it, very likely a bug but then not much we can do looking at that stack trace. Unless you provide concrete steps to reproduce the issue (preferable), usually logs + a full backtrace with debugging info available is the minimum we'd need to start investigating a crash... What I was saying is that what you did was very likely to cause a painful desync later, especially with cn=config and if you're likely to do this sort of thing again and again. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Syncrepl using certificate to authenticate, but certifivcated expired
by Windl, Ulrich 31 Mar '25

31 Mar '25

Hi! In my test environment (using openLDAP 2.5) the certificate used to authenticate syncrepl expired Friday night, so when returning on Monday, I was expe4cting error from syncrepl, but I did not see any. I suspect that this is due to persistent connections are being used. I see a big danger there: The operator may not notice that the certificated had expired as syncrepl still works (it seems, but there were no actual changes over the weekend)). However (as I understand it), syncrepl will start to fail once the network causes the persistent connection to fail, or a server is restarted. So I wonder: Is there a way to recognize expiration of the certificate? Maybe by limiting the life-time of a persistent connection, or slapd/syncrepl doing explicit checks on the certificate? Kind regards, Ulrich Windl

2 1

Can give me some books about openldap?
by anlex N 30 Mar '25

30 Mar '25

I have searched amazon.com and google.com. There are only a few books about openldap. I also review openldap official docs step by step. but I can not master openldap. if you have no books. What websites do you recommend to learn openldap?

4 8

LDIF for moddn: "ldap_rename: Server is unwilling to perform (53)"
by Windl, Ulrich 28 Mar '25

28 Mar '25

Hi! Reading https://kb.symas.com/en_US/configuration/configure-delta-syncrepl I realized that my syncprov is on the original database, not on the accesslog. So I tried to fix it my "moving" the overlay like this: dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config changetype: moddn newrdn: olcOverlay={0}syncprov deleteoldrdn: 1 newsuperior: olcDatabase={3}mdb,cn=config However as I got "ldap_rename: Server is unwilling to perform (53)" I wonder: Is my LDIF wrong, or is it an implementation restriction? Do I have to restart the server with a fresh config? Kind regards, Ulrich Windl

6 10

accesslog with delta syncrepl: Why wouldn't contebnt be synced?
by Windl, Ulrich 27 Mar '25

27 Mar '25

Hi! I had just asked https://serverfault.com/q/1177576/407952, but I'll summarize here: I think I configured delta-syncrepl for a MMR correctly using OpenLDAP >= 2.5.18 (cn=config also synced). However when I offlined one node and updated the main DIT via slapadd, the other node wouldn't update its DIT when the offlined node is online again. I wonder whether I have to empty or delete the corresponding accesslog, or is there some other step to perform? Is delta syncrepl looking at the accesslog only to detect changes? The syncrepl configs look like this for the DIT: olcSyncrepl: {0}rid=115 provider="ldap://server5/\ " searchbase="dc=..." type=refreshAndPersist \ retry="60 5 300 5 1800 +" logbase="cn=changelog-1" logfilter="(&(objectClass=au\ ditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog starttls=cr\ itical tls_reqcert=demand bindmethod=sasl saslmech=external tls_cert="/etc/ssl/\ servercerts/syncrepl.pem" tls_key="/etc/ssl/serverkeys/syncrepl.key" tls_cacert\ ="/etc/ssl/servercerts/ CA-bundle.pem" olcSyncrepl: {1}rid=116 provider="ldap://server6/\ " searchbase="dc=..." type=refreshAndPersist \ retry="60 5 300 5 1800 +" logbase="cn=changelog-1" logfilter="(&(objectClass=au\ ditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog starttls=cr\ itical tls_reqcert=demand bindmethod=sasl saslmech=external tls_cert="/etc/ssl/\ servercerts/syncrepl.pem" tls_key="/etc/ssl/serverkeys/syncrepl.key" tls_cacert\ ="/etc/ssl/servercerts/ CA-bundle.pem" Kind regards, Ulrich Windl

2 5

Upgrade from 2.4.45 to 2.4.49 and beyond
by justin＠1707.io 27 Mar '25

27 Mar '25

Hey Everyone, I've inherited some rather unmaintained servers as part of a new job and I'm looking to get them all up to date. We have a server for auth for satellite services that uses slapd/openLDAP. It's on a rather old version, and I'm wanting to upgrade it. I would like to see if anyone has advice on how to upgrade from Ubuntu 18.04.6 with the current 2.4.45 slapd/OpenLDAP to Ubuntu 24.04. I've looked around to try and find guides that show upgrades notes between versions but haven't found anything relevant. All advice appreciated! Regards, Justin

3 2

Notes on https://kb.symas.com/en_US/configuration/configure-delta-syncrepl
by Windl, Ulrich 24 Mar '25

24 Mar '25

Hi! Reading https://kb.symas.com/en_US/configuration/configure-delta-syncrepl I found some issues: 1. In "Chaining Overlay" there is a an extra "i" in "dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config i" 2. The syncrepl for "Multi-Master Replication (MMR)" still uses "mirrormode" 3. "Syncrepl" for MMR and cn=config is formatted badly (compared to slapd.conf version) Also for MMR there is a syncprov defined for the database to sync and the accesslog for that database. Why is syncprov for accesslog needed? Kind regards, Ulrich Windl

2 2

Overlay for alternate authentication
by BuzzSaw Code 20 Mar '25

20 Mar '25

We have an existing set of RHEL8 servers running the 2.4.x version of OpenLDAP - we can't upgrade to the latest version due to other dependencies. I'm trying to solve a problem where we want to use our 2FA authentication (which is OTP based on RADIUS) with some devices and applications that don't support RADIUS at all, but they *do* support LDAP authentication. I've read about using the SASL, but since that requires replacing the userPassword attribute for each user it won't work as I have to do this without breaking straight username/password binds for users. I looked into using overlays to create a new OU of users that was a translucent overlay of the existing ou=People (something like ou=rPeople), but searching this list archive and others says that won't work as I can't overlay/rewrite the userPassword attribute ? Is that correct? I'm trying to avoid duplicating the entire directory to new servers or even duplicating the existing ou=People structure just to create a new 'userPassword' attribute that can be used for SASL.

5 4

Feature Requests; where to go? (diff-friendly slapcat/ldapsearch)
by Windl, Ulrich 20 Mar '25

20 Mar '25

Hi! I had an idea for a new feature of slapcat (maybe ldapsearch, too), but I don't know where to file such. So I'm presenting the idea here: "Diff-friendly output format" The order of LDAP attributes is not determined, so after a change to an entry the order of attributes may vary. If you diff the older with the current output, there are more differences than actually there were changes. For example consider this diff (partial output): +entryCSN: 20250319115404.360112Z#000000#005#000000 +modifiersName: cn=config +modifyTimestamp: 20250319115404Z contextCSN: 20130722065709.189194Z#000000#000#000000 contextCSN: 20241204070658.632888Z#000000#001#000000 contextCSN: 20200721123717.002866Z#000000#002#000000 contextCSN: 20181031083258.073732Z#000000#003#000000 -contextCSN: 20250319114038.822575Z#000000#005#000000 +contextCSN: 20250319140809.186543Z#000000#005#000000 contextCSN: 20250227092006.790591Z#000000#006#000000 -entryCSN: 20250319115404.360112Z#000000#005#000000 -modifiersName: cn=config -modifyTimestamp: 20250319115404Z The modifiersName did not change, but its position had moved in output. In a diff-friendly format the position would not change. Obviously that could be done by sorting the output by attribute names (which would also help to locate a specific attribute), but it would have performance impacts, obviously. Another related option is attributes with a list of sub-attributes (name-value pairs), like syncrepl: In standard format the lines are wrapped, and with "-o ldif-wrap=no" you get one long line. For diff-friendliness may idea was to optionally wrap such name-value pairs after each pair, and if a single one exceeds the standard lengh, it would be wrapped still. So the idea could be like this: Use option -D for diff-friendly output format (sorting of attributes), and when doubled, also enable wrapping of name-value pairs. With "-o ldif-wrap=no" given also, single name-value pairs would end up on a separate line, but such lines wouldn't be wrapped themselves. Alternatively one could use "-odiff-friendly=X" where X is 1 or 2. (In case of contextCSN one could even think of X=3 activating sort of the same attribute by attribute value) Do you think it's a useful enhancement? I must admit I played with the idea implementing it myself, but after having had a look at the source of slapcat, it looked more low-level than I had expected, so I had no idea where to start... Kind regards, Ulrich Windl

3 2

Q: DN of a user certificate
by Windl, Ulrich 19 Mar '25

19 Mar '25

Hi! I'm playing with mapping the DN of user certificates to (the DN of) LDAP users. Maybe I'm missing something, but it seems openLDAP appends the certificate DN to the LDAP context for authentication. That way the names can get really long, just as the olcAuthzRegexp will. So can anybody give a real-life example which DN to use for the user certificates? I mean certificate DN, LDAP user context and olcAuthzRegexp. Kind regards, Ulrich Windl

2 1

Q: Using SASL EXTERNAL with certificates for syncrepl
by Windl, Ulrich 19 Mar '25

19 Mar '25

Hi! I'm trying to convert out rencreplc configurtation using plain authentication over TLS to external authentication using a user certificate. It almost works, but slapd is reporting "connection_read(11): TLS accept failure error=-1 id=1002, closing" and "conn=1002 fd=11 closed (TLS negotiation failure)" while I can connect using the certificate and peer with openssl s_client Openssl reports: ... Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1 Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 20974 bytes and written 5070 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2400 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ... Somehow I suspect that the certificate being a user certificate (DN mapped to a user entry) is not acceptable in syncrepl's tls_cert; can anybody confirm? The problem is that I'd like to trust a user certificate more than a host certificate for replication. And if I'd use a host certificate, how could I authenticate the user being used to get the changes? I looked a lot around using popular search engines, but could not find a useful example that is complete enough. Let me remark at this point that the description of tls_reqsan is quite poor in {SLAPD-CONFIG(5); it was not obvious to me that i9s is about "Subject Alternate Name". The other thing I noticed was a capitalized "Binding" in "...to establish a TLS session before Binding to the provider." (also in SLAPD-CONFIG(5)) Kind regards, Ulrich Windl

2 2

accesslog seemingly needs a lot of space
by Windl, Ulrich 19 Mar '25

19 Mar '25

Hi! Trying to convert my syncrepl configuration to a delta syncrepl configuration, the slave runs out of accesslog space during initial sync. For the main database about 30MB should be enough, but I configured 50MB, also for the accesslog files. It seems sync continues even if accesslog periodically complains like this: slapd[13951]: => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792) slapd[13951]: conn=-1 op=0 accesslog_response: got result 0x50 adding log entry reqStart=20250314110032.000187Z,cn=changelog-1 From stat I guess that accesslog needs at least three times as much space as the main database does: # stat /var/lib/ldap/data.mdb /var/lib/ldap/changelog-1/data.mdb File: /var/lib/ldap/data.mdb Size: 22888448 Blocks: 44704 IO Block: 4096 regular file Device: 33h/51d Inode: 259467 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 11:57:46.303713632 +0100 Modify: 2025-03-14 12:01:08.417328586 +0100 Change: 2025-03-14 12:01:08.417328586 +0100 Birth: 2025-03-14 11:57:46.303713632 +0100 File: /var/lib/ldap/changelog-1/data.mdb Size: 52424704 Blocks: 102392 IO Block: 4096 regular file Device: 33h/51d Inode: 259471 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 11:57:46.323713395 +0100 Modify: 2025-03-14 12:01:08.425328492 +0100 Change: 2025-03-14 12:01:08.425328492 +0100 Birth: 2025-03-14 11:57:46.323713395 +0100 Shouldn't (assuming the sync happens entry-by-entry) the accesslog have about the same size as the main database after initial sync (when all databases were empty)? When setting the size of the accesslog database to twice the size of the database it succeeded which stats like this: # stat /var/lib/ldap/data.mdb /var/lib/ldap/changelog-1/data.mdb File: /var/lib/ldap/data.mdb Size: 22888448 Blocks: 44704 IO Block: 4096 regular file Device: 33h/51d Inode: 259514 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 12:39:01.278545521 +0100 Modify: 2025-03-14 12:45:03.558274733 +0100 Change: 2025-03-14 12:45:03.558274733 +0100 Birth: 2025-03-14 12:39:01.278545521 +0100 File: /var/lib/ldap/changelog-1/data.mdb Size: 89657344 Blocks: 175112 IO Block: 4096 regular file Device: 33h/51d Inode: 259518 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 12:39:01.298545286 +0100 Modify: 2025-03-14 12:45:03.566274639 +0100 Change: 2025-03-14 12:45:03.566274639 +0100 Birth: 2025-03-14 12:39:01.298545286 +0100 So the blocks in the accesslog are roughly four times (3.91 ) as much as in the original database. Is there any doc making statements about the proportion? (I'm a fan of "small is beautiful" instead of "bigger is better") Kind regards, Ulrich Windl

3 8

invalid olcAuthzRegexp crashed openLDAP server in SLES15 SP6
by Windl, Ulrich 17 Mar '25

17 Mar '25

Hi! At work I have to connect to our SLES servers via Windows RDP and a Windows server. Unfortunately RDP is not working reliably, and it sometimes misses key presses, and at other times it duplicates them. That way I ended up adding an olcAuthzRegexp that lacked a backspace. Unfrtunately when trying to ldapmodify the server I just got: modifying entry "cn=config" ldap_result: Can't contact LDAP server (-1) the regex in question is: olcAuthzRegexp: {3} "^dn:dnQualifier=uid\3D(^,)\\2Cou\\3Dpeople\\2Cdc\\3DXXX \\2Cdc\\3Dde$" "dn: uid=$1,ou=people,dc=XXX=de" As it turned out the server dumped core (100% reproducible). I know the regex is bad, but maybe it shouldn’t kill the server. The server is SUSE’s version that corresponds to some 2.5.x with patches. Anyway the backtrace is: Mar 17 14:36:23 v05 slapd[15911]: conn=1000 op=1 syncprov_matchops: recording uuid for dn=cn=config on opc=0x7fcfe0000d58 Mar 17 14:36:23 v05 slapd[15911]: slap_get_csn: conn=1000 op=1 generated new csn=20250317133623.651964Z#000000#005#000000 manage=1 Mar 17 14:36:23 v05 slapd[15911]: slap_queue_csn: queueing 0x7fcfe0106c70 20250317133623.651964Z#000000#005#000000 Mar 17 14:36:23 v05 kernel: slapd[15919]: segfault at 7fc81ceea633 ip 00007fcff658553e sp 00007fcfe9ff4e40 error 4 in libldap-2.5.releng.so.0.1.13[7fcff653b000+5c000] likely on CPU 1 (core 0, socket 2) Mar 17 14:36:23 v05 kernel: Code: 7f 08 4d 85 ff 75 9e 48 83 c4 18 b8 fa ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 90 48 85 ff 74 3b 41 54 55 31 ed 53 48 89 fb <48> 8b 7f 08 49 89 f4 48 85 ff 75 3e 48 8b 7b 10 48 85 ff 75 25 4d … Mar 17 14:36:23 v05 systemd[1]: Started Process Core Dump (PID 15922/UID 0). Mar 17 14:36:23 v05 systemd-coredump[15923]: [🡕] Process 15911 (slapd) of user 1000 dumped core. Stack trace of thread 15919: #0 0x00007fcff658553e ldap_avl_free (libldap-2.5.releng.so.0 + 0x4a53e) #1 0x0000555fb6ca9b42 rewrite_info_delete (slapd + 0xd6b42) #2 0x0000555fb6c64bae slap_sasl_regexp_config (slapd + 0x91bae) #3 0x0000555fb6c03a09 n/a (slapd + 0x30a09) #4 0x0000555fb6c091d3 config_set_vals (slapd + 0x361d3) #5 0x0000555fb6c0a14f config_parse_add (slapd + 0x3714f) #6 0x0000555fb6bfcdcc n/a (slapd + 0x29dcc) #7 0x0000555fb6bfdc96 n/a (slapd + 0x2ac96) #8 0x0000555fb6c8a523 overlay_op_walk (slapd + 0xb7523) #9 0x0000555fb6c8a6ae n/a (slapd + 0xb76ae) #10 0x0000555fb6c2dbd2 fe_op_modify (slapd + 0x5abd2) #11 0x0000555fb6c2f941 do_modify (slapd + 0x5c941) #12 0x0000555fb6c1618f n/a (slapd + 0x4318f) #13 0x0000555fb6c1698d n/a (slapd + 0x4398d) #14 0x00007fcff6583da0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #15 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #16 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15915: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15917: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15911: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a91a3 __pthread_clockjoin_ex (libc.so.6 + 0xa91a3) #2 0x0000555fb6c131ca slapd_daemon (slapd + 0x401ca) #3 0x0000555fb6bf688e main (slapd + 0x2388e) #4 0x00007fcff6240e6c __libc_start_call_main (libc.so.6 + 0x40e6c) #5 0x00007fcff6240f35 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x40f35) #6 0x0000555fb6bf690a _start (slapd + 0x2390a) Stack trace of thread 15913: #0 0x00007fcff632ee86 epoll_wait (libc.so.6 + 0x12ee86) #1 0x0000555fb6c1007b n/a (slapd + 0x3d07b) #2 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #3 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15918: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15914: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) ELF object binary architecture: AMD x86-64 Mar 17 14:36:23 v05 ldapmodify[15921]: DIGEST-MD5 common mech free Mar 17 14:36:23 v05 systemd[1]: slapd.service: Main process exited, code=dumped, status=11/SEGV Mar 17 14:36:23 v05 systemd[1]: slapd.service: Failed with result 'core-dump'. Mar 17 14:36:23 v05 systemd[1]: systemd-coredump(a)3-15922-0.service: Deactivated successfully. Kind regards, Ulrich Windl

2 1

Trying to set 'olcPasswordHash' I get "ldap_modify: Object class violation (65) additional info: attribute 'olcPasswordHash' not allowed"
by Windl, Ulrich 17 Mar '25

17 Mar '25

Hi! After having loaded pw-sha2 in oOpenmLDAp 2.5, I tried to set a new default hashing schema, but I fail to do so using dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcPasswordHash olcPasswordHash: {SSHA256} olcPasswordHash: {SSHA} ---- modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Object class violation (65) additional info: attribute 'olcPasswordHash' not allowed Before I had tried "replace" instead of "add", and I tried to place both values in one line as suggested by slapd-config: olcPasswordHash: <hash> [<hash>...] This option configures one or more hashes to be used in generation of user passwords stored in the userPassword attribute during processing of LDAP Password Modify Extended Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA}, {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}. The manual page also states: This setting is only allowed in the frontend entry. I'm running out of ideas. Kind regards, Ulrich Windl

3 11

Understanding sync log for delta syncrepl
by Windl, Ulrich 17 Mar '25

17 Mar '25

Hi! Most likely I misconfigured the accesslog databases used for delta syncrepl (I'm still working on it), but I have some trouble understanding the logs created. I have two identical servers (SIDs 5 and 6) that also have an identical cn=config that is to be synced as well) I created two accesslog databases, one for cn=config, and one for the main database. For SDID=5 I see messages like: Mar 14 15:17:39 v05 slapd[26377]: do_syncrep1: rid=006 starting refresh (sending cookie=rid=006,sid=005,csn=20250314000000.000000Z#000000#000#000000;20250314000000.000000Z#000000#001#000000;20200721123717.002866Z#000000#002#000000;20181031083258.073732Z#000000#003#000000;20250314000002.000000Z#000000#005#000000;20250227092006.790591Z#000000#006#000000) Mar 14 15:17:39 v05 slapd[26377]: do_syncrep2: rid=006 LDAP_RES_SEARCH_RESULT Mar 14 15:17:39 v05 slapd[26377]: do_syncrepl: rid=006 rc -101 retrying Mar 14 15:17:39 v05 slapd[26377]: do_syncrep1: rid=006 starting refresh (sending cookie=rid=006,sid=005,csn=20130719093756.074776Z#000000#000#000000;20250217105250.345944Z#000000#001#000000;20250218171739.629994Z#000000#002#000000;20250217065706.238392Z#000000#003#000000;20250227092327.859231Z#000000#005#000000;20250227092348.803001Z#000000#006#000000) Mar 14 15:17:39 v05 slapd[26377]: do_syncrep2: rid=006 got search entry without Sync State control (reqStart=20250314114001.000003Z,cn=changelog-1) Mar 14 15:17:39 v05 slapd[26377]: do_syncrepl: rid=006 rc -1 retrying For the same time interval I see for SID=6: Mar 14 15:17:26 v06 slapd[14537]: do_syncrep1: rid=005 starting refresh (sending cookie=rid=005,sid=006,csn=20130719093756.074776Z#000000#000#000000;20250217105250.345944Z#000000#001#000000;20250218171739.629994Z#000000#002#000000;20250217065706.238392Z#000000#003#000000;20250227092327.859231Z#000000#005#000000;20250227092348.803001Z#000000#006#000000) Mar 14 15:17:26 v06 slapd[14537]: do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT Mar 14 15:17:26 v06 slapd[14537]: do_syncrepl: rid=005 rc -101 retrying Mar 14 15:17:26 v06 slapd[14537]: do_syncrep1: rid=005 starting refresh (sending cookie=rid=005,sid=006,csn=20250314000000.000000Z#000000#000#000000;20250314000000.000000Z#000000#001#000000;20200721123717.002866Z#000000#002#000000;20181031083258.073732Z#000000#003#000000;20250314000002.000000Z#000000#005#000000;20250227092006.790591Z#000000#006#000000) Mar 14 15:17:26 v06 slapd[14537]: do_syncrep2: rid=005 got search entry without Sync State control (reqStart=20250314123529.000001Z,cn=changelog-0) Mar 14 15:17:26 v06 slapd[14537]: do_syncrepl: rid=005 rc -1 retrying (no corelated messages on Node 1) Mar 14 15:17:39 v06 slapd[14537]: send_search_entry: conn 1021 ber write failed. Specifically I wonder what the "rc -101 retrying" is really about: the servers should be able to connect to each other. Also what "got search entry without Sync State control" means. Finally I also have a "rc -1 retrying" and the "ber write failed". I really don't know where to start debugging. The first syncprov is. dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 10 My first accesslog looks like: dn: olcOverlay={1}accesslog,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=changelog-0 olcAccessLogOps: writes olcAccessLogPurge: 60+00:00 1+00:00 olcAccessLogSuccess: FALSE olcAccessLogOld: (objectClass=*) The second syncprov is: dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 The second accesslog is: dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=changelog-1 olcAccessLogOps: writes olcAccessLogPurge: 60+00:00 1+00:00 olcAccessLogSuccess: FALSE olcAccessLogOld: (objectClass=*) And the databases are: dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbDirectory: /var/lib/ldap/changelog-0 olcSuffix: cn=changelog-0 olcAccess: {0}to * by dn.exact="uid=syncrepl,..." read by * break olcLimits: {0}dn.exact="uid=syncrepl,..." size.soft=unlimited olcRootDN: cn=admin,cn=changelog-0 olcRootPW: log-0 dn: olcDatabase={4}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbDirectory: /var/lib/ldap/changelog-1 olcSuffix: cn=changelog-1 olcAccess: {0}to * by dn.exact="uid=syncrepl,..." read by * break olcLimits: {0}dn.exact="uid=syncrepl,..." size.soft=unlimited olcRootDN: cn=admin,cn=changelog-1 olcRootPW: log-1 The syncrepl definitions are like this: olcSyncrepl: {0}rid=5 provider="ldap://v05 /" searchbase="cn=config" type="refreshAndPersist" \ retry="60 5 300 5 1800 +" logbase=cn=changelog-0 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" \ schemachecking=on syncdata=accesslog starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest" olcSyncrepl: {1}rid=6 provider="ldap://v06 /" searchbase="cn=config" type="refreshAndPersist" \ retry="60 5 300 5 1800 +" logbase=cn=changelog-0 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" \ schemachecking=on syncdata=accesslog starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest" olcSyncrepl: {0}rid=5 provider="ldap:// v05 /" searchbase="dc=..." type="refreshAndPersist" \ retry="60 5 300 5 1800 +" logbase=cn=changelog-1 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog \ starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest" olcSyncrepl: {1}rid=6 provider="ldap://v06 /" searchbase="dc=... " type="refreshAndPersist" \ retry="60 5 300 5 1800 +" logbase=cn=changelog-1 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog \ starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest" Kind regards, Ulrich Windl

1 0

Re: consumer replication not recovering
by Ondřej Kuzník 14 Mar '25

14 Mar '25

On Wed, Mar 12, 2025 at 03:10:12PM -0400, Suresh Veliveli wrote: > Here it is. Hi Suresh, I apologise for not really getting back to you for a while, rest assured I'm still thinking about it. However I'm still confused what might be happening and don't have much in terms of advice yet except that yes, the two (replication effectively stopping and the crash) seem to be two symptoms of the same issue. It looks like you're building OpenLDAP yourself, would you be able to apply a patch or two adding extra information to the sync logs that might help us trace this better? Are you able to compile and run OpenLDAP with -fsanitize=address in CFLAGS or an equivalent? > [root@...] # gdb ... > Reading symbols from /var/services/openldap/libexec/slapd... > BFD: warning: > /var/users/suresh.a/core.slapd.3003.bea19f5a376843abb488dce68d6e81af.5036.1741456520000000 > has a segment extending past end of file > [...] > warning: Error reading shared library list entry at 0x696e6e75723a5652 > Cannot access memory at address 0x69626f6e6e613a5e > Cannot access memory at address 0x69626f6e6e613a56 > Failed to read a valid object file image from memory. > [...] > Thread 2 (LWP 5036): > #0 0x00007f792d8868ba in ?? () > No symbol table info available. > Backtrace stopped: Cannot access memory at address 0x7ffebb22d9a0 I am a little concerned by the above warnings and the fact gdb is unable to extract any stack information at all from most threads. Doesn't seem to correspond what I'd usually see even when debugging information is missing. > Thread 1 (LWP 7650): > #0 connection_abandon (c=0x7f79158a5ba8) at connection.c:714 > o = 0x7f5fa0148170 > next = 0x7f5f90010300 In this frame, would you be able to print the following and paste/attach them here? - '*c' - '*o' - '*o->o_hdr' 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

Request for Guidance on Upgrading from 2.4.x(BDB with ppolicy) to 2.6.9
by anilkumar.pathuri7＠gmail.com 13 Mar '25

13 Mar '25

Dear LDAP Community, We are planning to upgrade our setup from OpenLDAP 2.4.x to 2.6.9 (latest version) and would appreciate your guidance on the following: Is a direct upgrade from 2.4.x to 2.6.9 possible, or are there intermediate steps required? We are currently using BDB with ppolicy. Does 2.6.9 support BDB, or is migration to MDB mandatory? Is ppolicy still supported in 2.6.9? Are the ppolicy module and schema included in 2.6.9, or do they need to be obtained externally? If a migration from BDB with ppolicy to MDB with ppolicy is required, could you kindly provide step-by-step guidance? We greatly appreciate any insights, documentation, or recommendations you can share. Thank you for your support! Regards, Anil P

3 3

Re: consumer replication net recovering
by Suresh Veliveli 12 Mar '25

12 Mar '25

This is another instance where replication stops. Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20241223060050.594465Z#000000#000#000000 tid 0x7f5aed0fb640 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_search (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 uid=xxxx,ou=People,dc=georgetown,dc=edu Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_modify uid=xxxxx,ou=People,dc=georgetown,dc=edu (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_message_to_entry: rid=143 DN: uid=xxxxx,ou=People,dc=georgetown,dc=edu, UUID: db41232e-527d-103f-995c-4344349468b5 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20241223060104.603554Z#000000#000#000000 tid 0x7f5aed0fb640 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_search (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 uid=yyyyy,ou=People,dc=georgetown,dc=edu Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_modify uid=yyyy,ou=People,dc=georgetown,dc=edu (0) No "syncrep_" messages were logged after the above. Regards, Suresh On Mon, Dec 23, 2024 at 2:42 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 5:46 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > I do have these but no syncrepl_sync. > > > > > > Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: syncrepl_message_to_entry: > > rid=129 DN: uid=xxxx,ou=xxxx,dc=georgetown,dc=edu, UUID: > > 37387976-3ae0-103f-94fc-3b4be3361dc7 > > Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: syncrepl_entry: rid=129 > > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) > > csn=20241212135921.652395Z#000000#000#000000 tid 0x7f671b7fe640 > > Yes sorry, that was a typo on my end. > > "syncrepl_" sync messages. Specifically you want to see the ones that > have > "be_" in them, but not "be_search". I.e., be_add, be_modify, etc. They > show the result of the operation, something like: > > syncrepl_entry: rid=100 be_modify <DN> (<result code>) > > --Quanah > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

5 30

LMDB: issues when resizing via set_mapsize
by Stefan de Konink 12 Mar '25

12 Mar '25

Hi, Some background; a Windows user of my open source ETL software complained about the huge files. Under Linux I don't have any issues, but I wanted to resolve this issue by implementing automatic growth via a pattern: MapFullError, set_mapsize, apply writing batch again. This week I entered a bug[1] which was stated as not a bug in LMDB. Today I ended up in build/lib/mdb.c:5966: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() which also seem I am not the only one hitting, and several fixes have been introduced. The issue does not occur every time when the resize takes place, but can be consistently reproduced given the same input. The error will then occur at the same place. When my initial size is big enough, not to resize there is no issue. In short I am using py-lmdb to access a read only env, and in a second thread a write function is launched which reads out a queue. Upon the MapFullError I am linearly increasing the mapsize, and continue with the failed batch. I have four dupSort tables, the rest is ordinary. I was pointed in the bug at the documentation. One sentence struck me: "It may be called at later times if no transactions are active in this process." My assumption was that if I would have two independent env's I could do whatever I wanted in the first, and the second could do its resize. Does the documentation suggest that the full application must finish all its transactions independent of env? [1] https://bugs.openldap.org/show_bug.cgi?id=10316 -- Stefan

2 1

meta backend : forward the credentials to the server ?
by carnival＠protonmail.com 07 Mar '25

07 Mar '25

Hello, I'm trying to configure a proxy with slapd-meta. I have my data on a OpenLDAP server ldap-1.example.org and my meta backend setup on ldap-proxy.example.org. Here is the main part of my conf : # {2}meta, config dn: olcDatabase={2}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=test,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=bind,dc=test,dc=com olcRootPW: password olcDbRebindAsUser: FALSE # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbURI: "ldap://ldap-1.example.org:389/ou=dpt,dc=test,dc=com" olcDbIDAssertBind: mode=none flags=non-prescriptive,proxy-authz-non-critical b indmethod=simple timeout=0 network-timeout=0 binddn="cn=manager" cr edentials="password" keepalive=0:0:0 olcDbRewrite: {0}suffixmassage "ou=dpt,dc=test,dc=com" "ou=dpt,dc=test,dc= com" olcDbRebindAsUser: FALSE It's work fine, when I do a ldapsearch on ldap-proxy.example.org I retrieve my data stored on ldap-1.example.org. But in order to do that, I'm forced to use unique and administrative accounts : cn=bind,dc=test,dc=com for my proxy and cn=manager for my main LDAP server. For security reasons, I would like to avoid using an admin account for binding and instead use any user credentials I choose to connect to the target servers for searches beyond the first target (my proxy). For example, if I have an account named ou=account,dc=test,dc=com on my LDAP server, I would like to bind my proxy directly with this account and dynamically propagate the credentials for verification on my LDAP server, returning the results if the credentials are correct. I thought that "rebind-as-user YES" would resolve this, but it doesn't work. Is there something I'm missing? Thanks ! Arthur

1 0

Getting details for "TLS trace: SSL3 alert read:fatal:unsupported certificate"
by Windl, Ulrich 06 Mar '25

06 Mar '25

Hi! After "playing" significant time with certificate authentication, I managed to authenticate one user. However when I tried to authenticate a different user with a similar certificate, I see a TLS trace: SSL3 alert read:fatal:unsupported certificate Error. Can I can some details about the "usupportedness" of my certificate? The only thing I could think if is that uid of the newer certificate has a CN that is three characters longer than the one that worked. A more complete trace for ldapwhoami woul look like this: ... ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS trace: SSL_connect:SSLv3/TLS read server certificate request TLS certificate verification: depth: 2, err: 0, subject: /.... Root-CA (2018), issuer: /... Root-CA (2018) TLS certificate verification: depth: 1, err: 0, subject: /... Host-CA (2018), issuer: /... Root-CA (2018) TLS certificate verification: depth: 0, err: 0, subject: /... FQHN, issuer: /... Host-CA (2018) TLS trace: SSL_connect:SSLv3/TLS read server certificate TLS trace: SSL_connect:TLSv1.3 read server certificate verify TLS trace: SSL_connect:SSLv3/TLS read finished TLS trace: SSL_connect:SSLv3/TLS write change cipher spec TLS trace: SSL_connect:SSLv3/TLS write client certificate TLS trace: SSL_connect:SSLv3/TLS write certificate verify TLS trace: SSL_connect:SSLv3/TLS write finished ldap_sasl_interactive_bind: user selected: EXTERNAL ldap_int_sasl_bind: EXTERNAL ldap_int_sasl_open: host=FQHN SASL/EXTERNAL authentication started ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 26 bytes to sd 3 ldap_msgfree ldap_result ld 0x56432476ac30 msgid 2 wait4msg ld 0x56432476ac30 msgid 2 (infinite timeout) wait4msg continue ld 0x56432476ac30 msgid 2 all 1 ** ld 0x56432476ac30 Connections: * host: FQHN port: 389 (default) * from: IP=172.20.16.36:57868 refcnt: 2 status: Connected last used: Wed Mar 5 15:42:03 2025 ** ld 0x56432476ac30 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x56432476ac30 request count 1 (abandoned 0) ** ld 0x56432476ac30 Response Queue: Empty ld 0x56432476ac30 response count 0 ldap_chkResponseList ld 0x56432476ac30 msgid 2 all 1 ldap_chkResponseList returns ld 0x56432476ac30 NULL ldap_int_select read1msg: ld 0x56432476ac30 msgid 2 all 1 ber_get_next TLS trace: SSL3 alert read:fatal:unsupported certificate ber_get_next failed, errno=0. ldap_err2string ldap_sasl_interactive_bind: Can't contact LDAP server (-1) ... Kind regards, Ulrich Windl

3 5

Q: Uniqueness of syncrepl rid
by Windl, Ulrich 04 Mar '25

04 Mar '25

Hi! I have a question on the uniqueness of rid in syncrepl: Do they have to be globally unique, or just unique within a database (olcDatabase config)? Kind regards, Ulrich Windl

4 5

OlcLimits : sizelimit exceeded (openldap 2.5.16)
by bourguijl＠gmail.com 03 Mar '25

03 Mar '25

Dears, I've an issue with one user for which I set its limits to "unlimited" but which get err=4 (sizelimit exceeded). This is in the context of a META ldap fronted to a ldap backend. If I do the ldapsearch of this user in CLI directly on the ldap backend where the OlcLimits are set for it, this works perfectly, no err=4 errors but if this ldapsearch comes from the META ldap frontend with the same user which is used in the olcDbIDAssertBind as Binddn, it's failling with err=4 !!?? I did check ldap logs at back end and they are identical in both cases except the err=4. I don't see what can be the cause ?? Any help will be appreciate !! Thx in advance, Jean-Luc.

2 1

How to start debugging olcAuthzRegexp?
by Windl, Ulrich 03 Mar '25

03 Mar '25

Hi! I tried to remove the credentials from my syncrepl configuration using certificate authentication instead. To do so I added a user certificate for my own user and tried ldapwhoami to verify that it works. Unfortunately it does not. I read quite a lot on the subject, and either all the descriptions are all poorly written and incomplete, or it must be very simple to get it running. However I failed so far. My suspect is that my olcAuthzRegexp does not properly map the certificate's name to the user, or the mapping is not called at all. Can anybody provide a sample configuration for the client user to verify the configuration, and maybe give an example on the server side to get it working. What I have tried so far is having a ~/ldaprc with: TLS_REQCERT demand TLS_CACERT ./User-CA.crt TLS_CERT ./uid=user.crt TLS_KEY ./uid=user.pem LDAPSASL_MECH external And I tried the command "ldapwhoami -H ldap://FQHN -D uid=user,cn=gssapi,cn=auth -Z -v" I tried these olcAuthzRegexp: olcAuthzRegexp: {1} "C=DE,...,O=...,uid=([^,]+)" uid=$1,ou=people,dc=...,dc==de olcAuthzRegexp: {2} "^uid=([^,]+),cn=gssapi,cn=auth$" uid=$1,ou=people,dc=...,dc=de (I left out the details of the certificate and directory contexts) Kind regards, Ulrich Windl

4 3

manual page slapd-mdb.5 and "maxsize"
by Windl, Ulrich 03 Mar '25

03 Mar '25

Migrating to OpenLDAP 2.5 and MDB I hit the default 10MB limit (when trying to import a 6.8MB LDIF). Seeking how to extend the size online, I found: maxsize <bytes><https://manpages.debian.org/testing/slapd/slapd-mdb.5.en.html#maxsize> Specify the maximum size of the database in bytes. A memory map of this size is allocated at startup time and the database will not be allowed to grow beyond this size. The default is 10485760 bytes. This setting may be changed upward if the configured limit needs to be increased. However it's completely non-obvious that the name for cn=config is "olcDbMaxSize" (and not "olcMaxssize"). (The final MDB file size was about 23MB, including the indices) Kind regards, Ulrich Windl

4 6

[authcid=<identity>] [authzid=<identity>]
by Stefan Kania 03 Mar '25

03 Mar '25

hi to all, I like to split the replication for cn=config and the object-db between to different kerberos-principals so I did the following (so far) 1. create to principals and a keytab for both of them. 2. configured k5start to get two different cchache files (one for each user) 3. Now I want to change my syncrepl from: --------------------------- dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=001 provider=ldaps://provider01.example.net bindmethod=sasl saslmech=gssapi searchbase="cn=config" type=refreshAndPersist retry="5 5 100 +" timeout=1 tls_reqcert=allow olcSyncRepl: rid=002 provider=ldaps://provider02.example.net bindmethod=sasl saslmech=gssapi searchbase="cn=config" type=refreshAndPersist retry="5 5 100 +" timeout=1 tls_reqcert=allow --------------------------- And ----------------------------- dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=101 provider=ldaps://provider01.example.net bindmethod=sasl saslmech=gssapi authzid=uid=krepl-main,cn=gssapi,cn=auth timeout=0 network-timeout=0 filter="(objectclass=*)" searchbase="dc=example,dc=net" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" tls_reqcert=allow olcSyncrepl: rid=102 provider=ldaps://provider02.example.net bindmethod=sasl saslmech=gssapi authzid=uid=krepl-main,cn=gssapi,cn=auth timeout=0 network-timeout=0 filter="(objectclass=*)" searchbase="dc=example,dc=net" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" keepalive=240:10:30 tls_reqcert=allow ----------------------------------- to use a different identity. I found the options [authcid=<identity>] [authzid=<identity>] But nothing how to configure these options. When I get the ticket for the user and do a ldapwhoami I'm getting dn:uid=krepl-config,cn=gssapi,cn=auth and dn:uid=krepl-main,cn=gssapi,cn=auth The DNs are: krbPrincipalName=krepl-krbPrincipalName=krepl-config(a)EXAMPLE.NET,cn=EXAMPLE.NET,cn=kerberos,dc=example,dc=net and krbPrincipalName=krepl-main(a)EXAMPLE.NET,cn=EXAMPLE.NET,cn=kerberos,dc=example,dc=net So which option du I have to take and what is the right value for the option? Stefan

3 5

When init new consumers receiving: missing or invalid at 'pwdPolicySubentry'
by erikdewaard＠gmail.com 03 Mar '25

03 Mar '25

Hi, When bootstrapping consumers through replication (clean conf/data dir) receiving msgs about pwdPolicySubentry missing. Its not always the same: sometimes 4 msgs another time 60 etc. I have this on various consumers 2.5.17/2.6.7 I thought this could be related to some ordering, maybe the accounts were created before ppolicy cn=noexpirepasswordpolicy data was replicated? <167>2025-02-27T12:16:20.993758+01:00 consumer22 slapd[1098021]: slapd starting <167>2025-02-27T12:16:32.035015+01:00 consumer22 slapd[1098021]: ppolicy_get: policy subentry cn=noexpirepasswordpolicy,ou=policies,dc=company,dc=com missing or invalid at 'pwdPolicySubentry', no policy will be applied! <167>2025-02-27T12:16:35.580938+01:00 consumer22 slapd[1098021]: ppolicy_get: policy subentry cn=noexpirepasswordpolicy,ou=policies,dc=company,dc=com missing or invalid at 'pwdPolicySubentry', no policy will be applied! best regards

2 1

OpenLDAP Pass-through Authentication
by Dino Edwards 01 Mar '25

01 Mar '25

Hi, Trying to get pass-through authentication working however, I'm running to the following error in OpenLDAP: openldap | 679ceede.3aa31e0a 0x7f2ff617e6c0 conn=1004 op=1 SRCH attr=uid mail displayName openldap | 679ceede.3aa4b816 0x7f2ff617e6c0 conn=1004 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000019 etime=0.000172 nentries=1 text= openldap | 679ceede.3aaafd88 0x7f2ff597d6c0 conn=1005 fd=14 ACCEPT from IP=172.16.32.1:47082 (IP=0.0.0.0:1389) openldap | 679ceede.3aab8f34 0x7f2ff597d6c0 conn=1005 op=0 BIND dn="cn=username(a)domain.tld,ou=users,dc=domain,dc=local <mailto:cn=username@domain.tld,ou=users,dc=domain,dc=local> " method=128 openldap | 679ceede.3aac9267 0x7f2ff597d6c0 SASL [conn=1005] Failure: cannot connect to saslauthd server: No such file or directory openldap | 679ceede.3aad25b9 0x7f2ff597d6c0 conn=1005 op=0 RESULT tag=97 err=49 qtime=0.000005 etime=0.000120 text= openldap | 679ceede.3ab0191f 0x7f2ff617e6c0 conn=1005 fd=14 closed (connection lost) openldap | 679ceede.3ab3d76a 0x7f2ff597d6c0 conn=1004 fd=13 closed (connection lost) I followed the admin docs at: https://www.openldap.org/doc/admin26/guide.html#Pass-Through%20authenticatio n Here's what I did: Created /usr/lib/sasl2/slapd.conf with the following content: mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/run/sasl2/mux Created /etc/saslauthd.conf with the following content: ldap_servers: ldap://192.168.xxx.xxx.xxx ldap_search_base: OU=Users,DC=domain,DC=tld ldap_filter: (uid=%u) ldap_bind_dn: CN=saslauthd,CN=Users,DC=domain,DC=tld ldap_password: somepassword Added a user that already exists in domain.tld in openldap with the following password: {SASL}username(a)domain.tld <mailto:%7bSASL%7dusername@domain.tld> I would appreciate some help on this. Thanks

5 20

Transparent proxy to existing LDAP but with replacing specific attribute from another source
by Alexey D. Filimonov 28 Feb '25

28 Feb '25

Hi. A have Active Directory domain across 30+ domain controllers. In one single location, I have a server with corporate software that uses AD as normal ordinary LDAP with simple binds and it takes users. I want to add users their high quality photos, but I don't want them across all domain controllers in active directory. Can I build a proxy server with OpenLDAP that will proxy all requests to backend AD servers and return results, but for results it will replace one attribute, jpegPhoto, if it was requested, with some binary contents taken from elsewhere ?

2 1

olcDbMaxSize decrease possible?
by cyril＠stoll.info 27 Feb '25

27 Feb '25

Hi there For some reason I don't remember I set the olcDbMaxSize to 4 GB. Turns out that is way too large for our OpenLDAP servers. Both the admin guide and the slapd-mdb manpage state that "this setting may be changed upward". Unfortunately there is no mentioning of decreasing that size. On our servers the data.mdb and lock.mdb Files together are around 176 MB. I don't really expect a significant growth of our OpenLDAP Servers. So I guess that setting it to 1 GB or even just 500 MB would be more than enough for our needs in the coming years. So my question is, can I also decrease that size? Or should I just let it be at 4 GB even though we will never ever come close to that? Thanks a lot and best regards, Cyril

2 1

Querying a tree covered by multiple databases
by Norman Gray 27 Feb '25

27 Feb '25

Greetings. If I have a server which manages a tree split into two databases, one covering o=top, and one ou=sub,o=top, then a query against base o=top with subtree scope returns only objects within the first database, and not the second. Should I have expected that? (I didn't) [ This is a for-interest question. This isn't really a practical problem for me: I'm encountering it because I have a situation where I'm searching objects in ou=sub,o=top and in o=top, which would be on different servers in the real case, but which are in the same server as part of a test harness. Of course, I doubt it would be a good production design to have a tree split into multiple databases like this. ] That makes sense if the semantics of a search are that it searches a _database_, but it conflicts with the intuition that a search is of a _tree_, where I'd expect a search of o=top to implicitly include ou=sub,o=top as well. My problem is that I can't find where in the manual it tells me I should expect the former rather than the latter. What have I not read? Both ldapsearch(1) and ldap_search(3) discuss the scope in terms of sub_tree_, and don't mention databases (I wouldn't expect them to, since here a 'database' is an implementation detail of the LDAP server). Section 1.1 of TFM says 'A directory is a specialized database specifically designed for searching and browsing', but that's 'database' being used somewhat generically. Perhaps I should be looking at referrals? But the introduction of referrals in TFM suggest that these are a mechanism for referring clients to servers broadly 'elsewhere', and Sect. 5.3 documents olcReferral by saying that 'queries not local to one of the databases defined below will be referred to the LDAP server running on [another server]'. And queries to ou=sub,o=top _is_ 'local to one of the databases'. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

2 2

How do I list existing indexes
by Richard Perini 26 Feb '25

26 Feb '25

I'm sure this question has been asked before, but my googling has failed to find an answer: How can I get a list of attribute indexes for our OpenLDAP instance? We're running version 2.4.57 (FreeBSD). Thanks in advance, -- Richard Perini Ramico Australia Pty Ltd Sydney, Australia rpp(a)ramico.com.au ----------------------------------------------------------------------------- "The difference between theory and practice is that in theory there is no difference, but in practice there is"

3 4

OpenLDAP 3-way multimaster oathHOTPCounter problem
by agrru01＠gmail.com 26 Feb '25

26 Feb '25

Hello! I am using a 3-way multimaster syncrepl setup with the slapo-otp module. My problem is that when authenticating with a user using HOTP, the attribute oathHOTPCounter only updates the value on the target ldap instance. This means the other two ldap instances do not get the updated HOTP-counter value and therefore will allow authentication using the same HOTP code. Interestingly enough, if I manually edit the oathHOTPCounter value it synchronizes with the other masters. Any idea what the problem could be?

2 1

A ldif for authentication
by Mohsen Pahlevanzadeh 24 Feb '25

24 Feb '25

Hello, I'm very happy with OpenLDAP. I have the following scenario: I need to have a back to support 1. Usernames 2. Groups 3. Passwords of usernames 4. password of groups And some CN Note: Not only I don't want to use /etc/passwd and local authentication, but also I need to virtual {user,account}. Would you please help me to generate an ldif to import to openldap? Yours, Mohsen

2 1

Debian Bookworm: Issues with stucking / hanging slapd process 2.5, while add / modify entries (master-master replication)
by linuxmail＠4lin.net 24 Feb '25

24 Feb '25

Hello, we fighting since upgrade from Buster to Bookworm with smaller and bigger issues on our OpenLDAP. We use WebADM as IDM (Rcdevs) and this is using OpenLDAP as backend. Since a long while on Bookworm, we have the issues, that slapd stucks on operations, like on adding entries. For example adding more than 1 CN entry to an existing OU. The only way to get all working is again, to stop slapd, but systemctl stop slapd doesn't work, you have to use kill -9 .. and that, pretty often. So, I hoped, to get it working again, I cloned the VMs; cutted the (normal) network and used a localhost bridge, so that both can see each others, without issues. Then I've created a backup (slapcat); deleted the db and slapd.d/cn=config ... and restored on both the DB. This part worked without issues .. but: ``` cat /home/foo/sudo_single.ldif dn: cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local objectclass: sudorole objectclass: top cn: jochoa_fra_dev_bookworm_02 sudorunasuser: ALL sudooption: !authenticate sudocommand: /bin/su sudohost: fra-dev-bookworm-02.example.local sudouser: jochoa(a)example.local ldapadd -ZZ -c -x -D 'cn=webadmin,ou=Accounts,dc=example,dc=local' -W -H ldap://fra-corp-auth-01.example.com:389 -f /home/foo/sudo_single.ldif -vv ldap_initialize( ldap://fra-corp-auth-01.example.com:389/??base ) Enter LDAP Password: add objectclass: sudorole top add cn: jochoa_fra_dev_bookworm_02 add sudorunasuser: ALL add sudooption: !authenticate add sudocommand: /bin/su add sudohost: fra-dev-bookworm-02.example.local add sudouser: jochoa(a)example.local adding new entry "cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local" ``` and then .. it just stucks, till I break with CTRL +C The same happens via ApacheDirectory or using WebADM Gui ... sometimes it works .. but often not. ```` eb 20 11:20:22 fra-corp-auth-01 slapd[710]: daemon: activity on 1 descriptor Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: daemon: activity on: Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: 22r Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: daemon: read active on 22 Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: daemon: epoll: listen=8 active_threads=0 tvp=zero Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: daemon: epoll: listen=9 active_threads=0 tvp=zero Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: daemon: epoll: listen=10 active_threads=0 tvp=zero Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: connection_get(22) Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: connection_get(22): got connid=1041 Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: connection_read(22): checking for input on id=1041 Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: op tag 0x68, time 1740046822 Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: conn=1041 op=1 do_add Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: conn=1041 op=1 do_add: dn (cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local) Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: >>> dnPrettyNormal: <cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local> Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: <<< dnPrettyNormal: <cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local>, <cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local> Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: conn=1041 op=1 ADD dn="cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: => mdb_entry_get: ndn: "cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: => mdb_entry_get: oc: "(null)", at: "(null)" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: mdb_dn2entry("cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local") Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: => mdb_dn2id("cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local") Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: <= mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pair found (-30798) Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: => mdb_entry_get: cannot find entry: "cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: mdb_entry_get: rc=32 Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: ==> mdb_add: cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: oc_check_required entry (cn=jochoa_fra_dev_bookworm_02,ou=user_rules,ou=sudoers,dc=example,dc=local), objectClass "sudoRole" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: oc_check_allowed type "objectClass" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: oc_check_allowed type "cn" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: oc_check_allowed type "sudoRunAsUser" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: oc_check_allowed type "sudoOption" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: oc_check_allowed type "sudoCommand" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: oc_check_allowed type "sudoHost" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: oc_check_allowed type "sudoUser" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: oc_check_allowed type "structuralObjectClass" Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: daemon: activity on 1 descriptor Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: daemon: activity on: Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: Feb 20 11:20:22 fra-corp-auth-01 slapd[710]: daemon: epoll: listen=8 active_threads=0 tvp=zero ``` If I try to stop the slapd om ldap1: ``` Feb 20 11:23:10 fra-corp-auth-01 slapd[710]: conn=1001 fd=20 closed (slapd shutdown) Feb 20 11:23:10 fra-corp-auth-01 slapd[710]: connection_closing: readying conn=1041 sd=22 for close Feb 20 11:23:10 fra-corp-auth-01 slapd[710]: connection_close: deferring conn=1041 sd=22 Feb 20 11:23:10 fra-corp-auth-01 slapd[710]: connection_closing: readying conn=1011 sd=23 for close Feb 20 11:23:10 fra-corp-auth-01 slapd[710]: connection_close: deferring conn=1011 sd=23 Feb 20 11:23:10 fra-corp-auth-01 slapd[710]: slapd shutdown: waiting for 4 operations/tasks to finish ``` strace shows: ``` futex(0x7f3e9a9ff990, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 720, NULL, FUTEX_BITSET_MATCH_ANY ``` So, if I stop all .. start slapd again .. all seems fine .. * ldap2 ``` Feb 20 11:49:32 fra-corp-auth-02 slapd[686]: conn=1209 op=2 syncprov_op_search: registered persistent search Feb 20 11:49:32 fra-corp-auth-02 slapd[686]: conn=1209 op=2 syncprov_op_search: no change, skipping log replay Feb 20 11:49:32 fra-corp-auth-02 slapd[686]: conn=1209 op=2 syncprov_op_search: nothing changed, finishing up initial search early Feb 20 11:49:32 fra-corp-auth-02 slapd[686]: conn=1209 op=2 syncprov_sendinfo: refreshDelete cookie= Feb 20 11:49:32 fra-corp-auth-02 slapd[686]: conn=1209 op=2 syncprov_search_response: detaching op ``` then I again try to use ldapadd .. and I see still: * ldap2 ``` ... Feb 20 11:54:35 fra-corp-auth-02 slapd[4696]: =>do_syncrepl rid=002 Feb 20 11:54:36 fra-corp-auth-02 slapd[4696]: daemon: epoll: listen=8 active_threads=0 tvp=zero Feb 20 11:54:36 fra-corp-auth-02 slapd[4696]: daemon: epoll: listen=9 active_threads=0 tvp=zero Feb 20 11:54:36 fra-corp-auth-02 slapd[4696]: daemon: epoll: listen=10 active_threads=0 tvp=zero Feb 20 11:54:36 fra-corp-auth-02 slapd[4696]: start_refresh: rid=002 a refresh on rid=001 in progress, pausing Feb 20 11:54:37 fra-corp-auth-02 slapd[4696]: =>do_syncrepl rid=002 Feb 20 11:54:38 fra-corp-auth-02 slapd[4696]: daemon: epoll: listen=8 active_threads=0 tvp=zero Feb 20 11:54:38 fra-corp-auth-02 slapd[4696]: daemon: epoll: listen=9 active_threads=0 tvp=zero Feb 20 11:54:38 fra-corp-auth-02 slapd[4696]: daemon: epoll: listen=10 active_threads=0 tvp=zero Feb 20 11:54:38 fra-corp-auth-02 slapd[4696]: start_refresh: rid=002 a refresh on rid=001 in progress, pausing Feb 20 11:54:39 fra-corp-auth-02 slapd[4696]: =>do_syncrepl rid=002 .... but .. a ldapsearch on ldap1 .. **still works** :-/ on ldap1 .. log is silent, except from my ldapsearch and ... I have to kill -9 slapd on ldap1 again and start .. I have no clue .. what else I can do ..... any hints ? cu denny

2 2

slapo-otp: manual page could be improved
by Windl, Ulrich 21 Feb '25

21 Feb '25

Hi! Reading the slapo-otp manual page, It's not quite clear to me how it works: * The tokens are stored in a separate entry, but does the manual page say what object type that entry has to be? I wonder why the token isn't stored directly within the user entry as tokens most likely are not shared. * Likewise "parameters" are stored in a separate entry; again what object type would those be? * Confusingly the manual talks about "attributes" next: Are those "parameters"? I mean: length and HMAC algorithm might be shared among entries, but counter and time-step cannot. A sample configuration would be really helpful, given that the only reference is "See also slapd-config(5)". Kind regards, Ulrich Windl

2 1

Migration from 2.4 to 2.5: problem with using "olcPPolicyDefault" in ACL duriung slapadd
by Windl, Ulrich 20 Feb '25

20 Feb '25

Hi! I'm about to migrate openLDAP 2.4 from SLES12 SP5 to openLDAP 2.5 from SLES15 SP6, following the rather terse https://www.openldap.org/doc/admin25/appendix-upgrading.html. I've removed the policy schema as advised from the LDIF export of cn=config, but now it seems that slapadd cannot use "olcPPolicyDefault" in an ACL: # slapadd -v -n0 -F /etc/openldap/slapd.d -S 1 -w -l 0.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}rfc2307bis,cn=schema,cn=config" (00000001) added: "cn={4}yast,cn=schema,cn=config" (00000001) added: "cn={5}sudo,cn=schema,cn=config" (00000001) added: "olcDatabase={-1}frontend,cn=config" (00000001) olcAccess: value #1: unknown attr "olcPPolicyDefault" in to clause. <access clause> ::= access to <what> [ by <who> [ <access> ] [ <control> ] ]+ <what> ::= * | dn[.<dnstyle>=<DN>] [filter=<filter>] [attrs=<attrspec>] <attrspec> ::= <attrname> [val[/<matchingRule>][.<attrstyle>]=<value>] | <attrlist> <attrlist> ::= <attr> [ , <attrlist> ] <attr> ::= <attrname> | @<objectClass> | !<objectClass> | entry | children <who> ::= [ * | anonymous | users | self | dn[.<dnstyle>]=<DN> ] [ realanonymous | realusers | realself | realdn[.<dnstyle>]=<DN> ] [dnattr=<attrname>] [realdnattr=<attrname>] [group[/<objectclass>[/<attrname>]][.<style>]=<group>] [peername[.<peernamestyle>]=<peer>] [sockname[.<style>]=<name>] [domain[.<domainstyle>]=<domain>] [sockurl[.<style>]=<url>] [ssf=<n>] [transport_ssf=<n>] [tls_ssf=<n>] [sasl_ssf=<n>] <style> ::= exact | regex | base(Object) <dnstyle> ::= base(Object) | one(level) | sub(tree) | children | exact | regex <attrstyle> ::= exact | regex | base(Object) | one(level) | sub(tree) | children <peernamestyle> ::= exact | regex | ip | ipv6 | path <domainstyle> ::= exact | regex | base(Object) | sub(tree) <access> ::= [[real]self]{<level>|<priv>} <level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+ <control> ::= [ stop | continue | break ] slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=908): ▒5=▒ Closing DB... (Also note the garbage in the error message that seems to appear for any slapadd error) As noted Openldap is SUSE's version (openldap2_5-2.5.18+31-150500.11.12.1.x86_64) they re-introduced in SLES15 SP5 (maybe due to failing to provide a working migration tool to 389-DS and a proper administration manual) So is it a bug that the attribute cannot be used in ACL, or is it a configuration error on my side? (line 908 is "dn: olcDatabase={0}config,cn=config") The actual line in question is like this: olcAccess: {1}to attrs=olcPPolicyDefault by dn.exact="uid=PP-Checker,ou=system,dc=domain,dc=org" read by * break Kind regards, Ulrich Windl

2 2

Change from mono to multivalued
by Frédéric Goudal 19 Feb '25

19 Feb '25

Hello, I may have to change some attributes from mono valued to multivalued on my production openldap I would like to know if I can do the change dynamically on the running ldap ? Most of my openldap are in 2.6.x version, but… I have one old in 2.4 (yes I know, it’s a very bad idea but too many problems to change it for me now) Thanks in advance Frederic — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

2 1

EAP-TLS extend logged lines
by Alexey D. Filimonov 19 Feb '25

19 Feb '25

Hello. Currently I have EAP-TLS auth. On successfull auth, it logs Wed Feb 19 15:23:13 2025 : Auth: (9) Login OK: [anonymous-xxx] (from client name_of_client1 port 8 cli ee:ee:ee:ed:ae:ee) I'd like to extend or replace this line with UPN from certiificate and other attributes. Where should I start from ?

2 2

Attribute value as glue
by mbalakri＠opentext.com 18 Feb '25

18 Feb '25

We have multimaster replication in place, and sync replication is working. However, we have noticed some glue values for certain entries. What could be the reason for these glue entries, and how can we avoid them? This is a sample entry wit glue values for objectClass and structuralObjectClass attribtues. Please suggest how to avoid these glue values. dn: cn=organizational users,o=test,cn=test,cn=acd,o=in.bbn.ac entryUUID: 2acd5574-47fb-4414-b930-65d3fefc40cb creatorsName: cn=Directory Manager,o=in.bbn.ac createTimestamp: 20240730130003Z entryCSN: 20240730130003.412795Z#000000#001#000000 modifiersName: cn=Directory Manager,o=in.bbn.ac modifyTimestamp: 20240730130003Z objectClass: top objectClass: glue structuralObjectClass: glue

4 11

External LDAP authentication depending on user attributes?
by alexey＠filimonic.net 17 Feb '25

17 Feb '25

I have two LDAP servers (ActiveDirectory) with users: On AD horns-and-hooves.org: cn=Jane Smith,ou=users,dc=horns-and-hooves,dc=org cn: jane.smith(a)contoso.com On AD bells-and-whistles.com: cn=John Snow,ou=users,ou=europe,dc=bells-and-whistles,dc=com mail: john.snow(a)contoso.com And for mail system, I need to grab some of those users to single OpenLDAP database (dc=internal), add some mail system-specific attributes (that dont exist in source ADs) and add passthrough authentication for them to the AD server where they belong. Like this: cn=jane.smith,ou=horns-and-hooves,dc=internal mailQuota: 10 imapHost: imap1 mail: jane.smith(a)contoso.com sourceOrg: horns-and-hooves cn=john.snow,ou=bells-and-whistles,dc=internal mailQuota: 20 imapHost: imap2 mail:: john.snow(a)contoso.com sourceOrg: bells-and-whistles I expect algorithm like this: First, I manually create users in OpenLDAP directory without passwords with correct attributes. When Jane makes simple_bind to OpenLDAP server, the server determines if user is related to horns-and-hooves organization or to bells-and-whistles. If "horns-and-hooves" then server makes a search against ldap://horns-and-hooves.org:389/dc=horns-and-hooves,dc=org for '(mail=$1)' where $1 is value of mail from `mail` attribute. it finds one item, OpenLDAP tries to make bind to ldap://horns-and-hooves.org:389 with DN of item found and password provided by Jane to OpenLDAP. If "bells-and-whistles" then backend server is ldap://bells-and-whistles.com:389/dc=bells-and-whistles,dc=com , other is same. How server determines if user is a hosn-an-hooves user or bells-and-whistles user - based on some attriburte value (sourceOrg) or based on DN value (ou=horns-and-hooves,dc=internal vs ou=bells-and-whistles,dc=internal) - IDK if any of this is possible. Does this algorithm implementation requires SALSd, or it can be done with OpenLDAP-only? Could you please help me getting this configuration done?

3 2

Few questions about replica (mirror mode?)
by alexey＠filimonic.net 17 Feb '25

17 Feb '25

I plan few OpenLDAP servers: N readonly secondaries and single writable main. In my case OpenLDAP is critical as readonly database, and changes are allowed to fail. But I need all readonly replicas contain the same data same time, and I have possibilities to temporarily disconnect readonly secondaries from master. Is there a some kind of operational\replication mode when: - Transactional changes over all servers: Writable main fails writing to database and propagating them to secondaries in case any of secondaries can not receive same changes - Secondary server may start "empty" and self-register as secondary server on writeable main, then get in sync. Until sync complete, secondary server will not satisfy any requests from clients.

3 2

lload backend-server connection issues
by Ben Poliakoff 17 Feb '25

17 Feb '25

I've successfully set up haproxy with current openldap slapd backend instances, the ldap client IP is passed on to my slapd instances, and things like IP based ACLs work. But now I'm exploring and comparing the features of the OpenLDAP lloadd backend. I've been using the embedded version, loading lloadd.a into slapd and I've been using the example configs from https://www.openldap.org/doc/admin26/loadbalancer.html as a starting point. I'm consistently seeing these errors on the backend slapd: Feb 4 10:45:33 test local4.debug slapd[508415]: proxyp(19): invalid header signature Feb 4 10:45:33 test local4.debug slapd[508415]: slapd(19): proxyp failed And on the frontend slapd (running lload) I'm seeing these sorts of errors: Feb 4 10:48:12 slapd-lb-a local4.debug slapd[271207]: operation_init: received a new operation, bind request with msgid=1 for client connid=6 Feb 4 10:48:12 slapd-lb-a local4.debug slapd[271207]: request_bind: connid=6, msgid=1 no available connection found When I compare the traffic between slapd w/lload and the backend slapd with traffic between haproxy and the same backend slapd, the main thing that I notice is that the slapd w/lload is doing a TLSv1 client hello whereas haproxy is doing a TLSv1.3 client hello. Is it possible that the lloadd code doesn't support TLSv1.3? I'd be surprised if that were the case, since the same slapd happily supports client connections with TLSv1.3, but I can't figure out why it's only trying TLSv1. I'm running openldap 2.6.9 packages from Symas on Debian 12, for what it's worth. While I've been working on this I've been using the slapd.conf style config, but would transition to cn=config if it were to go to production. I've tried configuring the backend server URI with ldap://, ldaps://, pldap://, and pldaps://, all with the same results. My current config follows. Thanks for any suggestions! Ben ------- current config ----------------------------------------------- TLSCertificateFile /etc/haproxy/haproxy.pem TLSCertificateKeyFile /etc/haproxy/haproxy.pem TLSCACertificatePath /etc/ssl/certs loglevel stats #loglevel -1 pidfile /var/symas/run/openldap-lload.pid allow bind_v2 include /opt/symas/etc/openldap/schema/core.schema modulepath /opt/symas/lib/openldap # require at least SSL/TLS for simple binds security simple_bind=1 moduleload lloadd.la backend lload # The Load Balancer manages its own sockets, so they have to be separate # from the ones slapd manages (as specified with the -h "URLS" option at # startup). listen ldaps://:10636 # Enable authorization tracking feature proxyauthz # Specify the number of threads to use for the connection manager. The default is 1 and this is typically adequate for up to 16 CPU cores. # The value should be set to a power of 2: io-threads 2 TLSShareSlapdCTX true # Authentication and other options (timeouts) shared between backends. bindconf bindmethod=simple tls_cacertdir="/etc/ssl/certs" binddn=uid=ldap-lb,ou=Services,dc=example,dc=com credentials=xxxxxxxxxxxxxxxxxxxxxxxxxxx network-timeout=5 tier bestof backend-server uri=pldaps://backend-slapd-hostname:8636 retry=5000 max-pending-ops=50 conn-max-pending=10 numconns=10 bindconns=5 ####################################################################### database monitor

2 1

Make OpenLDAP proxy only simple_bind requests to other LDAPs
by Alexey D. Filimonov 11 Feb '25

11 Feb '25

My goal is to [manually] maintain a database of users using OpenLDAP directory, with some set of attributes and values. All of those users have their second accounts in different external LDAP directories (2 directories). For those users, I want OpenLDAP server to passthrough simple_bind authentication to one of those directories. When I manually create a user in OpenLDAP directory, I want specify a `backend keys` in some attributes, that will tell OpenLDAP server how to process user's simple_bind authentication. For example, I can specify some sort of attributes like `backendRealm = ActiveDirectory1` and `mail = jack(a)contoso.com` to tell OpenLDAP to lookup object DN on servers from group `ActiveDirectory1` with `mail=jack(a)contoso.com` filter and try to simple_bind against one server from group `ActiveDirectory1` using DN it fount and password user provided originally. DNs of all users are not even partially equal between directories. Suffixes are different too. All OpenLDAP users and attributes are maintained manually, without proxying (except authentication). Please help me if I can do this somehow using OpenLDAP? Can I do this without using SASLD? Alex.

2 4

container image building and syncing
by Marc 11 Feb '25

11 Feb '25

I use echo "127.0.0.2 ldap.example.com" >> /etc/hosts to prevent the running ldap server from syncing during image building. However when using DOCKER_BUILDKIT=1 this is not possible any more (read only fs). I was wondering if it is possible to start slapd so it does not start syncing?

3 5

OpenLDAP Self Registration/Password Reset Portal
by killian.greig＠gmail.com 11 Feb '25

11 Feb '25

I have been working on an OpenLDAP Self Registration/Password Reset Portal in Go that I will be releasing under a BSD license. Its still very much embryonic but if you are interested in taking an early look, please let me know. I'd love to get feedback on it. Kind regards, Killian

8 14

ldap acl matching
by Marc 09 Feb '25

09 Feb '25

olcAccess: {9} to dn.subtree="...... by ssf=256 set="([ldap:///o=XXXX,ou=aaaa,dc=bbbbb,dc=cccc,dc=ddddd??sub?(cn=eeee)])/member & user" search by ssf=256 set="([ldap:///o=YYYY,ou=aaaa,dc=bbbbb,dc=cccc,dc=ddddd??sub?(cn=eeee)])/member & user" search by ssf=256 set="([ldap:///o=ZZZZ,ou=aaaa,dc=bbbbb,dc=cccc,dc=ddddd??sub?(cn=eeee)])/member & user" search Currenlty I have the above rules which seem to work. But for every entry in ou=aaaa I need to manually add an acl line. How can I rewrite this to 1 line that matches XXX, YYYY, ZZZZ and anything else I add in ou=aaaa?

1 0

Re: OpenLDAP 2.6 Long Term Support Announcement
by Geert Hendrickx 06 Feb '25

06 Feb '25

Hi What is now the status of OpenLDAP 2.5 / 2.6 / 2.7 ? The website still lists 2.5.x as the current LTS release, and 2.6.x as the Feature Release. Has the below plan been delayed, or is the website just not up to date? Thanks for any clarification Geert On Sat, Aug 10, 2024 at 15:24:56 +0000, project(a)openldap.org wrote: > The OpenLDAP Project is pleased to announce the promotion of OpenLDAP > 2.6 from Feature Release to Long Term Support (LTS) Release, effective > January, 2025. It is now the recommended OpenLDAP version for > deployments that prioritize stability over features. The projected > lifespan for OpenLDAP 2.6 as the LTS release is five years. > > OpenLDAP 2.5 is now in its end of life stage and, at the discretion of > the Project, will receive critical fixes until January 15, 2027. After > that it will be designated as a historical release and no longer > supported or maintained by the Project. Users are encouraged to develop > a plan that will help them upgrade quickly to the new LTS version so > that they can continue on a supported release. > > OpenLDAP 2.7 is the new Feature Release and will see its first public > availability in the fall of 2024. > > ------------- > Compatibility > ------------- > > Replication: > Replication compatibility between OpenLDAP 2.5 and 2.6 is excellent. > The Project expects this to remain the case throughout the remaining > end-of-life stage of OpenLDAP 2.5. > > Configuration Files: > Configuration file compatibility between OpenLDAP 2.5 and 2.6 is > excellent, but may require some manual intervention at upgrade time, > particularly if you are using the OpenLDAP Load Balancer daemon. > > > ---------------------- > Additional Information > ---------------------- > > * The OpenLDAP Release Maintenance Policy can be found at > https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/t… > > * Notes covering upgrading from OpenLDAP 2.5 to 2.6 can be found at > https://www.openldap.org/doc/admin26/appendix-upgrading.html >

2 1

ldap vs db auth
by Marc 06 Feb '25

06 Feb '25

I was actually wondering how ldap compares to mariadb or other databases for authentication. Has anyone actually tested this?

2 1

Re: consumer replication net recovering
by Suresh Veliveli 17 Jan '25

17 Jan '25

Ok. I will send you the conf files (minus creds). Can I send them directly to you? Thanks, Suresh On Fri, Jan 17, 2025 at 3:01 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, January 17, 2025 2:45 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > Hi Quanah, > > > > > > Understood. Unfortunately, we are experiencing the issue. Here is my > > configuration. > > > > > > On Master: > > database mdb > > suffix "dc=georgetown,dc=edu" > > . > > dbnosync FALSE > > checkpoint 128 5 > > maxsize 108993459200 > > > > > > > ># Replication > > overlay syncprov > > syncprov-checkpoint 10 5 > > syncprov-sessionlog 100 > > > > > > > > On the Replica: > > syncrepl rid=132 > > provider=ldaps://aaa-master-1.uis.georgetown.edu:636/ > > type=refreshAndPersist > > > > keepalive=300:5:5 > > retry="5 5 300 +" > > > > > > How do we go about fixing this? > > Looks like you're using the deprecated slapd.conf files, which can have > interesting issues because they may not properly order directives. > Without > the full slapd.conf for both provider and consumer (minus sensitive data > like passwords), there's not a lot for me to go off of here. > > --Quanah > > > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

Re: consumer replication net recovering
by Suresh Veliveli 17 Jan '25

17 Jan '25

Hi Quanah, Understood. Unfortunately, we are experiencing the issue. Here is my configuration. *On Master:* database mdb suffix "dc=georgetown,dc=edu" . dbnosync FALSE checkpoint 128 5 maxsize 108993459200 # Replication overlay syncprov syncprov-checkpoint 10 5 syncprov-sessionlog 100 *On the Replica:* syncrepl rid=132 provider=ldaps://aaa-master-1.uis.georgetown.edu:636/ type=refreshAndPersist keepalive=300:5:5 retry="5 5 300 +" How do we go about fixing this? Thanks, Suresh On Fri, Jan 17, 2025 at 2:30 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, January 17, 2025 10:51 AM -0700 Thomas Pritchard > <pritchardtw(a)gmail.com> wrote: > > > > > I have not experienced the master crashing but I have also experienced > > stalled replication regularly over the last 2 years. We've been on 2.46 > > and have keep alive enabled. We were hoping an upgrade would resolve the > > problem but it seems to exist on latest versions as well. I am also on > > aws ec2 instances. > > > I've been running OpenLDAP in AWS on EC2 instances for the last 3 years at > two different companies, and have never encountered this behavior. > > --Quanah > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

Re: consumer replication not recovering
by Suresh Veliveli 17 Jan '25

17 Jan '25

Hi Quanah, You are correct. I misspoke. We ran "bdb" in OpenLDAP: slapd 2.4.50 (Aug 6 2020 11:11:46). We switched to "mdb" when we went from 2.4.50 to 2.6.x version. The upgrade path, as mentioned, was a clean install of 2.6.x and export of db (slapcat) and import(slapadd). Regards, Suresh On Fri, Jan 17, 2025 at 12:48 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, January 6, 2025 6:47 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > It was "bdb". For migration, we did a clean install, used "slapcat" to > > export the db and "slapadd" to import. We used this procedure a > > number of times in the past when we switched OS, for upgrades etc. Do > > you have a recommended procedure in mind? > > >> We did an upgrade from 2.6.3 to 2.6.7 at the same time, changing the > >> backend db to "mdb". I think that's when we started to notice that > >> consumer replication is not recovering. So we upgraded again to 2.6.8 to > >> now 2.6.9. > > > There was no bdb backend in the 2.6 series. It was removed after the 2.4 > series, so the upgrade route you describe is not feasible. > > > --Quanah > > > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

1 0

Re: consumer replication not recovering
by Suresh Veliveli 17 Jan '25

17 Jan '25

It was "bdb". For migration, we did a clean install, used "slapcat" to export the db and "slapadd" to import. We used this procedure a number of times in the past when we switched OS, for upgrades etc. Do you have a recommended procedure in mind? Regards, Suresh On Mon, Jan 6, 2025 at 6:36 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, January 6, 2025 10:33 AM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > We just had another instance like this. Any suggestions? > > > > > > Thanks, > > Suresh > > > > > > On Fri, Jan 3, 2025 at 4:52 PM Suresh Veliveli > > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > > > > We did an upgrade from 2.6.3 to 2.6.7 at the same time, changing the > > backend db to "mdb". I think that's when we started to notice that > > consumer replication is not recovering. So we upgraded again to 2.6.8 to > > now 2.6.9. > > What backend were you using on 2.6.3 before migrating to mdb? At this > point, I'd suspect your migration may not have been executed correctly. > > --Quanah > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

question regarding olcAccess peername.ip="0.0.0.0%0.0.0.0"
by cyril＠stoll.info 17 Jan '25

17 Jan '25

Hi there My predecessor created a couple of ACLs that are IP based. For example this one: olcAccess: {10}to dn.subtree="ou=something,dc=domain,dc=tld" by peername.ip="0.0.0.0%0.0.0.0" none by * +0 break Unfortunately I can't find any hints what "0.0.0.0%0.0.0.0" means. Can anyone explain that? The only part of the documentation where 0.0.0.0 occurs is in "20.4.4. Listener". In that case it looks to me like 0.0.0.0 is actually the localhost. In other areas (e.g. some Firewalls) 0.0.0.0 is the WAN/Internet which is pretty much the opposite of localhost. Since the subnetmask in the ACL is also 0.0.0.0 I assume that the whole construct peername.ip="0.0.0.0%0.0.0.0" means basically "any" IP. But in that case it does not make a lot of sense to me to even have that in the ACL. However there are a lot of configs leftover from my predecessor that don't make a lot of sense to me, so there's that. Thanks for any hints/explanations and best regards, Cyril

4 7

LMDB: Questions about the MDB_NOSYNC and MDB_MAPASYNC flags
by chris＠christrenkamp.com 16 Jan '25

16 Jan '25

Hi, I have several questions about the environment options in mdb_env_open. * MDB_NOSYNC states that as long as the filesystem preserves the write order, the database will lose durability, but preserve ACI. If we're using EXT4, does that mean we must mount the filesystem with "data=ordered" so LMDB will preserve ACI when used in combination with MDB_NOSYNC? Are there any other mount options we should use so we don't lose ACI? * MDB_MAPASYNC states it has the same corruption potential as MDB_NOSYNC. Does it preserve ACI if the filesystem preserves the write order like MDB_NOSYNC? * The docs states that (MDB_MAPASYNC | MDB_WRITEMAP) may be preferable over MDB_NOSYNC. When would you want to use one over the other? Is there a good rule of thumb to follow if you have to use one of these options? Thanks

1 0

acl question
by Frédéric Goudal 13 Jan '25

13 Jan '25

Hello, I’m working on the acl on my ldap, and I have found a rule that puzzle me on it’s last statement : by * +0 break Well as 0 means no access what does +0 mean ? On my opinion it does nothing and the statement is equivalent to : by * break Am I correct or do I miss something ? f.g. — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

2 2

LDAP Tools don't use LDAP.conf
by maudez.eric＠neuf.fr 13 Jan '25

13 Jan '25

I notice that the ldap.conf file is not used with commands ldapsearch, ldapwhoami (ldap tools). An environment variable (LDAPCONF) was set and pointing to the file (/etc/openldap/ldap.conf) but it doesn't work. On the other hand, using the information provided in an ldaprc file works. How to ensure the LDAP.conf file is taken into account because I need it for a mutual authentication connection with the use of LDAPS for SASL EXTERNAL. I'm using an openldap 2.6.6 version on CentOS.

9 23

Re: [EXT] Re: consumer replication not recovering
by Suresh Veliveli 11 Jan '25

11 Jan '25

I got the debug info this time. Whenever I restart a stuck replica it is crashing the master. Hope the following will be helpful. Regards, Suresh ------------------- Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/var/services/openldap/libexec/slapd -h ldap://*:389 ldaps://*:636 -f /var/serv'. Program terminated with signal SIGSEGV, Segmentation fault. #0 connection_abandon (c=0x7f27364cf0e8) at connection.c:714 714 op.orn_msgid = o->o_msgid; [Current thread is 1 (Thread 0x7f0d98cf5640 (LWP 2460))] (gdb) bt full #0 connection_abandon (c=0x7f27364cf0e8) at connection.c:714 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} o = 0x7f0d8413eab0 next = 0x7f0d74137490 op = {o_hdr = 0x7f0d98cf45e0, o_tag = 80, o_time = 0, o_tincr = 0, o_tusec = 0, o_qtime = {tv_sec = 0, tv_usec = 0}, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = { rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0, rs_newDN = {bv_len = 0, bv_val = 0x0}, rs_nnewDN = {bv_len = 0, bv_val = 0x0}}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = { stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 143657, oh_conn = 0x7f27364cf0e8, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>} #1 0x00000000004460d5 in connection_closing (c=0x7f27364cf0e8, why=0x5db380 <conn_lost_str> "connection lost") at connection.c:785 __PRETTY_FUNCTION__ = "connection_closing" #2 0x0000000000447d18 in connection_read (s=25, cri=0x7f0d98cf49a0) at connection.c:1453 rc = -2 c = 0x7f27364cf0e8 __PRETTY_FUNCTION__ = "connection_read" #3 0x000000000044741b in connection_read_thread (ctx=0x7f0d98cf49f0, argv=0x19) at connection.c:1260 rc = 0 cri = {op = 0x7f0d74137490, func = 0x0, arg = 0x0, ctx = 0x7f0d98cf49f0, nullop = 0} s = 25 --Type <RET> for more, q to quit, c to continue without paging--c #4 0x00007f274ee74bed in ldap_int_thread_pool_wrapper (xpool=0xc9b0c0) at tpool.c:1059 pq = 0xc9b0c0 pool = 0xc9afc0 task = 0x7f0da01c5960 work_list = 0xc9b130 ctx = {ltu_pq = 0xc9b0c0, ltu_id = 139696375027264, ltu_key = {{ltk_key = 0x4be35e <slap_sl_mem_init>, ltk_data = 0x7f0d90000b60, ltk_free = 0x4be177 <slap_sl_mem_destroy>}, {ltk_key = 0x4466db <operation_counter_init>, ltk_data = 0x7f0d90100bb0, ltk_free = 0x44652a <conn_counter_destroy>}, {ltk_key = 0xf79390, ltk_data = 0x7f0d90101170, ltk_free = 0x539d95 <mdb_reader_free>}, {ltk_key = 0x519179 <search_stack>, ltk_data = 0x7f0d8a5fe010, ltk_free = 0x519155 <search_stack_free>}, {ltk_key = 0x515d3d <scope_chunk_get>, ltk_data = 0x7f0d981f4010, ltk_free = 0x515cf3 <scope_chunk_free>}, {ltk_key = 0x46103b <slap_op_free>, ltk_data = 0x7f0dc8694410, ltk_free = 0x460f8b <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 521 hash = 1213313545 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #5 0x00007f274e489c02 in start_thread () from /lib64/libc.so.6 No symbol table info available. #6 0x00007f274e50ec40 in clone3 () from /lib64/libc.so.6 No symbol table info available. (gdb) On Wed, Jan 8, 2025 at 7:38 AM Suresh Veliveli < Suresh.Veliveli(a)georgetown.edu> wrote: > Hi Ulrich, > > Quanah helped to build one with debug and not stripped. > > Thanks, > Suresh > > On Wed, Jan 8, 2025 at 2:29 AM Windl, Ulrich <u.windl(a)ukr.de> wrote: > >> Hi! >> >> >> >> I don’t know the details of the build process, but sometimes RPM strips >> the binaries. Otherwis you could look for strip or a corresponding option >> in the Makefiles. >> >> >> >> Ulrich >> >> >> >> *From:* Suresh Veliveli <Suresh.Veliveli(a)georgetown.edu> >> *Sent:* Tuesday, January 7, 2025 8:22 PM >> *To:* Quanah Gibson-Mount <quanah(a)fast-mail.org> >> *Cc:* Windl, Ulrich <u.windl(a)ukr.de> >> *Subject:* [EXT] Re: consumer replication not recovering >> >> >> >> I used "make STRIP="" install" but it still installed the stripped >> version. I understand your suggestion. I don't have the appropriate access >> on my end to install Symas packages. I can only install the ones I build >> with a prefix limited to /var/services directory. >> >> >> >> Thanks, >> Suresh >> >> >> >> On Tue, Jan 7, 2025 at 2:07 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> >> wrote: >> >> >> >> --On Tuesday, January 7, 2025 11:22 AM -0500 Suresh Veliveli >> <Suresh.Veliveli(a)georgetown.edu> wrote: >> >> > >> > I downloaded the src - openldap-apkg26.tar.gz, removed the optimization >> > flags (export CFLAGS='-g'), configure, build and install, but still >> > installed the stripped version. Am I missing something? >> > >> > >> > [root@aaa-dev-gcp-1 libexec]# file slapd >> > slapd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically >> > linked, interpreter /lib64/ld-linux-x86-64.so.2, >> > BuildID[sha1]=547e20101751207ad48cc96006ea51e7610c7a1c, for GNU/Linux >> > 3.2.0, stripped >> >> This is basic software building, but: >> >> make STRIP="" install >> >> I still suggest using the Symas packages over building things yourself. >> >> --Quanah >> >> >> >> >> -- >> >> Suresh Veliveli >> >> Sr. UNIX Systems Engineer >> >> Georgetown University >> >> University Information Services | Security Infrastructure and >> Policy-Identity and Collaboration >> >> 202-262-6676 (cell) | 202-687-3108 (work) >> > > > -- > Suresh Veliveli > Sr. UNIX Systems Engineer > Georgetown University > University Information Services | Security Infrastructure and > Policy-Identity and Collaboration > 202-262-6676 (cell) | 202-687-3108 (work) > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

1 0

Unable to get the contextCSN
by Frédéric Goudal 08 Jan '25

08 Jan '25

Hello, I just have build a new ldap server @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2024 09:45:55) $ It is an attenpt to do a partial replication from another ldap server. The objects seem to be synchronized in the logs I have lines like slap_queue_csn: queueing 0x77bfe8109e30 20241218104201.919382Z#000000#00a#000000 where the csn is correct. What is strange is that if I try to get the contextCSN, from the directoryI have no value returned : /usr/local/bin/ldapsearch -H ldap://ldapext2024.dmze.ipb.fr -x -s base -b dc=ipb,dc=fr contextCSN # extended LDIF # # LDAPv3 # base <dc=ipb,dc=fr> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN # # search result search: 2 result: 0 Success # numResponses: 1 The olcSyncrepl value is : {0}rid=430 provider=ldap://<provider> binddn="uid=ldapsync,ou=people,dc=ipb,dc=fr" bindmethod=simple credentials=secret filter="(| (entryDN:dnSubtreeMatch:=ou=groups,dc=ipb,dc=fr) (entryDN:dnSubtreeMatch:=ou=people,dc=ipb,dc=fr))" searchbase="dc=ipb,dc=fr" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" attrs="uid,sn,givenName,userPassword,mail,member,ipbCompteValide,ipbServiceAllow,ipbServiceDeny,ipbPupi" logbase=cn=accesslog type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 exattrs=hasSubordinates I have several other secondary ldap from the same source, with the same confiiguration, except the filter is (objectClass=*) and there is no attrs value. I suspect the error is on the attrs or filter but what do I miss ? thanks in advance f.g. — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

3 6

Enabling PPolicy on a live LDAP...
by Marco Gaiarin 08 Jan '25

08 Jan '25

I need to enable PPolicy overlay to control passord policy on an existing LDAP installation. I have to expect some 'breakage'? Or policy attributes get defined only explicitly and have decent default? Speaking plainly: i have to expect to be cut off of my LDAP account immediately because i have my password old? Thanks. --

2 1

Re: [EXT] Re: Replication issues with openldap 2.5 {resolved}
by Ulises Gonzalez Horta 07 Jan '25

07 Jan '25

Can you please give an explanation of the full meaning?? That way we can learn because online it refers to invalid credentials, providing the user is good, then the password is what left over See this example where I intentionally put the wrong password root@nm03-lab-roc1:~/openldap_config_tree/2.1_replication# ldapsearch -Z -LLL -H ldap://servert:389 -D "uid=user,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net" "(mail=* ugonzalezhorta(a)breezeline.com)" cn Enter LDAP Password: ldap_bind: Invalid credentials (49) Ulises Gonzalez Horta Lead Linux Engineer C: 786 450 2970/ 240 727 6267 E: ugonzalezhorta(a)breezeline.com <jsutherland1(a)breezeline.com> On Fri, Jan 3, 2025 at 2:16 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, January 3, 2025 8:49 AM -0500 Ulises Gonzalez Horta > <ugonzalezhorta(a)breezeline.com> wrote: > > > > > > > Yeah, the error message was misleading here, error 49 is wrong password, > > but I knew for sure the password was right. > > Maybe a log entry as the one you suggested will help you fast pinpoint > > the issue > > That's not what result code 49 means. > > --Quanah > >

2 2

monitoring MMR sync
by Dave 07 Jan '25

07 Jan '25

Hello Everyone, Hope you are enjoying the day. Was curious what people are doing to monitor their MMR clusters being out of sync. At least the implementation we found and have been trying is using telegraf and the [ldap_org](https://github.com/falon/CSI-telegraf-plugins/blob/master/plugins… plugin to gather all objects on each ldap master and compare their count. How is the community doing it? Any better way to go about this? Any input is appreciated! Best, Dave

6 7

Re: consumer replication not recovering
by Suresh Veliveli 06 Jan '25

06 Jan '25

We did an upgrade from 2.6.3 to 2.6.7 at the same time, changing the backend db to "mdb". I think that's when we started to notice that consumer replication is not recovering. So we upgraded again to 2.6.8 to now 2.6.9. Thanks, Suresh On Fri, Jan 3, 2025 at 2:19 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, January 3, 2025 7:52 AM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > > > The OS is Rock9, AWS EC2 instance. > > Question - Was this working on an earlier OpenLDAP version, and just > started having issues with 2.6.9? I was re-reading your initial post and > that wasn't clear. > > Thanks! > > --Quanah > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 2

Re: Replication issues with openldap 2.5
by Ulises Gonzalez Horta 03 Jan '25

03 Jan '25

Thanks for replying, from what I see in your answer, I have already distracted a and b, I can say c is also ruled out but I would like to double check it, maybe acls are not processing in the expected order. What is the best way to troubleshoot acls?? Any recommended log level? Ulises Gonzalez Horta Lead Linux Engineer C: 786 450 2970/ 240 727 6267 E: ugonzalezhorta(a)breezeline.com <jsutherland1(a)breezeline.com> On Fri, Dec 27, 2024 at 2:09 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 27, 2024 10:34 AM -0500 Ulises Gonzalez Horta > <ugonzalezhorta(a)breezeline.com> wrote: > > > > > > > Good morning > > > > I am trying to setup a replication in ldap 2.5, using syncrepl, I have a > > provider server and a consumer, both of the servers are running 2.5.11 > > from Ubuntu 22.04, I followed the admin guide chapter 18.3.1 to do the > > configuration. I have some information on the provider that is > > successfully being replicated to the consumer without any errors > > > > > > Consumer configuration > > ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config olcSyncRepl > > olcUpdateref > > dn: olcDatabase={1}mdb,cn=config > > olcSyncrepl: {0}rid=100 provider=ldap://provider:389 type=refr > > eshOnly interval=00:00:05:00 retry="300 +" > > searchbase="dc=metrocast,dc=net" f > > ilter="(|(entryDN:=dc=metrocast,dc=net)(entryDN:dnOneLevelMatch:=dc=met > > > Why do you have such a complicated filter? > > > > > On the consumer this same query returns error 49 > > > > ldapsearch -Z -LLL -H ldap://providert:389 -D > > "uid=user1,ou=employees,dc=metrocast,dc=net" -W -b > > "ou=employees,dc=metrocast,dc=net" "(mail=*pepe(a)breezeline.com) > > Either: > > a) The user entry doesn't exist > b) The user entry is missing the userPassword attribute > c) The ACLs don't allow anonymous "auth" access on the userPassword > attribute > > --Quanah > > >

5 11

Hello, I have an issue with the configuration of pam_setquota.so. I added the following quota schema:
by Rodrigo Prieto 03 Jan '25

03 Jan '25

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 8fd665e7 dn: cn=quota,cn=schema,cn=config objectClass: olcSchemaConfig cn: quota olcAttributeTypes: {0}( 1.3.6.1.4.1.19937.1.1.1 NAME 'quota' DESC 'Quotas (FileSystem:BlocksSoft,BlocksHard,InodesSoft,InodesHard)' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{255} ) olcObjectClasses: {0}( 1.3.6.1.4.1.19937.1.2.1 NAME 'systemQuotas' DESC 'System Quotas' SUP posixAccount AUXILIARY MUST uid MAY quota ) I create a user, and the attributes are created correctly: objectclass: systemQuotas objectclass: posixAccount objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person quota: /home,500,510,0,0 Configuration of /etc/pam.d/common-session: # here are the per-package modules (the "Primary" block) session [default=1] pam_permit.so # here's the fallback if no module succeeds session requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around session required pam_permit.so # and here are more per-package modules (the "Additional" block) session required pam_unix.so session [success=ok default=ignore] pam_ldap.so minimum_uid=1000 session optional pam_systemd.so session optional pam_mkhomedir.so skel=/etc/skel umask=077 session required pam_setquota.so # end of pam-auth-update config When logging in with an LDAP user, the following appears in Debian logs: pam_setquota(login:session): no limits defined in configuration for user zprieto on /dev/vda5. I don’t know what is missing that prevents the user’s attributes from being read. Thank you very much.

2 1

Replication issues with openldap 2.5
by Ulises Gonzalez Horta 27 Dec '24

27 Dec '24

Good morning I am trying to setup a replication in ldap 2.5, using syncrepl, I have a provider server and a consumer, both of the servers are running 2.5.11 from Ubuntu 22.04, I followed the admin guide chapter 18.3.1 to do the configuration. I have some information on the provider that is successfully being replicated to the consumer without any errors Consumer configuration ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config olcSyncRepl olcUpdateref dn: olcDatabase={1}mdb,cn=config olcSyncrepl: {0}rid=100 provider=ldap://provider:389 type=refr eshOnly interval=00:00:05:00 retry="300 +" searchbase="dc=metrocast,dc=net" f ilter="(|(entryDN:=dc=metrocast,dc=net)(entryDN:dnOneLevelMatch:=dc=metrocast ,dc=net)(&(entryDN:dnSubtreeMatch:=dc=metrocast,dc=net)(entrydn:dnSubtreeMatc h:=ou=Boxes,dc=metrocast,dc=net))(&(entryDN:dnSubtreeMatch:=dc=metrocast,dc=n et)(entrydn:dnSubtreeMatch:=ou=RadiusGroups,dc=metrocast,dc=net))(&(entryDN:d nSubtreeMatch:=dc=metrocast,dc=net)(entrydn:dnSubtreeMatch:=ou=group,dc=metro cast,dc=net))(&(entryDN:dnSubtreeMatch:=dc=metrocast,dc=net)(entryDN:distingu ishedNameMatch:=ou=People,dc=metrocast,dc=net))(&(entryDN:dnSubtreeMatch:=dc= metrocast,dc=net)(entryDN:dnSubtreeMatch:=ou=employees,dc=metrocast,dc=net))) " timelimit=unlimited sizelimit=unlimited bindmethod=simple binddn="cn=user,ou=boxes,dc=metrocast,dc=net" credentials="xxxx" start tls=critical tls_cacertdir="/etc/ldap/certs" olcUpdateRef: ldap://ldap-write.metrocast.net:389 I can confirm the DIT is present on the consumer and the values matches the provider item by item, including the encrypted passwords, The issue I am having is that a query that runs on the provider without any issue is failing to run on the consumer with error 49 invalid credentials, but I do know for sure that the provided credentials are good, I even did a tcpdump and confirmed they are fine On the provider a query similar to this one runs fine and returns a result ldapsearch -Z -LLL -H ldap://providert:389 -D "uid=user1,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net" "(mail=*pepe(a)breezeline.com) On the consumer this same query returns error 49 ldapsearch -Z -LLL -H ldap://providert:389 -D "uid=user1,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net" "(mail=*pepe(a)breezeline.com) I confirmed with ldapsearch -Y EXTERNAL -H ldapi:/// ..... that the information for user1 is exactly the same in the provider and the consumer for all the attributes including the passwords. Tcpdump confirmed that I am sending the right password, doing -W or -w $password gives the same result. For any user I use to run the query I get exactly the same error 49, I did verify that ACLs are not blocking the query. Is there anything else I should check?? any log level that could help me identify where the error is?? Currently my loglevel is olcLogLevel: 128 256 1024 This is a dev environment so I can do changes at will. Thanks and happy new year Ulises Gonzalez Horta Lead Linux Engineer C: 786 450 2970/ 240 727 6267 E: ugonzalezhorta(a)breezeline.com <jsutherland1(a)breezeline.com>

2 1

Re: consumer replication net recovering
by Suresh Veliveli 23 Dec '24

23 Dec '24

Pretty sure It didn't hit the defined maxsize. -rw-------. 1 ldap_svc ldap_svc 108993459200 Dec 20 17:36 data.mdb du -c -h data.mdb 5.2G data.mdb 5.2G total I don't see any "syncrepl_sync" references in the replica logs. The loglevel is "stats sync". Am I missing something? Thanks, Suresh On Fri, Dec 20, 2024 at 5:15 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 2:07 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > I do have sync logging enabled. This is the last record in the log file, > > and after that, nothing. It isn't attempting to get changes. > > One thing I'd confirm is that you haven't hit the defined maxsize of your > MDB database. > > Also, I don't see the result in what you posted for the operation. You > seem to have excluded all the "syncrepl_sync" log lines which are critical. > > --Quanah > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 2

Re: consumer replication net recovering
by Suresh Veliveli 20 Dec '24

20 Dec '24

I do have sync logging enabled. This is the last record in the log file, and after that, nothing. It isn't attempting to get changes. Log on the replica: Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_queue_csn: queueing 0x7f67101bc860 20241212135921.652395Z#000000#000#000000 Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_graduate_commit_csn: removing 0x7f67101bc860 20241212135921.652395Z#000000#000#000000 Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_queue_csn: queueing 0x7f67102311b0 20241212135921.652395Z#000000#000#000000 Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_graduate_commit_csn: removing 0x7f67102311b0 2*0241212135921.652395Z#000000#000#000000* *Log on the master:* Dec 12 08:59:30 aaa-prod-master-1 slapd[4072]: conn=936345 op=1 syncprov_sendresp: cookie=rid=129,csn=20241212135921.637305Z#000000#000#000000 *Dec 12 08:59:30 aaa-prod-master-1 slapd[4072]: conn=936345 op=1 syncprov_sendresp: cookie=rid=129,csn=20241212135921.652395Z#000000#000#000000* There is nothing in the log on the master or the replica after this entry. Regards, Suresh On Fri, Dec 20, 2024 at 1:40 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 11:22 AM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > > > > > Hi, > > > > > > We have a single master with multiple replicas. Our backend is mdb, and > > we are on the latest version, 2.6.9. The replication type > > is refreshAndPersist. Here is the relevant configuration. > > > > > > syncrepl rid=141 > > provider=ldaps://ldap-master.georgetown.edu:636/ > > type=refreshAndPersist > > > > .. > > .. > > keepalive=300:5:5 retry="5 5 300 +" > > > > > > > > This is now happening at regular intervals. When a consumer replication > > gets stuck, only a service restart seems to restart replication. > > > Need more information on what you mean by "getting stuck". Is it actually > attemping to get changes? Do you have sync logging enabled? If so, you > could see if that particular consumer is having an issue during > replication > and returning a non-zero result code as to why it's unable to proceed. Or > is it not establishing a replication connection at all? etc. > > --Quanah > > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

consumer replication net recovering
by Suresh Veliveli 20 Dec '24

20 Dec '24

Hi, We have a single master with multiple replicas. Our backend is mdb, and we are on the latest version, 2.6.9. The replication type is refreshAndPersist. Here is the relevant configuration. syncrepl rid=141 provider=ldaps://ldap-master.georgetown.edu:636/ type=refreshAndPersist .. .. keepalive=300:5:5 retry="5 5 300 +" This is now happening at regular intervals. When a consumer replication gets stuck, only a service restart seems to restart replication. ex: ldap-replica-1:1636 # requesting: contextCSN contextCSN: 20241212135921.652395Z#000000#000#000000 ldap-replica-1:2636 # requesting: contextCSN contextCSN: 20241220010002.746041Z#000000#000#000000 You can see the replica on port 1636 CSN is stuck at 20241212135921. Any thoughts? Thanks, -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

Replication Specifics and Clarification
by michael.miceli88＠gmail.com 19 Dec '24

19 Dec '24

Hi, this is my first post to this mailing list, so I apologize if this is in the wrong location. I have recently started replicating our openLdap database and as part of that I combed through the admin guide to get a better understanding. I believe I have a decent grasp on replication now, but I had a few clarifying questions to ensure I understand. 1. Firstly and least importantly, how is "present" in "present phase" pronounced? Is it present as a noun, e.g. these are things that are present in the database, or is it present like a verb, e.g. I'm presenting all the things in the database? 2. Besides not needing to send the entire object in the delete phase, is it true that delta-syncrRepl provides an additional benefit of having a persisted session log store, e.g. the session store can survive an openLdap reboot? I didn't see that explicitly mentioned in the admin guide, but it would seem to be to be true. Is it true? 3. Does having a session log configured make sense if delta-syncrepl is being used? I saw a non-authoritative guides saying it's nice to have just in case a fallback to syncrepl happens, but the admin guide doesn't do this anywhere, nor does it make sense to me since even if a consumer provides a stale session cookie, a present phase must occur regardless of a session log. 4. I found in a non-authoritative document online saying during the refresh stage, that either present or delete or both phases can occur. In what situation would both a present and a delete phase occur? Or is that document wrong? 5. Does the phrase "delete phase" feel confusingly named? I spent significant time trying to figure out how data would be synchronized when a non-stale cookie was provided by the consumer since I assumed the delete phase only handled deletes. It wasn't until I read this paragraph carefully in the admin guide. In fact, no where in the admin guide can I find explicit mention that adds occur in the delete phase as well. However, it can be inferred in the last sentence of the following quote. > The transmission of the updated entries in the delete phase is the same as in the present phase. The provider sends all the requested attributes of the entries updated within the search scope since the last synchronization to the consumer. In the delete phase, however, the provider sends a delete message for each entry deleted from the search scope, instead of sending present messages. The delete message consists only of the name of the entry and the synchronization control representing state delete. The new consumer copy can be determined by adding, modifying, and removing entries according to the synchronization control attached to the SearchResultEntry message.

3 3

Problem getting slapd-meta to work
by cyril＠stoll.info 18 Dec '24

18 Dec '24

Hi there Sorry for the long post however I aim to provide as much information as possible to help pinpoint the issue. Also sorry for any wrong wording as I am still a bit overwhelmed with OpenLDAP and struggle to understand everything I need. From my predecessor I inherited an OpenLDAP 2.4.x cluster running on RHEL 7. My job is to migrate this cluster to OpenLDAP 2.6.x on RHEL 8. The cluster consists of two provider and four consumer servers. The old cluster was based on self-compiled original OpenLDAP binaries. For the new cluster I am using the LTB version of OpenLDAP, currently with version 2.6.8. I also switched from HDB to MDB with the new cluster and am using Let's Encrypt instead of DigiCert certificates and upped the TLS version from 1.0 to 1.2. And for the default password hashing algorhythm I switched from SSHA to ARGON2. So there are lots of changes that might potentially influence the meta databases though I did not see anything that suggests this. The synchronisation of the normal databases between the provider servers and to the consumer servers is working fine. My problem is with the meta databases I try to build using slapd-meta. They are only needed on the consumer servers. Unfortunately the meta databases do not seem to be created or are not working as expected. On the old cluster I can ldapsearch in the meta databases and they show up as trees when connecting with Apache Directory Studio. On the new cluster I am setting up I don't see those meta trees in Apache Directory Studio and ldapsearches don't return any results. Furthermore slapcat on those databases returns the message "slapcat: database doesn't support necessary operations." The meta trees don't query external servers but suffixmassage locally present sub-trees. From what I've read this could also be accomplished with slapd-relay but the man page states that it is experimental. That is why I am trying the same way my predecessor did using slapd-meta. I temporarily set the loglevel to 4094 but even then did not see any hint on what goes wrong with those meta databases. By the way, when I do set the loglevel so high I can no longer connect using Apache Directory Studio, but that is not the issue I'm concerned about. Neither the documentation, nor the slapd-meta man page, nor the very few tutorials/stackexchange-posts/mailinglist-posts I found online about meta-back helped me in solving this issue. That is why I hope someone on this mailinglist can spot an issue in my configuration. Or point me to other resources/tutorials or share some debugging advice. For the purpose of sharing the configuration I omitted all the schemata and some of the ACLs. Also I removed the linebreaks so what belongs together is all on one line. Lastly I redacted any sensitive information. It is attached as a text/ldif file. Thanks a lot in advance and let me know if I need to share further information such as log entries etc. Best regards, Cyril

3 2

Replication Issue with OpenLDAP 2.6.3
by mridumit＠amdocs.com 18 Dec '24

18 Dec '24

Hi I am very new to OpenLDAP, and we have a multi master configuration with us and our replication is not working. The error we get in log file is mainly : slap_client_connect: URI=<provider url> DN="cn=<sample value>,dc=<sample value>,dc=<sample value>" ldap_sasl_bind_s failed (-1). Attaching below logs after starting slapd service , Could you please help us ? Oct 16 14:15:47 <our ldap host> slapd[853101]: @(#) $OpenLDAP: slapd 2.6.3 (Nov 15 2023 00:00:00) $#012#011openldap Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 11 (TLSProtocolMin 3.3) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 12 (TLSCertificateFile <path to crt file>) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 13 (TLSCertificateKeyFile <path to key file file>) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 14 (TLSCipherSuite ECDHE-RSA-AES256-SHA) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 17 (disallow bind_anon) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 19 (require bind) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 21 (security simple_bind=128) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 23 (serverID 001) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 23: SID=0x001 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 25 (moduleload syncprov) Oct 16 14:15:47 <our ldap host> slapd[853101]: loaded module syncprov Oct 16 14:15:47 <our ldap host> slapd[853101]: module syncprov: null module registered Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 28 (database config) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 29 (rootdn cn=admin,cn=config) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnPrettyNormal: <cn=admin,cn=config> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnPrettyNormal: <cn=admin,cn=config>, <cn=admin,cn=config> Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 30 (rootpw ***) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 33 (database monitor) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnPrettyNormal: <cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnPrettyNormal: <cn=Monitor>, <cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 36 (database mdb) Oct 16 14:15:47 <our ldap host> slapd[853101]: mdb_db_init: Initializing mdb database Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 37 (suffix dc=<sample value>,dc=com) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnPrettyNormal: <dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnPrettyNormal: <dc=<sample value>,dc=com>, <dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 38 (rootdn cn=Manager,dc=<sample value>,dc=com) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnPrettyNormal: <cn=Manager,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnPrettyNormal: <cn=Manager,dc=<sample value>,dc=com>, <cn=manager,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 39 (rootpw ***) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 40 (directory /home/ldap) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 49 (syncrepl ***) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnNormalize: <cn=<sample value>,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnNormalize: <cn=<sample value>,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnNormalize: <dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnNormalize: <dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: str2filter "(objectclass=*)" Oct 16 14:15:47 <our ldap host> slapd[853101]: begin get_filter Oct 16 14:15:47 <our ldap host> slapd[853101]: PRESENT Oct 16 14:15:47 <our ldap host> slapd[853101]: end get_filter 0 Oct 16 14:15:47 <our ldap host> slapd[853101]: Config: ** successfully added syncrepl rid=001 "<provider url>" Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 51 (mirrormode TRUE) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 52 (multiprovider on) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 55 (index entryCSN eq) Oct 16 14:15:47 <our ldap host> slapd[853101]: index entryCSN 0x0004 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 56 (index entryUUID eq ) Oct 16 14:15:47 <our ldap host> slapd[853101]: index entryUUID 0x0004 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 58 (index objectClass eq) Oct 16 14:15:47 <our ldap host> slapd[853101]: index objectClass 0x0004 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 59 (index ps eq) Oct 16 14:15:47 <our ldap host> slapd[853101]: index ps 0x0004 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 60 (index <sample value>-safe-id eq) Oct 16 14:15:47 <our ldap host> slapd[853101]: index <sample value>--id 0x0004 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 61 (checkpoint 128 15) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 64 (overlay syncprov) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 66 (syncprov-checkpoint 100 10) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 72 (limits dn.exact=cn=<sample value>,dc=<sample value>,dc=com size=unlimited time=unlimited) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnNormalize: <cn=<sample value>,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnNormalize: <cn=<sample value>,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnNormalize: <cn=Subschema> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnNormalize: <cn=subschema> Oct 16 14:15:47 <our ldap host> slapd[853103]: slapd startup: initiated. Oct 16 14:15:47 <our ldap host> slapd[853103]: backend_startup_one: starting "cn=config" Oct 16 14:15:47 <our ldap host> slapd[853103]: config_back_db_open Oct 16 14:15:47 <our ldap host> slapd[853103]: config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context Oct 16 14:15:47 <our ldap host> slapd[853103]: config_back_db_open: No explicit ACL for back-config configured. Using hardcoded default Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "cn=config" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.895827Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "cn=module{0}" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.896054Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "cn=schema" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.897011Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn={0}core> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn={0}core> Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "cn={0}core" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.899435Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn={1}> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn={1}> Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "cn={1}" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.903375Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "olcDatabase={-1}frontend" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.903549Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "olcDatabase={0}config" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.903679Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "olcDatabase={1}monitor" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.903828Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "olcDatabase={2}mdb" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.904066Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "olcOverlay={0}syncprov" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.904212Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: backend_startup_one: starting "cn=Monitor" Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Backends> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Backends> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backends> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backends> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Connections> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Connections> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Connections> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=connections> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Databases> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Databases> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Databases> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=databases> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Listeners> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Listeners> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listeners> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listeners> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Log> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Log> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Log> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=log> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Operations> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Operations> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Operations> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=operations> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Overlays> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Overlays> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlays> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlays> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=SASL> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=SASL> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=SASL> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=sasl> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Statistics> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Statistics> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Statistics> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=statistics> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Threads> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Threads> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Threads> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=threads> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Time> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Time> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Time> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=time> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=TLS> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=TLS> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=TLS> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=tls> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Waiters> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Waiters> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Waiters> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=waiters> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 0,cn=Databases,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 0,cn=databases,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 1,cn=Databases,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 1,cn=databases,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 3> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 3> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 4> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 4> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Max File Descriptors> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=max file descriptors> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Total> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=total> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Current> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=current> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Frontend> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=frontend> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 0,cn=Backends,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 0,cn=backends,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 2,cn=Backends,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 2,cn=backends,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 1,cn=Overlays,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 1,cn=overlays,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 3,cn=Backends,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 3,cn=backends,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 1,cn=Overlays,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 1,cn=overlays,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listener 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listener 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listener 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listener 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listener 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listener 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listener 3> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listener 3> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listener 4> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listener 4> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Bind> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=bind> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Unbind> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=unbind> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Search> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=search> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Compare> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=compare> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Modify> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=modify> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Modrdn> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=modrdn> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Add> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=add> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Delete> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=delete> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Abandon> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=abandon> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Extended> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=extended> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 2,cn=Databases,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 2,cn=databases,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Bytes> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=bytes> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=PDU> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=pdu> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Entries> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=entries> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Referrals> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=referrals> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Max> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=max> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Max Pending> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=max pending> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Open> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=open> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Starting> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=starting> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Active> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=active> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Pending> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=pending> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backload> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backload> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=State> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=state> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Runqueue> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=runqueue> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Tasklist> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=tasklist> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Start> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=start> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Current> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=current> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Uptime> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=uptime> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Read> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=read> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Write> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=write> Oct 16 14:15:47 <our ldap host> slapd[853103]: backend_startup_one: starting "dc=<sample value>,dc=com" Oct 16 14:15:47 <our ldap host> slapd[853103]: mdb_db_open: "dc=<sample value>,dc=com" Oct 16 14:15:47 <our ldap host> slapd[853103]: mdb_db_open: database "dc=<sample value>,dc=com": dbenv_open(/home/ldap). Oct 16 14:15:47 <our ldap host> slapd[853103]: syncprov_db_open: starting syncprov for suffix dc=<sample value>,dc=com Oct 16 14:15:47 <our ldap host> slapd[853103]: => mdb_entry_get: ndn: "dc=<sample value>,dc=com" Oct 16 14:15:47 <our ldap host> slapd[853103]: => mdb_entry_get: oc: "(null)", at: "contextCSN" Oct 16 14:15:47 <our ldap host> slapd[853103]: mdb_dn2entry("dc=<sample value>,dc=com") Oct 16 14:15:47 <our ldap host> slapd[853103]: => mdb_dn2id("dc=<sample value>,dc=com") Oct 16 14:15:47 <our ldap host> slapd[853103]: <= mdb_dn2id: got id=0x1 Oct 16 14:15:47 <our ldap host> slapd[853103]: => mdb_entry_decode: Oct 16 14:15:47 <our ldap host> slapd[853103]: <= mdb_entry_decode Oct 16 14:15:47 <our ldap host> slapd[853103]: => mdb_entry_get: found entry: "dc=<sample value>,dc=com" Oct 16 14:15:47 <our ldap host> slapd[853103]: mdb_entry_get: rc=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: slapd starting Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 4r listener=(nil) Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 7r listener=0x5612300dd830 Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 8r listener=0x5612300dd920 Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 9r listener=0x5612300ddad0 Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 10r listener=0x5612300ddbc0 Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 11r listener=0x5612300ddd10 Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: activity on 1 descriptor Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: activity on: Oct 16 14:15:47 <our ldap host> slapd[853103]: Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Consumer 001> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=consumer 001> Oct 16 14:15:47 <our ldap host> slapd[853103]: =>do_syncrepl rid=001 Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_client_connect: URI=<provider url> DN="cn=<sample value>,dc=<sample value>,dc=com" ldap_sasl_bind_s failed (-1) Oct 16 14:15:47 <our ldap host> slapd[853103]: do_syncrepl: rid=001 rc -1 retrying (4 retries left) Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: activity on 1 descriptor Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: activity on: Oct 16 14:15:47 <our ldap host> slapd[853103]: Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: =>do_syncrepl rid=001 Oct 16 14:15:52 <our ldap host> slapd[853103]: slap_client_connect: URI=<provider url> DN="cn=<sample value>,dc=<sample value>,dc=com" ldap_sasl_bind_s failed (-1) Oct 16 14:15:52 <our ldap host> slapd[853103]: do_syncrepl: rid=001 rc -1 retrying (3 retries left) Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: activity on 1 descriptor Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: activity on: Oct 16 14:15:52 <our ldap host> slapd[853103]: Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: =>do_syncrepl rid=001 Oct 16 14:15:57 <our ldap host> slapd[853103]: slap_client_connect: URI=<provider url> DN="cn=<sample value>,dc=<sample value>,dc=com" ldap_sasl_bind_s failed (-1) Oct 16 14:15:57 <our ldap host> slapd[853103]: do_syncrepl: rid=001 rc -1 retrying (2 retries left) Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: activity on 1 descriptor

4 9

Meta backends as Failover for replication
by Compy Ulix 16 Dec '24

16 Dec '24

Hello, I have 2 openldap backends with replication configured in mirror mode. Can I use a third openLDAP with the slapd-meta backend as failover system? Is it a reliable solution? Does anyone have a feedback on this kind of solution ? Thanks you for your answer, Franck

2 1

LDIF conversion
by duttaa＠hotmail.com 13 Dec '24

13 Dec '24

Hi, I want to build an application using Java and C++ to convert LDAP responses (sub tree search, tree with multi level hierarchy) into LDIF file. Are there any open source libraries which can be used for this use case. Thanks Abhijit

3 3

ECDSA certs TLS init failed for slapd
by jehan Procaccia 11 Dec '24

11 Dec '24

Hi we finally moved from RSA signed certificate to ECDSA signature as it is the defaults nowdays (https://community.letsencrypt.org/t/ecdsa-certificates-by-default-and-other…) unfortunatly , slapd doesnt like those certificates : / slapd[641]: @(#) $OpenLDAP: slapd 2.4.44 (Feb 23 2022 17:11:27) $/ /mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/serve/ / slapd[641]: main: TLS init def ctx failed: -1/ / slapd[641]: slapd stopped./ This happened on a server running old openldap 2.4 (openldap-2.4.44-25.el7_9.x86_64) is there a directive to allow ECDSA certs in slapd (2.4) ? is it natively supported in up2date versions of openldap 2.5 / 2.6 ? is there a special directive in certbot to request slapd certs ? thanks .

4 5

Re: Meaning of "slapd[2606]: ppolicy_bind: Setting warning for password expiry for ... = ... seconds"
by Ondřej Kuzník 10 Dec '24

10 Dec '24

On Tue, Dec 10, 2024 at 07:23:55AM +0000, Windl, Ulrich wrote: >> It seems you are running with a loglevel that includes "trace", so I >> will repeat what I said before: >> >> "If you set your log level to trace, you will get logs that document >> decisions made during the tool/server operation. As a user, that is what >> I want out of a level with a name like that." > > The loglevel setup is this: > olcLogLevel: config > olcLogLevel: sync > olcLogLevel: none The message is clearly[0] emitted with level TRACE only, so either you're running a different slapd or these are not the logging options that are actually in use. Maybe -d <level> (debug level setting) and you're referring to the stderr output? [0]. https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/over… -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: [EXT] Re: Meaning of "slapd[2606]: ppolicy_bind: Setting warning for password expiry for ... = ... seconds"
by Ondřej Kuzník 09 Dec '24

09 Dec '24

On Wed, Dec 04, 2024 at 10:47:24AM +0000, Windl, Ulrich wrote: >> Not sure what makes you think this is even a bug? > > It's the number of messages: > (Uptime 56 days) > # journalctl -b |grep 'Setting warning for password expiry' | wc -l > 72697 It seems you are running with a loglevel that includes "trace", so I will repeat what I said before: "If you set your log level to trace, you will get logs that document decisions made during the tool/server operation. As a user, that is what I want out of a level with a name like that." Yes, that means you will have plenty of things logged that might not interest you under most circumstances. If it bothers you, set a reasonable loglevel like stats and sync. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

PP/expiry issues with Ubuntu22 and RH6
by Felix Natter 07 Dec '24

07 Dec '24

Dear openldap experts, the company I work for recently migrated to Ubuntu 22.04, and we use openldap with password policies and password expiry (once per year), with no changes to OpenLDAP config. However, we also use a scientific linux 6 (SL6, ~RH6) compile machine for backwards compatibility purposes (also using OpenLDAP). Now what happens is: - user ldaptestuser1's password expires - she/he changes her/his password on Ubuntu (problem 1: no PP checking, maybe due to cache_credentials = yes in /etc/sssd/sssd.conf) - SL6 (host X) does not know about that (problem 2: pwd checking on SL6 _always_ yields a Constraint violation, so user ldaptestuser1 cannot login there): ldaptestuser1@X's password: You are required to change your password immediately (password aged) You are required to change your LDAP password immediately. Last login: DATE from Y WARNING: Your password has expired. You must change your password now and login again! Changing password for user ldaptestuser1. Enter login(LDAP) password: New password: Retype new password: LDAP password information update failed: Constraint violation Password fails quality checking policy passwd: Authentication token manipulation error Connection to X closed. I cannot see any relevant error in the server (sys)log (with stats logging). Which log level shall I enable? - is there a workaround / fix for problem 1? - Regarding problem 2: shall I disable password expiry (shadow extension)? Many Thanks and Best Regards! -- Felix Natter

2 2

make the attribute mail SINGLE-VALUE
by A. Schulze 05 Dec '24

05 Dec '24

Hello, I'm planing a schema to store data (mostly mail addresses) in OpenLDAP. one (soft) requirement: the mail address should be a single value. secondary addresses goes in an other attribute which allow multiple values. The only way I found for now is to copy the definition of 'mail' in core.schema [1] and write attributetype ( <my oid> NAME ( 'mail-sv' ) DESC 'RFC1274: RFC822 Mailbox (copy from core.schema, but SINGLE-VALUE)' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE ) This would work but it's not convenient: Everybody expect a mail address in a attribute named "mail", not "mail-sv" Are there other options to fulfill the requirement or makes the requirement at all no sense? I appreciate any comments. Andreas [1] https://github.com/openldap/openldap/blob/master/servers/slapd/schema/core.…

2 1

Meaning of "slapd[2606]: ppolicy_bind: Setting warning for password expiry for ... = ... seconds"
by Windl, Ulrich 04 Dec '24

04 Dec '24

Hi! Me again after 10 years with basically the same question (https://www.openldap.org/lists/openldap-technical/201411/msg00044.html): What is the meaning of messages like these (note the number of messages created): Nov 19 11:53:47 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040879 seconds Nov 19 11:53:50 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040876 seconds Nov 19 11:53:52 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040874 seconds Nov 19 11:53:54 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040872 seconds Nov 19 11:53:57 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040869 seconds Nov 19 11:53:59 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040867 seconds Nov 19 11:57:41 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040645 seconds Nov 19 11:57:44 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040642 seconds Nov 19 11:58:01 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040625 seconds ... Nov 19 13:18:35 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035791 seconds Nov 19 13:18:39 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035787 seconds Nov 19 13:18:41 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035785 seconds Nov 19 13:18:44 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035782 seconds Nov 19 13:18:46 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035780 seconds Nov 19 13:18:48 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035778 seconds Nov 19 13:18:51 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035775 seconds Nov 19 13:18:54 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035772 seconds Nov 19 13:18:56 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035770 seconds Nov 19 13:18:59 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035767 seconds Nov 19 13:19:02 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035764 seconds So the server logs such an entry every few seconds. I might guess that the user tried to authenticate every few seconds (for whatever reason). But what I wonder most: The LDAP server does not seed to "set" the password expiration; it just has to check the value. And for the latter I see no need to log it in syslog. It seems the number is the number of seconds until the password actually expired. So is that a (historic) bug? And yes, I'm still running a historic 2.4 version of OpenLDAP, so no need to tell me that it's quite old. (Despite of that we really intend to upgrade, but the more persons involved, the loger it takes...) Kind regards, Ulrich

2 2

autoca Attribute olcAutoCAserverClass
by Stefan Kania 29 Nov '24

29 Nov '24

Hello, I try to add the autoca overlay with the following ldif: -------------- dn: olcOverlay=autoca,olcDatabase={2}mdb,cn=config objectClass: olcAutoCAConfig objectClass: olcOverlayConfig olcOverlay: autoca olcAutoCADays: 3652 olcAutoCAKeybits: 4096 olcAutoCAserverClass: ipHost olcAutoCAserverDays: 1826 olcAutoCAserverKeybits: 4096 olcAutoCAuserClass: person olcAutoCAuserDays: 365 olcAutoCAuserKeybits: 4096 -------------- ldapadd gives me: adding new entry "olcOverlay=autoca,olcDatabase={2}mdb,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcAutoCAserverClass> handler exited with 1 If I remove the attribute from my ldif, it works. What is wrong with the olcAutoCAserverClass attribute in my ldif? I try to look it up in the admin handbook but I could not find anything. I looked in the source code and found: ------------ { "serverClass", "objectclass", 2, 2, 0, ARG_STRING|ARG_MAGIC|ACA_SRVCLASS, autoca_cf, "( OLcfgOvAt:22.2 NAME 'olcAutoCAserverClass' " "DESC 'ObjectClass of server entries' " "EQUALITY caseIgnoreMatch " "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, ------------ For me it looks the same as the attribute olcAutoCAuserclass. ------------- { "userClass", "objectclass", 2, 2, 0, ARG_STRING|ARG_MAGIC|ACA_USRCLASS, autoca_cf, "( OLcfgOvAt:22.1 NAME 'olcAutoCAuserClass' " "DESC 'ObjectClass of user entries' " "EQUALITY caseIgnoreMatch " "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, ------------- Stefan

2 2

mdb_tassert(txn, rc == 0) fails in mdb_page_dirty()
by Christian Wendt 29 Nov '24

29 Nov '24

Hi, I have a system that fails to write to its lmdb based database. There is an assertion triggered from within mdb_txn_commit() inside mdb_page_dirty(). Further investigation shows that there is a duplicate page in a freelist entry: ~# mdb_stat -narrfff /home/skov/data/data.mdb Reader Table Status (no active readers) 0 stale readers cleared. (no active readers) Freelist Status Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 28 Transaction 128121111, 3 pages, maxspan 1 1281 1300 1468 Transaction 128121112, 6 pages, maxspan 1 [bad sequence] 229 229 569 1317 1444 1460 Transaction 128121113, 5 pages, maxspan 1 ... What could trigger such a duplicate entry and what could I try to do to figure out the root cause of the issue? Is there a recommended way of detecting or handling such errors at runtime? Thanks a lot for any pointers. Best regards, Christian Wendt

2 3

Client IP address in accesslog ?
by Benjamin Renard 21 Nov '24

21 Nov '24

Hi, I would like to know if there is a way to get the client's IP address in the events recorded by accesslog (at least during BINDs). I found traces of requests for this dating back to 2010, but I haven't been able to determine if it was ever implemented. 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

6 9

Technical account impersonation or not
by BECOT Jérôme 20 Nov '24

20 Nov '24

Hello all, We currently use two distinct accounts for chaining and replication purpose. We want to use a passwordless policy and we go for certificates. As we only own a single certificate per slave server, this means that we authenticate as a single user. We see two way to do things: * Either we just use one account (bound by olcAuthzRegexp rule) and merge ACLs to allow this account to read the directory for sync and write authentication attributes for chaining * Or we keep two accounts and use Proxy Auth to impersonate the other one I personnaly would go for the first one as I don't see any value to use another mechanism given that these are technical accounts that have only one purpose each, except having a distinct login in the logs. What would you advice ? I may have miss something intersting, any security issue, or maybe there is another way. Thank you ! Jerome

2 2

RE26 testing call (2.6.9) #1
by Quanah Gibson-Mount 19 Nov '24

19 Nov '24

This is the first testing call for OpenLDAP 2.6.9. 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.9 Engineering Fixed libldap TLS connection timeout handling (ITS#8047) Fixed libldap GnuTLS incompatible pointer type (ITS#10253) Fixed libldap OpenSSL set_ciphersuite error handling (ITS#10223) Fixed libldap to check for OpenSSL EVP_Digest* failure (ITS#10224) Fixed slapd cn=config disallowed modification of cn=schema (ITS#10256) Fixed slapd syncrepl assert during refresh at shutdown (ITS#10232) Fixed slapd syncrepl retry state during refreshDone (ITS#10234) Fixed slapd-ldap use of multi-precision add for op counters (ITS#10237) Fixed slapd-mdb idl intersection (ITS#10233) Fixed slapd-wt idl intersection (ITS#10233) Fixed slapo-memberof to omit dynamic values (ITS#10230) Fixed slapo-nestgroup leak in nestgroup_memberFilter (ITS#10249) Fixed slapo-translucent regression with subordinate databases (ITS#10248) Fixed slapo-translucent regression when requesting attributes (ITS#10272) Fixed slappw-argon2 defaults to be more secure (ITS#9827) Minor Cleanup ITS#10155 ITS#10218 ITS#10219 ITS#10227 ITS#10231 ITS#10235 ITS#10263 ITS#10264 Regards, Quanah

3 2

ACL on userPassword attribute on a relay database
by ptitoliv+openldap＠ptitoliv.net 18 Nov '24

18 Nov '24

Hello dear Openldap community, I'm writing you this email because I'm trying to create a configuration using relay backend + rvm and settings ACLs in the virtual database and I must admit I'm a little bit confused about all these components are working together. I actually have two databases: - The real one dc=ptitoliv,dc=net - The virtual one dc=example,dc=com I did a simple configuration using the RWM overlay and the rwm-suffixmassage directive. Everything seems to be okay except for the ACL. More precisely, my concern is about the ACL to apply in order to restrict the access to the userPassword attribute to the "virtual self" on the virtual database. My current status is the following : - If I don't put any ACL on the relay database, the userPassword attribute is readable by any authenticated user which is a thing I don't want - If I put the following ACL "to attrs=userPassword by self write by anonymous auth by * none" on the relay database nobody can read the userPassword including the virtual self. About the second point, if I understood correctly it's because the virtual binddn is mapped directly to the real one and the ACL tries to be resolved using the real binddn and not the virtual one like it is shown in the next trace. 673bb5e0.21d77b65 0x7f0d33dbf700 => access_allowed: read access to "uid=user,ou=people,dc=example,dc=com" "userPassword" requested 673bb5e0.21d78357 0x7f0d33dbf700 => acl_get: [1] attr userPassword 673bb5e0.21d79164 0x7f0d33dbf700 => acl_mask: access to entry "uid=user,ou=people,dc=example,dc=com", attr "userPassword" requested 673bb5e0.21d798c0 0x7f0d33dbf700 => acl_mask: to value by "uid=user,ou=people,dc=ptitoliv,dc=net", (=0) 673bb5e0.21d7bab8 0x7f0d33dbf700 <= check a_dn_pat: self 673bb5e0.21d7cc2c 0x7f0d33dbf700 <= check a_dn_pat: anonymous 673bb5e0.21d7d9d5 0x7f0d33dbf700 <= check a_dn_pat: * 673bb5e0.21d7e601 0x7f0d33dbf700 <= acl_mask: [3] applying none(=0) (stop) 673bb5e0.21d7f6df 0x7f0d33dbf700 <= acl_mask: [3] mask: none(=0) 673bb5e0.21d7fda4 0x7f0d33dbf700 => slap_access_allowed: read access denied by none(=0) So my question is that if it is possible to have an ACL on a virtual database in order to make the userPassword only readable by the logged user itself. Or is it just something that is not possible and if i want to access the userPassword attribute, it can be only done on the real database ? I tried to do some rewrite operation on the binddn but without any success 🙁 Thanks for you help ! Regards, Olivier Bonhomme

1 0

RE25 testing call (2.5.19) #1
by Quanah Gibson-Mount 18 Nov '24

18 Nov '24

This is the first testing call for OpenLDAP 2.5.19. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/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.5.19 Engineering Fixed libldap GnuTLS incompatible pointer type (ITS#10253) Fixed libldap OpenSSL set_ciphersuite error handling (ITS#10223) Fixed libldap to check for OpenSSL EVP_Digest* failure (ITS#10224) Fixed slapd syncrepl assert during refresh at shutdown (ITS#10232) Fixed slapd-ldap use of multi-precision add for op counters (ITS#10237) Fixed slapd-mdb idl intersection (ITS#10233) Fixed slapd-wt idl intersection (ITS#10233) Fixed slapo-translucent regression with subordinate databases (ITS#10248) Fixed slapo-translucent regression when requesting attributes (ITS#10272) Fixed slappw-argon2 defaults to be more secure (ITS#9827) Minor Cleanup ITS#10155 ITS#10219 ITS#10221 ITS#10227 ITS#10231 ITS#10264 Regards, Quanah

1 0

Master crashing when restarting Replicas
by Suresh Veliveli 14 Nov '24

14 Nov '24

Hello, We have a single master with multiple replicas. Sometimes when replicas are restarted the master is crashing. Openldap version - 2.6.7 Backend Database - mdb (gdb) core core.slapd.3003.d7d7f844eec3408ba1dfc465ee8306a1.16323.1731327494000000 [New LWP 16333] [New LWP 16741] [New LWP 16327] [New LWP 16328] [New LWP 16329] [New LWP 16360] [New LWP 16325] [New LWP 17359] [New LWP 16794] [New LWP 16323] [New LWP 16324] [New LWP 17765] [New LWP 16998] [New LWP 16334] [New LWP 17766] [New LWP 16999] [New LWP 16361] [New LWP 16795] Core was generated by `/var/services/openldap/libexec/slapd -h ldap://*:389 ldaps://*:636 -f /var/serv'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000004389bb in ?? () [Current thread is 1 (LWP 16333)] (gdb) bt full #0 0x00000000004389bb in ?? () No symbol table info available. #1 0x0000000000000000 in ?? () No symbol table info available. (gdb) q Nov 11 07:18:14 aaa-prod-master-1 kernel: slapd[16333]: segfault at 18 ip 00000000004389bb sp 00007f79ccaf8650 error 4 in slapd[419000+12d000] likely on CPU 1 (core 1, socket 0) Nov 11 07:18:14 aaa-prod-master-1 kernel: Code: 89 e8 b9 0e 00 00 00 4c 89 e7 f3 48 ab 48 89 e8 48 8b ad 90 01 00 00 8b 90 c0 00 00 00 85 d2 75 35 48 8b 10 4c 89 e6 4c 89 f7 <8b> 52 18 c7 80 c0 00 00 00 01 00 00 00 48 8b 05 91 82 1b 00 89 94 Nov 11 07:18:14 aaa-prod-master-1 systemd[1]: Created slice Slice /system/systemd-coredump. Nov 11 07:18:14 aaa-prod-master-1 systemd[1]: Started Process Core Dump (PID 349553/UID 0). Nov 11 07:18:17 aaa-prod-master-1 systemd-coredump[349554]: Process 16323 (slapd) of user 3003 dumped core.#012#012Stack trace of thread 16333:#012#0 0x00000000004389bb n/a (slapd + 0x389bb)#012#1 0x000000000043a6f4 connection_closing (slapd + 0x3a6f4)#012#2 0x000000000043b5ce n/a (slapd + 0x3b5ce)#012#3 0x00007f9340de7d1a ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43d1a)#012#4 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#5 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16741:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16327:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16328:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16329:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16360:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16325:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 17359:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16794:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f9340488fa0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x88fa0)#012#2 0x00007f9340de7db7 ldap_int_thread_pool_wrapper (libldap.so.2 + 0x43db7)#012#3 0x00007f9340489c02 start_thread (libc.so.6 + 0x89c02)#012#4 0x00007f934050ec40 __clone3 (libc.so.6 + 0x10ec40)#012#012Stack trace of thread 16323:#012#0 0x00007f934048679a __futex_abstimed_wait_common (libc.so.6 + 0x8679a)#012#1 0x00007f934048b6d3 __pthread_clockjoin_ex (libc.so.6 + 0x8b6d3)#012#2 0x00000000004381ca slapd_daemon (slapd + 0x381ca)#012#3 0x000000000041e47f main (slapd + 0x1e47f)#012#4 0x00007f9340429590 __libc_start_call_main (libc.so.6 + 0x29590)#012#5 0x00007f9340429640 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x29640)#012#6 0x000000000041e855 _start (slapd + 0x1e855Nov 11 07:18:17 aaa-prod-master-1 systemd[1]: systemd-coredump(a)0-349553-0.service: Deactivated successfully. Nov 11 07:18:17 aaa-prod-master-1 systemd[1]: systemd-coredump(a)0-349553-0.service: Consumed 3.288s CPU time. Nov 11 07:18:18 aaa-prod-master-1 systemd[1]: slapd.master.service: Main process exited, code=dumped, status=11/SEGV Nov 11 07:18:18 aaa-prod-master-1 systemd[1]: slapd.master.service: Failed with result 'core-dump'. Nov 11 07:18:18 aaa-prod-master-1 systemd[1]: slapd.master.service: Consumed 14h 31min 2.574s CPU time. Any thoughts? Thanks, -- Suresh Veliveli Sr. Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration

3 3

Trouble with UID Filter in OpenLDAP (slapd meta): Missing Schema or Configuration Issue?
by tmp 2810 07 Nov '24

07 Nov '24

Hi! I think I'm finally able to configure slapd with a meta backend, but I'm experiencing a strange issue when I perform a search with ldapsearch and try to filter by uid. If I use "uid=user" it doesn't work, but if I use "cn=user" it does work, and I need the searches to be by uid. I understand this could be related to the schemas I’m loading, but I thought uid was a standard attribute already loaded in core.schema. Just in case, I'm using Debian 12, and these are the schemas available: collective.schema corba.schema core.schema cosine.schema dsee.schema duaconf.schema dyngroup.schema inetorgperson.schema java.schema misc.schema msuser.schema namedobject.schema nis.schema openldap.schema pmi.schema These are the schemas I’m using to test: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/nis.schema And as a detail, I find that this part referring to uid (I might be mistaken) is commented out: attributetype ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) DESC 'RFC1274: user identifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) but when I try to uncomment it, I get the error: 672b6c65.324d8768 0x7febb561d200 /etc/ldap/schema/core.schema: line 564 attributetype: Duplicate attributeType: "0.9.2342.19200300.100.1.1" Just in case, here’s my configuration. Could it be that something is missing so that a user can log in against this slapd? Since my applications search by uid (some are very legacy and I can't modify them), I'm unable to verify if everything is correctly set up to make a connection. The only indication that it’s working is that I can retrieve all users with ldapsearch and their attributes, but I can't filter by uid. ########################################## include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/nis.schema modulepath /usr/lib/ldap moduleload back_meta.la moduleload back_ldap.la database meta suffix "dc=proxy" rootdn "cn=admin,dc=proxy" rootpw 1234 ## example.com uri "ldaps://ldap.google.com/dc=proxy" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on rebind-as-user yes chase-referrals yes idassert-bind bindmethod=simple binddn="uid=ldap,ou=Users,dc=example,dc=com" credentials="secret-password" tls_reqcert=demand tls_reqsan=demand tls_cert=/root/ldapcerts/ldap.crt tls_key=/root/ldapcerts/ldap.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem idassert-authzFrom "*" ############################### Thanks for all the help!

3 2

Re: Issue with slapd and Google LDAP Integration (lowercase user)
by tmp 2810 05 Nov '24

05 Nov '24

Thats my actual config and the message on the logs is : Unauhtenticated ================================================ uri "ldaps://ldap.google.com/dc=proxy" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_reqcert=demand tls_reqsan=demand tls_cert=/root/ldapcerts/google_cert.crt tls_key=/root/ldapcerts/google_cert.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem ================================================ I've actually been trying all kinds of configurations for the last 2 weeks. Is there a chance that this doesn't work with Google's LDAP? I can't find a single example on the entire internet of someone who has managed to do this whit the LDAP of google. El mar, 5 nov 2024 a las 12:51, Quanah Gibson-Mount (<quanah(a)fast-mail.org>) escribió: > > > --On Monday, November 4, 2024 8:29 PM -0300 tmp 2810 <t2810mp(a)gmail.com> > wrote: > > > Once again, I apologize; I ran so many tests that I accidentally copied > > one where the binddn was incorrect. > > > > The target looks more like this: > > > >## example.com > > uri "ldaps://ldap.google.com/dc=proxy" > > suffixmassage "dc=proxy" "dc=example,dc=com" > > lastmod off > > readonly on > > idassert-bind bindmethod=simple > > binddn="cn=ChiwewDaw" > > cn, is by definition, case insensitive. If Google LDAP is forcing case > sensitivity in this attribute, it is gross violation of the LDAP RFCs. > However, having had to interface with it in the past, I don't believe that > is the case. I would generally suspect that this is not the full DN of > the > user. > > > idassert-bind bindmethod=sasl > > saslmech=EXTERNAL > > tls_reqcert=demand > > tls_reqsan=demand > > starttls=critical > > > This is not sufficient, please read the man page: > > > idassert-bind bindmethod=none|simple|sasl [binddn=<simple > DN>] > [credentials=<simple password>] [saslmech=<SASL > mech>] > [secprops=<properties>] [realm=<realm>] > [authcId=<authentication > ID>] [authzId=<authorization ID>] > [authz={native|proxyauthz}] > [mode=<mode>] [flags=<flags>] > [starttls=no|yes|critical] > [tls_cert=<file>] [tls_key=<file>] > [tls_cacert=<file>] > [tls_cacertdir=<path>] > [tls_reqcert=never|allow|try|demand] > [tls_reqsan=never|allow|try|demand] > [tls_cipher_suite=<ciphers>] > [tls_ecname=<names>] > [tls_protocol_min=<version>] > [tls_crlcheck=none|peer|all] > > > You *must* specify tls_cert, tls_key, and tls_cacert as a part of > idassert-bind as it provides the TLS identity to bind as. In your > configuration for simple bind, tls_cert and tls_key are unnecessary as > you're not doing SASL/EXTERNAL binds. > > --Quanah > > > >

3 2

Re: Issue with slapd and Google LDAP Integration (lowercase user)
by tmp 2810 05 Nov '24

05 Nov '24

Yes, indeed the way was to use a simple bind of an email user with admin permissions in Google, and with that, I was able to do the bind. Thank you! El mar, 5 nov 2024 a las 13:16, Quanah Gibson-Mount (<quanah(a)fast-mail.org>) escribió: > > > --On Tuesday, November 5, 2024 1:06 PM -0300 tmp 2810 <t2810mp(a)gmail.com> > wrote: > > > I've actually been trying all kinds of configurations for the last 2 > > weeks. Is there a chance that this doesn't work with Google's LDAP? I > > can't find a single example on the entire internet of someone who has > > managed to do this whit the LDAP of google. > > I've no idea if Google's LDAP supports SASL/EXTERNAL. You'd have to ask > Google. We used simple binds to Google w/o issue at a prior job I worked > at to sync data from OpenLDAP to it. > > --Quanah > > > >

1 0

Re: Issue with slapd and Google LDAP Integration (lowercase user)
by tmp 2810 05 Nov '24

05 Nov '24

Thank you for the response! No, no... these are example data that I put together to understand how Google users are structured and the issue that uppercase letters are causing me. In the Google LDAP audit, I see that the user fails and appears in lowercase. Once again, I apologize; I ran so many tests that I accidentally copied one where the binddn was incorrect. The target looks more like this: ## example.com uri "ldaps://ldap.google.com/dc=proxy" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on idassert-bind bindmethod=simple binddn="cn=ChiwewDaw" credentials="password-fake" tls_reqcert=demand tls_reqsan=demand starttls=critical tls_cert=/root/ldapcerts/ldap_cert.crt tls_key=/root/ldapcerts/ldap_cert.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem if i use: idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_reqcert=demand tls_reqsan=demand starttls=critical i have the error : "Unauthenticated"

2 1

Issue with slapd and Google LDAP Integration (lowercase user)
by tmp 2810 04 Nov '24

04 Nov '24

Hello everyone! I have been trying to configure slapd for a week to use it as a proxy for Google's LDAP service in order to connect some legacy applications. Since I have multiple domains in Google, I need to centralize all users into a common "dc." Everything is working well, but the problem is that, apparently, when connecting to Google, I am provided with a certificate that I download from the admin console. However, with that certificate alone, slapd cannot connect to the target. So, I generate some credentials from the Google LDAP admin and add them to the slapd configuration. The issue is that, for some reason, slapd converts the username to lowercase, and Google rejects it because it is case-sensitive. Is it possible to disable this function? (There is no way to create a user in Google that is only in lowercase) Here is my current slapd configuration: ################################################################ include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/nis.schema modulepath /usr/lib/ldap moduleload back_meta.la moduleload back_ldap.la database meta suffix "dc=proxy" rootdn "cn=admin,dc=proxy" rootpw 1234 ## example.com uri "ldap://172.25.3.127:2636/dc=proxy" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on idassert-bind bindmethod=simple binddn="ChiwewDaw" credentials="ASk0i9ejiosej9o303" tls_reqcert=demand tls_reqsan=demand starttls=critical tls_cert=/root/ldapcerts/ldap_cert.crt tls_key=/root/ldapcerts/ldap_cert.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem ################################################################## Thank you for your assistance! (ps: If anyone knows how to make it work using only the certificate, that would be great.)

2 1

Re: multi-master OpenLDAP with SASL/GSSAPI
by Travis Bean 04 Nov '24

04 Nov '24

On Tue, Jul 30, 2024 at 2:29 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Sunday, July 28, 2024 7:09 PM -0700 Travis Bean <tbean74(a)gmail.com> > wrote: > > > I developed a Bash script (https://launchpad.net/linuxha) to automate > > the installation and configuration of complex Linux software that is > > out of reach for most people. I want the syntax of this script to be > > perfect so I can use it as a teaching tool to educate people about > > Linux. > > > > If anyone on this mailing list is knowledgeable about multi-master > > OpenLDAP with SASL/GSSAPI authentication, please review the > > OpenLDAP/SASL/GSSAPI code that is part of my LinuxHA script and > > provide feedback. Thank you. > Just glancing at your script I see errors, such as: > > SASL_MECH GSSAPI PLAIN > > for ldap.conf. The man page clearly notes this takes a SINGLE mechanism. If ldap.conf(5) only supports one SASL mechanism for the SASL_MECH variable, then the man page at https://www.openldap.org/software/man.cgi?query=ldap.conf needs to be updated to clarify this. I originally configured the SASL_MECH variable for OpenLDAP's ldap.conf(5) the same way I configured the mech_list variable for Postfix's smtpd.conf and the auth_mechanisms variable for Dovecot's 10-auth.conf. I configured multiple SASL mechanisms for each of these variables for testing purposes. For a local area network, a system administrator has complete control over all the workstations and can make sure they all have Kerberos installed. For internet facing servers providing services to the wide area network (WAN), it makes sense to use a second SASL mechanism (something other than SASL/GSSAPI) in case any WAN devices do not have Kerberos installed, since a sysadmin may have no control over what is installed on WAN devices. I recently replaced libpam-ldap and libnss-ldap with sssd-ldap and sssd-krb5 for LinuxHA, since SSSD is a much better solution for identity and authentication. > Also, SASL/PLAIN is insecure and should never be used. Technically this is true. Even though when SASL/PLAIN is used in conjunction with Transport Layer Security, the credentials are encrypted. When ldap.conf(5) is installed on a server (as was the case when I was testing ldap.conf(5) on LinuxHA), using SASL/PLAIN is not insecure because it is only connected to a local socket on the local machine. > Another note is that SASL/GSASPI is extremely dependent on valid hostname > resolution. The pam ldap.conf seems unlikely to work (ldap://localhost for > the URI). When /etc/ldap.conf (the configuration file for PADL’s pam_ldap and nss_ldap modules) or /etc/ldap/ldap.conf (the configuration file for client applications such as ldapsearch, ldapadd, ldapmodify, and ldapdelete) is installed on a server rather than a workstation, you use "uri ldap://localhost", or "uri ldap://127.0.0.1", or better yet use LDAP over IPC mechanisms (LDAP over Inter-Process Communication) a.k.a. UNIX domain sockets (i.e., "uri ldapi:///"). See the following webpage for further details: https://datatracker.ietf.org/doc/html/draft-chu-ldap-ldapi-00 > I see so many things that are bad practice in this script in general I'm > not going to spend any more time reviewing it. I have tried very hard to make sure there are no “bad practices” incorporated into LinuxHA. From a security standpoint, I have attempted to design LinuxHA so it is one step ahead of standard security policies. Everytime Canonical releases a new version of Ubuntu Server, the configuration for LinuxHA has to be updated. I have tested LinuxHA on seven versions of Ubuntu Server thus far — from 12.04 to 24.04. Even though I try to go through all the software packages incorporated into LinuxHA everytime Canonical releases a new version of Ubuntu Server to see if any configuration file has changed and needs to be updated, it may take awhile to complete these updates. If you find any misconfiguration in LinuxHA, please submit a bug report: https://bugs.launchpad.net/linuxha/+filebug Kind regards, Travis Bean

3 2

Removing AutoCA overlay, objectClass, etc
by Brendan Kearney 29 Oct '24

29 Oct '24

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 8

Unnamed sub-databases in LMDB
by ruben.soh＠rutgers.edu 26 Oct '24

26 Oct '24

Background: I am trying to implement a fully dynamic connectivity algorithm, based on this paper (https://dl.acm.org/doi/10.1145/502090.502095), using LMDB as the backend. Other implementations use an in-memory binary search tree. I am currently working on trying to implement an Euler Tour Forest using LMDB. Essentially, an Euler Tour of an unbalanced tree is obtained by doing a DFS and assigning an increasing index every time we visit a node (https://en.m.wikipedia.org/wiki/Euler_tour_technique). An Euler Tour Tree is simply a balanced tree containing the euler tour index as the key and a pointer to the node as the value, so I plan to store each Euler Tour Tree using an LMDB database. Problem: I need an unlimited amount of sub-databases - my first thought was to use mdb_dbi_open, however, it seems like this doesn't scale well because a list of named sub-databases is stored in every transaction. In the talk about LMDB's functionality at CMU (https://www.youtube.com/watch?v=tEa5sAh-kVk) there is some reference to sub-databases, but from reading the code it seems like unnamed sub-databases are only used for sorted duplicate keys. Am I correct in thinking that I'm going to need to add some new code to support unnamed sub-databases, or is there some way to do it that I'm not recognizing? And if I do need to change things, where should I start? Ruben Soh

2 1

Error after OpenLDAP update from 2.4 to 2.5 - ppolicy schema
by sharbich＠t-online.de 21 Oct '24

21 Oct '24

Hello, unfortunately I missed the update version note for the schema ppolicy. After updating and restarting the slapd service, I can no longer delete the schema. I get the following error message: "root@dsme01:~# slapcat -n0 > config.ldif olcAttributeTypes: value #0 olcAttributeTypes: Duplicate attributeType: "1.3.6.1.4.1.42.2.27.8.1.1" config error processing cn={15}ppolicy,cn=schema,cn=config: olcAttributeTypes: Duplicate attributeType: "1.3.6.1.4.1.42.2.27.8.1.1" slapcat: bad configuration file!" What can I do now? Greetings from Stefan Harbich

3 2

Help me understand LMDB internals
by ruben.soh＠rutgers.edu 20 Oct '24

20 Oct '24

I am a student trying to understand the code for LMDB. One thing I am confused about - there is apparently no mutex for creating a reader transaction. In the function mdb_txn_renew0, which is called by mdb_txn_begin to create the transaction, I see that if we are creating a read-only transaction, we select a meta page without acquiring any mutex. Then, the meta page snapshotted in these lines (and accessed later in the function as well): /* Copy the DB info and flags */ memcpy(txn->mt_dbs, meta->mm_dbs, CORE_DBS * sizeof(MDB_db)); /* Moved to here to avoid a data race in read TXNs */ txn->mt_next_pgno = meta->mm_last_pg+1; What happens if a write transaction commits to the meta page while this copy is happening? Isn't it possible that the reader transaction will have copied an inconsistent view of the meta page? Sincerely, Ruben

2 1

Re: Replication issue during performance test with MMR configuration and LastBind enabled
by Falgon 16 Oct '24

16 Oct '24

Hello, I'm working on the same project as Meheni. Thanks for your answer, we'll try version 2.6 OpenLDAP using the lastbind-precision. However we have several questions for the current version we're using. Is this a known problem and referenced somewhere? (we haven't found it) Is it normal to find no replication error logs even in stats + sync mode? We ran some tests in sequential mode (300,000 accounts one after the other) and managed to reproduce the problem. -Denis Le mer. 11 oct. 2023 à 14:11, Quanah Gibson-Mount <quanah(a)fast-mail.org> a écrit : > > > --On Tuesday, October 10, 2023 9:30 PM +0200 Ziani Meheni > <mehani06(a)gmail.com> wrote: > > > > > > > Hello, we are working on a project and we've come across a problem with > > the replication after performance testing : > > You need to use OpenLDAP 2.6 and then set the: > > lastbind-precision > > value. I use 5 minutes. > > --Quanah >

4 8

Advice for upgrade from OpenLDAP 2.4 to 2.6?
by gsafcik+ldap＠gmail.com 15 Oct '24

15 Oct '24

Hello all, We are planning an upgrade from OpenLDAP 2.4 to 2.6. We would like some guidance on the upgrade path. We are currently looking over the upgrade guides: - https://www.openldap.org/doc/admin25/appendix-upgrading.html - https://www.openldap.org/doc/admin26/appendix-upgrading.html Currently, we build OpenLDAP from source to create the RPMs and then install them. We are building version 2.4.56-4. Originally they were built for CentOS 7, but we've recently converted to AWS AL2023. We have 3 mdb write instances (synced to each other) and then many hdb read instances (consumers) syncing to those. The following are the RPMs built: - openldap-2.4.56-4.el7.x86_64.rpm - openldap-clients-2.4.56-4.el7.x86_64.rpm - openldap-compat-2.4.56-4.el7.x86_64.rpm - openldap-debuginfo-2.4.56-4.el7.x86_64.rpm - openldap-devel-2.4.56-4.el7.x86_64.rpm - openldap-servers-2.4.56-4.el7.x86_64.rpm We plan on addressing the components listed in those guides earlier and to build/install version 2.6 as we have before. We have run into an issue before where CPU spiked on our consumers when we tried to change them to mdb which stopped the 2.5 upgrade but now we're thinking of upgrading and changing the backend to mdb at the same time for the upgrade. We wanted to see if anyone has any advice or caveats that they've run into during their upgrades and to see if this general upgrade path is good. We appreciate any help anyone can offer with the OpenLDAP upgrade. Thanks!

3 2

ACL: write vs. manage
by Windl, Ulrich 14 Oct '24

14 Oct '24

Hi! Basically I have the same question as unanswered https://serverfault.com/q/998893/407952: What is the difference between write and manage? I have a use with write permissions for pwdGraceUseTime, and deleting that attribute requires "-e relax" for ldapmodify. However when my user ties it, it gets a ldap_modify: Insufficient access (50) Kind regards, Ulrich

2 1

symas2.6.7 is data transfer is faster in centos7 but very very slow in rocky8
by anilkumar.pathuri7＠gmail.com 11 Oct '24

11 Oct '24

Hi Team, GM We are working on moving from openldap2.4.44 to symasldap2.6.7. We have total of 13million docs. centos7 to centos7 is taking 1~2hours where as rocky8 is taking 48hours and more. Settings of centos7 and rocky8 are identical. We are moving to rocky8 as centos7 is EOL. Can you please let us know how we can fix the data transfer issue. Regards, Anil P

4 14

ldapsearch by aliased objectClass
by Joril 11 Oct '24

11 Oct '24

Hello, I've created an alias by following the FAQ at https://www.openldap.org/faq/data/cache/1111.html dn: uid=alias,ou=People,dc=example,dc=net objectclass: alias objectclass: extensibleObject uid: alias aliasedobjectname: uid=target,ou=Retired People,dc=example,dc=com The problem I'm facing is that this needs to be queried by an application (out of my control) that queries LDAP looking for a particular objectClass, like this: (&(objectClass=person)(uid=alias)) This query misses the alias, I guess because the alias object has just "alias" and "extensibleObject" as classes... Is this expected? Is there a way to work around this, server-side? I mean, to tell the LDAP server to look for "aliased" properties? Many thanks for your time!

3 3

An interesting note on using ldappasswd in OpenLDAP 2.4
by Windl, Ulrich 09 Oct '24

09 Oct '24

Hi! In the past I was using some LDAP administrator account to reset a user's password (using "ldappasswd -H $server -x -ZZ -D $admin -W "$DN""), and the system output the new password. But after having created a special account that ist to be used to reset passwords only, the same command failed with Result: Constraint violation (19) Additional info: Password fails quality checking policy So it seems the admin account circumvents the password policy restrictions, while the special account does not. But the main reason I'm writing this is that the passwords generated by ldappasswd do not seem to fulfill today's requirements (too short, basically). However 2.4 is very old, and it seems the current ldappasswd does no longer create automatic passwords (reading https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/ldap…). Regards, Ulrich

2 1

Slapd process randomly hangs on consumers and comes back to life after a while with no intervention
by Pierre-Jean CROUZET 20 Sep '24

20 Sep '24

Hello, To start with, this is my very first post on a mailing list of this kind. I've read much about how to do things right, like here: https://www.openldap.org/doc/admin24/troubleshooting.html or here: https://www.openldap.org/faq/data/cache/59.html Nonetheless, please do tell me if I'm not following the standards. I'm facing an issue with my OpenLDAP servers that I struggle to fix or even find info about. To summarize: We have an architecture of 2 providers with mirror mode replication for their configuration. They are LXC's hosted in a datacenter. We have 2 consumers with mirror mode replication for their config also, and they get the DB (mdb backend) from the above providers. They are VMs hosted in a different hypervisor and datacenter than the providers. We have a loadbalancing architecture in front that sends requests evenly to the 4 servers. The writes requests directed to the consumers are forwarded to the providers using the chain overlay. The slapd process of those 2 consumers randomly hangs. When it happens, the slapd service is still running and listening, but not a single query can go through, even the logging stops. Like a complete freeze. The service comes back to life after some time (several minutes, different every time) without any manual intervention. Trying to manually restart the process during such even obviously fails, unless I kill -9, which is not something I want to do. My observations so far : - The hangs appear only during business hours (nothing during nights or week-end). - Only the consumers hang. The providers are always fine. - CPU / RAM / Disks are fine before / during the crashes. - The hangs seem random and I could not find a way to trigger them at will. - strace shows the following lines in an infinite loop during hangs. ``` [pid 1082] gettimeofday({tv_sec=1726669191, tv_usec=694473}, NULL) = 0 [pid 1082] poll([{fd=18, events=POLLIN|POLLPRI}], 1, 100) = 0 (Timeout) [pid 1082] sched_yield() ``` It seems that the process is waiting for some data that never comes. The fd=18 is referencing to a TCP socket connected to provider1. So it would suggests that the provider is not sending what the consumer wants. This has led me to several suppositions: 1. Network issues Unlikely, since only those 2 servers in the DC are experiencing misbehavior, and I can telnet / ldapsearch from the faulty consumer to the provider with no problem during hangs. 2. Syncrepl / slapo-chain misconfiguration I might have a configuration problem, but no matter how much I review it, I don't see what's wrong. I've provided the syncrepl / slapo-chain conf in the config.ldif attachment. I've also provided several other attachments that I thought would be helpful: - log.txt => The slapd logs in trace level that show the last bind before the service hangs. - ldaps_request.log => An ldapsearch performed against the faulty consumer during hang. - starttls_request.log => Same as above, but using StartTLS => the connection seems successful and stops at the server hello TLS exchange. Versions : - slapd: 2.5.18 LTS - Server: Ubuntu 22.04 LTS I am a bit out of ideas on things I could try to fix the issues. Hence this email. I thank you for your time and I am very grateful for any help you could give me. Regards, Pierre-Jean

1 0

"realdn" in auditlog
by Christopher Paul 17 Sep '24

17 Sep '24

Hi OpenLDAP-Technical, What does a comment beginning with "realdn" mean in an auditlog LDIF? I see it after the first line of COMMENT FIELD INFORMATION on some modify operations. Running version 2.5.18 on Ubuntu. At first glance, it looks like it's due to overlays (refint, ppolicy) making modifications as a result of an operation by "realdn"(?)b Many thanks for any insight on this. -- Chris Paul | Rex Consulting |https://www.rexconsulting.net ParaphraseBasicClose

2 1

Double free in ldap_set_option
by radiatejava 16 Sep '24

16 Sep '24

I am getting double free core from ldap library. We are running this version of the code (2.4.49 with 2 patches). git clone https://github.com/openldap/openldap.git -b OPENLDAP_REL_ENG_2_4_49 git cherry-pick 32e965c27134d3d83adbf471186330e361150491 git cherry-pick 5452fb154eaabc46992402a4f1bb1081bc367157 Any idea what could be going on? I am putting the stack trace below: #2 0x00007a1e506d7590 in DoLiveCoreDump (cause=0x7a1e506df7e2 "DoubleFree") at src/heap-profiler.cc:732 #3 0x00007a1e506bed31 in (anonymous namespace)::do_free_with_callback (ptr=ptr@entry=0x5af3d4216dc8, invalid_free_fn=0x7a1e506bd270 <(anonymous namespace)::InvalidFree(void*)>) at src/tcmalloc.cc:1299 #4 0x00007a1e506dd467 in (anonymous namespace)::do_free (ptr=0x5af3d4216dc8) at src/tcmalloc.cc:1376 #5 tc_free (ptr=0x5af3d4216dc8) at src/tcmalloc.cc:1761 #6 0x00007a1e3f19106b in ldap_pvt_tls_set_option (ld=ld@entry=0x0, option=option@entry=24579, arg=arg@entry=0x7a1e416e2220) at tls2.c:766 #7 0x00007a1e3f186386 in ldap_set_option (ld=0x0, option=24579, invalue=0x7a1e416e2220) at options.c:791 #8 0x00007a1e415e03fd in auth::LdapAuthenticationBroker::connectAndBindLdap(sec::LdapProvider const&) () from /mgmt/usr/lib/x86_64-linux-gnu/libauth.so

2 1

Search callbacks for refreshAndPersist sync searches
by Hawes, David 10 Sep '24

10 Sep '24

I have a custom overlay that registers a callback to rewrite attribute values for searches. I noticed that it was not working for refreshAndPersist sync searches for queued responses, and the reason for this is that there are no callbacks registered in syncprov_qtask() [1]. I'd see the initial responses come through with rewritten attributes, but later responses would not be rewritten. I had some success adding the callbacks back, but it was a bit of a minefield. Before investigating further, I was hoping to understand why the decision was made to not set callbacks in syncprov_qtask(). For now I'm operating under the assumption that this is simply not supported. So, why aren't callbacks supported for queued sync responses? I noticed that valsort doesn't handle syncrepl responses [2], and I wonder if the reason is because the results may be inconsistent, as I am experiencing. [1] https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/serv… [2] https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/serv…

2 3

certutil - nsldap + nss trustargs
by venugopal chinnakotla 04 Sep '24

04 Sep '24

Hi Team, We are migrating our source code to use openldap client libraries instead of nsldap libraries. We have the below query for the openldap team. Please share your thoughts on this feature availability in the openldap library. nsldap has the below feature while validating TLS Connections. please refer to the nss tool, and refer to the section "Options and Arguments" https://www-archive.mozilla.org/projects/security/pki/nss/tools/certutil -t trustargs Specify the trust attributes to modify in an existing certificate or to apply to a certificate when creating it or adding it to a database. There are three available trust categories for each certificate, expressed in this order: "SSL, email, object signing". In each category position use zero or more of the following attribute codes: p Valid peer P Trusted peer (implies p) c Valid CA T Trusted CA to issue client certificates (implies c) C Trusted CA to issue server certificates (SSL only) (implies c) u Certificate can be used for authentication or signing w Send warning (use with other attributes to include a warning when the certificate is used in that context) The attribute codes for the categories are separated by commas, and the entire set of attributes enclosed by quotation marks. For example: -t "TCu,Cu,Tuw" Use the -L option to see a list of the current certificates and trust attributes in a certificate database. our query: Does openldap provide trustargs support to verify TLS connection? Please share details on this. Thanks In advance. -- Thanks, *c.venugopal*

4 3

Syncrepl getting stuck on partial sync
by jose Pereira 04 Sep '24

04 Sep '24

Hello All! I have multiple setups with a Provider(2.6.4) and consumer(2.6.2) with RefreshAndPersist. From time to time I see data missing in the consumer e.g only groups are present and all users are missing, even though users were never removed from the Provider, and were present in the Consumer beforehand. On the Provider all data is present and correct. I can still see the incoming connection, from the Consumers Sync, in the Provider without errors. No errors on the Comsumer logs from syncrepl (with -256 logs). Attempted to look in debug (-1 logs), but nothing caught my eye. When this happened I attempted restart services on both the Provider and the Consumer, disabling and re-enabling the sync on the Consumer. Only clearing the Consumers database seemed to fix the issue. There maybe be sporatic failures in the network connectivity between both systems. This is the config on the Consumer olcSyncrepl: {0}rid=000 provider=ldaps://Provider:636 type=refreshAndPersist retry="30 5 300 +" searchbase="ou=subtree,dc=test,dc=net" scope=sub schemachecking=on binddn="cn=Manager,dc=test,dc=net" credentials=credentials keepalive=240:10:30 Any advice on how to troubleshoot this or fix it?

4 18

FW: [External] RE: Help Openldap objectclass schema add
by Khan, Afaque 04 Sep '24

04 Sep '24

Hi Openldap- Version 2.6.7 I am using below command to change the current running port to 2636 but I am getting below error message Error: name '_pretty_exception' is not defined dsconf -D "cn=admin..... " ldap://(hostname) config replace nsslapd-secureport=2636 Please let me know the command or steps to change the port and also please let me know where to add below local objectclass created file to add new objectclass in schema I am not able to find the slapd.conf(5) or slapd.conf(8) file to include below schema objectclass file '/usr/local/etc/openldap/schema/local.schema' Thanks Afaque khan From: Chris Paul <chris.paul(a)rexconsulting.net<mailto:chris.paul@rexconsulting.net>> Sent: Tuesday, September 3, 2024 1:10 AM Subject: [External] RE: Help Openldap objectclass schema add You don't often get email from chris.paul(a)rexconsulting.net<mailto:chris.paul@rexconsulting.net>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> WARNING: This message has originated from an External Source. This may be a phishing email that can result in unauthorized access to Honeywell systems. Please use proper judgment and caution when opening attachments, clicking links, scanning QR codes, or responding. Hi Afaque, You have not indicated what you have tried, given any error, your configuration, or useful information except that everyone now knows that you work for..... Have you read the OpenLDAP admin guide, and the man pages? When I post to openldap-technical(a)openldap.org<mailto:openldap-technical@openldap.org>, I never reveal my clients' identity, for their protection. Yes, obscurity is a layer of security. Good luck to you and....., -- Chris Paul | https://www.rexconsulting.net Sent: Monday, September 2, 2024 3:13 AM To: openldap-technical-request(a)openldap.org<mailto:openldap-technical-request@openldap.org>; openldap-technical(a)openldap.org<mailto:openldap-technical@openldap.org> Subject: Help Openldap objectclass schema add Hi Openldap Team, I have installed the openldap openldap-2.6.7 version on RHEL 8 but I am not able to add the new objectclass hworgperson and attribute manager and hwtype. Please let me know how I can add the new objectclass and attributes. Help -----Original Message----- From: openldap-technical-request(a)openldap.org<mailto:openldap-technical-request@openldap.org> <openldap-technical-request(a)openldap.org<mailto:openldap-technical-request@openldap.org>> Sent: Monday, September 2, 2024 3:37 PM Subject: [External] Welcome to the "openldap-technical" mailing list WARNING: This message has originated from an External Source. This may be a phishing email that can result in unauthorized access to Honeywell systems. Please use proper judgment and caution when opening attachments, clicking links, scanning QR codes, or responding. Welcome to the "openldap-technical" mailing list! To post to this list, send your message to: openldap-technical(a)openldap.org<mailto:openldap-technical@openldap.org> You can unsubscribe or make adjustments to your options via email by sending a message to: openldap-technical-request(a)openldap.org<mailto:openldap-technical-request@openldap.org> with the word 'help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You will need your password to change your options, but for security purposes, this password is not included here. If you have forgotten your password you will need to reset it via the web UI.

2 1

Help Openldap objectclass schema add
by Khan, Afaque 04 Sep '24

04 Sep '24

Hi Openldap Team, I have installed the openldap openldap-2.6.7 version on RHEL 8 but I am not able to add the new objectclass hworgperson and attribute manager and hwtype. Please let me know how I can add the new objectclass and attributes. Help Thanks & Regards, Afaque khan Advanced Cyber Sec Archt/Engr Honeywell | Honeywell Global Security Mobile: +91 9599800986 md.khan(a)honeywell.com<mailto:md.khan@honeywell.com> Thanks & Regards, Afaque khan Advanced Cyber Sec Archt/Engr Honeywell | Honeywell Global Security Mobile: +91 9599800986 md.khan(a)honeywell.com<mailto:md.khan@honeywell.com> -----Original Message----- From: openldap-technical-request(a)openldap.org <openldap-technical-request(a)openldap.org> Sent: Monday, September 2, 2024 3:37 PM To: Khan, Afaque <md.khan(a)honeywell.com> Subject: [External] Welcome to the "openldap-technical" mailing list WARNING: This message has originated from an External Source. This may be a phishing email that can result in unauthorized access to Honeywell systems. Please use proper judgment and caution when opening attachments, clicking links, scanning QR codes, or responding. Welcome to the "openldap-technical" mailing list! To post to this list, send your message to: openldap-technical(a)openldap.org<mailto:openldap-technical@openldap.org> You can unsubscribe or make adjustments to your options via email by sending a message to: openldap-technical-request(a)openldap.org<mailto:openldap-technical-request@openldap.org> with the word 'help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You will need your password to change your options, but for security purposes, this password is not included here. If you have forgotten your password you will need to reset it via the web UI.

2 1

long restart time of openldap
by Norbert 29 Aug '24

29 Aug '24

Hi, we have ldap servers with many ldap entries (3 million and more) these are replicating with other instances (Master-Master + Read slaves). When we need to restart and ldap due to maintenance or other problems those are taking a lot of time before they serving a requests again. It looks like that in most cases it does a full refresh of the whole tree (printed to the log) but there are is also a timespan where nothing is printed to the log but the slapd process is really busy and consuming more than one core. We are currently using 2.5.16.1 of openldap but have experienced this with older version too. Any hint about how to improve this? Thanks, Norbert

2 5

LMDB write commit time hockey-sticks [corrected]
by Alec Matusis 22 Aug '24

22 Aug '24

Problem: Our application first writes data into LMDB. After the write cursor is closed, the LMDB is used with a read-only cursor. Our problem is that writing commit time hockey-sticks. Here is the graph on the machine with 128GB of RAM: https://i.imgur.com/py83dRV.jpeg (happens at 3200) We used a virtual machine with 16 GB, to wait less for this hockey-stick: https://i.imgur.com/CYohM3O.jpeg (red curve is the commit time, happens at 3080; the lmdb env stats are on the bottom graph. Size on the top graph is total program size from /proc/[pid]/statm) . We tried various combinations of environment flags: MDB_WRITEMAP, MDB_MAPASYNC, MDB_NOSYNC and MDB_NOMETASYNC. We also tried increasing mapsize. Nothing seems to matter (e.g. https://i.imgur.com/MkZJkxp.jpeg with 64G mapsize and MDB_NOSYNC), the best combination seems to be without any flags at all. Smaller mapsizes are worse, but increasing mapsize above 4GB in a 16GB RAM machine doesn't seem to gain anything. Can you recommend a way to prevent or delay this hockey-stick when we are in the write regime and the reads are very minimal? We just want to write the data to disk fast, we don’t even need mmap() for read performance, we will need it in the read-only mode later, after the write cursor finishes and a read-only cursor is used. Details: The environment contains two databases, one with no flags (keys are 32 bytes, values are 8 byte integers), second one with MDB_INTEGERKEY (keys are 8 byte integers, values are 32 bytes, uses MDB_APPEND for writing). All commits are similar sized, 6000-8000 pages (page size is 4096). Each commit therefore is ~400k keys total for boths dbs, (7000*4096/((32+8)*2). The VM has no disk swap, from perf output here https://i.imgur.com/zuTGawz.jpeg we can see that the machine is under page swap load. On a VM with 16GB RAM, hockey-stick happens when the LMDB size is only 1.5GB, 12% of the available RAM. Detailed stats: Below is the excerpt from the application log on each commit, the same data is plotted in the linked graphs above. Memory stats are from. /proc/[pid]/statm , lmdb stats are from the environment.“Difference” the time the commit takes, it degrades from 45 seconds to 3+ minutes. Final LMDB size in this log is pgs_in_use 448993*4096 = 1.84GB. Start of log before write degradation: 2024-08-09 02:26:19 [INFO][src/importer.rs:198] File 3054: 132932384 bytes. Memory stats: Size: 27540910 pages, Resident: 286072 pages, Shared: 99484 pages, Text: 981 pages, Data: 191849 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pgs 0 last_pgno 108959 last_txnid 18 max_readers 126 num_readers 1 free_pgs 56171 pgs_in_use 52788 Difference: 0 min 44 sec 2024-08-09 02:27:03 [INFO][src/importer.rs:198] File 3055: 133951354 bytes. Memory stats: Size: 27541730 pages, Resident: 298463 pages, Shared: 111020 pages, Text: 981 pages, Data: 192669 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pg s 0 last_pgno 121928 last_txnid 19 max_readers 126 num_readers 1 free_pgs 62881 pgs_in_use 59047 Difference: 0 min 48 sec 2024-08-09 02:27:51 [INFO][src/importer.rs:198] File 3056: 133218473 bytes. Memory stats: Size: 27543735 pages, Resident: 313441 pages, Shared: 123980 pages, Text: 981 pages, Data: 194674 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pg s 0 last_pgno 133243 last_txnid 20 max_readers 126 num_readers 1 free_pgs 69672 pgs_in_use 63571 Difference: 0 min 40 sec …… End of log after write degradation: 2024-08-09 04:39:33 [INFO][src/importer.rs:198] File 3127: 132694310 bytes. Memory stats: Size: 27654397 pages, Resident: 1028693 pages, Shared: 727992 pages, Text: 981 pages, Data: 305336 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pgs 0 last_pgno 745440 last_txnid 91 max_readers 126 num_readers 1 free_pgs 308699 pgs_in_use 436741 Difference: 2 min 36 sec 2024-08-09 04:42:09 [INFO][src/importer.rs:198] File 3128: 133418687 bytes. Memory stats: Size: 27654397 pages, Resident: 1033516 pages, Shared: 732815 pages, Text: 981 pages, Data: 305336 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pgs 0 last_pgno 745440 last_txnid 92 max_readers 126 num_readers 1 free_pgs 304043 pgs_in_use 441397 Difference: 3 min 18 sec 2024-08-09 04:45:27 [INFO][src/importer.rs:198] File 3129: 133118782 bytes. Memory stats: Size: 27654397 pages, Resident: 1043876 pages, Shared: 743175 pages, Text: 981 pages, Data: 305336 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pgs 0 last_pgno 762922 last_txnid 93 max_readers 126 num_readers 1 free_pgs 313929 pgs_in_use 448993

1 1

start slapd with mdb on readonly filesystem
by Zach Hanson-Hart 19 Aug '24

19 Aug '24

Hello list, When starting slapd when an lmdb backend in readonly mode is on a readonly filesystem, slapd fails to start with: 66c347f4.334226ce 0x7fc9c14ffb08 @(#) $OpenLDAP: slapd 2.6.6 (Oct 22 2023 00:57:15) $ 2024-08-19T09:26:12.865756736-04:00 openldap 2024-08-19T09:26:12.875884302-04:00 66c347f4.342f703c 0x7fc9c14ffb08 olcDbDirectory: value #0: invalid path: Read-only file system 2024-08-19T09:26:12.875912369-04:00 66c347f4.3430d2ab 0x7fc9c14ffb08 config error processing olcDatabase={1}mdb,cn=config: olcDbDirectory: value #0: invalid path: Read-only file system 2024-08-19T09:26:12.875942620-04:00 66c347f4.3434526e 0x7fc9c14ffb08 slapd stopped. 2024-08-19T09:26:12.875950918-04:00 66c347f4.343518c7 0x7fc9c14ffb08 connections_destroy: nothing to destroy. Is there something I can set to make it start even though the filesystem is readonly? For reference, the slapd configuration is below: dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /etc/openldap/scratch/run/slapd.pid olcArgsFile: /etc/openldap/scratch/run/slapd.args olcLogLevel: stats olcAuthzPolicy: none olcSecurity: ssf=0 tls=0 simple_bind=0 transport=0 olcReadOnly: FALSE dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: to dn.base="" by * read olcAccess: to dn.base="cn=Subschema" by * read dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/openldap olcModuleload: back_mdb.so olcModuleload: back_ldap.so olcModuleLoad: ppolicy dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif include: file:///etc/openldap/schema/cosine.ldif include: file:///etc/openldap/schema/inetorgperson.ldif dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: to dn.base="cn=config" by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * read olcAccess: to dn.subtree="cn=config" by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * read olcAccess: to * by * read dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcSuffix: ou=data,dc=example,dc=com olcRootDN: cn=root,ou=data,dc=example,dc=com olcRootPW: <REDACTED> olcReadOnly: TRUE olcDbDirectory: /var/lib/openldap/data olcAccess: to dn.base="ou=data,dc=example,dc=com" by * read # Allow full read access for now for testing. olcAccess: to dn.subtree="ou=data,dc=example,dc=com" by * read olcLimits: * size=unlimited time=unlimited olcDbMaxsize: 171798691840 olcDbIndex: objectClass eq,pres olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn eq Thanks in advance. Zach

1 0

Need support to configure ldap for duo MFA for auth proxy.
by Ajay Kumar 16 Aug '24

16 Aug '24

Hi Team, we get stuck at configuring Openldap for enabling Multifactor authentication for ldap users. As per duo support team, for doing the same we need to configure schema includes the memberOf overlay for groups and that the following requirements to satisfied: Synced groups must have the groupOfNames object class. Synced groups must list their members by DN (directoryName) via the member attribute. Synced groups must have a cn attribute, used as the Duo group name after import. Synced groups must also have the attributes entrydn (used as the distinguished name) and entryuuid (the group unique identifier). Synced users must list group memberships by DN using the memberOf attribute. Synced users must have the organizationalPerson object class. We are trying to enable Multifactor authentication using duo auth proxy & duo admin panel configuration for ldap users. Ldap server is getting synced successfully with Duo admin portal but groups and users details not getting fetched at duo admin portal. Duo support team mentioned to change ldap configuration as mention in below mentioned article. Can you pls share some reference document to make required changes. https://duo.my.site.com/s/article/4529?language=en_US Regards, Ajay Kumar Engineering Cloud Ops | Bharti Airtel Ltd. Mob.: +91 8510020994 [photo_6075787602121832799_m] *********************************************************************************************************************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited . The information contained in this mail is propriety and strictly confidential. *********************************************************************************************************************************************************************** “CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.”

2 1

Push-based synchronization & dynamic attributes
by Benjamin Renard 13 Aug '24

13 Aug '24

Hello, Since updating our LDAP infrastructure to OpenLDAP 2.5 (2.5.13 from the Debian repository), we have encountered desynchronization issues with certain objects. The synchronization in place is in push mode as documented in the official documentation (https://www.openldap.org/doc/admin25/replication.html#Syncrepl%20Proxy). The problem seems to stem from the fact that we are using dynamic attributes via the dynlist overlay, and the master server attempts to push these dynamic attributes to the slave servers when modifications are made to these objects, which the slaves refuse. Log extract from one of our slave servers: Aug 13 10:12:28 volubilis slapd[2005636]: conn=20983 op=54 MOD dn="uid=ele-ladon-test,ou=contracts,o=easter-eggs" Aug 13 10:12:28 volubilis slapd[2005636]: conn=20983 op=54 MOD attr=eeTechnicalContact eeStartDate eeStorageDisks entryCSN modifiersName modifyTimestamp eeContractId eeContractIncludedService Aug 13 10:12:28 volubilis slapd[2005636]: conn=20983 op=54 RESULT tag=103 err=16 qtime=0.000022 etime=0.000536 text=modify/delete: eeContractId: no such attribute Note: The attribute eeContractId is a dynamic attribute of the object in question. Previously, with OpenLDAP 2.4, we did not have this issue, and the attributes were dynamic (and therefore managed by dynlist) on both our master server and slave servers. To immediately resolve this problem, we have removed the dynlist configuration on our slave servers. These attributes are therefore "static" on our slave servers, and desynchronizations are potentially possible. How can we correctly manage this situation? Please note that some of the affected attributes are both static on certain objects and dynamic on others, so we cannot simply exclude them completely from synchronization. Thank you in advance. -- 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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical