I have discovered that I have a development server that is giving back multiple copies of the entryDN and subschemaSubentry values when operational attributes are requested. However, my production server (running the same locally compiled version of 2.4.44) does not.
My question is what the dickens have I misconfigured that would cause this?
Examples:
$ ldapsearch -x -H ldaps://production_server -D cn=manager,dc=example,dc=com -y password_file -b 'dc=example,dc=com' -s base '(objectclass=*)' '+' dn: dc=example,dc=com creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20020531160527Z modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20020531160527Z structuralObjectClass: organization entryUUID: b745df88-a640-1027-9374-fb1dd3799b92 entryCSN: 20031108140804.000000Z#000017#000#000000 contextCSN: 20161004102449.402212Z#000000#000#000000 contextCSN: 20170111164206.727511Z#000000#001#000000 contextCSN: 20161219150039.213065Z#000000#002#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema auditContext: cn=accesslog hasSubordinates: TRUE
$ ldapsearch -x -H ldaps://development_server -D cn=manager,dc=example,dc=com -y password_file -b 'dc=example,dc=com' -s base '(objectclass=*)' '+' dn: dc=example,dc=com creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20020531160527Z modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20020531160527Z structuralObjectClass: organization entryUUID: b745df88-a640-1027-9374-fb1dd3799b92 entryCSN: 20031108140804.000000Z#000017#000#000000 contextCSN: 20161004102449.402212Z#000000#000#000000 contextCSN: 20170111013201.758363Z#000000#001#000000 contextCSN: 20161219150039.213065Z#000000#002#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema hasSubordinates: TRUE entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema auditContext: cn=accesslog
- Frank Swasey