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.