HI!
I've implemented a sync job which has to also sync passwords with a password modification timestamp from an Oracle DB to OpenLDAP. There's a latency in this password sync so the exact password modification timestamp has to be copied from the source DB to attribute pwdChangedTime in OpenLDAP.
Setting the pwdChangedTime alone with the Relax Rules control is no problem. But when the add or modify request also contains the userPassword attribute slapo-ppolicy also wants to add a (later) value for pwdChangedTime and this results in:
Constraint violation: attribute 'pwdChangedTime' cannot have multiple values
Any chance to achieve this in a single add/modify request? I think this scenario is not so unusual in the real world. So slapo-ppolicy should not generate 'pwdChangedTime' if it's already in the write request in case of Relax Rules control enabled.
Ciao, Michael.
On 11/11/2011 12:19 PM, Michael Ströder wrote:
HI!
I've implemented a sync job which has to also sync passwords with a password modification timestamp from an Oracle DB to OpenLDAP. There's a latency in this password sync so the exact password modification timestamp has to be copied from the source DB to attribute pwdChangedTime in OpenLDAP.
Setting the pwdChangedTime alone with the Relax Rules control is no problem. But when the add or modify request also contains the userPassword attribute slapo-ppolicy also wants to add a (later) value for pwdChangedTime and this results in:
Constraint violation: attribute 'pwdChangedTime' cannot have multiple values
Any chance to achieve this in a single add/modify request? I think this scenario is not so unusual in the real world. So slapo-ppolicy should not generate 'pwdChangedTime' if it's already in the write request in case of Relax Rules control enabled.
If I understand your problem correctly, the operation you are performing should be considered administrative, and thus password policy should not apply. I believe you already raised discussions related to clearly identifying administrative operations in order to bypass some overlays. These issues definitely ought to be considered.
p.
openldap-technical@openldap.org