openldap-technical May 2024

openldap-technical@openldap.org

19 participants
21 discussions

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

06 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

olcPPolicyForwardUpdates not working
by Benjamin Renard 19 Jun '25

19 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

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

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

Re: Facing issues with Symas LDAP upgrade from 2.4 to 2.5
by anil kumar pathuri 25 Jul '24

25 Jul '24

hi Quanah, Hope you are doing well. Thank you for your email. PFA This is what I did: Installed openldap 2.4.44 --> Upgraded to Symas OpenLDAP 2.4.57 --> Upgrading from Symas OpenLDAP 2.4.57 to Symas OpenLDAP 2.6.7 ***PS: I am not using slapd.conf, what should I do in this case. Regards, Anil P On Fri, 17 May 2024 at 01:57, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, May 16, 2024 7:55 PM +0000 anilkumar.pathuri7(a)gmail.com > wrote: > > > Hi Team, GM > > Successful while trying to upgrade from openLDAP 2.4.44 to > SymasLDAP2.4.57 > > > > Facing issues while trying to upgrade to 2.5.x and 2.6.x from > > SymasLDAP2.4.57 https://repo.symas.com/soldap2.5/upgrading/ > > > > Issues while trying to upgrade from SymasLDAP2.4.57 to SymasLDAP 2.5.17. > > 1. config error processing olcDatabase={2}mdb,cn=config > > UNKNOWN attributeDescription "OLCDBINDEX" inserted > > Providing a config snippet is not particularly useful. > > You also say issue going from 2.5.x to 2.6.x but then you say the error is > in going from 2.4.57 to 2.5.17. > > Your error generally indicates that you're missing a module load on the > MDB > backend module. > > --Quanah > >

7 13

[OpenLDAP 2.5] Accesslog size and performance issues
by BECOT Jérôme 28 May '24

28 May '24

Hello, Here is our setup: 2 master in mirrormode with accesslog replication and several slaves with lastbind and chain overlay. Everything works, but the accesslog db is quite large and filled with authtimestamp updates from client hosts running sssd. We also have a disk performance issue when the cleanup process is launched every 4h. We plan to reduce the accesslog history by setting 12h retention and increase cleanup . It should reduce the number of entries and therefore lighten the cleanup process but: I wonder if increasing the frequency will also have a positive effects (as the though here is that there will be less entries to delete). I think that allocated pages in the mdb database won't change. Is there a safe way to reduce the db size ? Finally, we considered not logging the sssd auth timestamp updates, but lastbind doesn't have any option to filter which branch is allowed to update, the only option is to set the precision to a higher value. Is there a way to achieve this ? Any suggestion will be warmly appreciated. Thank you Jerome

4 7

its8752 failure
by patrick+openldap.org＠laimbock.com 27 May '24

27 May '24

Hi all, Almalinux 9.4 x86_64. When building 2.6.8 with gcc 11.4.1 20231218 (Red Hat 11.4.1-3) or gcc 13.2.1 20231205 (Red Hat 13.2.1-6) I get a failure in 'make -j1 its' in its8752: >>>>> Starting its8752 ... running defines.sh This test tracks a case where slapd deadlocks during a significant write load See https://bugs.openldap.org/show_bug.cgi?id=8752 for more information. Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Populating database on first provider... Stopping slapd and reworking configuration for MPR... Starting provider slapd on TCP/IP URI ldap://localhost:9011/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9012/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9013/ Using ldapsearch to check that provider slapd is running... Starting provider slapd on TCP/IP URI ldap://localhost:9014/ Using ldapsearch to check that provider slapd is running... Setting up accesslog on each provider... Modifying dn: cn=Elmer_Fudd,ou=People,dc=example,dc=com on provider 1 Modifying dn: cn=Elmer_Fudd,ou=People,dc=example,dc=com on provider 2 Modifying dn: cn=Elmer_Fudd,ou=People,dc=example,dc=com on provider 3 Modifying dn: cn=Elmer_Fudd,ou=People,dc=example,dc=com on provider 4 Waiting 7 seconds for servers to catch up... Waiting 7 seconds for servers to catch up... Waiting 7 seconds for servers to catch up... Waiting 7 seconds for servers to catch up... Waiting 7 seconds for servers to catch up... Waiting 7 seconds for servers to catch up... Servers did not replicate in time >>>>> ./data/regressions/its8752/its8752 failed (exit 1) make[1]: Leaving directory '/builddir/build/BUILD/openldap-2.6.8/tests' make[1]: *** [Makefile:364: mdb-its-yes] Error 1 make: *** [Makefile:355: regressions] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.cKP3aW (%check) Looking at its8752 in bugzilla there is a target of 2.7.0 and there are a number of other ITSs mentioned: https://bugs.openldap.org/show_bug.cgi?id=9782 (confirmed) https://bugs.openldap.org/show_bug.cgi?id=9580 (in progress) https://bugs.openldap.org/show_bug.cgi?id=9341 (unconfirmed) Is this test supposed to pass successfully on 2.6.8? Thanks, Patrick

1 0

el9 bind ip address
by Marc 24 May '24

24 May '24

Anyone know if this file is still working in el9? Looks like if I put SLAPD_URLS it is not read. /etc/sysconfig/slapd

4 7

Unable to enable auditlog in openldap 2.4
by kalybox2020＠gmail.com 21 May '24

21 May '24

We are using cn=config file for configuration. Using ldapmodify dn: olcOverlay={8}auditlog,olcDatabase={1}hdb,cnc=config objectclass: olcOverlayConfig objectClass: olcAuditlogConfig olcAuditLogFile: /var/log/ldapauditlog.ldif restarted slapd, Gave permissions to this file, and restarted slapd, still not able to generate logs. Thanks -Kaly

1 0

How to setup replication in openldap 2.6.7
by kalybox2020＠gmail.com 21 May '24

21 May '24

How to setup replication in openldap 2.6.7 Please let me know Thanks -Kaly

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2024