hi all,
I am using some pwdChangedTime range queries to warn users about password expiration.
An example filter might be:
(&(pwdChangedTime<=20211019000000Z)(pwdChangedTime>=20211018000001Z)(pwdPolicySubentry=cn=default270g,ou=policies,ou=people,dc=example,dc=edu))
since in-place upgrade to OpenLDAP-2.6.2 these queries return no entries.
If I remove either comparison condition:
(&(pwdChangedTime>=20211018000001Z)(pwdPolicySubentry=cn=default270g,ou=policies,ou=people,dc=example,dc=edu))
(&(pwdChangedTime<=20211019000000Z)(pwdPolicySubentry=cn=default270g,ou=policies,ou=people,dc=example,dc=edu))
they both work.
Did I forget some re-index?
thank you in advance for your time,
Francesco
On 7/11/22 10:38, Francesco Malvezzi wrote:
I am using some pwdChangedTime range queries to warn users about password expiration.
An example filter might be:
(&(pwdChangedTime<=20211019000000Z)(pwdChangedTime>=20211018000001Z)(pwdPolicySubentry=cn=default270g,ou=policies,ou=people,dc=example,dc=edu))
since in-place upgrade to OpenLDAP-2.6.2 these queries return no entries.
Are you 100% sure that there should be an entry returned with a pwdChangedTime value in this 24h interval?
If I remove either comparison condition: (&(pwdChangedTime>=20211018000001Z)(pwdPolicySubentry=cn=default270g,ou=policies,ou=people,dc=example,dc=edu)) (&(pwdChangedTime<=20211019000000Z)(pwdPolicySubentry=cn=default270g,ou=policies,ou=people,dc=example,dc=edu)) they both work.
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".
Ciao, Michael.
[...]
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,
regards,
Francesco
[1] a fresh ldappasswd or a modify on the pwdChangedTime attribute fixes the issue on a given entry.
--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.
Regards, Quanah
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
--On Monday, July 11, 2022 11:38 AM +0200 Francesco Malvezzi francesco.malvezzi@unimore.it wrote:
hi all,
I am using some pwdChangedTime range queries to warn users about password expiration.
An example filter might be:
(&(pwdChangedTime<=20211019000000Z)(pwdChangedTime>=20211018000001Z)(pwdP olicySubentry=cn=default270g,ou=policies,ou=people,dc=example,dc=edu))
since in-place upgrade to OpenLDAP-2.6.2 these queries return no entries.
If I remove either comparison condition:
(&(pwdChangedTime>=20211018000001Z)(pwdPolicySubentry=cn=default270g,ou=p olicies,ou=people,dc=example,dc=edu))
(&(pwdChangedTime<=20211019000000Z)(pwdPolicySubentry=cn=default270g,ou=p olicies,ou=people,dc=example,dc=edu))
they both work.
Did I forget some re-index?
What release did you upgrade from?
Regards, Quanah
On 11/07/22 17:16, Quanah Gibson-Mount wrote:
--On Monday, July 11, 2022 11:38 AM +0200 Francesco Malvezzi francesco.malvezzi@unimore.it wrote: [...]
Did I forget some re-index?
What release did you upgrade from?
from OpenLDAP-2.4.56,
thank you,
Francesco
openldap-technical@openldap.org
-
Francesco Malvezzi -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl