Recently I have been working to get slapd syncrepl working using an LDAP backend (push based replication). While I have had fantastic results with syncrepl doing pull based, the push based is killing me.

I'm having issues with the following output when I start slapd: syncrepl_message_to_entry: rid=700 mods check (pwdAttribute: value #0 invalid per syntax)

Which is focusing on my default password policy. I have seen other messages about this similar issue, but most of which never produced an answer, so I'm hoping that I must be overlooking something fairly simple.

I am running this slapd (2.4.35) instance with an olc database, and the following relevant parameters:

objectClass: olcDatabaseConfig
objectClass: oldLDAPConfig    
olcDatabase: {1}ldap
olcDbACLBind: bindmethod=simple binddn="cn=Directory Manager" credentials="xxxxxxx"
olcDbOnErr: continue
oldDbUri: ldap://mysatelliteldapserver
oldSyncrepl: rid=700 provider=ldaps://masterldapserver.mydomain.com:636 bindmethod=simple binddn="cn=Directory Manager" credentials="xxxxxxxx" filter="(objectclass=*)" searchbase="dc=my,dc=base" scope=sub schemachecking=off type=refreshOnly interval=00:00:05:00

Which should pull from "masterldapserver" and push to "mysatelliteldapserver". This works until it hits my password policy, when then it gets:

syncrepl_message_to_entry: rid=700 mods check (pwdAttribute: value #0 invalid per syntax)

Which is totally bogus. I've even gone as far as preconfigured the password policies on the destination satellite server and then restarted replication.

The source clearly shows:

pwdAttribute: userPassword

But comes back with the value #0 (which at other times I've associated that with being a "null" vale).

So, the question is, has anyone else ran across this and does anyone have a suggestion for some type of fix or workaround?

Thanks in advance

  • On a side note, I have modified my replication filter to be "(!(objectClass=pwdPolicy))" which works, but I don't like the solution. Also, examining the LDAP directory through this host (the one presenting the LDAP backend) shows the pwdAttribute as being blank, but connecting to the host directly shows "userPassword" in this value.
    – Eirik Toft
    Jun 16 '14 at 15:54

'value #0' isn't the value itself. It means the 0th value.

Try changing it to the OID of 'userPassword', or maybe you don't have the right schemas loaded in the slave for it to know what userPassword is.


I endorse @EJP answer: either the consumer is missing a compilation option (like support of {CRYPT} passwords, which has to be enabled as a compile option) or a module (like support for {SHA256} or {PDKDF2-SHA*} password which require both compilation of the module and module insert in cn=config).

It is something about consumer missing the support for the hashing schema used by provider.

  • Thanks for the endorsement but what you then go on to say is completely different from my answer.
    – user207421
    Aug 19 '21 at 23:40

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.