openldap-technical March 2025

openldap-technical@openldap.org

26 participants
31 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

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

Q: "olcDatabase: {1}mdb" from slapcat: why "{1}"?
by Windl, Ulrich 03 Apr '25

03 Apr '25

I have an amost philosophical question about LDIF and OenLDAP: Considering dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb # ... I wonder why olcDatabase needs the "{1}" when olcDatabase is a single-valued attribute. I understand that "olcDatabase={1}mdb" is needed for ordering the databases within cn=config, But why is the "{1}" repeated for the actual attribute? When I tried to remove it, I saw that after a slapcat it's there again. Kind regards, Ulrich

2 6

Re: [EXT] Re: Re: Re: accesslog with delta syncrepl: Why wouldn't contebnt be synced?
by Ondřej Kuzník 31 Mar '25

31 Mar '25

On Mon, Mar 31, 2025 at 06:31:30AM +0000, Windl, Ulrich wrote: > Ondřej, > > I must admit that I loaded the same LDIF using -w on both servers > (whenever the automatic sync would not work, or the server would not > start). However the LDIFs should have contained some entryCSN for each > entry, and if I had edited an entry, incremented the entryCSN "a bit". > In my understanding the contextCSN would be adjusted to be the latest > entryCSN, right? Hi Ulrich, `-w` will replace all CSNs from the LDIF with freshly generated ones, that's why I say you should only do that on a manual reload on *one* replica and then use their DB to reload everyone else with. You are rewriting the whole DB from scratch after all. > Still I'm surprised that some "Odd" CSN would cause a huge memory > allocation that causes the server to crash. Until it happens again, > I'll ignore it for now (as I have much more work to do) I'm not saying for sure it's causing it, very likely a bug but then not much we can do looking at that stack trace. Unless you provide concrete steps to reproduce the issue (preferable), usually logs + a full backtrace with debugging info available is the minimum we'd need to start investigating a crash... What I was saying is that what you did was very likely to cause a painful desync later, especially with cn=config and if you're likely to do this sort of thing again and again. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Syncrepl using certificate to authenticate, but certifivcated expired
by Windl, Ulrich 31 Mar '25

31 Mar '25

Hi! In my test environment (using openLDAP 2.5) the certificate used to authenticate syncrepl expired Friday night, so when returning on Monday, I was expe4cting error from syncrepl, but I did not see any. I suspect that this is due to persistent connections are being used. I see a big danger there: The operator may not notice that the certificated had expired as syncrepl still works (it seems, but there were no actual changes over the weekend)). However (as I understand it), syncrepl will start to fail once the network causes the persistent connection to fail, or a server is restarted. So I wonder: Is there a way to recognize expiration of the certificate? Maybe by limiting the life-time of a persistent connection, or slapd/syncrepl doing explicit checks on the certificate? Kind regards, Ulrich Windl

2 1

Can give me some books about openldap?
by anlex N 30 Mar '25

30 Mar '25

I have searched amazon.com and google.com. There are only a few books about openldap. I also review openldap official docs step by step. but I can not master openldap. if you have no books. What websites do you recommend to learn openldap?

4 8

LDIF for moddn: "ldap_rename: Server is unwilling to perform (53)"
by Windl, Ulrich 28 Mar '25

28 Mar '25

Hi! Reading https://kb.symas.com/en_US/configuration/configure-delta-syncrepl I realized that my syncprov is on the original database, not on the accesslog. So I tried to fix it my "moving" the overlay like this: dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config changetype: moddn newrdn: olcOverlay={0}syncprov deleteoldrdn: 1 newsuperior: olcDatabase={3}mdb,cn=config However as I got "ldap_rename: Server is unwilling to perform (53)" I wonder: Is my LDIF wrong, or is it an implementation restriction? Do I have to restart the server with a fresh config? Kind regards, Ulrich Windl

6 10

accesslog with delta syncrepl: Why wouldn't contebnt be synced?
by Windl, Ulrich 27 Mar '25

27 Mar '25

Hi! I had just asked https://serverfault.com/q/1177576/407952, but I'll summarize here: I think I configured delta-syncrepl for a MMR correctly using OpenLDAP >= 2.5.18 (cn=config also synced). However when I offlined one node and updated the main DIT via slapadd, the other node wouldn't update its DIT when the offlined node is online again. I wonder whether I have to empty or delete the corresponding accesslog, or is there some other step to perform? Is delta syncrepl looking at the accesslog only to detect changes? The syncrepl configs look like this for the DIT: olcSyncrepl: {0}rid=115 provider="ldap://server5/\ " searchbase="dc=..." type=refreshAndPersist \ retry="60 5 300 5 1800 +" logbase="cn=changelog-1" logfilter="(&(objectClass=au\ ditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog starttls=cr\ itical tls_reqcert=demand bindmethod=sasl saslmech=external tls_cert="/etc/ssl/\ servercerts/syncrepl.pem" tls_key="/etc/ssl/serverkeys/syncrepl.key" tls_cacert\ ="/etc/ssl/servercerts/ CA-bundle.pem" olcSyncrepl: {1}rid=116 provider="ldap://server6/\ " searchbase="dc=..." type=refreshAndPersist \ retry="60 5 300 5 1800 +" logbase="cn=changelog-1" logfilter="(&(objectClass=au\ ditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog starttls=cr\ itical tls_reqcert=demand bindmethod=sasl saslmech=external tls_cert="/etc/ssl/\ servercerts/syncrepl.pem" tls_key="/etc/ssl/serverkeys/syncrepl.key" tls_cacert\ ="/etc/ssl/servercerts/ CA-bundle.pem" Kind regards, Ulrich Windl

2 5

Upgrade from 2.4.45 to 2.4.49 and beyond
by justin＠1707.io 27 Mar '25

27 Mar '25

Hey Everyone, I've inherited some rather unmaintained servers as part of a new job and I'm looking to get them all up to date. We have a server for auth for satellite services that uses slapd/openLDAP. It's on a rather old version, and I'm wanting to upgrade it. I would like to see if anyone has advice on how to upgrade from Ubuntu 18.04.6 with the current 2.4.45 slapd/OpenLDAP to Ubuntu 24.04. I've looked around to try and find guides that show upgrades notes between versions but haven't found anything relevant. All advice appreciated! Regards, Justin

3 2

Notes on https://kb.symas.com/en_US/configuration/configure-delta-syncrepl
by Windl, Ulrich 24 Mar '25

24 Mar '25

Hi! Reading https://kb.symas.com/en_US/configuration/configure-delta-syncrepl I found some issues: 1. In "Chaining Overlay" there is a an extra "i" in "dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config i" 2. The syncrepl for "Multi-Master Replication (MMR)" still uses "mirrormode" 3. "Syncrepl" for MMR and cn=config is formatted badly (compared to slapd.conf version) Also for MMR there is a syncprov defined for the database to sync and the accesslog for that database. Why is syncprov for accesslog needed? Kind regards, Ulrich Windl

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2025