Hello all,
I updated our slapd daemon from 2.4 to 2.5 and want to use pwdEndTime operation attribute I read a lot of docs and can not find how I can add this attribute for all existing users.
It is an internal operation attribute that was introduced in slapd version 2.5 (OpenLDAP 2.5+ now ships the ppolicy schema hard-coded in the overlay slapo-ppolicy)
So as I see this attribute has no true/false or other flag (it is internal scheme attribute), which allows me to add it to dn: cn=passwordDefault,ou=Policies,dc=zone,dc=net or policy overlay olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
os is there any way I can enable it and update existing users with pwdEndTime attribute?
On 10/9/23 16:46, Volodymyr Lisnyi wrote:
So as I see this attribute has no true/false or other flag (it is internal scheme attribute), which allows me to add it to dn: cn=passwordDefault,ou=Policies,dc=zone,dc=net or policy overlay olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
os is there any way I can enable it and update existing users with pwdEndTime attribute?
Hey
You are not supposed to add this attribute to a policy. Because it is an operational attribute you need to add it to the user entries.
Hello Souji,
Ok, I can add it to the user entries, but what I see is that new users also don't have this attribute. So what is the procedure (also can not find this in the manual) to enable it by default because I can not add it to the new users manually on a regular basis? Also from docs not clear if both *pwdStartTime and **pwdEndTime *are needed or if I can use only the last *pwdEndTime.*
On Tue, Oct 10, 2023 at 4:38 PM Souji Thenria mail@souji-thenria.net wrote:
On 10/9/23 16:46, Volodymyr Lisnyi wrote:
So as I see this attribute has no true/false or other flag (it is internal scheme attribute), which allows me to add it to dn: cn=passwordDefault,ou=Policies,dc=zone,dc=net or policy overlay olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
os is there any way I can enable it and update existing users with pwdEndTime attribute?
Hey
You are not supposed to add this attribute to a policy. Because it is an operational attribute you need to add it to the user entries.
-- Souji Thenria
On 10/10/23 14:46, Volodymyr Lisnyi wrote:
Ok, I can add it to the user entries, but what I see is that new users also don't have this attribute. So what is the procedure (also can not find this in the manual) to enable it by default because I can not add it to the new users manually on a regular basis?
What are you trying to archive? The attribute might be automatically added if you have defined the pwdMaxAge in your policy.
Also from docs not clear if both pwdStartTime and pwdEndTime are needed or if I can use only the last pwdEndTime.
In my opinion the man page (slapo_ppolicy(5)) is quite clear about this:
tl;dr pwdStartTime defines when the becomes valid and pwdEndTime defines when the password becomes invalid for a user.
pwdStartTime: This attribute specifies the time the entry's password becomes valid for authentication. Authentication attempts made before this time will fail. If this attribute does not exist, then no restriction applies.
pwdEndTime: This attribute specifies the time the entry's password becomes invalid for authentication. Authentication attempts made after this time will fail, regardless of expiration or grace settings. If this attribute does not exist, then this restriction does not apply.
In case pwdStartTime is greater than pwdEndTime: Note that pwdStartTime may be set to a time greater than or equal to pwdEndTime; this simply disables the account.
Hello Souji,
The attribute might be automatically added if you have defined the
pwdMaxAge in your policy.
we have it in the policy (and it was there before the upgrade from 2.4 to 2.5) dn: cn=passwordDefault,ou=Policies,dc=domain,dc=net ... pwdMaxAge: 31536000
but users don't have pwdEndTime, they have only pwdChangedTime: 20221219200631Z and in case the password expires in a year they also get pwdReset: TRUE
That is why I am not sure how to enable this pwdEndTime operation attribute (because I can not find any flag for "dn: cn=passwordDefault,ou=Policies,dc=domain,dc=net" or "dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config")
Sorry, I missed that "If this attribute does not exist, then no restriction applies.", so pwdStartTime can be absent without any problems.
On Tue, Oct 10, 2023 at 5:58 PM Souji Thenria mail@souji-thenria.net wrote:
On 10/10/23 14:46, Volodymyr Lisnyi wrote:
Ok, I can add it to the user entries, but what I see is that new users also don't have this attribute. So what is the procedure (also can not find this in the manual) to enable it by default because I can not add it to the new users manually on a regular basis?
What are you trying to archive? The attribute might be automatically added if you have defined the pwdMaxAge in your policy.
Also from docs not clear if both pwdStartTime and pwdEndTime are needed or if I can use only the last pwdEndTime.
In my opinion the man page (slapo_ppolicy(5)) is quite clear about this:
tl;dr pwdStartTime defines when the becomes valid and pwdEndTime defines when the password becomes invalid for a user.
pwdStartTime: This attribute specifies the time the entry's password becomes valid for authentication. Authentication attempts made before this time will fail. If this attribute does not exist, then no restriction applies.
pwdEndTime: This attribute specifies the time the entry's password becomes invalid for authentication. Authentication attempts made after this time will fail, regardless of expiration or grace settings. If this attribute does not exist, then this restriction does not apply.
In case pwdStartTime is greater than pwdEndTime: Note that pwdStartTime may be set to a time greater than or equal to pwdEndTime; this simply disables the account.
-- Souji Thenria
On 10/10/23 16:31, Volodymyr Lisnyi wrote:
Hello Souji,
The attribute might be automatically added if you have defined the
pwdMaxAge in your policy.
we have it in the policy (and it was there before the upgrade from 2.4 to 2.5) dn: cn=passwordDefault,ou=Policies,dc=domain,dc=net ... pwdMaxAge: 31536000
but users don't have pwdEndTime, they have only pwdChangedTime: 20221219200631Z and in case the password expires in a year they also get pwdReset: TRUE
That is why I am not sure how to enable this pwdEndTime operation attribute (because I can not find any flag for "dn: cn=passwordDefault,ou=Policies,dc=domain,dc=net" or "dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config")
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. Why do zou want to use it, does the pwdMaxAge stopped working after the update?
Sorry, I missed that "If this attribute does not exist, then no restriction applies.", so pwdStartTime can be absent without any problems.
No worries.
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.
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.
On Tue, Oct 10, 2023 at 7:39 PM Souji Thenria mail@souji-thenria.net wrote:
On 10/10/23 16:31, Volodymyr Lisnyi wrote:
Hello Souji,
The attribute might be automatically added if you have defined the
pwdMaxAge in your policy.
we have it in the policy (and it was there before the upgrade from 2.4 to 2.5) dn: cn=passwordDefault,ou=Policies,dc=domain,dc=net ... pwdMaxAge: 31536000
but users don't have pwdEndTime, they have only pwdChangedTime: 20221219200631Z and in case the password expires in a year they also get pwdReset: TRUE
That is why I am not sure how to enable this pwdEndTime operation attribute (because I can not find any flag for "dn: cn=passwordDefault,ou=Policies,dc=domain,dc=net" or "dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config")
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. Why do zou want to use it, does the pwdMaxAge stopped working after the update?
Sorry, I missed that "If this attribute does not exist, then no restriction applies.", so pwdStartTime can be absent without any
problems.
No worries.
-- Souji Thenria
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
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
On Wed, Oct 11, 2023 at 12:41:21PM +0300, Volodymyr Lisnyi wrote:
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.
Hi Volodymyr, pwdStartTime+pwdEndTime are completely independent of pwdMaxAge. And if set on an account, they are meant to be managed by the password administrator, not OpenLDAP.
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.
Not sure what you mean.
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.
They should either implement ppolicy themselves or let slapd do this (e.g. by letting it handle Binds). Not much OpenLDAP can do if they ignore important parts of the spec (especially those that have been around for more than a decade).
Per the ppolicy drafts, a password is expired if pwdChangedTime+pwdMaxAge is in the past
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"
I can't speak for Okta and whether they even support ppolicy at all. From what you're describing they probably don't?
Regards,
Hello Ondřej,
pwdStartTime+pwdEndTime are completely independent of pwdMaxAge. And if
set on an account, they are meant to be managed by the password administrator, not OpenLDAP.
this is very interesting, where I can read information about this to prove okta support that okta ldap daemon must respect pwdChangedTime or pwdReset, because pwdStartTime+pwdEndTime isn't managed by OpenLDAP security policy.
Not sure what you mean.
I mean that we post the same, that slapd doesn't ignore pwdMaxAge
I can't speak for Okta and whether they even support ppolicy at all. From
what you're describing they probably don't?
anyway they need to somehow get the user password expiration date, but what you post about pwdStartTime+pwdEndTime (managed by the password administrator), seem like the only way is use pwdChangedTime user attribute + pwdMaxAge policy attribute or rely on pwdReset. But this just additional thoughts, which I will forward to them after confirmation that pwdStartTime+pwdEndTime is meant to be managed by the password administrator. Also, password administrator related to slapd means that a human (some script) add/remove/update pwdStartTime+pwdEndTime for each user and this can not be done by overlay/policy or other standard slapd functional.
On Wed, Oct 11, 2023 at 1:02 PM Ondřej Kuzník ondra@mistotebe.net wrote:
On Wed, Oct 11, 2023 at 12:41:21PM +0300, Volodymyr Lisnyi wrote:
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.
Hi Volodymyr, pwdStartTime+pwdEndTime are completely independent of pwdMaxAge. And if set on an account, they are meant to be managed by the password administrator, not OpenLDAP.
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.
Not sure what you mean.
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.
They should either implement ppolicy themselves or let slapd do this (e.g. by letting it handle Binds). Not much OpenLDAP can do if they ignore important parts of the spec (especially those that have been around for more than a decade).
Per the ppolicy drafts, a password is expired if
pwdChangedTime+pwdMaxAge
is in the past
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"
I can't speak for Okta and whether they even support ppolicy at all. From what you're describing they probably don't?
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Wed, Oct 11, 2023 at 02:42:06PM +0300, Volodymyr Lisnyi wrote:
Hello Ondřej,
pwdStartTime+pwdEndTime are completely independent of pwdMaxAge. And if set on an account, they are meant to be managed by the password administrator, not OpenLDAP.
this is very interesting, where I can read information about this to prove okta support that okta ldap daemon must respect pwdChangedTime or pwdReset, because pwdStartTime+pwdEndTime isn't managed by OpenLDAP security policy.
Hi you should read the latest ppolicy draft[0] and ppolicy manpage[1]. Also depends what kind of service Okta is meant to provide for you.
I can't speak for Okta and whether they even support ppolicy at all. From what you're describing they probably don't?
anyway they need to somehow get the user password expiration date, but what you post about pwdStartTime+pwdEndTime (managed by the password administrator), seem like the only way is use pwdChangedTime user attribute
- pwdMaxAge policy attribute or rely on pwdReset. But this just additional
thoughts, which I will forward to them after confirmation that pwdStartTime+pwdEndTime is meant to be managed by the password administrator. Also, password administrator related to slapd means that a human (some script) add/remove/update pwdStartTime+pwdEndTime for each user and this can not be done by overlay/policy or other standard slapd functional.
Password administrator is defined in the draft[0]. Okta can be it, just affects how certain features are (not) triggered.
To find out when a password expires, you can follow the spec[2]. The ppolicy overlay also implements the old Netscape password usability control and advertises itself as such in rootDSE, just use the control (oid 1.3.6.1.4.1.42.2.27.9.5.8) and with the right privileges you will be given feedback about the account's validity.
[0]. https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy [1]. https://openldap.org/software/man.cgi?query=slapo-ppolicy&sektion=5&... [2]. https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy-11#n...
Regards,
openldap-technical@openldap.org
-
Ondřej Kuzník -
Souji Thenria -
Volodymyr Lisnyi