Am Thu, 5 Mar 2020 18:15:41 +0100 schrieb Clément OUDOT clement.oudot@worteks.com:
Le 05/03/2020 à 10:10, Dieter Klünter a écrit :
Am Wed, 04 Mar 2020 13:36:08 +0000 schrieb Manuela Mandache manuela.mandache@protonmail.com:
Hello all,
We have a directory running on OpenLDAP 2.4.44 with the ppolicy overlay on the main database. When a new entry with a userPassword defined is created, pwdChangedTime is not defined, so this initial userPassword never expires.
The directory has been migrated from its OpenLDAP 2.3.34 instance (yes, we missed some steps...), and there the pwdChangedTime is set, and naturally equal to createTimestamp.
The overlay is configured as follows: dn: olcOverlay={2}ppolicy,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {2}ppolicy olcPPolicyDefault: ou=ppolicy,dc=example,dc=com olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE
Is there a parameter I missed which would switch on setting pwdChangedTime at entry creation? Do I have to provide some other configuration elements?
Or is it unreasonable to expect this initialisation of the attribute this way, and only a password change can set it? I think the setting at creation is rather handy... Using pwdMustChange would be difficult, we have a lot of client apps which would be forced to check and probably adapt their authentication procedures.
[...] The password attribute value must be set by a password modify exented operation in order to set password policy in effect, see man slapo-ppolicy(5)
Are you sure? The password modify extended operation is required for smbk5pwd overlay, but not for ppolicy overlay?
From ldappasswd(1) ldappasswd uses the LDAPv3 Password Modify (RFC 3062) extended operation.
I just test a creation of an entry with a password when ppolicy overlay is configured, and the pwdChangedTime is well created.
That is, what it should do.
-Dieter