OpenLDAP syncrepl probblem with password policies

Question

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

Answer 1

'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.

Answer 2

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.