Link to home
Start Free TrialLog in
Avatar of icfire
icfire

asked on

ADsDSOObject - Provider error '80040e37'

When I try to do an AD lookup I get the error:

Provider error '80040e37'
Table does not exist.

If I access the page from the server it works just fine, but if I access it from a client computer it does not work.  I have tried accessing it as both administrator and a regular user from both the server and the client computer.  I move the script to another server and it works like it is supposed to.  Is there some policy somewhere that would block remote sessions from this?  I have provided some of the code snippets that are relevant the page is over 500 lines of code so I am condensing.

' First, need to discover the local global catalog server
Set objADsRootDSE = GetObject("LDAP://RootDSE")

' Form an ADsPath string to the DN of the root of the Active Directory forest
strADsPath = "LDAP://" & objADsRootDSE.Get("DefaultNamingContext")

' Wrap the ADsPath with angle brackets to form the base string
strBase = "<" & strADsPath & ">"
                                                    
' Release the ADSI object, no longer needed
Set objADsRootDSE = Nothing
                                                    
'  Specify the LDAP filter First, indicate the category of objects to
' be searched (all people, not just users)
strObjects = "(objectCategory=person)"

' Strip the domain part
strName = Right(Request.ServerVariables("AUTH_USER"), Len(Request.ServerVariables("AUTH_USER")) - InSt(Request.ServerVariables("AUTH_USER"), "\"))

' Add the two filters together
strFilter = "(&" & strObjects & "sAMAccountName=" & strName & ")"

'  Set the attributes we want the recordset to contain.  We're interested in
' the common name and telephone number
strAttributes = "cn, adspath"

' Specify the scope (base, onelevel, subtree)
strScope = "subtree"

' Create ADO connection using the ADSI OLE DB provider
Set cnnADOConnection = Server.CreateObject("ADODB.Connection")
cnnADOConnection.Open "Provider=ADsDSOObject"

' Create ADO commmand object and associate it with the connection
Set cmdADOCommand = Server.CreateObject("ADODB.Command")
cmdADOCommand.ActiveConnection = cnnADOConnection

' Create the command string using the four parts
cmdADOCommand.CommandText = strBase & ";" & strFilter & ";" & strAttributes & ";" & strScope

' Execute the query for the user in the directory
Set rstADORecordset = cmdADOCommand.Execute
Avatar of deighc
deighc

If your web application uses Windows Integrated authentication AND your webserver is NOT a domain controller then I suspect that you've encountered the known 'delegation' limitation of Windows Integrated authentication.

For various technical reasons (that I won't bother describing here) IIS is unable to pass on end-user credentials to other machines when using Windows Integrated authentication. In the situation that I describe above (ie. you're using Windows Integrated auth AND the IIS box is not a domain controller) IIS would be unable to access the AD because it must access this on another machine (ie. a domain controller).

But this limitation doesn't exist (again, for technical reasons that I won't go into here) if you access your web app directly on the IIS machine.

You mentioned that your ASP page works when accessing it directly on the server, and this is what made me think that you have a 'delegation' issue.

So my questions are: Are you using Windows Integrated authentication? Is the IIS machine a domain controller?
Avatar of icfire

ASKER

Yes I am using Windows Integrated Authentication and no the computer is not a DC.  If I switch to basic authentication and put in my logon credentials every time I access the site then it works fine.  How do I set the computer for delegation so I can use Integrated Authentication and not have to logon every time I hit the site?

ASKER CERTIFIED SOLUTION
Avatar of deighc
deighc

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of icfire

ASKER

Sorry about that.  the steps did work, I was just impatient for the changes to get migrated across the domain.  I would make the changes and then try it and expect it to work, when in reality I should have made the changes waited for the domain replication to happen and then tried it.  It was a patience thing for me.