On Tue, Oct 10, 2023 at 09:09:52PM +0300, Volodymyr Lisnyi wrote:
In this case it might be just another attribute, which can be used for example for a temp. guest account. In that case, a function to add it to all existing users would be pointless, because it is not designed for that.
This attribute is needed for regular accounts, we don't have guest accounts. That is why we need it on a regular basis and also need to propagate it to existing users.
pwdStartTime+pwdEndTime are used to set explicit password validity, regardless of password changes. Most often you need pwdMaxAge and react to password expiry accordingly.
Why do zou want to use it, does the pwdMaxAge stopped working after the update?
Some time ago (not sure when) okta ldap agent started ignoring "pwdReset: TRUE", slapd daemon doesn't ignore pwdMaxAge and correctly set "pwdReset: TRUE" for accounts with expired passwords. Okta support tested this on their end and asked us to add pwdEndTime to users and test if this helps. That's why I am trying to find a way add pwdEndTime to password policy and propagate it to the users.
slapd doesn't ignore pwdMaxAge if a policy is in effect (check!) and doesn't need to store anything except pwdChangedTime to do this[0], also pwdReset is independent of pwdMaxAge and you might want to check whether Okta has/should have manage permissions on userPassword attribute: depending on its understanding of ppolicy, that might/not be appropriate - having manage permissions on userPassword makes one "password administrator" and affects ppolicy behaviour (again read man slapo-ppolicy and the latest draft[1] for more information).
[0]. Per the ppolicy drafts, a password is expired if pwdChangedTime+pwdMaxAge is in the past [1]. https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy