password policy module memory leaks / excessive replication?

["Paul B. Henson" <henson@acm.org>]

I've been testing the password policy module lately. I updated our
development LDAP infrastructure Monday, basically loading and enabling the
module, adding a default policy:

dn: cn=default,ou=ppolicy,dc=csupomona,dc=edu
cn: default
objectClass: organizationalRole
objectClass: pwdPolicy
pwdAttribute: userPassword
pwdLockout: TRUE
pwdLockoutDuration: 1800
pwdMaxFailure: 100
pwdFailureCountInterval: 300

And a policy specific for service accounts:

dn: cn=serviceaccount,ou=ppolicy,dc=csupomona,dc=edu
cn: serviceaccount
objectClass: organizationalRole
objectClass: pwdPolicy
pwdAttribute: userPassword

After some initial testing and determining that the current implementation
is not suitable for account lockouts, I haven't touched it since Monday.
Yesterday, I started getting alerts that the systems were low on memory, and
upon looking, found extremely bloated slapd processes. Next, I started
getting alerts that the accesslog mdb was running out of space.

Upon investigation, I found that the service account that is used to gather
statistics was generating a considerable amount of churn every time it
authenticated (every 30 seconds). This account was explicitly configured to
use the service account password policy:

dn: cn=slapd-monitor,ou=user,ou=service,dc=csupomona,dc=edu
objectClass: person
cn: slapd-monitor
sn: LDAP monitoring account
pwdPolicySubentry: cn=serviceaccount,ou=ppolicy,dc=csupomona,dc=edu

Which should be pretty much "do nothing". (I realize now that this policy
will actually result in pwdFailureTime entries being created for failed
authentications, and accumulating forever until a successful authentication,
but there are no failed authentications for this service account, only
successful ones, in this case).

There were 1662836 entries in the access log for this dn since Monday that
as far as I can tell solely change the CSN:

dn: reqStart=20140502031556.000000Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20140502031556.000000Z
reqEnd: 20140502031558.000000Z
reqType: modify
reqSession: 2
reqAuthzID: cn=ldaproot,dc=csupomona,dc=edu
reqDN: cn=slapd-monitor,ou=user,ou=service,dc=csupomona,dc=edu
reqResult: 0
reqMod: entryCSN:= 20140501211559.348458Z#000000#003#000000
reqMod: modifiersName:= cn=ldaproot,dc=csupomona,dc=edu
reqMod: modifyTimestamp:= 20140501211559Z
reqEntryUUID: c16729b0-ce1e-4f9d-9123-e0b8f115133c
entryUUID: 240ec245-0bac-4e20-b387-19243f720674
creatorsName: cn=accesslog
createTimestamp: 20140501211559Z
entryCSN: 20140501211559.348458Z#000000#003#000000
modifiersName: cn=accesslog
modifyTimestamp: 20140501211559Z

This explains why the accesslog was running out of space, it was full of
these. It doesn't explain why the slapd process exploded in memory use,
unless I suppose the steady-state memory usage of a slapd this busy
processing replication is higher than one that's not quite so busy.

But I'm confused as to why loading the password policy module, for an
account with a policy configured to pretty much not do anything, results in
a modification of the CSN for every authentication?

I'm going to go peruse the source code to see if I can determine what's
going on, but any expert opinions would be most welcome.

Thanks much.