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.