Novell Home

Solving ObjectProperties Problems with ADSI

Novell Cool Solutions: Tip
By Steve O'Hara

Digg This - Slashdot This

Posted: 19 Jul 2006
 

Problem

"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 =
objLDAP.OpenDSObject("LDAP://openldap.com:389/uid=kurt,ou=People,dc=OpenLDAP
,dc=Org",
"", "", 0)
binder=sam.schema
set schobj=GetObject(binder)
for each prop in schobj.optionalproperties
    wscript.echo prop
next

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."

Solution

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.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell