openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

pwdHistory setting not being honored
by kevin martin 19 Aug '21

19 Aug '21

we HAD a password history setting with ppolicy to store 10 passwords in history, and that worked fine. Now, our policy has changed and only the last 4 passwords can't be used but when I try to change to a password that I know was not in the last 4 password changes I'm told that the password exists in my history. looking at an ldif dump my user has 10 pwdHistory entries but shouldn't the change in policy cause slapd to only look at my last 4 most recent pwdHistory entries, because it's certainly not doing so. do I have to dump the ldap into an ldif, remove pwdHistory entries, and reload it to make the password history stuff work correctly? version of slapd is 2.4.45. --- Regards, Kevin Martin

2 1

Re: migrate from 2.4 to 2.5, determine existing MDB format
by kevin martin 19 Aug '21

19 Aug '21

if I have multiple slapd servers running 2.4 can I update my master server to 2.5 with the new format and will the 2.4 mirrors be able to handle the new format or is it an all or nothing upgrade of all servers at once? --- Regards, Kevin Martin On Sat, Aug 7, 2021 at 2:31 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Saturday, August 7, 2021 3:48 PM +0200 Michael Ströder > <michael(a)stroeder.com> wrote: > > > On 8/7/21 1:34 PM, Howard Chu wrote: > >> Michael Ströder wrote: > >>> On 8/7/21 9:58 AM, Michael Ströder wrote: > >>>> On 8/7/21 12:02 AM, Quanah Gibson-Mount wrote: > >>>>> With OpenLDAP 2.5.7 and later it is possible to export a 2.4 > >>>>> database with slapcat in all circumstances. > >>>> > >>>> This will be very helpful because downstream packagers won't have to > >>>> provide two different versions of slapcat (as currently discussed on > >>>> opensuse-factory list). > >>> > >>> Is it sufficient to use commit d00efea7d19ad339f244f1325883031830125876 > >>> as back-port patch? > >> > >> backport into 2.5? Yes. > > > > Yes, of course into 2.5. > > I would also backport: > > commit dffa47ed752fd840e7a7cc0d1b95e4474f2de95b > Author: Howard Chu <hyc(a)openldap.org> > Date: Fri Aug 6 22:13:47 2021 +0100 > > ITS#9611 bconfig: canonicalize structuralObjectclass > > until 2.5.7 is available, as that is also for 2.4 to 2.5 upgrade > compatibility. It affects the dyngroup, dynlist, and memberof overlays. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Antw: [EXT] Re: Index seems to return wrong amount of candidate causing really poor search performance
by Ulrich Windl 19 Aug '21

19 Aug '21

>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 16.08.2021 um 23:20 in Nachricht <45379D5CBFA94DE3B1EA38E5(a)[192.168.1.4]>: > > ‑‑On Monday, August 16, 2021 10:00 PM +0000 Petteri Stenius > <Petteri.Stenius(a)ubisecure.com> wrote: > >> >> Thank you for your quick response. >> >> >> If idlexp is the accepted solution then I'd like to understand how to >> choose correct value for idlexp? >> >> >> I have quickly tested with most values. With my quick tests I could not >> find any significant impact on performance. Setting idlexp to maximum 31 >> did however cause slapd to crash with segmentation fault on my system. > > The appropriate value for any environment is entirely dependent on that > environment's indexing and attribute value distribution for those indexed > attributes. You generally want the minimum value for idlexp that allows > searches to function without performance problems. Increasing the idlexp > size increases slapd memory usage. Keep in mind that every increase in the > idlexp value increases the index slot range by a power of 2. The largest Did you mean "to a power of 2", or do you really mean "by a power of 2"? > value I've ever needed for a massively large db with wide value > distributions was 22. ... Regards, Ulrich

2 3

Re: OpenLDAP 2.5.7 available
by Michael Ströder 18 Aug '21

18 Aug '21

On 8/18/21 8:09 PM, project(a)openldap.org wrote: > OpenLDAP 2.5.7 is now available for download as detailed on our download page: As usual you can find packages for several openSUSE/SLE versions in this OBS project: https://build.opensuse.org/project/show/home:stroeder:openldap25 Feedback welcome! Notes: - Always backup your data before upgrading! - The packages received some packaging fixes and are usable now. - This is my private work not related to the OpenLDAP nor the openSUSE projects => blame me if something looks wrong with the packaging. - If unsure install openldap-ms, not openldap2. This uses a separate prefix /opt/openldap-ms. Ciao, Michael.

1 0

Index seems to return wrong amount of candidate causing really poor search performance
by chrichardso27＠gmail.com 18 Aug '21

18 Aug '21

Hi, Considering the following assumptions; - OpenLDAP version 2.4.51 - attributes objectClass and abc are indexed based on equality - the EQUALITY of attribute abc is based on distinguishedNameMatch - The database contains roughly 2 million entries - 2 entries have defined the attribute abc with a dn value cn=foo,dc=bar and objectClass=someClass - 2 entries have defined the attribute abc with a dn value cn=bar,dc=baz and objectClass=someClass Now, the issue started with really slow search performance using objectClass=someClass & abc=cn=foo,dc=bar as filter criteria. Debugging a while seems to indicate that the objectClass filter returns roughly 2 million entries as candidates. Now, one would expect that the second filter would return only the 2 potential candidates from the abc index, or a subset of the whole database but this is not the case. The second filter also returns nearly the whole database entries as potential candidates and causes really slow query performance. Interestingly, this only occurs when attribute abc has value cn=foo,dc=bar, but for some reason for the entry having attribute abc with value cn=bar,dc=baz the query returns immediately. In both cases, the actual entries matching the search return immediately but for the problematic search "(&(objectClass=someClass)(abc=cn=foo,dc=bar))", the completion of the search takes a long time (around 15 seconds to be precise). The issue started suddenly and wasn't a degradation of query performance over time. Few things I have tried - Rebuilt the whole database again - Reindex the existing database again - Testing with bdb and mdb as backends - Increased cache sizes for bdb to hold the whole database in cache - For bdb adjust the page size of the indexes according to suggestion by db_tuner - Change the order of the filters None of these made any difference. At the moment, there does not seem to be any good options to try. Any ideas or help would be greatly appreciated!

6 18

Configuring OpenLdap Proxy for Mirror-Mode
by Wayne McNaught 17 Aug '21

17 Aug '21

I have previously asked this question with no response 18 months ago, I would still like some assistance I have configured multiple LDAPs in a Mirror-Mode configuration and fronted by OpenLDAP in proxy mode. I understand that the list contained in the DBURI attribute is used to define the backends, and all the proxies are configured with the same list. I understand that first URI in the DbURI attribute will be used unless this fails, in which case it will fall back to the second URI. It will then keep on the second one until that one fails. This seems fine for most failure cases, when all proxies recognise the same failure. If communication fails between one proxy and the one backend LDAP and doesn't affect all proxies, writes will now be directed to different backends from different proxies. Is there some way to keep the proxies in-line or recognise a failure on one proxy and force the others to change. Or is this not needed?

4 4

Re: RE25 testing call #1 (OpenLDAP 2.5.7)
by Nick Folino 16 Aug '21

16 Aug '21

No issues with Fedora 34 On Mon, Aug 16, 2021 at 1:35 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > This is the first testing call for OpenLDAP 2.5.7. Depending on the > results, this may be the only testing call. > > Generally, get the code for RE25: > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/o… > > > > Extract, configure, and build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. > > Thanks! > > OpenLDAP 2.5.7 Engineering > Fixed lloadd client state tracking (ITS#9624) > Fixed slapd bconfig to canonicalize structuralObjectclass (ITS#9611) > Fixed slapd-mdb multival crash when attribute is missing an equality > matchingrule (ITS#9621) > Fixed slapd-mdb compatibility with OpenLDAP 2.4 MDB databases > (ITS#8958) > Fixed slapd-monitor number of ops executing with asynchronous backends > (ITS#9628) > Fixed slapd-sql to add support for ppolicy attributes (ITS#9629) > Fixed slapd-sql to close transactions after bind and search (ITS#9630) > Fixed slapo-accesslog to make reqMod optional (ITS#9569) > Fixed slapo-ppolicy logging when pwdChangedTime attribute is not > present (ITS#9625) > Documentation > slapo-accesslog(5) note that reqMod is optional (ITS#9569) > Add guide section on load balancer (ITS#9443) > Updated guide to document multiprovider as replacement for > mirrormode (ITS#9200) > Updated guide to clarify slapd-mdb upgrade requirements (ITS#9200) > Updated guide to document removal of deprecated options from > client > tools (ITS#9200) > > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

RE25 testing call #1 (OpenLDAP 2.5.7)
by Quanah Gibson-Mount 16 Aug '21

16 Aug '21

This is the first testing call for OpenLDAP 2.5.7. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.5.7 Engineering Fixed lloadd client state tracking (ITS#9624) Fixed slapd bconfig to canonicalize structuralObjectclass (ITS#9611) Fixed slapd-mdb multival crash when attribute is missing an equality matchingrule (ITS#9621) Fixed slapd-mdb compatibility with OpenLDAP 2.4 MDB databases (ITS#8958) Fixed slapd-monitor number of ops executing with asynchronous backends (ITS#9628) Fixed slapd-sql to add support for ppolicy attributes (ITS#9629) Fixed slapd-sql to close transactions after bind and search (ITS#9630) Fixed slapo-accesslog to make reqMod optional (ITS#9569) Fixed slapo-ppolicy logging when pwdChangedTime attribute is not present (ITS#9625) Documentation slapo-accesslog(5) note that reqMod is optional (ITS#9569) Add guide section on load balancer (ITS#9443) Updated guide to document multiprovider as replacement for mirrormode (ITS#9200) Updated guide to clarify slapd-mdb upgrade requirements (ITS#9200) Updated guide to document removal of deprecated options from client tools (ITS#9200) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

order of <what> clauses in ACLs
by Michael Ströder 13 Aug '21

13 Aug '21

HI! Frankly I forgot whether I asked this before: Let there be ACLs with dn.regex="..", attrs=foo,bar and val.regex=".." in the <what> clauses. Obviously depending on complexity of regex-pattern and length of DNs / avals the regex checking is more expensive than equality checking of attrs=. Can I improve ACL performance by order of <what> clauses or are they processed in fixed order anyway? If in fixed order, which one? Ciao, Michael.

3 3

Highly Available Proxies
by Wayne McNaught 12 Aug '21

12 Aug '21

I have asked this question previously and didn't get any answers, really hoping someone can help here this time around. I have configured multiple LDAPs in a Mirror-Mode configuration and fronted by OpenLDAP in proxy mode. I understand that the list contained in the DBURI attribute is used to define the backends, and all the proxies are configured with the same list. I understand that first URI in the DbURI attribute will be used unless this fails, in which case it will fall back to the second URI. It will then keep on the second one until that one fails. This seems fine for most failure cases, when all proxies recognise the same failure. If communication fails between one proxy and the one backend LDAP and doesn't affect all proxies, writes will now be directed to different backends from different proxies. Is there some way to keep the proxies in-line or recognise a failure on one proxy and force the others to change. Or is this not required?

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical