Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

LDAP query referencing department field

Status
Not open for further replies.

robodada

Programmer
Nov 8, 2004
9
0
0
US
This is really bizarre....

I'm trying to query LDAP from an ASP page (IIS 5.0 on Win 2K).

Query looks like this:
Code:
dim adoConnection, sSQL, rs

'the ADserver is on a different machine than is running IIS
const sDomain = "ADServer/dc=mydomain,dc=net"

'' use ADO

Set adoConnection = CreateObject("ADODB.Connection")
adoConnection.Provider = "ADsDSOObject"
adoConnection.Open ""

sSQL = "Select ADsPath, name, distinguishedName, title, mail, telephoneNumber, street, l, st, postalCode, sn, givenName,info from 'LDAP://" & sDomain & "' " 

Set rs = adoConnection.Execute(sSQL)

This works great. However, if I add in the 'department' field, as in:
Code:
sSQL = "Select ADsPath, department, name, distinguishedName, title, mail, telephoneNumber, street, l, st, postalCode, sn, givenName,info from 'LDAP://" & sDomain & "' "

I get an error 80004005 'Unspecified Error'. I look at the Active Directory schema and department is shown alongside all of the other fields I'm retrieving, and there doesn't appear to be anything unusual about it.

If I write a similar VBS script with the same SQL statement, I can execute it just fine from a command prompt or the desktop -- and it retrieves the department field without any problem. I've run this against several different LDAP servers from several different hosts, and I get the same problems. I've tried changing the security context under which IIS is running, making it a domain user instead of the default IIS user, and that didn't change anything.

Can anybody think of any reason why 'department' would be inaccessible?

Rob Schripsema
Integra Software




 
This is a long shot but figured it is worth mentioning. Are you getting the error on the query or when you are attempting to display the department field? The reason I ask is if the department is null, you may be erroring out because of that. The best test for this is to refine your query to one person, verifying that this person does in fact have a department and see if your script works then.

Hope that works. If not, try using the GetObject to query the AD instead of using the data provider. I stopped using the data provider because of other quirks.

Mark
 
Thanks for the input .... but the error occurred on the query, not on the display of the field. My code was already checking for null or multi-value fields -- that wasn't the problem.

How would one get a listing of all AD users (i.e., all of the folks set up to log in to the domain) using GetObject? I'm trying to create an intranet employee directory from data already in AD....

Rob
 
robodada did you find a solution to this problem with the department field? I've got the same problem. See below.

I have a page which grabs data from Active Users which was working great last week. All of a sudden my code doesn't like some of the field names. For the purpose of keeping this short let's just say it's one field 'Department'



Code:
 Dim department 

MyFullName = "FRED BLOGGS"
SQLStmt = "SELECT name,physicaldeliveryofficename,[b]department[/b] " & _
          "FROM 'LDAP://lvp-ad.myserver.wan' " & _
          "WHERE objectClass = 'user' AND name='" & MyFullName &"'"

Set Conn = CreateObject("ADODB.Connection")
Conn.Provider = "ADSDSOObject"

Conn.Open "ADs Provider"

Set rs = Conn.Execute(SQLStmt)



So, if i remove department all works fine. Any help appreciated.
 
spambler,

I hate to admit it, but I never did actually solve this problem. I'm pretty certain it has to do with security issues and IIS, but I didn't have enough expertise in that area myself, and the sys admins I was working with really didn't either - and they didn't have the time to research it.

What I ended up discovering is that I COULD access those fields if the code was running as a script in the context of a user -- in other words, as a VBS script running from Windows Scheduler. So, as a workaround that was perfectly fine with the client, we created an Access database that held all of the information we needed, then wrote a script that would periodically refresh that database with the data from the LDAP server (AD in this case), and then wrote the ASP pages to get data from Access. They were more than happy with a latency of up to a day, and we can run the script 2 or 3 times a day without a problem, so it worked OK for us to do this. Don't know if that would work in your case.

I was surprised that this issue is not more well known and that there's not more support/information available (from MS or whomever) on what causes it and how to get around it. After months of asking and searching, no one seems to know the answer.

Hope that helps.

 
It is a security issue.
What you can do is run the asp under the context of a domain user.
OR If you are able to pull some info with anonymous credentials change the security on Department to allow anonymous read-only access.
 
zcolton --

We couldn't run asp under the context of a domain user -- there are other apps out there and the sys admins didn't want to open up IIS that far. Understandable.

I was trying to go down the second path -- changing security on the department field to allow anonymous access -- and could find no one (and no documentation) on how to do that. Where in Win 2K server tools (or whatever) does one go to find or set permissions on individual LDAP fields?

Help me understand this....
 
You have to load the MMC tool for AD schema administration, find the attribute, and set the security to everyone - read access. All by memory of when I used to do real work - so there may be some other steps in there ...

-Chris Larivee
 

That MS Knowledge base should get you started...

But beware of the damage you could cause if you make one mistake. One the sites I run, I opted for running the asp under the context of a domain user. I don't change that for an entire site, just one directory, and very limited access for the account I created and use.

zcolton
 
Thanks for the info, folks. Wish I'd known all of this a few months ago -- but perhaps "spambler" will benefit from all of this!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top