• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1427
  • Last Modified:

Retrieving LDAP info from eDirectory from IIS

Hello,
A customer is using Novell eDirectory 8.7.3.2 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:

ldap://ldap.company.com:389/o=company??base?(objectClass=*)

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]
    ou=STAFF
      then some containers of interest.

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

0
Curriculum
Asked:
Curriculum
  • 4
  • 3
1 Solution
 
meverestCommented:
Helo what is the exact text of the message thrown?  Are there any other clues from log files or event viewer?

Cheers.
0
 
CurriculumAuthor Commented:
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.
0
 
meverestCommented:
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://ldap.company.com/o=company">; (objectClass=*); base"

Cheers.
0
Restore individual SQL databases with ease

Veeam Explorer for Microsoft SQL Server delivers an easy-to-use, wizard-driven interface for restoring your databases from a backup. No expert SQL background required. Web interface provides a complete view of all available SQL databases to simplify the recovery of lost database

 
CurriculumAuthor Commented:
Hi,
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

tnx
0
 
meverestCommented:
Hello,

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

Cheers.
0
 
CurriculumAuthor Commented:
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://ldap.mit.edu:389/o=mit/ou=Ohio' " & _
          "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:
o=mit
then about 10 ou's including:
ou=Ohio
then about 100 ou's including:
ou=Cleveland
then about 10 ou's including:
ou=STAFF
then about 300 cn's including:
cn=GBush
and within that container, tehre are five strings of
securityEquals, and one of them is of interest, which reads:
cn=Teachers,ou=STAFF,ou=Cleveland,ou=Ohio,o=big

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 :
/o=mit/ou=Ohio/ou=Cleveland

throws an error.

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

tnx !
0
 
meverestCommented:
Hello,

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://ldap.mit.edu:389/o=mit/ou=Ohio 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:

dn=o=mit,ou=Ohio,username=Curriculum
attributes:
objectclass=user,staffmember
ou=Ohio,staff,sales
cn=Joe Curriculum
username=Curriculum
sn=Curriculum
givenname=Joe
password=blah

dn=o=mit,ou=Ohio,username=meverest
attributes:
objectclass=user,customer
ou=Australia
cn=Mike Everest
username=meverest
sn=Everest
givenname=Mike
password=goose

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://ldap.mit.edu:389/o=mit/ou=Ohio WHERE objectClass='*'

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

LDAP://ldap.mit.edu:389/o=mit/ou=Ohio/username=Curriculum
LDAP://ldap.mit.edu:389/o=mit/ou=Ohio WHERE objectClass='staffmember'
LDAP://ldap.mit.edu:389/o=mit WHERE objectClass='staffmember'
LDAP://ldap.mit.edu:389 WHERE objectClass='staffmember'

these will return just the second:

LDAP://ldap.mit.edu:389/o=mit WHERE objectClass='cust*'
LDAP://ldap.mit.edu:389/o=mit/ou=Ohio WHERE ou='australia'

etc.

a very brief overview, but hopefully helpful?

Cheers,  Mike.



0

Featured Post

Granular recovery for Microsoft Exchange

With Veeam Explorer for Microsoft Exchange you can choose the Exchange Servers and restore points you’re interested in, and Veeam Explorer will present the contents of those mailbox stores for browsing, searching and exporting.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now