Re: Extensible filters and ordering searches: filtering shadowExpire by range?

[Michael Ströder <michael@stroeder.com>]

On 6/19/19 8:56 AM, Côme Chilliet wrote:
> Yeah this is what I was calling timestamp sorry, getting the integer
> for today is easy, but it seems there is no way for writing a search
> filter with greater-than or lesser-than for this attribute.>
> It has to do with the LDAP protocol that LDAP lets schema define
> attributes in ways that forbid substring and range filters.

LDAP models (see RFC 4512) allows this kind of schema definitions.
Sometimes it makes sense to e.g. explicitly omit matching rules.
So it's not a deficiency of the "LDAP protocol".

The object class shadowAccount and its attribute shadowExpire was
defined in RFC 2307 and schema shipped with OpenLDAP just sticks with
that. One has to remember that the object class shadowAccount was
defined for providing a simple shadow map on Unixoid systems. Thus the
attribute shadowExpire was never meant to be used in LDAP search operations.

You would have to publish a revised RFC for fixing that.

But nobody will work on that. It's because you should never ever rely on
attribute shadowExpire for password expiry because it's only enforced
when processing a shadow map on a Unixoid system and it's useless for
password expiry when processing LDAP bind operations.

Furthermore for user changing his/her own password I often see an ACL
like that:

access to
  attrs=userPassword,shadowExpire
    by group="cn=slapd Password Admins,dc=example,dc=com" write
    by self write
    by anonymous auth

Can you see what's wrong with it?
(Actually there are two issues in the above ACL.)

To summarize the summary of the summary:
=> Use slapo-ppolicy for enforcing password expiry instead.

Ciao, Michael.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature