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.
Thank you and regards,
Manuela
Sent with [ProtonMail](https://protonmail.com) Secure Email.
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)
-Dieter
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday 5 March 2020 10:10, Dieter Klünter dieter@dkluenter.de wrote:
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 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)
-Dieter
Thank you for the answer. It's the change of behavior between OpenLDAP 2.3.34 and 2.4.44 which surprised me.
Regards,
Manuela
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?
I just test a creation of an entry with a password when ppolicy overlay is configured, and the pwdChangedTime is well created.
You may have a configuration issue.
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
Le 05/03/2020 à 18:55, Dieter Klünter a écrit :
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.
Agree but the question was related to ppolicy overlay, not ldappasswd command.
When you create an entry, you do it with a standard ADD operation. It there is a password in the entry, the ppolicy overlay will do its job and create the pwdChangedTime attribute.
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday 5 March 2020 18:15, Clément OUDOT clement.oudot@worteks.com wrote:
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?
I just test a creation of an entry with a password when ppolicy overlay is configured, and the pwdChangedTime is well created.
You may have a configuration issue.
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.
Regards,
Manuela
Clément Oudot | Identity Solutions Manager
clement.oudot@worteks.com
Worteks | https://www.worteks.com
--On Friday, March 6, 2020 8:47 AM +0000 Manuela Mandache manuela.mandache@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?
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.
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. :)
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Le 06/03/2020 à 17:47, Quanah Gibson-Mount a écrit :
--On Friday, March 6, 2020 8:47 AM +0000 Manuela Mandache manuela.mandache@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?
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.
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 objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE olcPPolicyForwardUpdates: FALSE
The LDIF of the created entry:
dn: uid=testpolicy,ou=users,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top pwdPolicySubentry: cn=default,ou=ppolicies,dc=example,dc=com uid: testpolicy userPassword:: e1NTSEEyNTZ9VyttdTB0eU5LZThnamFDajBaU0J2Tm9MRFJ0anNTbDZqUkk1WTZ MREk2V1lSZlhCZ0YvRndBPT0= sn: test cn: test
The related ppolicy :
dn: cn=default,ou=ppolicies,dc=example,dc=com objectClass: device objectClass: extensibleObject objectClass: pwdPolicy objectClass: top cn: default pwdAttribute: userPassword pwdAllowUserChange: TRUE pwdCheckQuality: 1 pwdExpireWarning: 86400 pwdGraceAuthNLimit: 0 pwdInHistory: 4 pwdLockout: TRUE pwdMaxAge: 31536000 pwdMaxFailure: 3 pwdMinAge: 0 pwdMinLength: 4 pwdMustChange: TRUE pwdSafeModify: FALSE
On 3/9/20 10:19 AM, Clément OUDOT wrote:
Le 06/03/2020 à 17:47, Quanah Gibson-Mount a écrit :
--On Friday, March 6, 2020 8:47 AM +0000 Manuela Mandache manuela.mandache@protonmail.com 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
What happens if you set this to FALSE?
Ciao, Michael.
Le 09/03/2020 à 10:31, Michael Ströder a écrit :
On 3/9/20 10:19 AM, Clément OUDOT wrote:
Le 06/03/2020 à 17:47, Quanah Gibson-Mount a écrit :
--On Friday, March 6, 2020 8:47 AM +0000 Manuela Mandache manuela.mandache@protonmail.com 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
What happens if you set this to FALSE?
I don't see what it could change, as I create the user entry with an already encrypted password. So ppolicy overlay will not hash the password.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday 9 March 2020 10:19, Clément OUDOT clement.oudot@worteks.com wrote:
Le 06/03/2020 à 17:47, Quanah Gibson-Mount a écrit :
--On Friday, March 6, 2020 8:47 AM +0000 Manuela Mandache manuela.mandache@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
[...]
Hi Clément and hi all,
Thanks for your suggestions.
After all this time, I finally found my configuration problem: My directory was in a test environment and I didn't want to be bothered with password expiration, so I set pwdMaxAge at about 100 years (36,500 days). In seconds, this exceeds 2^31-1, and most of the ppolicy features were out of service.
Regards,
Manuela
openldap-technical@openldap.org
-
Clément OUDOT -
Dieter Klünter -
Manuela Mandache -
Michael Ströder -
Quanah Gibson-Mount