openldap-technical January 2025

openldap-technical@openldap.org

24 participants
24 discussions

Removing AutoCA overlay, objectClass, etc
by Brendan Kearney 06 Nov '25

06 Nov '25

list members, i have a multi-provider footprint that i want to remove the AutoCA functionality from. when i loaded the overlay, i set it to disabled, per the below: dn: olcOverlay={5}autoca objectClass: olcOverlayConfig objectClass: olcAutoCAConfig objectClass: top olcOverlay: {5}autoca structuralObjectClass: olcAutoCAConfig entryUUID: 739501f2-49ad-103e-911a-3dc9b40470bf creatorsName: uid=brendan,ou=domainusers,ou=users,dc=bpk2,dc=com createTimestamp: 20240117175614Z olcAutoCADays: 3650 olcAutoCAKeybits: 2048 olcDisabled: TRUE olcAutoCAserverKeybits: 2048 olcAutoCAuserClass: inetOrgPerson olcAutoCAserverClass: device olcAutoCAserverDays: 1826 olcAutoCAuserDays: 365 olcAutoCAuserKeybits: 2048 entryCSN: 20240117192443.210024Z#000000#001#000000 modifiersName: uid=brendan,ou=domainusers,ou=users,dc=bpk2,dc=com modifyTimestamp: 20240117192443Z note, olcDisabled is set to true. it seems that something went awry and even though i didn't want the capability active, i wound up with some caCertificate and caPrivateKey objects created in the DIT. it looks like i may have added the overlay in an active state and disabled it after the caCertificate/PrivateKey objects were created. i want to clean up things and remove the AutoCA pieces until i can test them better. what process is needed to remove the objects and overlay, as replication may play a part in some of the effort? i could imagine that deleting the caCertificate and caPrivateKey objects would be relatively straight forward, but the overlay may prove a bit more complicated. i found a message on this list from some time ago, https://www.openldap.com/lists/openldap-technical/201811/msg00075.html, that says i can stop the slapd instance, remove the overlay ldif files and restart the instance, to accomplish this task. the issue that i am trying to avoid is having to take down the entire fully replicated DIT, in order to delete the overlay and not have replication recreate it because one active node "didn't get the memo". are there any insights into how i can delete overlays without having replication recreate the objects i want to remove, all while still providing at least one instance to service requests? if it clarifies things, i am running 3 slapd instances behind a load balancer and both the config DB and DIT are replicated between all nodes. if it comes to it, i could take down all instances to perform this work, but i would like to avoid it if possible. thanks in advance, brendan kearney

3 9

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

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

Re: consumer replication net recovering
by Suresh Veliveli 12 Mar '25

12 Mar '25

This is another instance where replication stops. Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20241223060050.594465Z#000000#000#000000 tid 0x7f5aed0fb640 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_search (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 uid=xxxx,ou=People,dc=georgetown,dc=edu Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_modify uid=xxxxx,ou=People,dc=georgetown,dc=edu (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_message_to_entry: rid=143 DN: uid=xxxxx,ou=People,dc=georgetown,dc=edu, UUID: db41232e-527d-103f-995c-4344349468b5 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20241223060104.603554Z#000000#000#000000 tid 0x7f5aed0fb640 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_search (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 uid=yyyyy,ou=People,dc=georgetown,dc=edu Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_modify uid=yyyy,ou=People,dc=georgetown,dc=edu (0) No "syncrep_" messages were logged after the above. Regards, Suresh On Mon, Dec 23, 2024 at 2:42 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 5:46 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > I do have these but no syncrepl_sync. > > > > > > Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: syncrepl_message_to_entry: > > rid=129 DN: uid=xxxx,ou=xxxx,dc=georgetown,dc=edu, UUID: > > 37387976-3ae0-103f-94fc-3b4be3361dc7 > > Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: syncrepl_entry: rid=129 > > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) > > csn=20241212135921.652395Z#000000#000#000000 tid 0x7f671b7fe640 > > Yes sorry, that was a typo on my end. > > "syncrepl_" sync messages. Specifically you want to see the ones that > have > "be_" in them, but not "be_search". I.e., be_add, be_modify, etc. They > show the result of the operation, something like: > > syncrepl_entry: rid=100 be_modify <DN> (<result code>) > > --Quanah > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

5 30

OpenLDAP Self Registration/Password Reset Portal
by killian.greig＠gmail.com 11 Feb '25

11 Feb '25

I have been working on an OpenLDAP Self Registration/Password Reset Portal in Go that I will be releasing under a BSD license. Its still very much embryonic but if you are interested in taking an early look, please let me know. I'd love to get feedback on it. Kind regards, Killian

8 14

Re: OpenLDAP 2.6 Long Term Support Announcement
by Geert Hendrickx 06 Feb '25

06 Feb '25

Hi What is now the status of OpenLDAP 2.5 / 2.6 / 2.7 ? The website still lists 2.5.x as the current LTS release, and 2.6.x as the Feature Release. Has the below plan been delayed, or is the website just not up to date? Thanks for any clarification Geert On Sat, Aug 10, 2024 at 15:24:56 +0000, project(a)openldap.org wrote: > The OpenLDAP Project is pleased to announce the promotion of OpenLDAP > 2.6 from Feature Release to Long Term Support (LTS) Release, effective > January, 2025. It is now the recommended OpenLDAP version for > deployments that prioritize stability over features. The projected > lifespan for OpenLDAP 2.6 as the LTS release is five years. > > OpenLDAP 2.5 is now in its end of life stage and, at the discretion of > the Project, will receive critical fixes until January 15, 2027. After > that it will be designated as a historical release and no longer > supported or maintained by the Project. Users are encouraged to develop > a plan that will help them upgrade quickly to the new LTS version so > that they can continue on a supported release. > > OpenLDAP 2.7 is the new Feature Release and will see its first public > availability in the fall of 2024. > > ------------- > Compatibility > ------------- > > Replication: > Replication compatibility between OpenLDAP 2.5 and 2.6 is excellent. > The Project expects this to remain the case throughout the remaining > end-of-life stage of OpenLDAP 2.5. > > Configuration Files: > Configuration file compatibility between OpenLDAP 2.5 and 2.6 is > excellent, but may require some manual intervention at upgrade time, > particularly if you are using the OpenLDAP Load Balancer daemon. > > > ---------------------- > Additional Information > ---------------------- > > * The OpenLDAP Release Maintenance Policy can be found at > https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/t… > > * Notes covering upgrading from OpenLDAP 2.5 to 2.6 can be found at > https://www.openldap.org/doc/admin26/appendix-upgrading.html >

2 1

Re: consumer replication net recovering
by Suresh Veliveli 17 Jan '25

17 Jan '25

Ok. I will send you the conf files (minus creds). Can I send them directly to you? Thanks, Suresh On Fri, Jan 17, 2025 at 3:01 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, January 17, 2025 2:45 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > Hi Quanah, > > > > > > Understood. Unfortunately, we are experiencing the issue. Here is my > > configuration. > > > > > > On Master: > > database mdb > > suffix "dc=georgetown,dc=edu" > > . > > dbnosync FALSE > > checkpoint 128 5 > > maxsize 108993459200 > > > > > > > ># Replication > > overlay syncprov > > syncprov-checkpoint 10 5 > > syncprov-sessionlog 100 > > > > > > > > On the Replica: > > syncrepl rid=132 > > provider=ldaps://aaa-master-1.uis.georgetown.edu:636/ > > type=refreshAndPersist > > > > keepalive=300:5:5 > > retry="5 5 300 +" > > > > > > How do we go about fixing this? > > Looks like you're using the deprecated slapd.conf files, which can have > interesting issues because they may not properly order directives. > Without > the full slapd.conf for both provider and consumer (minus sensitive data > like passwords), there's not a lot for me to go off of here. > > --Quanah > > > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

Re: consumer replication net recovering
by Suresh Veliveli 17 Jan '25

17 Jan '25

Hi Quanah, Understood. Unfortunately, we are experiencing the issue. Here is my configuration. *On Master:* database mdb suffix "dc=georgetown,dc=edu" . dbnosync FALSE checkpoint 128 5 maxsize 108993459200 # Replication overlay syncprov syncprov-checkpoint 10 5 syncprov-sessionlog 100 *On the Replica:* syncrepl rid=132 provider=ldaps://aaa-master-1.uis.georgetown.edu:636/ type=refreshAndPersist keepalive=300:5:5 retry="5 5 300 +" How do we go about fixing this? Thanks, Suresh On Fri, Jan 17, 2025 at 2:30 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, January 17, 2025 10:51 AM -0700 Thomas Pritchard > <pritchardtw(a)gmail.com> wrote: > > > > > I have not experienced the master crashing but I have also experienced > > stalled replication regularly over the last 2 years. We've been on 2.46 > > and have keep alive enabled. We were hoping an upgrade would resolve the > > problem but it seems to exist on latest versions as well. I am also on > > aws ec2 instances. > > > I've been running OpenLDAP in AWS on EC2 instances for the last 3 years at > two different companies, and have never encountered this behavior. > > --Quanah > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2025