Full_Name: Matthew Berg Version: 2.4.43+ OS: CentOS 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.97.88.240)
While debugging replication issues in a Zimbra installation, I discovered a significant number of accesslog entries with an empty reqDN and specifying values for contextCSN; e.g.
dn: reqStart=20170302180943.186147Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170302180943.186147Z reqEnd: 20170302180943.190880Z reqType: modify reqSession: 100 reqAuthzID: cn=config reqDN: reqResult: 0 reqMod: contextCSN:= 20170227211132.933390Z#000000#000#000000 reqMod: contextCSN:= 20170302180943.182601Z#000000#001#000000 reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000 entryUUID: 27b9f34c-93bf-1036-9636-3fa0e78444ec creatorsName: cn=config createTimestamp: 20170302180943Z entryCSN: 20170302180943.182601Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20170302180943Z
I was able to reproduce this behavior in a test lab with two freshly installed servers and no existing data. Given two servers, A and B, a write to A will result in the expected audit object being written to the access log on A, but when B applies the change it logs an additional auditModify (likewise B will cause the same additional entry on A).
This particular environment was running a patched build of 2.4.44. I audited our other production environments and did not see the same behavior with prior builds (primarily 2.4.39).
In order to rule out the possibility that this was introduced by any patched Zimbra applied I built out a new package from stock OpenLDAP sources and was able to reproduce with both 2.4.44 and 2.4.43, but not with 2.4.42 and earlier.