On Sep 28, 2021, at 6:09 PM, Mark Reynolds
<mreynolds(a)redhat.com> wrote:
You are not, you set it up correctly. One thing you did not list was that you are
supposed to add an aci that allows that group to update the userpassword attribute, but
that would not explain the constraint violation. It could be a bug.
One quick question, are you also using a subtree/local password policy that might be
conflicting with the global password policy? Local policies override the global policy.
Mark
Mark,
Thank you for the quick response!
I do have an aci set up and I can update passwords as
uid=selectivesync389,ou=svc_accts,dc=domain,dc=org if I pass in a plain text password.
I don’t believe we have a subtree/local policy but we did import this data from an ancient
389 install that we’re upgrading from. Does this answer your question? We dabbled a bit
in local policies a few years ago but finally just set policies globally in cn=config.
That knowledge is old but my notes say this should return subtree/local policies:
morgan@woodrow-2 ~ % ldapsearch -LLL -H ldaps://tstds21.domain -D cn=directory\ manager -x
-w pass '(objectclass=passwordpolicy)'
morgan@woodrow-2 ~ %
please correct me if my search is wrong.
thanks,
-morgan