(ITS#6031) An account locked on consumer is unlocked only when password is changed twice in a row on provider

[stlist@gmail.com]

Full_Name: Samuel Tran
Version: 2.3.43
OS: CentOS 5.x
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (216.73.248.203)


If I lock an account on a consumer 'pwdMaxFailure' consecutive failed bind
attempts, two password changes on the provider is required to unlock the account
on the consumer.
The first password change updates 'userPassword', 'pwdChangedTime' and removes
'pwdFailureTime'. The second updates 'userPassword', 'pwdChangedTime' and
removes 'pwdAccountLockedTime'.

The replication mode is delta-syncrepl.

Here is the configuration file on the provider:

#-------------------------------------------------
# Accesslog DB definition (slapo-accesslog)
#-------------------------------------------------

database        hdb
suffix          "cn=accesslog"
rootdn          "cn=root,cn=accesslog"
rootpw          {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
directory       /var/lib/ldap/accesslog
index           default eq
index           entryUUID,entryCSN,objectClass,reqEnd,reqResult,reqStart

limits dn.exact="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com"
time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE

#-------------------------------------------------
# Primary example.com database definition
#-------------------------------------------------

database        hdb
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"
rootpw          {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxx

directory       /var/lib/ldap/example.com

[snip]

index   objectClass,uidNumber,gidNumber,memberUid,employeeNumber eq,pres
index   employeeType,accountActive,ftpActive,mailActive,vacationActive,ou,mailRoutingAddress
eq
index   cn,mail,surname,givenname eq,pres,subinitial
index   displayName,gecos,telephoneNumber sub,subany
index   uid,aliasUid eq,sub,subany
index   entryUUID,entryCSN eq

limits dn.exact="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com"
time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

overlay syncprov
syncprov-checkpoint 100 30
syncprov-sessionlog 100

overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
logpurge 28+00:00 01+00:00

overlay ppolicy
ppolicy_use_lockout


Here is the configuration file on the consumer:

#-------------------------------------------------
# Primary example.com database definition
#-------------------------------------------------

database        hdb
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"
rootpw          {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

directory       /var/lib/ldap/example.com

[snip]

index   objectClass,uidNumber,gidNumber,memberUid,employeeNumber eq,pres
index   employeeType,accountActive,ftpActive,mailActive,vacationActive,ou,mailRoutingAddress,mailAlternateAddress,mailAliasActive,allowedService
eq
index   cn,mail,surname,givenname eq,pres,subinitial
index   displayName,gecos,telephoneNumber sub,subany
index   uid,aliasUid eq,sub,subany
index   entryUUID eq

#############################################################
# Syncrepl - Consumer configuration
#############################################################
syncrepl        rid=002
                provider=ldaps://info-ldap-001.example.com:636
                bindmethod=simple
                binddn="cn=syncrepl,ou=Accounts,ou=Apps,dc=example,dc=com"
                credentials=xxxxxxxx
                type=refreshAndPersist
                retry="5 +"
                searchbase="dc=example,dc=com"
                logbase="cn=accesslog"
                logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
                schemachecking=on
                syncdata=accesslog

overlay ppolicy
ppolicy_use_lockout

The problem is similar to the one reported in ITS #5398 for OL 2.4.8.
I saw Howard's reply stating that he was not able to reproduce the problem in
the current OL 2.4.x code. I was wondering if someone was able to reproduce the
problem using OL 2.3.43.

Thanks.