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
