openldap-technical April 2024

openldap-technical@openldap.org

17 participants
16 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

Replication Questions
by BECOT Jérôme 30 Apr '24

30 Apr '24

Hello ! I have few questions regarding replication. I'm doing partial replication on plain replication by limiting the syncrepl user permissions in the ACL. It works well. Is it supported ? Would it work with a delta-sync replication ? Another thing I've been told about is about memberOf overlay. My colleague told me that replication may fail when memberOf is enabled on consumers, mainly because sometimes the group is replicated before the user and memberOf would create an entry if a search is made on the user not yet replicated. Have you some insights about this behaviour that I have not met yet ? Regards

4 4

bindDN massage error
by lsoulas 30 Apr '24

30 Apr '24

Hi, I testing a configuration with rewriteMap option. I have an error bindDN massage error when the rule is redirected. I think who I don't use a good regexp for the rule. My configuration : /defaultsearchbase dc=local,dc=lan database meta suffix "dc=lan" uri "ldaps://192.168.50.2/dc=lan" overlay rwm rwm-rewriteEngine on rwm-rewriteMap ldap attr2dn "ldap://192.168.50.10" rwm-rewriteContext bindDN rwm-rewriteRule "(.*)" "${attr2dn(%1)}" "#"/ For this test, I whish who all request is redirected of the other server. If I viewing a tcp frames, the cn request add a $ in frame: /cn.$user, cn=Users,dc=local,dc=lan/ Thank you for your feedback *Loïc*

1 0

Need information related to multi thread support in OpenLDAP c sdk client
by c.venugopal521＠gmail.com 29 Apr '24

29 Apr '24

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 with in OpenLDAP to use it in our client program. Gone through OpenLDAP document and source code, but with 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 Venu

2 1

ldclt ldap performance testing
by Marc 27 Apr '24

27 Apr '24

I am doing some basic testing with ldap with this command. ldclt \ -a 400 \ -H ldap://x.x.x.x:xxxx \ -e bindeach,bindonly,close \ -D "uid=test,dc=me,dc=local" \ -w yyyyyy \ -n 1 I was testing this on two container test environments. Both are running with ~500MB, 1 core. 1. alpine - slapd 2.6.3, mdb still with default slapd.conf ldclt[5594]: Average rate: 12627.00/thr (1262.70/sec), total: 12627 ldclt[5594]: Average rate: 0.00/thr ( 0.00/sec), total: 0 ldclt[5594]: All threads are dead - exit. 2. alpine - slapd 2.6.6, mdb configured with acl's, ssl, modules etc. ldclt[8900]: Average rate: 1495.00/thr ( 149.50/sec), total: 1495 ldclt[8900]: Average rate: 1498.00/thr ( 149.80/sec), total: 1498 ldclt[8900]: Average rate: 1490.00/thr ( 149.00/sec), total: 1490 What should I be expecting from this? It looks like maybe slapd of 1. is not 100% with this 'threads are dead' messages. While slapd of 2. with 150 req/sec is that to be expected normal?

3 5

cache userPassword with bind
by Marc 25 Apr '24

25 Apr '24

I am testing a bit with bind's. With consecutive binds with the same test account I always get 'result not in cache'. How can I get this in cache? access_allowed: result not in cache (userPassword) 6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND dn="uid=test,dc=me,dc=local" method=128 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in cache (userPassword) 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to "uid=test,dc=me,dc=local " "userPassword" requested 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend default auth access granted to "(anonymous)" 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access granted by read(=rscxd)

3 7

RE26 testing call (2.6.8) #1
by Quanah Gibson-Mount 19 Apr '24

19 Apr '24

This is the first testing call for OpenLDAP 2.6.8. 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.8 Engineering Fixed libldap exit handling with OpenSSL3 again (ITS#9952) Fixed slapd-meta with dynlist (ITS#10164) Fixed slapd-meta binds when proxying internal op (ITS#10165) Added slapo-nestgroup overlay (ITS#10161) Added slapo-memberof 'addcheck' option (ITS#10167) Fixed slapo-accesslog startup initialization (ITS#10170) Fixed slapo-dynlist with abandoned operations (ITS#10044) Build Fixed build with gcc14.x (ITS#10166) Fixed back-perl with clang15 (ITS#10177) Contrib Added slapo-alias contrib module (ITS#10104, ITS#10182) Fixed slapo-autogroup to work with slapo-dynlist (ITS#10185) Documentation Fixed slapo-memberof exattr requirements (ITS#7400) Fixed slapo-memberof is no longer deprecated (ITS#7400) Minor Cleanup ITS#10103 ITS#10171 ITS#10172 ITS#10173 ITS#10179 ITS#10186 ITS#10188 ITS#10193 Regards, Quanah

2 1

timeout and network-timeout values of zero for syncrepl in LAN replication
by Christopher Paul 17 Apr '24

17 Apr '24

Hello OpenLDAP-technical list, I'm curious about community perspectives on a specific LDAP replication timeout and network-timeout settings: Setting "timeout=0" or "network-timeout=0" within a syncrepl/olcSyncrepl definition for replication settings is not the best practice for LAN environments. These parameters, when set to zero, instruct syncrepl to wait indefinitely for connections and replication operations to conclude. Within a LAN context, establishing new connections should ideally occur in less than a second. Delays beyond a couple of seconds should kick in the retry logic. This suggests that a more fitting network-timeout range is between 1 to 5 seconds. Concerning the "timeout" parameter, the ideal range might be between 60 to 120 seconds, to handle operations exceeding a minute, but again, kicking in retry logic if they exceed two minutes. I admit that my stance on the "timeout" setting is tentative, given that search operation duration hinges more on the provider's responsiveness rather than network speed alone. This approach ensures that LDAP replication remains both responsive and resilient, without compromising on efficiency or performance. Thoughts? -- Chris Paul | Rex Consulting |https://www.rexconsulting.net

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2024