Quanah Gibson-Mount quanah@fast-mail.org schrieb am 12.07.2022 um 18:19
in Nachricht <DF246C4B7CC06679D467B085@[192.168.1.17]>:
‑‑On Tuesday, July 12, 2022 1:31 PM +0200 Francesco Malvezzi francesco.malvezzi@unimore.it wrote:
[...]
Whatever "it works" really means. Without seeing example entries and their pwdChangedTime values it's impossible to say anything meaningful ‑ except the usual "it works for me".
it turns out this malfunctioning is affecting only entries whose password has been changed last time before the upgrade [1].
So to be sure that 'it works for you' you should pick a pretty old entry and craft the range pwdChangedTime query accordingly.
And of course this applies to you only if you did a in‑place update. If you slapcat‑ed and slapadd‑ed your entries, you are pretty safe,
This is due to ITS#9513 which changed the generalizedTime indexer. So any time‑based attributes need to be reindexed (or database exported/imported will fix it too). This got missed being documented on the OpenLDAP side. Can also affect replication when an in‑place upgrade is done.
Can't that be detected and fixed automatically?
Regards, Quanah