Retrieving LDAP info from eDirectory from IIS

Posted on 2005-04-11
Last Modified: 2012-05-05
A customer is using Novell eDirectory on Netware 6.5 sp2. My company's IIS application needs to find out some information from that directory. I'd like the solution to be generic LDAP rather than solved only through Novell tools, as we've also been asked to do the same thing for another customer with MS AD.

I have successfully set up a browser to the eDirectory from the IIS server using the third party LDAP browser tool from Softerra. The connection string that connects and lets me browse is:


where "company" replaces the organization's acronym, and the anonymous mode is used

I have seen in a prior answer some IIS code using the AdsDSOObject which should do this, but it doesn't work for me. I get a table error when the query is executed. From what I've read the table error is thrown when unexpected parameters are provided in the query.

Here's a snippet of the code I found in EE:

     oConn.Provider = "ADsDSOOBJECT"
     oConn.Properties("Encrypt Password") = False
     oConn.Open "ADs Provider", "cn=SchemaReader,cn=staff,dc=" & strDomain & ",dc=com","MYPASSWORD"
     strQuery = "<LDAP://" & strDomain &">; (&(objectClass=user)(objectCategory=Person)(sn=*)); sn,givenName,telephoneNumber,mail,sAMAccountname,ADsPath;subtree"

    Set oRS = oConn.Execute(strQuery)

The tree has a structure such that I want to get a cn value which is buried under:

ou=[a certain region]
   ou=[a certain facility]
      then some containers of interest.

Thanks for help on this. Let me know if you need more info.

Question by:Curriculum
    LVL 37

    Expert Comment

    Helo what is the exact text of the message thrown?  Are there any other clues from log files or event viewer?


    Author Comment

    The message is:
    Provider (0x80040E37)
    Table does not exist.

    I've seen a lot of tips here and in other forums that this message is thrown when EITHER the security settings arent right, or a parameter in the search is not valid per the host LDAP. That's a big range of possible causes !

    FYI, the host LDAP is set for anonymous connections, and I can connect to it fine from the web server machine using Softerra with the anonymous setting.
    LVL 37

    Expert Comment

    OK, and what part of the script throws that error?  by the sound of it, it happens at the line containing oConn.Execute(strQuery)?

    or does it occur when you attempt to access the recordset?

    are you sure of the query parameters?  Your Softerra sample starts virtually at the top of the LDAP tree (o=company) and the search filter is essentially a wildcard (objectClass=*)

    Have you tried starting with these basic parameters in the ASP query?  as in something like:

    oConn.Open "ADs Provider"
    strQuery = "<LDAP://">; (objectClass=*); base"


    Author Comment

    I get the error at oConn.Execute(strQuery)

    I had tried the exact Softerra string into the code as you noted, but still get the error which is:

    Provider (0x80004005)
    unspecified error

    My bet is that Softerra is running under a  domain user whereas  IIS code is running as IUSR_.

    Does this sound like I need to run IIS under a domain user ? The LDAP server is in anonymous connection model

    LVL 37

    Expert Comment


    >> I had tried the exact Softerra string into the code as you noted, but still get the error which is:

    my suggested connection and query strings are provided with no previous experience using that module - it is probably still not the correct syntax.

    >> My bet is that Softerra is running under a  domain user whereas  IIS code is running as IUSR_.
    >> Does this sound like I need to run IIS under a domain user ? The LDAP server is in anonymous connection model

    i doubt that very much - when accessing services over a network like this, the credentials used to run the service are not relevent.


    Author Comment

    Points still out there, as I have simply solved the first connectivity portion of my problem:

    Turns out I needed MDAC 2.7 or higher on the win2K server. I'm getting data back now. I had MDAC 2.6 before.

    So continuing with my initial question

    So now that I'm getting data back, I would appreciate any help from those of you who have dealt with highly nested trees. My query is taking 20 seconds, and I'm hoping I'm just new enough to this that it's an obvious fix:

    I'm using different code now than I posted above, just because this was the code I was using when I got the MDAC upgraded:
    [and I've substituted "big" for my organization and some other states for actual values]

    SQLStmt = "SELECT cn " & _
              "FROM'LDAP://' " & _
              "WHERE objectClass='*'
    Set Conn = CreateObject("ADODB.Connection")
    Conn.Provider = "ADSDSOObject"
    Conn.Open "ADs Provider"
    Set rs = Conn.Execute(SQLStmt)
    Response.Write rs.RecordCount

    and the LDAP structure is:
    then about 10 ou's including:
    then about 100 ou's including:
    then about 10 ou's including:
    then about 300 cn's including:
    and within that container, tehre are five strings of
    securityEquals, and one of them is of interest, which reads:

    and the fact that the entry has "Teachers" rather than something else is what I'm searching for.

    I'll come into the search knowing the value for the cn (GBush) but I won't know that GBush is in Cleveland, let alone Ohio. I'm hoping that there is an obvious way to find GBush without what appears to be a grab of many megabytes of data by the IIS machine rather than the work being done by the LDAP server.

    I have tried the intuitive thing, which is to add the next level to the search, but I get one of those pesky table errors. So :

    throws an error.

    Any ideas how to get what I need and get it quicker ?

    tnx !
    LVL 37

    Accepted Solution


    Sorry if i appear to be condescending here (don't mean to be), but what i think you need right now is LDAP 101.  You can probably google for resources just as well as i could, so i'll just make a few general comments here.

    LDAP doesn't really work the same way as a traditional relational database.  it is far less orderly in structure, intead of tables containing columns and rows, there are a set of attributes grouped together by some kind of loose relationship structure.

    LDAP is best suited for userbase type application which is why you will usually find it used in that context, but it can also be very efficient for other groups of data (enterprise system configuration information is a common example)

    A single object in the datastore can have two or more attributes, with general rules defining the type of attributes that the given object may or must have defined.

    For example, an objectclass or 'user' might include 'required' attributes as "username", "firstname", "lastname", and "password", as well as some 'optional' attributes like "department", "phone number", "email address", etc.

    Each uniue record is determined by the 'distinguished name' which is the only really unique identifier for the records contained in the directory, and any well conceived directory will have a well defined structure for the dn attributes.

    for example, the DN format may be something like:

    dn=o=<company>,ou=<department>,cn=<firstname> <initials> <lastname>

    The DN is essentially the 'key' for the object in the directory, and is essentially what the search is returning to you.

    The definition of an LDAP search then comes down to two things:  1.  a DN substring or 'search start', and 2.  define some attribute matches to seek.

    For example, the query above: LDAP:// WHERE objectClass='*' defines "o=mit,ou=Ohio" as the 'start' position.

    That means that the query results will contain ONLY objects with DN beginning with "o=mit,ou=Ohio" such as "o=mit,ou=Ohio,username=Curriculum" and "o=mit,ou=Ohio,username=meverest" as well as "o=mit,ou=Ohio,username=someone,sn=Jones,givenname=John", etc.

    Atthis stage, let me say this:  Don't confuse the DN contents with the attributes.  Just because a DN contains something that looks like an attribute that the object might have does not mean that the attribute is defined at all.  Even if that attribute is there, it may well be different to what is suggested by the DN.  (hope that makes sense)

    then the search filter defines the attributes that the returned objects must contain.  Here are two examples to simplify:

    cn=Joe Curriculum

    cn=Mike Everest

    Notice that in the second example, the DN contains ou=Ohio, but Ohio is not actually defined in the ou attribute value.  (That is probably not /usual/, but it is certainly /possible/)

    Now to search this two-record ldap.

    First of all, we can use this: LDAP:// WHERE objectClass='*'

    to return both records.  These searches will return just the first:

    LDAP:// WHERE objectClass='staffmember'
    LDAP:// WHERE objectClass='staffmember'
    LDAP:// WHERE objectClass='staffmember'

    these will return just the second:

    LDAP:// WHERE objectClass='cust*'
    LDAP:// WHERE ou='australia'


    a very brief overview, but hopefully helpful?

    Cheers,  Mike.


    Featured Post

    Highfive Gives IT Their Time Back

    Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

    Join & Write a Comment

    Suggested Solutions

    Today I came across an interesting issue that had me pulling my hair out.  I was troubleshooting a new internal web site which uses integrated security instead of anonymous.  When browsing the site from my laptop, I was able to access it with no iss…
    Logparser is the smartest tool I have ever used in parsing IIS log files and there are many interesting things I wanted to share with everyone one of the  real-world  scenario from my current project. Let's get started with  scenario - How do w…
    Migrating to Microsoft Office 365 is becoming increasingly popular for organizations both large and small. If you have made the leap to Microsoft’s cloud platform, you know that you will need to create a corporate email signature for your Office 365…
    Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

    734 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    21 Experts available now in Live!

    Get 1:1 Help Now