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: test@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.
I assume that the password policy does not replace my pwdChangedTime value with the current date, but duplicates the attribute.
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 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: test@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.
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.
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
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: test@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
Good morning,
May I suggest trying to import the backup.ldif with the default ppolicy with MaxAge=0:
dn: cn=default,ou=ppolicies,dc=example,dc=com pwdMaxAge: 0
So that it maybe will not add pwdChangedTime operational attribute automatically, and it does not conflict when importing the account objects. Afterwards, you can change pwdMaxAge of the default policy to your desire value.
Regards,
PS: I am not sure if it will work, but I guess it could be tried.
On Wed, Jan 12, 2022 at 10:35 AM David Coutadeur david.coutadeur@gmail.com wrote:
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: test@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.coutadeur@worteks.com +33 7 88 46 85 34 137 boulevard de Magenta, Paris 75010
Worteks | https://www.worteks.com
On 1/12/22 10:47, Óscar Remírez de Ganuza Satrústegui wrote:
May I suggest trying to import the backup.ldif with the default ppolicy with MaxAge=0:
dn: cn=default,ou=ppolicies,dc=example,dc=com pwdMaxAge: 0
So that it maybe will not add pwdChangedTime operational attribute automatically, and it does not conflict when importing the account objects. Afterwards, you can change pwdMaxAge of the default policy to your desire value.
I did not test the above.
But even if it would work it would not be an appropriate solution for the use-case "the admin restores a single user" without impacting general password policy enforcement.
Ciao, Michael.
On 1/12/22 10:35, David Coutadeur wrote:
Le 11/01/2022 à 16:27, Howard Chu a écrit :
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.
This is IMO indeed a tricky one:
I find arguments for the current behaviour but also for accepting submitted pwdChangedTime value in case relax rules control is used.
One could argue that the distinction between the two use-cases
"admin restores userPassword/pwdChangedTime"
and
"admin sets new userPassword"
can be deferred to ACL validation. The admin must have manage privilege on pwdChangedTime for the restore to succeed.
(There's still no authz for control usage...)
Ciao, Michael.
On Wed, Jan 12, 2022 at 05:28:32PM +0100, Michael Ströder wrote:
On 1/12/22 10:35, David Coutadeur wrote:
I suppose an admin changing the pwdChangedTime of an entry with the relax rule is a valid use case.
This is IMO indeed a tricky one:
I find arguments for the current behaviour but also for accepting submitted pwdChangedTime value in case relax rules control is used.
Modify requests seem to support this, gating it on ACL (password administrator role) + Relax control.
One could argue that the distinction between the two use-cases
"admin restores userPassword/pwdChangedTime"
and
"admin sets new userPassword"
can be deferred to ACL validation. The admin must have manage privilege on pwdChangedTime for the restore to succeed.
Those two would be distinguished by providing the new pwdChangedTime value in the Add?
From that perspective it might make sense to support this in Adds as we do in Modifies. Haven't thought about it too much yet. If you achieve consensus that the existing situation should change, please file an ITS addressing the above concerns and argue what Behera the draft intended.
AFAIK you should already be able to add the user and then set userPassword+pwdChangedTime if you have the rights.
Regards,
Hi,
For information, I have made a proposition in an issue here:
https://bugs.openldap.org/show_bug.cgi?id=9794
Feel free to comment or propose other ideas.
Regards,
David
Le 12/01/2022 à 17:45, Ondřej Kuzník a écrit :
On Wed, Jan 12, 2022 at 05:28:32PM +0100, Michael Ströder wrote:
On 1/12/22 10:35, David Coutadeur wrote:
I suppose an admin changing the pwdChangedTime of an entry with the relax rule is a valid use case.
This is IMO indeed a tricky one:
I find arguments for the current behaviour but also for accepting submitted pwdChangedTime value in case relax rules control is used.
Modify requests seem to support this, gating it on ACL (password administrator role) + Relax control.
One could argue that the distinction between the two use-cases
"admin restores userPassword/pwdChangedTime"
and
"admin sets new userPassword"
can be deferred to ACL validation. The admin must have manage privilege on pwdChangedTime for the restore to succeed.
Those two would be distinguished by providing the new pwdChangedTime value in the Add?
From that perspective it might make sense to support this in Adds as we do in Modifies. Haven't thought about it too much yet. If you achieve consensus that the existing situation should change, please file an ITS addressing the above concerns and argue what Behera the draft intended.
AFAIK you should already be able to add the user and then set userPassword+pwdChangedTime if you have the rights.
Regards,
openldap-technical@openldap.org
-
David Coutadeur -
Howard Chu -
Michael Ströder -
Ondřej Kuzník -
Óscar Remírez de Ganuza Satrústegui