Querying custom LDAP property via System.DirectoryServices in C#?

Question

I have a custom LDAP schema installed on my OpenLDAP server which is as follows:

attributeType ( 999.0.01
    NAME 'picturePath'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
    )

objectClass ( 999.1.01
    NAME 'indieStackTeam'
            DESC 'Team definition for IndieStack'
    SUP groupOfUniqueNames
    STRUCTURAL
            MAY     ( picturePath )
    )

In my ASP.NET MVC 2 application, I'm querying for the picturePath property like so (and it is confirmed that picturePath exists in the list of keys):

this.Picture = properties["picturePath"].Value as string;

When I attempt to do this under .NET 3.5 I get the following exception:

[COMException (0x8000500c): Unknown error (0x8000500c)]   
    System.DirectoryServices.PropertyValueCollection.PopulateList() +347013
    System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName) +49   
    System.DirectoryServices.PropertyCollection.get_Item(String propertyName) +150

However, when the same code runs under Mono (on the same server as OpenLDAP) it works perfectly fine. Clients such as LDAPAdmin can also read the picturePath property correctly.

More so, it's only when I go to read the value that it fails; I can see the property is there in the keys list, I just can't access it.

Unfortunately unknown error doesn't tell me a lot about what's going wrong, but I'm finding the .NET implementation of System.DirectoryServices is very flaky (you get the same unknown error if you connect to the LDAP server using lowercase in 'DC=').

Has anyone had this problem before and if so, how is it solved?

This will not answer your question, but is a general comment on the `picturePath` attribute. This attribute seems to represent a pathname on a file system, so you should consider using `IA5String` syntax and appropriate matching rules and ordering rules. — Terry Gardner, Dec 18 '11 at 12:11

score 3 · Answer 1 · answered Dec 18 '11 at 10:39

3

Two things you should check:

1) does that particular user object indeed have a value in picturePath? You might want to check for existance of the property before accessing it:

if(properties.Contains("picturePath") && properties["picturePath"].Count > 0)
{
   ....
}

2) If I remember correctly, to get access to custom attributes, you should explicitly refresh the cache for a user object before doing anything:

DirectoryEntry de = ......;  // find / assign that DirectoryEntry somehow

de.RefreshCache();  // to load all properties from the directory

or:

de.RefreshCache(new string[] { "picturePath" });  // to just load the "picturePath" attribute

Also: the classes in System.DirectoryServices are really mostly geared towards being used against Active Directory - there might be "surprises" or subtle incompatibilities when used against some other LDAP server - like OpenLDAP.

answered Dec 18 '11 at 10:39

marc_s

732,580
175
1,330
1,459

1

I agree with marc. You should have a look at using the Novell Directory services library. You can add a reference to it under Mono by adding the Novell.Directory.Ldap assembly. – startupsmith Dec 18 '11 at 22:41
It seems refreshing the cache has no effect and using properties.Contains("picturePath") raises the same 'Unknown error' exception. I've had a look at the Novell services library but it doesn't seem to be as full featured (it doesn't give you a way to list all the properties of an entry as far as I can see and other issues like that). – June Rhodes Dec 19 '11 at 00:19
This class here ftp://sdk.provo.novell.com/ndk/ldapcsharp/Samples/Samples/GetAttributeSchema.cs will get all of the attributes (names and values) for a given entry using the Novell Directory Services library. – startupsmith Dec 19 '11 at 06:56

score 0 · Accepted Answer · answered Dec 19 '11 at 01:23

It seems that the .NET LDAP client expects a correctly formed OID for attribute types and object classes.

You'll note that I was using OIDs of the form 999.X.YY, which while they might be syntactically correct, aren't usually encountered in the real world. My guess is the LDAP client parses OIDs and since these don't conform to what is expected, it throws an error.

I changed the OIDs to 1.3.6.1.4.1.40000.1.3.1 and 1.3.6.1.4.1.40000.1.4.1 respectively (I've also applied for a PEN, which will give me an assigned number instead of '40000'), refreshed the schema in the server and recreated the entries and the LDAP client now correctly reads the custom attributes.

Querying custom LDAP property via System.DirectoryServices in C#?

2 Answers2

Linked