Le mardi 18 juin 2019, 12:36:56 CEST Quanah Gibson-Mount a écrit :
So, there is no way to filter on shadowExpire values which are less than today's timestamp?
shadowExpire is defined as an integer type, not as a timestamp, so no.
It sounds crazy that such basic needs are not covered by LDAP protocol, have I missed something?
It's not clear to me what this has to do with the LDAP protocol. The definition of the "expire" field from /etc/shadow is:
Expire : days since Jan 1, 1970 that account is disabled i.e. an absolute date specifying when the login may no longer be used.
So it's an integer (just as the RFC defines it). I would imagine you could write something that converts a current timestamp into the number of days, etc, and then perform a search.
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. We should be able to use extensible filters for these, and specify which ordering or substring rule we want to see used. And if attributes using integer syntax were to default to integerOrdering when not specified, that would seem more sane.
Côme
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.
openldap-technical@openldap.org
-
Côme Chilliet -
Michael Ströder