pwdHistory setting not being honored
by kevin martin
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
1 year, 9 months
Re: migrate from 2.4 to 2.5, determine existing MDB format
by kevin martin
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>
>
1 year, 9 months
Antw: [EXT] Re: Index seems to return wrong amount of candidate causing really poor search performance
by Ulrich Windl
>>> 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
1 year, 9 months
Re: OpenLDAP 2.5.7 available
by Michael Ströder
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 year, 9 months
Index seems to return wrong amount of candidate causing really poor search performance
by chrichardso27＠gmail.com
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!
1 year, 9 months
Configuring OpenLdap Proxy for Mirror-Mode
by Wayne McNaught
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?
1 year, 9 months
Re: RE25 testing call #1 (OpenLDAP 2.5.7)
by Nick Folino
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...
> >
>
> 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 year, 9 months
RE25 testing call #1 (OpenLDAP 2.5.7)
by Quanah Gibson-Mount
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...>
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 year, 9 months
order of <what> clauses in ACLs
by Michael Ströder
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.
1 year, 9 months
Highly Available Proxies
by Wayne McNaught
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?
1 year, 9 months
