openldap-technical October 2023

openldap-technical@openldap.org

30 participants
29 discussions

openldap TLSv1.0 is enabled
by Andre Rodier 15 May '25

15 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 12

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

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

Scaling slapd nodes in Kubernetes with the MDB Backend
by Alejandro Imass 05 Jan '24

05 Jan '24

Hi there! We are working on a new installation and decided to try something new.. In the past I would have gone with multi-master with ldap balancer but after reading and researching more and more on MDB, we decided to try to integrate OpenLDAP into our current CI/CD pipelines using K8s. What we tried so far and it seems to work is initialize a common persistence storage and then an auto scaling group that shares that common drive. Ech pod has as many threads as virtual CPU it may have, and none of the pods can write, except a dedicated write pod (single instance) with multiple threads for writing. Is there anything else we are missing here? Any experience scaling OpenLDAP with Kubernetes or other container technology. Thank you in advance for any comments, pointers or recommendations! -- Alex

3 4

syncrepl between 2.4.57.0.1 and 2.6.2-3
by Frank, Michael 16 Nov '23

16 Nov '23

Airbus Amber Dear all, basically I trying to establish a syncrepl/refreshAndpersist Setup between: OpenLDAP: 2.4.57.0.1 @ Solaris < - > OpenLDAP: 2.6.2-3 @ Rhel 9.latest (don`t ask) An intial syncrepl activation does works properly (replication of ou`s content in both directions), but when I afterwards restart one of the replication Partners, the sync failes and in consequence on one of replication Partner the ou`s are deleted. From logging point of view there are somekind of issues to identify the remote object via the UUID which leads then to the deletion: ##schnipp 6538d3db.38892890 0x7f9fe65fe640 nonpresent_callback: rid=044 nonpresent UUID 25a0c72c-0364-103e-83af-fb52f2a7ef64, dn ou=permissions,dc=xxx,dc=xxxx,dc=xxxxxx 6538d3db.388983a6 0x7f9fe65fe640 nonpresent_callback: rid=044 adding entry ou=permissions,dc=xxxx,dc=xxxxx,dc=xxxx to non-present list ###schnapp Unfortunately I cannot find any Information which says something useful about the basic backward compatibility of the synrepl/refreshAndPersist implementation from 2.6 to 2.4. Can someone state why this mission is hopeless in detail or should the setup work basically ? (I know the best practice : everywhere same versions...) Best regards and thanks in advance, michael This Item has been reviewed and was determined as not listed under German regulation, nor EU export controls, nor U.S. export controls. However, in the case of the item has to be resold, transferred, or otherwise disposed of to an embargoed country, to an end user of concern or in support of a prohibited end use, you may be required to obtain an export license. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

3 8

Issue with refint and rwm overlay
by Maksim Saroka 07 Nov '23

07 Nov '23

Hello, We have a strange situation with refint and rwm overlays on ldap replica. Looks like those overlays depend on each other and on position in the slapd.conf file regarding database section. However refint overlay is working in any position if rwm overlay is not specified. Here are the examples with positions in the file: Refint overlay work if: 1. rwm overlay section database section refint overlay section Refint overlay does not work if: 1. database section refint overlay section rwm overlay section 2. rwm overlay section refint overlay section database section Could you please explain to us the root cause of that as I can't find any explanation in the docs. -------- Maksim Saroka DevOps/System Administrator Exadel.com <https://exadel.com/> Follow Us on LinkedIn <https://www.linkedin.com/company/exadel/> -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.

2 5

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

Re: No matter what I try I get: ldap_modify: Insufficient access (50)
by Alejandro Imass 27 Oct '23

27 Oct '23

On Fri, Oct 27, 2023 at 5:58 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, October 27, 2023 10:51 AM +0200 Alejandro Imass > <aimass(a)yabarana.com> wrote: > > > Again for future people reading this, if you encounter ACL issues and you > > want to modify the LDIF database in /etc/openldap/slapd.d don't do it > > manually. > > Your advice here is generally wrong. > > You mean they SHOULD edit them manually ? I'm actually suggesting to use slapadd and slapmodify directly on the filesystem if everything else fails. What's wrong with that suggestion? >

2 1

No matter what I try I get: ldap_modify: Insufficient access (50)
by Alejandro Imass 27 Oct '23

27 Oct '23

OpenLDAP 2.6.6r1 on Apline Linux aarch64 Not sure what I am doing wrong but I am unable to change the rootDN's password. # ldapmodify -H ldapi:/// -Y EXTERNAL -D 'cn=config' << EOF > dn: olcDatabase={0}config,cn=config > changetype: modify > add: olcRootPW > olcRootPW: {SSHA}cZbRoOhRew8MBiWGSEOiFX0XqbAQwXUr > EOF SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Insufficient access (50) I also tried remotely, and same thing. I noticed *olcAccess: {0}to * by * none* in the config DB but I didn't put that there, and not sure how to change it. Here is the slapcat output: (Also, at the end I copied the LDIF I use to initialize the LDAP) / # slapcat -n 0 dn: cn=config objectClass: olcGlobal cn: config olcDisallows: bind_anon olcRequires: authc structuralObjectClass: olcGlobal entryUUID: 3ebf1971-b32e-41eb-ac58-a0a30fe18734 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.508761Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/openldap olcModuleLoad: {0}back_mdb.so olcModuleLoad: {1}refint.so olcModuleLoad: {2}memberof.so olcModuleLoad: {3}argon2.so structuralObjectClass: olcModuleList entryUUID: 3b732d07-c664-4294-87ca-d5e29a32aa6c creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.509009Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema structuralObjectClass: olcSchemaConfig entryUUID: c38bf741-8d4a-4e36-b012-22a70577d429 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.509955Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: cn={0}core,cn=schema,cn=config objectClass: olcSchemaConfig cn: {0}core [snip] ... dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcPasswordHash: {ARGON2} structuralObjectClass: olcDatabaseConfig entryUUID: 4459a62b-80f9-449c-b4a6-20cd2108a486 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.512390Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config *olcAccess: {0}to * by * none* olcAddContentAcl: TRUE olcLastMod: TRUE olcLastBind: FALSE olcLastBindPrecision: 0 olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 08d3cdfa-b552-45ab-a183-fc5802e9c910 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.512505Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/openldap/openldap-data olcSuffix: dc=foo,dc=bar olcRootDN: cn=admin,dc=foo,dc=bar olcRootPW:: e0FSR09OMn0kYXJnb24yaSR2PTE5JG09NDA5Nix0PTMscD0xJHVKeWYwVWZCMjVTUV RmWDdvQ3lLMnckVTQ1REpxRUZ3RDB5RmFMdlRWeUFDSEx2R013ek5HZjE5ZHZ6UFI4WHZHYw== olcDbIndex: objectClass eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: 169807ec-3bfc-4a20-b4ab-e60cddd777a2 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.512483Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf structuralObjectClass: olcMemberOfConfig entryUUID: f45b11d4-aba8-40ec-83b5-5688aa6c4c42 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.513061Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: olcOverlay={1}refint,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {1}refint olcRefintAttribute: memberof olcRefintAttribute: member olcRefintAttribute: uniqueMember olcRefintAttribute: manager olcRefintAttribute: owner olcRefintNothing: cn=admin,dc=foo,dc=bar structuralObjectClass: olcRefintConfig entryUUID: 498d5840-1ebf-43d9-ad16-264069969adc creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.513211Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: olcDatabase={2}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {2}monitor olcRootDN: cn=config olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 82712ebd-5149-496a-bec8-a2853249d9f3 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.513336Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z Here is the LDIF I am using to initialize the LDAP and populate slapd.d: # config global dn: cn=config objectClass: olcGlobal cn: config #TODO: fine tune security rlevel estrictions #olcSecurity: ssf=1 update_ssf=112 simple_bind=64 olcDisallows: bind_anon olcRequires: authc # dynamic backend modules: dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/openldap olcModuleload: back_mdb.so olcModuleLoad: refint.so olcModuleLoad: memberof.so olcModuleload: argon2.so # schemas dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif include: file:///etc/openldap/schema/cosine.ldif include: file:///etc/openldap/schema/inetorgperson.ldif include: file:///etc/openldap/schema/nis.ldif include: file:///etc/openldap/schema/dynamodel.ldif # frontend settings dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend olcPasswordHash: {ARGON2} # LMDB database definitions dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 1073741824 olcSuffix: dc=foo,dc=bar olcRootDN: cn=admin,dc=foo,dc=bar olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$uJyf0UfB25SQTfX7oCyK2w$U45DJqEFwD0yFaLvTVyACHLvGMwzNGf19dvzPR8XvGc olcDbDirectory: /var/lib/openldap/openldap-data olcDbIndex: objectClass eq # memberOf overlay dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf # refint overlay dn: olcOverlay={1}refint,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {1}refint olcRefintAttribute: memberof olcRefintAttribute: member olcRefintAttribute: uniqueMember olcRefintAttribute: manager olcRefintAttribute: owner olcRefintNothing: cn=admin,dc=foo,dc=bar dn: olcDatabase=monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: monitor olcRootDN: cn=config olcMonitoring: FALSE Thank you in advance for any pointers ! -- Alex

3 5

Re: No matter what I try I get: ldap_modify: Insufficient access (50)
by Alejandro Imass 27 Oct '23

27 Oct '23

On Thu, Oct 26, 2023 at 11:13 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thu> Try the following (and replace with the correct URL): > > > > $ ldifmodify -x -H ldap://localhost/ -D cn=config -W << EOF > > > dn: olcDatabase={0}config,cn=config > > > changetype: modify > > > add: olcRootPW > > > olcRootPW: {SSHA}cZbRoOhRew8MBiWGSEOiFX0XqbAQwXUr > > > EOF > > There doesn't appear to be an old olcRootPW value either, so that wouldn't > work. > > Thanks for your response. There actually is one in dn: olcDatabase={1}mdb,cn=config Anyway I solved my issue and was able to modify the config DB using slapadd and slapmodify directly on the filesystem as root and that is that. Thanks again for your help! -- Alex

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2023