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
<[email protected]> wrote:
--On Wednesday, August 30, 2017 2:49 PM +0800 Chris Leung
<[email protected]> 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>
