openldap-technical August 2023

openldap-technical@openldap.org

20 participants
32 discussions

Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
by Sean Gallagher 01 Aug '23

01 Aug '23

Hi All, This is loosely related to issue 10065 https://bugs.openldap.org/show_bug.cgi?id=10065, but can be read independently. I have devised a work-around to slapd's inability to check client names on Client certificates and am in the process of removing a proxy (haproxy) I had in front of my slapd server. I have however come across an annoying compromise and I'm offering here a suggestion on how to remove it. In particular, with the proxy, I could write rules targeting particular clients that worked, even before their initial "bind" operation by using the "sockname=" pattern in the access control rules. This does not seem possible when slapd talks directly to the clients. before the initial "bind" operation, only the IP address is available to tell clients apart, which are not very reliable. IP addresses are easily spoofed. It would be much better to use the client certificate to match against the particular client. Currently the client ID on the certificate is passed to the SASL layer with the sasl_setprop(...,SASL_AUTH_EXTERNAL,...) call. There it remains until the client performs a "bind" using the SASL EXTERNAL mechanism. At this point, the EXTERNAL client ID is used to derive a distinguished name by filtering it through the "olcAuthzRegexp". It should be noted that LDAP v3 does not require the client to perform such a bind operation. My Proposal is to expose the EXTERNAL identity to the ACL rules in a similar way to how the "real" prefix exposes the authentication identity - by creating an "external" prefix. As such, the matching rules externalanonymous externalusers externalself externaldn externaldnattr Could be used to restrict access to clients, even before or without a bind operation. To maintain naming consistency, The name passed to SASL could have the "olcAuthzRegexp" mapping applied before the ACL rule is applied. In this case, the "external" identity would be the same as the unprefixed identity, after a bind using SASL EXTERNAL mechanism had occured. This arrangement would have several advantages including: *) only exposing the userPassword to the particular client that needs it. *) enforcing client/IP address associations in a rigorous manner. *) general ACL rules for operations that do not need a "bind" operation. *) restricting SIMPLE binds to particular clients. Any Thoughts ? -- This email has been checked for viruses by AVG antivirus software. www.avg.com

6 27

updating from el7 to alpine openldap 2.6
by Marc 01 Aug '23

01 Aug '23

I am updating my ldap container and migrate from el7 to alpine. While running some test queries I noticed that the new 2.6 alpine has probably different defaults, I am getting "Size limit exceeded (4)". However this does not show in the ldap error log. What would be good loglevel config to see quickly if there is an issue with client queries? I am a little worried that if MTA's are getting incomplete results and dropping mail.

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2023