Home/ Questions/Q 6964133
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T15:53:10+00:00

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

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0