Hello,
Le 11/01/2022 à 16:27, Howard Chu a écrit :
David Coutadeur wrote:
Hi,
When doing a backup / restore on my OpenLDAP 2.5.9 instance, I faced a
behaviour that I think must be defined explicitely, in
draft-behera-ldap-password-policy,
or at least in OpenLDAP documentation.
My backup contains an entry like this:
dn: uid=test,ou=people,ou=branch,dc=example,dc=com
cn: test
sn: test
givenName: test
uid: test
userPassword: secret
pwdChangedTime: 20220110153431Z
mail: t...@domain.com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
There is also a valid default password policy: (which must be defined before
the users in the backup file)
dn: cn=default,ou=ppolicies,dc=example,dc=com
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
objectClass: organizationalRole
cn: default
pwdMaxAge: 7776000
pwdAttribute: userPassword
pwdCheckQuality: 2
pwdLockout: TRUE
pwdMaxFailure: 5
pwdMinLength: 6
pwdMustChange: TRUE
pwdCheckModule: /usr/local/openldap/lib64/ppm.so
When restoring the backup with this command:
ldapadd -x -h '127.0.0.1:389' -D 'cn=Manager,dc=example,dc=com' -w 'secret' -f
backup.ldif -e relax
I have an error showing that the attribute pwdChangedTime is duplicated and
must not be defined twice.
Backups should be restored with slapadd. Or you should strip all operational
attributes when using ldapadd.
As you can see in the entry above, there is no operational attributes
except pwdChangedTime.
I need to include pwdChangedTime, else the password won't expire at the
desired date.
I assume that the password policy does not replace my pwdChangedTime value with
the current date, but duplicates the attribute.
The ppolicy overlay sets the attribute to the current time if you have an aging
policy defined. Probably
it should check that pwdChangedTime does not already exist, but it is not
expected for normal users to be
LDAPadding entries with this operational attribute included.
I suppose an admin changing the pwdChangedTime of an entry with the
relax rule is a valid use case.
Thus, if it is a valid use case, we should be able to combine it with
other operations, like changing the userPassword.
So we should define the behaviour in such case.
I agree with your suggestion: it seems more interresting for the given
pwdChangedTime to take precedence over the one computed by the password
policy.
If it is ok for you, I can create an issue.
Could you define this behaviour somewhere?
1/ Is it possible to update the pwdChangedTime attribute along with the
userPassword ?
2/ If so, what value should be stored? (the given value or the current date?)
3/ Optionally, update OpenLDAP code according to the defined behaviour
Thanks in advance for your answer.
Regards,
David
--
David Coutadeur | IAM integrator
david.coutad...@worteks.com
+33 7 88 46 85 34
137 boulevard de Magenta, Paris 75010
Worteks | https://www.worteks.com
