We attempted to use the DirectorySearcher object in Microsoft .NET to access Person data in our Domino (6.0.1) LDAP Directory. The DirectorySearcher object uses ADSI to access the LDAP directory. The result was that we could see the “standard” LDAP attributes (those inherited from X500 days) in our directory, but not any of the newer and additional attributes. The “invisible” attributes included the attributes introduced in the inetOrgPerson object class as well as our own custom attributes.
The reason for this seems to be that the default Domino schema includes invalid object classes and attributes. We solved the problem by removing them from the Domino Directory, and now ADSI can access all the desired attributes correctly.
This posting is to share our experience in case you have the same problem, and also to point out to IBM/Lotus that they are populating their schema with invalid items.
The offending objectClasses and attributeTypes are the ones with $ (dollar) characters in their OID. This contravenes RFC2252. The relevant sections in RFC2252 are as follows: Section 4.1 defines permitted characters for different purposes. 4.2 defines the syntax for Attribute Types. 4.4 defines the syntax for Object Classes. In fact my reading of these paragraphs is that the Domino schema contravenes more than just the dollar signs in OIDs, but I only had to remove those for ADSI to work, so that’s all I did.
This is the Microsoft article that describes how ADSI attempts to read the subschemaSubentry of an LDAP version 3 directory and treats it as a version 2 directory if there are schema errors: Microsoft Support
In diagnosing the problem, I was helped by the excellent free LDAP browser from Softerra, http://www.softerra.com which also caches the subschemaSubentry, and reports errors. The errors it reported were just the items that had a dollar in their OID, which made the error easy to identify.
The offending items were from the Domino Directory, as follows:
2 Object classes generated from Forms:
$$ReturnGeneralError
$$SearchTemplateDefault
54 Attribute Types generated from Fields in the Forms with alias names:
PolicyArchive
PolicyDesktop
PolicyRegistration
PolicySecurity
PolicySetup
First of all I tried to find what it is that gets these forms included in the LDAP schema, so that I could make them excluded. But they don’t conform to the instructions in Admin Help for extending the schema, so they are either special in some secret way, or the instructions don’t say what it is that really includes or excludes a form from the schema. (The third form that starts $$ is $$ViewTemplateDefault, which is not included in the schema - so how is it different from the two I listed above?)
Having failed to find out how to exclude the forms from the schema, I simply removed them from the Directory Database design. We are using this particular directory purely as an LDAP directory, and not using web access (that might need the $$* forms), and not using Policies, and so there have not been any problems so far – but I’m sure this could compromise our support with IBM.
I think another way could be to enter each of the non-conforming items into the lschema.ldif file, with OIDs that don’t have a dollar. The Admin Help says that the schema daemon gives items from that file priority over items from the Directory. But you’re not supposed to change that file either, and there are 54 invalid attributeTypes to over-ride.
If you do decide to remove forms from your Directory, remember you need to do it from the Administration Server of the Directory. This is because the Schema Daemon always loads the schema from the directory on the Administration Server and not the directory on actual server(s) running LDAP (if different).