Dear Quanah,

I would like to point out the password out of sync is not 100% happen when error 16 occour. I've checked:

- both openldap server with the same password policy and overlay enabled, e.g., both can generate pwdfailuretime and replicate to each other when user bind with incorrect password to any one of the server

- pwdfailuretime actually exist on the entries (and both server), but it fail with attribute not exist

Sep 1 01:20:19 openldap1 slapd[30596]: mdb_modify: uid=xxxxxxxxxxxxx Sep 1 01:20:19 openldap1 slapd[30596]: mdb_modify_internal: replace userPassword Sep 1 01:20:19 openldap1 slapd[30596]: mdb_modify_internal: replace pwdChangedTime Sep 1 01:20:19 openldap1 slapd[30596]: mdb_modify_internal: softdel pwdFailureTime Sep 1 01:20:19 openldap1 slapd[30596]: mdb_modify_internal: replace entryCSN Sep 1 01:20:19 openldap1 slapd[30596]: mdb_modify_internal: replace modifiersName Sep 1 01:20:19 openldap1 slapd[30596]: mdb_modify_internal: replace modifyTimestamp Sep 1 01:20:19 openldap1 slapd[30596]: mdb_modify_internal: delete pwdFailureTime Sep 1 01:20:19 openldap1 slapd[30596]: mdb_modify_internal: 16 modify/delete: pwdFailureTime: no such attribute Sep 1 01:20:19 openldap1 slapd[30596]: send_ldap_result: err=16 matched="" text="modify/delete: pwdFailureTime: no such attribute" Sep 1 01:20:19 openldap1 slapd[30596]: null_callback : error code 0x10 Sep 1 01:20:19 openldap1 slapd[30596]: slap_graduate_commit_csn: removing 0x7fb460118ed0 20170831172019.265684Z#000000#002#000000 Sep 1 01:20:19 openldap1 slapd[30596]: syncrepl_message_to_op: rid=001 be_modify uid=xxxxxxxxxxxxxxx (16) Sep 1 01:20:19 openldap1 slapd[30596]: do_syncrep2: rid=001 delta-sync lost sync on (reqStart=20170831172019.000000Z,cn=xxxxxxxxxxxxx) , switching to REFRESH

And then, in most case, the user password could be sync afterward.

Anyway, thanks for your information. I think I need to gather more information for the issue and post to the list again.

Thanks.

Chris

On Wed, 30 Aug 2017, Quanah Gibson-Mount wrote:

--On Wednesday, August 30, 2017 9:21 AM -0700 Quanah Gibson-Mount quanah@symas.com wrote:

...

--On Wednesday, August 30, 2017 2:49 PM +0800 Chris Leung chris@q-station.net wrote:

...

Sometime, the user password is replicated without problem after switched to REFRESH, however, sometime password can't be sync.

Error 16 means "no such attribute exists". My guess would be you have ACLs that block your replica from replicating userPassword. I'd also guess that you originally loaded the replica via a slapcat of the other master, so some accounts have passwords, and others don't. This is all guesswork of course, but it would match the behavior you're seeing.

Also, I would confirm that you have identical overlay configurations between the two masters. It sounds like on has ppolicy and perhaps the other one doesn't? Also be sure and read the ppolicy manpage closely on replication behavior.

--Quanah

--

Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com