Hello Ondřej,

> Most often you need pwdMaxAge and react to password expiry accordingly.

can you then explain why I have pwdMaxAge in the policy but users don't have pwdStartTime+pwdEndTime, that's what I am trying to achieve, but can not find any way to do this for now.

> 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

Maybe I was not clear, but I say the same that pwdMaxAge is not ignored by slapd and pwdChangedTime changed for the user during password change, same as pwdReset: True set after password expires confirm this.

> 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).

there is no problem with Okta managing users' passwords, the problem is that Okta ignores pwdReset and doesn't ask users to change expired passwords.

> 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

does this mean that pwdEndTime must be used to understand user password expiration?
And if yes, how I can enable it, because as I posted above I don't see any flags for this not in
"cn=passwordDefault,ou=Policies,dc=domain,dc=net" not in "dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config"

On Wed, Oct 11, 2023 at 11:48 AM Ondřej Kuzník <ondra@mistotebe.net> wrote:
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

--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP