Globally instantiated Chaining Overlay makes subschemaSubentry Attribute vanish from ldapsearches

[Michael.Heep@o2.com]

Hi list,

I encountered the following phenomenon when experimenting with a globally 
instantiated chaining overlay for automatic update referral chasing:

Issueing the following ldapsearch without the overlay instantiated gave 
the expected results:
> ldapsearch -D "uid=<xxx>,ou=cno-ldc,ou=people,dc=o2online,dc=de" -b "" 
-s base -WxZZLLL "*" "+"
Enter LDAP Password: 
dn:
objectClass: top
objectClass: OpenLDAProotDSE
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: dc=o2online,dc=de
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.334810.2.3
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedFeatures: 1.3.6.1.1.14
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
supportedLDAPVersion: 3
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: EXTERNAL
entryDN:
subschemaSubentry: cn=Subschema

After uncommenting the chain directives from my LDAP server's slapd.conf 
and running the same ldapsearch again the subschemaSubentry was no longer 
included in the ldapsearch output:
> ldapsearch -D "uid=<xxx>,ou=cno-ldc,ou=people,dc=o2online,dc=de" -b "" 
-s base -WxZZLLL "*" "+"
Enter LDAP Password: 
dn:
objectClass: top
objectClass: OpenLDAProotDSE
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
[... same as above ;) ...]
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: EXTERNAL

I'm using OL 2.3.20 + DBD 4.2.52 with the 4 Patches on RHES30.
Here's an excerpt of my slapd.conf containing the relevant information:
access to attrs=userPassword
        by self write
        by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" write
        by dn.exact="cn=syncreader,dc=o2online,dc=de" read
        by anonymous auth
access to attrs=shadowLastChange
        by self write
        by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" write
        by * read
access to *
        by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" write
        by * read
...
# Chainig overlay for automatic referral chasing (global so it affects 
updaterefs!) 
overlay chain 
chain-uri               "ldap://<master ip>:389"
chain-idassert-bind     bindmethod=simple binddn="<rootdn>" 
credentials=<rootpw> mode=self
chain-tls               start
#######################################################################
# BDB database definitions
#######################################################################
database        bdb
...

As you can see the user I used to bind to the server has the proper access 
(to * write). The same thing happens when I use the rootdn, though. So I 
doubt it's an ACL issue.
I know the chain-idassert-bind is a little dirty because I'm using the 
rootdn, but this is just my testenvironment. First I want to get it up and 
running with an as simple as possible configuration.

So is this behavior intended, a bug/feature or simply some 
misconfiguration on my side.
Any help yould be much apreciated.

Thanks and kind regards,
Michael Heep