Root DSE missing objectClass additions

[JesseCoretta]

Describe the bug

Following an offline edit of the cn=Root DSE,cn=config entry within /opt/opends/config/config.ldif (and a subsequent restart), it appears that additions of supplemental AUXILIARY objectClass values are not appearing during LDAP Search operations, while any other attribute type amendments appear as expected.

Consider the following AUXILIARY objectClass present within the schema:

objectClasses: ( 1.3.6.1.4.1.56521.999.107.93
          NAME 'advertisedConfig'
          SUP top AUXILIARY
          MAY ( advertisedSearchBase $ protocolGateway ) ) 

The default Root DSE:

dn: cn=Root DSE,cn=config
cn: Root DSE
ds-cfg-show-all-attributes: false
objectClass: ds-cfg-root-dse-backend
objectClass: top

... then becomes (as seen in my text editor):

dn: cn=Root DSE,cn=config
cn: Root DSE
ds-cfg-show-all-attributes: false
objectClass: advertisedConfig
objectClass: ds-cfg-root-dse-backend
objectClass: top
advertisedSearchBase: ou=Consultants,ou=Accounts,dc=example,dc=com
protocolGateway: 192.168.1.100

Following a successful restart of OpenDJ, an LDAP Search of the Root DSE returns the following:

dn:
objectClass: top
objectClass: ds-root-dse
advertisedSearchBase: ou=Consultants,ou=Accounts,dc=example,dc=com
protocolGateway: 192.168.1.100

... which shows me the edits are present -- except for the "advertisedConfig" AUXILIARY objectClass. I can reproduce this behavior with other classes, custom or standard.

I would fully expect issues to arise if I were trying to add a STRUCTURAL class to this entry, but AUXILIARY classes should work.

To Reproduce
Steps to reproduce the behavior:

1. stop-ds
2. vi /opt/opendj/config/config.ldif, visit (approximately) line 1532, edit as shown above, save and quit
3. start-ds, watch logs for errors (none)
4. See ldapsearch notes below.

This fails to match an entry when using the class as a filter item:

$ ldapsearch -xb '' -s base -H ldap://localhost '(objectClass=advertisedConfig)'

This successfully matches the entry when only requesting the attribute types by class name (not by filter), but "advertisedConfig" is still not being disclosed in the search result:

$ ldapsearch -xb '' -s base -H ldap://localhost '(objectClass=*)' @advertisedConfig

... and this also works when requesting specific attributes as filter conditions in place of objectClass (e.g.: (protocolGateway=*)):

$ ldapsearch -xb '' -s base -H ldap://localhost '(objectClass=protocolGateway=*)'

Expected behavior
Any objectClass values added to the Root DSE by legitimate means (likely of the AUXILIARY kind) should be visible assuming their definition in the schema is valid and well formed. Furthermore, use in search filters should yield expected search results.

OpenDJ version
Using Ubuntu 22, I can reproduce this behavior starting at v4.6.5 and up.

Conclusion

• Added objectClass value is not disclosed in search results (missing objectClass: classname)
• Added objectClass value is not evaluated as a filter element during search request processing (objectClass=classname)
• Added objectClass value is evaluated in the context of attribute selection (e.g.: @classname instead of specificAttribute)

Thank you 😃

Jesse Coretta

EDIT: fixed search result for clarity