"We're using eDirectory, and we're using ADSI to retrieve user details from the LDAP server. All works fine for 95% of the user objects. The 5% that fail all contain an "ichainFormFillCrib" attribute as their first attribute, which seems to cause problems for ADSI when retrieving the optionalProperties collection.
I think this is an ADSI fault somewhere because I can see the contents of the object fine with LDP or LDAPBrowser.
OptionalProperties is a collection property of the schema object in ADSI. If you cut and paste the following code into a file called "test.vbs" and then run it from a cmd window "cscript test.vbs" you'll see it in action.
dim sam, binder,schobj,prop
Set objLDAP = GetObject("LDAP:")
Set sam =
"", "", 0)
for each prop in schobj.optionalproperties
In the case where I get a problem, the "schobj.optionalproperties" is coming back as a string rather than a collection. I'm fairly sure that must mean there's been some kind of error translating the data stream that has come back from LDAP."
The LDAP integration uses ADSI to connect to the LDAP server. This is a generalized Microsoft API for connecting to any type of directory server including Active Directory and means that you don't have to write server-specific code. All it actually does is wrap LDAP calls within a COM object.
There are some nice features built into the object one of which is the ability to read the schema of the LDAP server which involves opening the LDAP object and looping through all the Mandatory and Optional Attributes.
We do this every time we read a user object from the LDAP server to populate a collection of attribute|value pairs for all attributes including empty ones.
It turns out that ADSI has a couple of problems with certain LDAP servers that send down attributes in proper IETF standard form. Certain data types from eDirectory cause ADSI to mis-interpret the content and break the parser. This can be remedied at the server end by setting a master attribute in eDirectory to turn on ADSI compatibility. Another way (which is better) is to read the values within ADSI using a lower level API - IADsPropertyList. This doesn't return empty attributes, only those with a value. This is not as good as the previous method but is fine for our situation.
So, I changed the code so that we have a mixture of both methods - if the system detects that the original method has failed, then it uses the IADsPropertyList mechanism.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.