openldap-technical January 2024

openldap-technical@openldap.org

22 participants
23 discussions

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

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

Openldap 2.4 -> Openldap 2.6.3 replication hurdles
by Viktor Keremedchiev 08 Feb '24

08 Feb '24

Hello, I'm somewhat not experienced with LDAP on the server side of things I’m importing openldap 2.4. into 2.6.3. (rockylinux 9). My goal is to 2 have 2 N-way (or multi-master*) ldap nodes. I’ve changed hdb to mdb, created accesslog folder, fixed permissions, SSL etc The import doesn’t throw any errors. My understanding is that I need to have cn=config replication, as well as my small dc=domain,dc=com, replication as well The cn=config replication I call via this on both nodes followed by restarts dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=002 provider=ldaps://prod-ldap2.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N… searchbase="cn=config" schemachecking=on type=refreshAndPersist retry="10 10 60 +" tls_reqcert=allow keepalive=240:10:30 olcSyncRepl: rid=001 provider=ldaps://prod-ldap1.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N…… searchbase="cn=config" schemachecking=on type=refreshAndPersist retry="10 10 60 +" tls_reqcert=allow keepalive=240:10:30 - add: olcMirrorMode olcMirrorMode: TRUE Now once I do that I’ve experimented with changing the olcLogLevel and it seems to work. The rid’s on each node are different server2 has rid=002, server 1 has rid=001 as well as different olcServerID The part I run into issues is when I enable replication to the dc=domain,dc=com via dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {2}syncprov olcSpCheckpoint: 20 10 olcSpSessionlog: 10000000 dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=021 provider=ldaps://prod-ldap1.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N…. searchbase="dc=domain,dc=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="5 10 60 +" tls_reqcert=allow keepalive=240:10:30 olcSyncRepl: rid=022 provider=ldaps://prod-ldap2.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N…. searchbase="dc=domain,dc=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="5 10 60 +" tls_reqcert=allow keepalive=240:10:30 - add: olcMirrorMode olcMirrorMode: TRUE I have 2 sets rids 001/002 and 021/022 and I have olcMirrorMode set to true on both cn=config and domain replication I’m pasting the relevant code around accesslog and syncprov that I think I’m getting wrong dn: olcOverlay={3}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {3}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig dn: olcOverlay={4}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {4}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=adaptavist,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart structuralObjectClass: olcMdbConfig dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig Replication works from node1 to node2, and in reverse. But it stops after 20 minutes or so After replication stops I see the on accesslog on one node has 4 records, on the other it has 3 and it never catches up even if I restart although at first it all works regardless of which node I update (change a random password) What am I doing wrong? Perhaps more than one thing Thank you

3 5

Accesslog requirement for sync replication
by Marc Franquesa 05 Feb '24

05 Feb '24

Hi I have been using replication since long time without any issues (and still without issues), but on recent versions I got this warning on the logs: syncprov_setup_accesslog: couldn't get definition for attribute reqType, is accesslog configured? The answer is no, I never configured accesslog (this why I'm a bit confused, as I never used/needed on my replication setup). After reviewing the documentation I understand that for syncrepl I should load and configure accesslog overlay. Although I have some questions/concerns I haven't been able to found/understand from the documentation and would like someone clarifies: * Is there any way to implement replication without accesslog? (currently I have it but I would like to not get that warning) * If I setup accesslog, do I need to setup a different accesslog DIT for each target DIT I replicate? Or can a single accesslog be shared with 2 different target DITs? I mean: I'm currently replicating both cn=config (dynamic configuration) and the main DIT (so 2 different contexts/DITs/trees) Do I need to use a different accesslog DIT for each one or can they share the same DIT as accesslog ? * Does this log DIT needs to be backup up or is simply a log which I could get rid of in case of recovery? Any comments, hints or simply answers are welcome Thanks

2 3

Plans for the next LTS release?
by Sergio Durigan Junior 01 Feb '24

01 Feb '24

Hi there, Two years ago I sent an announcement mentioning that the OpenLDAP 2.5.x series was accepted for a Micro Release Exception in Ubuntu Jammy (20.04). This meant that I'd be able to release any updates to the 2.5.x series on Jammy, which I have been doing since then. We are now getting ready to work on the next Ubuntu LTS release, which will come out next April. I seem to remember upstream discussions mentioning that the next OpenLDAP LTS release would likely be the 2.7.x series, but I don't remember seeing anything else about it. Are there any plans to start working on the OpenLDAP LTS major series? Thanks a lot, -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

3 5

UNKNOWN attributeDescription "..." inserted.
by Bastian Tweddell 01 Feb '24

01 Feb '24

Dear all, We are facing 'UNKNOWN attributeDescription' errors in our infrastructure, caused by two different reasons. I realized those only by using `slapcat` which prints the following error/warning message to STDERR: ``` UNKNOWN attributeDescription "..." inserted. ``` In both cases, this issue does not degrade the production of our system. All operations including syncreplication are working in normal parameter. Case A: In our production, a dedicated slapd syncrepl consumer has the totp module from contrib enabled and ldapbind calls against '{TOTP1}' are performed. This module introduces a new attribute "authTimestamp". IIUC, `slapcat` cannot know about this attribute, because it is not in the config. But attributes of that type are stored in the MDB. I'd like to ask: - How should we deal with this situation? - Is it safe to continue as is or should we define the attribute "authTimestamp" in our schema extension as well? Case B: We are about to remove some attribute definitions from our schema extension. These are obsolete and not in use in the DB anymore. On the testbed slapd+syncrepl works as expected. But here as well, even though that the DB does not contain any of the obsolete attributes in any entry, `slapcat` throws the same error/warning for all removed attributes from the schema file. My first approach was to re-index the database (even with truncate mode), which did not solve the situation. Stopping the consumer slapd, removing the mdb files and restarting the syncrepl solves it. But on production I would not want to do re-sync everything unnecessarily (it would be possible though). I'd like to ask here: - Is there a way to cleanup MDB from obsolete attributes? - Where/how are those attributes referenced in MDB? - Would it harm to ignore those errors? - Is the removal of attribute definitions from the schema not supported/suggested at all? Btw, we are running slapd 2.6.3 with mdb backend. (Upgrade to 2.6.7 is in planning now). During the composition of this mail, further issues came up with slapd-totp and I would like to add some follow-up questions here. If you prefer, I'll write another mail or I could open an issue on bugzilla. 1. By reading some code in slapd-totp.c I recognized that the introduced attribute authTimestamp is SINGLE-VALUE. But slapcat reveals that entries have multiple values of authTimestamp. This sounds not correct to me. 2. In slapd-totp.c: line 856 and 873 both call `ch_calloc` for the same structm, shadowing the same pointer. This looks like a memory leak to me, because also only one free is called. (I might be wrong though). Many thanks in advance, -- Bastian Tweddell Juelich Supercomputing Centre phone: +49 (2461) 61-6586 High Performance Systems --------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------- 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), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens --------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------

3 6

Upgrade Openldap software from 2.4 to 2.6
by kalybox2020＠gmail.com 24 Jan '24

24 Jan '24

Hello, I would like to upgrade the openldap software from 2.4 to 2.6 version. Can you please describe the high level steps involved? Is it going to be in place upgrade? Or we need to install a new 2.6 instance and export the data from old 2.4 and import into 2.4? Pleas elet me know -Kaly

3 2

Performance tuning in Openldap 2.4
by kalybox2020＠gmail.com 24 Jan '24

24 Jan '24

Hello Team, What are the various Tuning parameters that we should look at for performance tuning Openldap 2.4? 1. Indexing (See logs and find out if any unindexed searches, and index them as needed) 2. DB_CONFIG tuning various parameters such as cachesize etc Anything else, please let me know. Thank you -Kaly

2 1

How to check the version of openldap running
by kalybox2020＠gmail.com 22 Jan '24

22 Jan '24

How to check the current openldap version software running? I am told its 2.4. But is there a command to validate? Thank you -Kaly

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2024