We created a master / slave environment, where a ldap server replicates another periodically. All entries are replicated correctly, but the attribute 'userPass' is not replicated. We assumed this is an ACL issue, so on the master side we added

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {3}to attrs=userPassword by dn.base="cn=syncprov,dc=thedomain,dc=com" read

but the userPass is still missing.

To debug this step-by-step, it would be helpful

  1. Is there a tool that helps me checking ACL issues? So i could impersonate a user and check an attribute?

  2. What logging level on the server side would display ACL issues?

  3. Whenever we try ldapmodify changes on the slave side, they are rejected with 'shadow context', which is pretty logical, but how can we make changes? Do we have to exclude the cn=config from replicating

  4. Since any changes on the slave side are rejected, how do we stop replication mode at all?


You can simply check if the ACL is correct now by logging in with the credentials for the replication user and confirming that the userPassword gets displayed when you query other user objects.

For instance with a simple ldapsearch -D "cn=syncprov,dc=thedomain,dc=com" -w secret -p 389 -h server.example.com "cn=Heiner"

If the ACL is correct, you should be able to see the userPassword.

Fixing the ACL won't automatically start replicating the missing userPassword attributes to your slave.

(The changed ACL does not modify the original user account object, although cn=syncprov can now see an extra attribute, that is not a "new" attribute, on the master server that account remains unchanged. And since replication only synchronizes objects that have been updated nothing happens.)

You will need to completely initialise the slave again, this time with the userPasswords's.

  • Did the check as suggested, and everything is displayed but 'userPass' does not show up, so at least it is clear it is an ACL issue. Thanks! – Heiner Feb 13 '19 at 22:27
  • 1
    Solved the ACL issue: the olcAccess: {3}to attrs=userPassword by ... was generally correct but had to be issued before the first by * none – Heiner Feb 13 '19 at 23:11
  • 1
    Please also note the mismatch between userPassword in the acl and userPass in text. Is it a clerical mistake? If not, you need the attribute name to match. – 473183469 Feb 25 '19 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.