openldap-technical April 2025

openldap-technical@openldap.org

9 participants
21 discussions

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

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

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

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

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

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

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

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2025