openldap-technical January 2025

openldap-technical@openldap.org

24 participants
20 discussions

ldap proxy
by fred750164＠gmail.com 04 Feb '25

04 Feb '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 21

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

04 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

6 6

Re: OpenLDAP 2.6 Long Term Support Announcement
by Geert Hendrickx 29 Jan '25

29 Jan '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 >

1 0

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

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

17 Jan '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 19

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

17 Jan '25

Hi Quanah, You are correct. I misspoke. We ran "bdb" in OpenLDAP: slapd 2.4.50 (Aug 6 2020 11:11:46). We switched to "mdb" when we went from 2.4.50 to 2.6.x version. The upgrade path, as mentioned, was a clean install of 2.6.x and export of db (slapcat) and import(slapadd). Regards, Suresh On Fri, Jan 17, 2025 at 12:48 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, January 6, 2025 6:47 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > It was "bdb". For migration, we did a clean install, used "slapcat" to > > export the db and "slapadd" to import. We used this procedure a > > number of times in the past when we switched OS, for upgrades etc. Do > > you have a recommended procedure in mind? > > >> We did an upgrade from 2.6.3 to 2.6.7 at the same time, changing the > >> backend db to "mdb". I think that's when we started to notice that > >> consumer replication is not recovering. So we upgraded again to 2.6.8 to > >> now 2.6.9. > > > There was no bdb backend in the 2.6 series. It was removed after the 2.4 > series, so the upgrade route you describe is not feasible. > > > --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)

1 0

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

17 Jan '25

It was "bdb". For migration, we did a clean install, used "slapcat" to export the db and "slapadd" to import. We used this procedure a number of times in the past when we switched OS, for upgrades etc. Do you have a recommended procedure in mind? Regards, Suresh On Mon, Jan 6, 2025 at 6:36 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, January 6, 2025 10:33 AM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > We just had another instance like this. Any suggestions? > > > > > > Thanks, > > Suresh > > > > > > On Fri, Jan 3, 2025 at 4:52 PM Suresh Veliveli > > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > > > > We did an upgrade from 2.6.3 to 2.6.7 at the same time, changing the > > backend db to "mdb". I think that's when we started to notice that > > consumer replication is not recovering. So we upgraded again to 2.6.8 to > > now 2.6.9. > > What backend were you using on 2.6.3 before migrating to mdb? At this > point, I'd suspect your migration may not have been executed correctly. > > --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

question regarding olcAccess peername.ip="0.0.0.0%0.0.0.0"
by cyril＠stoll.info 17 Jan '25

17 Jan '25

Hi there My predecessor created a couple of ACLs that are IP based. For example this one: olcAccess: {10}to dn.subtree="ou=something,dc=domain,dc=tld" by peername.ip="0.0.0.0%0.0.0.0" none by * +0 break Unfortunately I can't find any hints what "0.0.0.0%0.0.0.0" means. Can anyone explain that? The only part of the documentation where 0.0.0.0 occurs is in "20.4.4. Listener". In that case it looks to me like 0.0.0.0 is actually the localhost. In other areas (e.g. some Firewalls) 0.0.0.0 is the WAN/Internet which is pretty much the opposite of localhost. Since the subnetmask in the ACL is also 0.0.0.0 I assume that the whole construct peername.ip="0.0.0.0%0.0.0.0" means basically "any" IP. But in that case it does not make a lot of sense to me to even have that in the ACL. However there are a lot of configs leftover from my predecessor that don't make a lot of sense to me, so there's that. Thanks for any hints/explanations and best regards, Cyril

4 7

LMDB: Questions about the MDB_NOSYNC and MDB_MAPASYNC flags
by chris＠christrenkamp.com 16 Jan '25

16 Jan '25

Hi, I have several questions about the environment options in mdb_env_open. * MDB_NOSYNC states that as long as the filesystem preserves the write order, the database will lose durability, but preserve ACI. If we're using EXT4, does that mean we must mount the filesystem with "data=ordered" so LMDB will preserve ACI when used in combination with MDB_NOSYNC? Are there any other mount options we should use so we don't lose ACI? * MDB_MAPASYNC states it has the same corruption potential as MDB_NOSYNC. Does it preserve ACI if the filesystem preserves the write order like MDB_NOSYNC? * The docs states that (MDB_MAPASYNC | MDB_WRITEMAP) may be preferable over MDB_NOSYNC. When would you want to use one over the other? Is there a good rule of thumb to follow if you have to use one of these options? Thanks

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2025