openldap-technical July 2023

openldap-technical@openldap.org

29 participants
33 discussions

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

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

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

mdb_env_close, mdb_dbi_close, mdb_dbi_open
by Sam Dave 21 Aug '23

21 Aug '23

Hi, I'm interested in understanding these functions better. These are not criticisms.. since these functions are called rarely, I have no problem synchronizing them. I ask only for curiosity's sake. * mdb_env_close: "Only a single thread may call this function." Why can't different environments (separate files/dirs on disk) be closed from different threads? * mdb_dbi_close: "Handles should only be closed by a single thread." Why can't at least databases on different environments (separate files/dirs on disk) be closed from different threads? * mdb_dbi_open: "This function must not be called from multiple concurrent transactions in the same process." Why can't this function be called from different threads to open at least databases on different environments (separate files/dirs on disk)? What are the reasons for these limitations, under the hood? Could these functions have been designed in a different way, to allow for more multithreading (again, I'm not asking for this, I'm just curious). - Sam

2 4

ACL with filter memberOf
by Carsten Jäckel 06 Aug '23

06 Aug '23

Dear experts, an accessUser account used for application access has to be granted read access to member accounts of a group (groupOfNames). The list of attributes to be read by the accessUser is limited. The accessUser has to search in the limited attribute list (e. g. uid=abcd). Using OpenLDAP 2.4.49 (with configured overlay 'memberOf') we achieved this goal by configuring the following ACLs in olcAcces of olcDatabase={1}mdb,cn=config: {0}to * by self read by anonymous auth by * break {1}to dn.subtree="dc=example,dc=com" filter="(|(dc=example)(dc=users))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc=accessUsers,dc=example,dc=com" read by * break {2}to dn.subtree="dc=users,dc=example,dc=com" filter="(memberOf=cn=group1,dc=groups,dc=example,dc=com)" attrs="entry,objectclass,uid,cn,displayName,telephoneNumber,ou,mail,memberOf,entryDN" by dn.exact="cn=accessUser,dc=accessUsers,dc=example,dc=com" read by * break During migration to OpenLDAP 2.5 we eliminated the overlay 'memberOf' and replaced it's functionality by the overlay 'dynlist'. As a consequence we experienced that the filter statement in ACL {2} doesn't work any longer in OpenLDAP 2.5. Result of ldapsearch -x -W -D "cn=accessUser,dc=accessUsers,dc=example,dc=com" -b "dc=users,dc=example,dc=com" -s sub "(memberOf=cn=group1,dc=groups,dc=example,dc=com)" "entry objectclass uid cn displayName telephoneNumber ou mail memberOf entryDN" doesn't return any results alhough the group object contains members. We suppose that it has something to to with memberOf becoming some kind of 'virtual' attribute which may be only calculated when explicitly asked for. (Please correct this assumtion if it's incorrect.) These are the relevant parts of our configuration in OpenLDAP 2.5: Frontend: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=subschema" by * read mdb: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/symas/openldap-data olcAccess: {0}to * by self read by anonymous auth by * break olcAccess: {1}to dn.subtree="dc=example,dc=com" filter="(|(dc=example)(dc=us ers))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc=accessUse rs,dc=example,dc=com" read by * break olcAccess: {3}to dn.subtree="dc=users,dc=example,dc=com" filter="(|(dc=examp le)(dc=users))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc= accessUsers,dc=example,dc=com" read by * break" olcDbIndex: cn olcDbIndex: default eq,sub olcDbIndex: departmentNumber pres,eq,sub olcDbIndex: displayName olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: gidNumber eq olcDbIndex: givenName olcDbIndex: host eq olcDbIndex: inetUserStatus olcDbIndex: mail eq olcDbIndex: mailLocalAddress eq olcDbIndex: member eq olcDbIndex: memberOf eq olcDbIndex: memberUid eq olcDbIndex: objectclass eq olcDbIndex: sn olcDbIndex: sudoHost eq,sub olcDbIndex: sudoUser eq,sub olcDbIndex: uid olcDbIndex: uidNumber eq olcDbIndex: uniqueMember eq olcDbMaxReaders: 126 olcDbMaxSize: 10000000000 olcReadOnly: FALSE olcRootDN: cn=manager,dc=example,dc=com olcRootPW:: <abcd1234> olcSuffix: dc=example,dc=com dn: olcOverlay={0}refint,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {0}refint olcRefintAttribute: member olcRefintNothing: cn=someone,dc=example,dc=com dn: olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcPPolicyConfig objectClass: top olcOverlay: {1}ppolicy olcPPolicyDefault: cn=passwordDefault,ou=password_policies,ou=configurations ,dc=example,dc=com olcPPolicyHashCleartext: TRUE dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcDynListConfig objectClass: olcOverlayConfig objectClass: top olcOverlay: {2}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames dn: olcOverlay={3}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: {3}syncprov olcSpCheckpoint: 10 1 olcSpSessionlog: 20000 dn: olcOverlay={4}dds,olcDatabase={1}mdb,cn=config objectClass: olcDDSConfig objectClass: olcOverlayConfig olcOverlay: {4}dds olcDDSinterval: 1h olcDDSmaxTtl: 10d olcDDSminTtl: 10s olcDDSstate: TRUE olcDDStolerance: 5s dn: olcOverlay={5}otp,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: top olcOverlay: {5}otp My question now is: what is the correct ACL configuration/filter statement to ask for a user's group memberships to achieve our goal in OpenLDAP 2.5? Any help would be greatly appreciated! --Carsten

2 1

Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
by Sean Gallagher 01 Aug '23

01 Aug '23

Hi All, This is loosely related to issue 10065 https://bugs.openldap.org/show_bug.cgi?id=10065, but can be read independently. I have devised a work-around to slapd's inability to check client names on Client certificates and am in the process of removing a proxy (haproxy) I had in front of my slapd server. I have however come across an annoying compromise and I'm offering here a suggestion on how to remove it. In particular, with the proxy, I could write rules targeting particular clients that worked, even before their initial "bind" operation by using the "sockname=" pattern in the access control rules. This does not seem possible when slapd talks directly to the clients. before the initial "bind" operation, only the IP address is available to tell clients apart, which are not very reliable. IP addresses are easily spoofed. It would be much better to use the client certificate to match against the particular client. Currently the client ID on the certificate is passed to the SASL layer with the sasl_setprop(...,SASL_AUTH_EXTERNAL,...) call. There it remains until the client performs a "bind" using the SASL EXTERNAL mechanism. At this point, the EXTERNAL client ID is used to derive a distinguished name by filtering it through the "olcAuthzRegexp". It should be noted that LDAP v3 does not require the client to perform such a bind operation. My Proposal is to expose the EXTERNAL identity to the ACL rules in a similar way to how the "real" prefix exposes the authentication identity - by creating an "external" prefix. As such, the matching rules externalanonymous externalusers externalself externaldn externaldnattr Could be used to restrict access to clients, even before or without a bind operation. To maintain naming consistency, The name passed to SASL could have the "olcAuthzRegexp" mapping applied before the ACL rule is applied. In this case, the "external" identity would be the same as the unprefixed identity, after a bind using SASL EXTERNAL mechanism had occured. This arrangement would have several advantages including: *) only exposing the userPassword to the particular client that needs it. *) enforcing client/IP address associations in a rigorous manner. *) general ACL rules for operations that do not need a "bind" operation. *) restricting SIMPLE binds to particular clients. Any Thoughts ? -- This email has been checked for viruses by AVG antivirus software. www.avg.com

6 27

updating from el7 to alpine openldap 2.6
by Marc 01 Aug '23

01 Aug '23

I am updating my ldap container and migrate from el7 to alpine. While running some test queries I noticed that the new 2.6 alpine has probably different defaults, I am getting "Size limit exceeded (4)". However this does not show in the ldap error log. What would be good loglevel config to see quickly if there is an issue with client queries? I am a little worried that if MTA's are getting incomplete results and dropping mail.

2 2

OpenLDAP with DANE
by John Scott 30 Jul '23

30 Jul '23

Hello, Thanks to the TLS callback support, I discovered that using DANE with libldap is actually really easy. OpenSSL has DANE support built-in, so all you have to do is turn it on and get the DNS records. As a proof-of-concept, I've written an example that disables the use of certificate authorities and uses DANE alone, in accordance with their preference in the TLSA record, to connect to Debian's LDAP instance. Note that Debian currently uses GnuTLS for OpenLDAP which has, in my opinion, not so good DANE support, so this code won't work. I'm offering my help to the Debian maintainers though to change that. Code is at https://salsa.debian.org/-/snippets/649

2 1

lmdb and alignment clarification
by bach＠bullno1.com 27 Jul '23

27 Jul '23

I have read a few threads on lmdb alignment but I am still not clear on what kind of padding should be done. Use case: I want to store aligned SIMD vectors in the value and operate on them directly with SIMD instructions without copying. As I understand it, lmdb guarantees 2-byte alignment. However, it can also move nodes around for tree rebalancing or page reclaiming. Thus, merely aligning the key and value might not be enough. Right now, based on my reading of the code, I'm assuming that the data layout in a leaf page is like this: [page_header][mp_ptrs]...[node_header][key][value][node_header][key][value] Basically, nodes are stored contiguously in memory with `node_header` and `key` always aligned to 2-byte. New nodes are allocated from the bottom of the page and offsets are stored/allocated into MDB_page.mp_ptrs from the top. Is this correct? If so, to ensure that `value` has a certain alignment, even when accounting for nodes being moved around, one would also have to ensure that `sizeof(node_header) + sizeof(key) + sizeof(value)` is a multiple of the alignment. Is this reasoning correct? For the overflow page, is the structure similar? Just that one single page header is used for a number of contiguous pages.

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2023