openldap-devel

openldap-devel@openldap.org

1 participants
1442 discussions

SASL Binds and meaning of "users"
by Ondřej Kuzník 19 Apr '23

19 Apr '23

Recently seen a few people assume that authz-regexp search-based mappings enforce that an entry is found or the Bind is failed, which is not the case. Obviously the admin guide[0] should be adjusted not to cause more confusion but the question remains: Should we be able to decide whether an identity should be considered a "user" (Bind succeeds)? Right now, trusting certificates issued by a CA means *all* of them will always be accepted if valid for Binding against the server. Similar with other SASL mechanisms (kerberos, ...) but those tend to have another way of setting up a policy that can be decided for a specific combination of identity+server. It mostly matters for internal ACL purposes, those clients have passed a Bind and so are considered "users", complicating ACL design somewhat. Accepting a SASL Bind for authorisation in external clients is of less value, it can only give a yes/no answer where a more detailed answer is usually needed anyway. It might be possible to make the search-based mappings a policy point, letting a mapping that triggered but failed to map to an entry become an indication that the bind should be denied. This would be considerable change for some deployments out there, while it might protect some that (wrongly) assumed this to be the case already. Obviously "Direct Mappings" would stay unaffected because they should be well understood already[1]. [0]. https://www.openldap.org/doc/admin26/sasl.html#Search-based%20mappings [1]. Admin guide for direct mappings already says "it allows mapping to DNs which refer to entries not held by this server" in the first paragraph -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

3 2

pcache LDAP_MATCHING_RULE_IN_CHAIN support
by Johan 27 Mar '23

27 Mar '23

Hello all, We have an OpenLDAP instance proxying an active directory with back_meta and mr_passthru. We also have pcache on top, and as it do not support LDAP_MATCHING_RULE_IN_CHAIN, I looked about implementing it. I found that we could retrieve cached results with pcacheQueryID, but I can't get why this is not used in the current code? I dit it this way (querying pcacheQueryID for previsouly cached results) and tests are successful I can now declare templates like this : pcacheAttrset 0 * pcacheTemplate (&(objectClass=)(member:1.2.840.113556.1.4.1941:=)) 0 900 Plesae see attached patch Did I miss something about the use of pcacheQueryID ? or anything else ? Do you think this could be added upstream? P.S.: Is there a reason mr_passthru is not included to OpenLDAP ? not even in contrib ? Thanks for reading

3 4

multi-modify
by Howard Chu 06 Dec '22

06 Dec '22

One of the features Symas built into its Connexitor software (back in 2000, based on OpenLDAP 2.0) was the ability to perform modifications inline with a search request. Back then we used back-perl tweaked heavily to accomplish it. Having an ability to do batch modifies would be pretty useful in general. It's a feature that's commonly used in SQL as well. One way to do this in modern LDAP would be to define a batchModify control, to be sent with a Search request. The controlValue would contain a sequence of modOps, like a Modify request, but without the rest of the request body. For each entry returned by the Search request, the modOps would be applied to the entry before returning it. A response control would be attached to each entry, giving the result code for the modification attempt on that entry. Anyone interested in implementing this as an overlay? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

make test fail on riscv64 (was: RE26 testing call #1 (2.6.4))
by Michael Ströder 20 Nov '22

20 Nov '22

On 10/4/22 18:49, Quanah Gibson-Mount wrote: > This is the first testing call for OpenLDAP 2.6.4. Depending on the > results, this may be the only testing call. make test seems to fail for openSUSE on riscv64 already for test000-rootdse. Not sure whether that's an issue with build options in the .spec file or whatever. Those package builds run in temporary VMs [1]. Do you have a command at hand how to dump all relevant files in case any of the tests aborts? Can I lookup how the OpenLDAP project runs automated builds and tests in gitlab and borrow from that? Ciao, Michael. [1] https://build.opensuse.org/package/show/home:stroeder:branches:home:stroede…

3 12

FOSDEM 2023
by Howard Chu 12 Nov '22

12 Nov '22

Anyone interested in setting up at FOSDEM next year? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 6

[OldapWS] -> Proposal of a REST Web Service for CRUD Operations
by Olivier CHATOR 16 Sep '22

16 Sep '22

Dear all, I am a "long time user" of OpenLDAP core parts. If the core is very stable, I often received some request from application developers, complaining about the lack of REST Web Service API to manipulate their Directory objects. Of course, as far as I could see, there is commercial solution available to do this, or even a project using Spring. But I could not see a simple proposal based on a simple Apache Server and "fully free" of rights. I also saw (https://www.openldap.org/devel/contributing.html) that "The OpenLDAP Project welcomes contributions of independently-developed stand-alone LDAP-related software packages suitable for distribution separately from existing packages (e.g., OpenLDAP Software, JLDAP, JDBC-LDAP)". Then, I would like to propose a full Open Source first realease of a CRUD REST Web Service to manipulate OpenLDAP's Directory Objects. I know that this first release is very limited in term of features, but I think it does the "core job", and may be a common base to be enriched to build a real OpenLDAP REST API ? Package available here: https://drive.google.com/drive/folders/1s4zlTleJ1JWhQWP2kLGHtTRofpWNevS7?us… Thanks for your time reading this proposal, do not hesitate to ask if you have any question. Kind regards, Olivier Chator

1 0

Another bogus Usenix report on LMDB failure modes
by Howard Chu 14 Aug '22

14 Aug '22

Yet another paper out of University of Wisconsin researching open source projects like LMDB without communicating with anyone on the project https://www.usenix.org/conference/atc20/presentation/rebello I explain their mistake on Twitter https://twitter.com/hyc_symas/status/1558909442737012736 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Plain syncrepl vs. accesslog aka. ITS#9580
by Ondřej Kuzník 30 Jun '22

30 Jun '22

It's becoming untenable how a plain refresh cannot be represented in accesslog in a way that's capable of serving a deltasync session. Whatever happens, we have lost a fair amount of information to run a proper deltasync yet if we don't want to abandon this functionality, we have to try and fill some in. The current issues: With refreshDeletes=FALSE we get a list of entries in no particular order (each can be tagged with a CSN of the latest change), then have to synthesize a list of deletes with no idea what CSN they belong to at all, the best we can do is pick the whole CSN vector (we certainly *cannot* pick a single CSN for any of them, not even the highest timestamp). If we're receiving refreshDeletes=TRUE, we have lost less information as there are no implied deletes in the normal case where no subtree renames happen to remove a whole subtree from view (we fail here at the moment). Updates are still liable to be returned in arbitrary order, at least we know they're tagged with some sort of CSN, most likely the CSN of the last change to the entry except for entries that have been deleted. Some of the above is due to how the provider decides to send information down to us and we are free to change that. The major gap that the provider cannot fill is deletes implied by present phase ending. The entries deleted there cannot be tagged with a single CSN since we need to remember the whole vector to make a consistent decision whether or not to recreate an entry in the future. Since we do not follow RFC 4533 in many aspects already, e.g. we send cookies in the middle of a refresh, our cookies are often unusable on their own, we can just own up to this and define an extension to the protocol if needed. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

2 6

Patch for SSL ctx
by Michael Ströder 21 May '22

21 May '22

HI! Could someone please review whether this patch makes sense? https://build.opensuse.org/package/view_file/home:firstyear:branches:networ… Ciao, Michael.

2 1

Fwd: 2.5 deprecated backends
by Aapo Romu 28 Mar '22

28 Mar '22

We are heavily utilising back-sql on our product. Granted it has its issues but it does so far fulfill our needs. We are currently running on 2.4.58 which we build ourselves for Debian and RHEL/CentOS based systems. We needed couple of patches to back-sql to make it work for us. I just created issues (and added my patches) for them. I don't have a slightest idea if the patches are of any use for you but they make our environments work. Removing back-sql from future releases would make us stuck with 2.4 release. https://bugs.openldap.org/show_bug.cgi?id=9629 https://bugs.openldap.org/show_bug.cgi?id=9630 --- Aapo Romu --- Software Architect --- Eficode Oy On Mon, 9 Aug 2021 at 00:02, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Sunday, August 8, 2021 6:32 PM +0100 Howard Chu <hyc(a)symas.com> > wrote: > > > Quanah Gibson-Mount wrote: > >> For 2.5, we deprecated: > >> > >> back-ndb > >> back-sql > >> back-perl > >> > >> Should these be removed for 2.6? > > > > I still routinely build back-perl in master. Is there any reason to > > remove it? > > Not necessarily, that's why I started the discussion. back-bdb was > deprecated with 2.3, but was around for all of 2.4 as well. I see no > reason to keep back-ndb around. back-sql has numerous open issues, but > I've no real insight into whether it retains any usefulness. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

3 5

← Newer
1
2
3
4
5
6
7
...
145
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel