openldap-technical November 2023

openldap-technical@openldap.org

22 participants
16 discussions

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

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

slapd 2.5 forwarding request .. please help
by enrico.becchetti＠gmail.com 09 Dec '23

09 Dec '23

Hi everyone, I have a particular setup and I need your help. I have a Slapd 2.5 running in a debian virtual machine. This ldap server has its own tree, dc=example,dc=com. I need this slapd server to forward the authentication requests for two domains other than its own, for example dc=example2,dc=com towards -> 192.168.1.1 dc=example3,dc=com towards -> 192.168.2.1 I read in the documentation that it is possible to do this forward but I can't modify the configuration using ldapmodify. Can you help me ? Thanks Willy

2 2

Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
by Ben Poliakoff 01 Dec '23

01 Dec '23

This is more of a practical question than a technical one, but it's prompted by a technical change: I'm *very* **very** belatedly transitioning from flat file slapd.conf config to slapd.d/OLC. With flat file configuration, it was straightforward to include text comments (e.g. "# blah blah"), but as far as I know there isn't any sort of analog for comments, when using slapd.d. Looking for any tips about how best to annotate slapd configuration, in a slapd.d/olc world. Does anyone have a practice that they find works well for them? Do people just maintain separate documents/wiki pages/etc that describe their servers' configs? Ben

13 15

solaris client ldap-backend to AD and DSE
by Craig H Silva (Cenitex) 30 Nov '23

30 Nov '23

I need to configure openldap as a proxy to AD so that AD can be upgraded to version 2019. Currently using Unix services for Windows, which works to provide nis information to solaris (11) and zfsappliance but it was deprecated after windows 2012. There's still nis info info in various attributes in AD schema, but the nis service is about to go. So an alternative is needed. I have the proxy configured with ldap-backend and its very happy to provide all the attribute information, but the solaris ldap client wants the DSE through the proxy and for the life of me I can't work out what is impeding it. I can "ldapsearch -Y EXTERNAL -H ldapi:/// -b "" -s base -LLL "+"" on the openldap system and the DSE is returned and I can get the DSE with an ldapsearch from the solaris client if I point directly at the AD ldap server, but if i point solaris at the openldap proxy - nada. This really upsets the ldapclient on solaris - it feels degraded. It feels like its an access issue as I can get a DSE when root on the openldap system. from config: # {1}ldap, config dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: dc=myorg,dc=lcl olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Schema" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read olcAccess: {3}to * by self read by users read by anonymous auth olcAddContentAcl: FALSE olcLastMod: FALSE olcMaxDerefDepth: 15 olcReadOnly: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbURI: "ldaps://myorgdevad.myorgdev.lcl:636" Any guidance appreciated - logs available on request. Craig Silva | Specialist Engineer – Unix & Storage Services Level 18, 80 Collins Street, Melbourne 3000 (03) 9063 5126 cenitex.vic.gov.au Cenitex acknowledges the Traditional Owners and custodians of the land and we pay our respects to their Elders, past, present and emerging. We are an inclusive workplace that embraces diversity in all its forms. ---------------------------------------------------------------------- Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email.

2 2

Re: Need assistant to Implement and Configure OpenLDAP for users authentication from Multi-Domain
by Quanah Gibson-Mount 28 Nov '23

28 Nov '23

--On Thursday, November 23, 2023 12:21 PM +0000 Sunil Sharma <sunil.sharma(a)mdsglobalit.com> wrote: > • What would be the Best OS for OpenLDAP currently, is it Linux, > CentOS or any other? Generally any current linux distribution with a current openldap release. > • We have users from Multi-Domain where these domains do not have any > trust relationship between each other and we need to authenticate the > users from multi-Domain for UC applications (CUCM, CUC, CER, UCCE, > Expressways and Jabber). > > > > We are looking if we can sync the user database from > these multidomain to a single OpenLDAP server and then from this OpenLDAP > to UC applications using single search base for authentication, is this > possible? Probably? --Quanah

1 0

Access to cn=monitor from read-only ldap
by Kevin Cousin 21 Nov '23

21 Nov '23

Hi List, I've got an LDAP architecture with one read-write OpenLDAP (primary) and some read-only OpenLDAP (replica). I load the cn=monitor backend on the primary? is it sufficient to have the cn=monitor backend on the slave too or should I activate it on the replicas ? Regards, Kevin C

3 2

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2023