ldap oclAccess does not seem to work with pwdPolicy - openldap

Question

I have installed ldap 2.4.3 on Ubuntu 14.04. I have configured pwdPolicy overlay and it works when the users changes his/her own password and when admin changes the password. The problem is that when admin changes the password the policies are not adhered. So, I created another account called usermanagement and added the dn to oclAccess. I can modify all fields I've tried using the usermanagement account except for userpassword.
When running ldappasswd I get Insufficient access (50)
This is My olcAccess:
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by dn="cn=admin,dc=zed,dc=com" write by dn="cn=usermanagement,dc=zed,dc=com" write by anonymous auth by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=zed,dc=com" write by dn="cn=usermanagement,dc=zed,dc=com" write by * read
Edit
I have enabled debugging and then executed ldappasswd -H ldap://localhost -x -D "uid=luis,ou=users,dc=zed,dc=com" -W -S "uid=vixian,ou=users,dc=zed,dc=com". The log shows:
983c0f8 bdb_dn2entry("cn=passworddefault,ou=policies,dc=zed,dc=com")
5983c0f8 => bdb_entry_get: found entry: "cn=passworddefault,ou=policies,dc=zed,dc=com"
5983c0f8 bdb_entry_get: rc=0
5983c0f8 change password must use DELETE followed by ADD/REPLACE
5983c0f8 send_ldap_result: conn=1004 op=1 p=3
5983c0f8 send_ldap_result: err=50 matched="" text="Must supply old password to be changed as well as new one"
5983c0f8 send_ldap_extended: err=50 oid= len=0
5983c0f8 send_ldap_response: msgid=2 tag=120 err=50
I then tried to delete the userPassword using ldapmodify and it was successful but replacing or adding produced the same result permission denied.
I have updated the olcAccess following #ejp suggestion:
olcAccess: {0}to attrs=userPassword,shadowLastChange
by group/groupOfUniqueNames/uniqueMember.exact="cn=itinst,ou=groups,dc=zed,dc=com" write
by anonymous auth
by self write
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to *
by self write
by group/groupOfUniqueNames/uniqueMember.exact="cn=itinst,ou=groups,dc=zed,dc=com" write
by users read by anonymous search

Answer 1

The problem is that when admin changes the password the policies are not adhered.
When the managerDN changes the password 'the policies are not adhered'. You should not use the managerDN for anything. That's the account the server runs as, and it can do anything, of course. You should define a separate admin account in the DIT, and give it the appropriate access rights, as I have for the entire ldap admins group in the example below.
It doesn't have anything to do with your olcAccess. Have a look at the documentation for how to do this properly. I have:
olcAccess {0}to attrs=userPassword
by dn.base="cn=replicator,dc=verismart,dc=com,c=us" write
by group/groupOfUniqueNames/uniqueMember.exact="cn=ldap admins,ou=groups,dc=verismartlabs,dc=com" write
by group/groupOfUniqueNames/uniqueMember.exact="cn=applications,ou=groups,dc=verismartlabs,dc=com" write
by anonymous auth by self write
olcAccess {1}to dn.base="" by * read
olcAccess {2}to *
by self write
by dn.base="cn=replicator,dc=verismart,dc=com,c=us" write
by group/groupOfUniqueNames/uniqueMember.exact="cn=ldap admins,ou=groups,dc=verismartlabs,dc=com" write
by group/groupOfUniqueNames/uniqueMember.exact="cn=applications,ou=groups,dc=verismartlabs,dc=com" write
by users read
by anonymous search
EDIT As you're using the ppolicy overlay:
You should use the -e ppolicy argument to ldappasswd so you can see the extended response if any.
The user must also use the -a option to ldappasswd to specify the old password, as suggested by the log, or -A to get it to prompt you for it. The change log is saying change password must use DELETE followed by ADD/REPLACE, which means you have to supply both the old and the new password. ldappasswd will send a DELETE for the old one and an ADD or a REPLACE for the new value.
How you get the admin to do it without knowing the old password is another question, looking ... Works for me via an application, but I've never done it via ldappasswd. Maybe -e ppolicy is the answer to that too.
EDIT 2 It is because you have pwdSafeModify=TRUE in your password policy. This rather useless setting makes it impossible for administrators to reset passwords without knowing the old one, and if the old one was known there would be no need for the administrative reset at all. I have it turned off, but then all my passwords are changed only by Java code: one piece for the user himself, and another for the administrator, so I can enforce pwdSafeModify myself.