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.

Am Wed, 04 Mar 2020 13:36:08 +0000 schrieb Manuela Mandache <manuela.mandache(a)protonmail.com&gt;: > 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)

Am Thu, 5 Mar 2020 18:15:41 +0100 schrieb Clément OUDOT <clement.oudot(a)worteks.com&gt;: > 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(a)protonmail.com&gt;: >> >>> 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.

Hello Clément, Thanks for your answer. Well, if you don't get the same behavior as I do, it does seem I have a configuration issue. But what configuration issue can that be? Where should I look for it? The present dynamic configuration of the directory running on 2.4.44 was obtained through direct conversion of the static configuration of the directory running on 2.3.34 - where the pwdChangedTime is set when I add a new entry with ldapadd.

Le 06/03/2020 à 17:47, Quanah Gibson-Mount a écrit : > --On Friday, March 6, 2020 8:47 AM +0000 Manuela Mandache > <manuela.mandache(a)protonmail.com&gt; wrote: >> Thanks for your answer. Well, if you don't get the same behavior as I >> do, >> it does seem I have a configuration issue. But what configuration issue >> can that be? Where should I look for it? > > I might start with seeing if there are noticable differences between > the 2.3 and 2.4 ppolicy man pages.  And perhaps Clément can share the > config he was working with. :) Here is the overlay configuration: dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config [..] olcPPolicyHashCleartext: TRUE

Le 06/03/2020 à 17:47, Quanah Gibson-Mount a écrit : > --On Friday, March 6, 2020 8:47 AM +0000 Manuela Mandache > manuela.mandache(a)protonmail.com wrote: > > > Hello Clément, > > Thanks for your answer. Well, if you don't get the same behavior as I > > do, > > it does seem I have a configuration issue. But what configuration issue > > can that be? Where should I look for it?

> I might start with seeing if there are noticable differences between > the 2.3 and 2.4 ppolicy man pages.  And perhaps Clément can share the > config he was working with. :)

dn: cn=default,ou=ppolicies,dc=example,dc=com

pwdMaxAge: 31536000