LDAP: Table Does Not Exist from ASP but not VBS

[rklein]

The problem seems to have started with our last w2k DC was demoted. Here's the offending section of Code:

Set objDomain = GetObject ("LDAP://mydc/RootDSE")
objADsPath = objDomain.Get("DefaultNamingContext")
Set objDomain = Nothing

Set con = Server.CreateObject("ADODB.Connection")
Set Com = Server.CreateObject("ADODB.Command")

con.provider ="ADsDSOObject"

con.open "Active Directory Provider"
Set Com.ActiveConnection = con

Com.CommandText = "SELECT AdsPath FROM 'LDAP://" & objADsPath & "' WHERE sAMAccountname='" & user & "'"

Set rs = Com.Execute

set objUser = GetObject(rs.Fields("AdsPath").Value)

Originally I was using Set objDomain = GetObject ("GC://RootDSE") but have made several variations hoping to get better results.

I've also tried sending domain admin credentials:

con.open "Active Directory Provider", "domain\domainadmin", "password"

But get this error from the ASP page. "An External Object Raised an Error. No Error Description Available"

 

[djtech2k]

This is not a blanket rule, but quite often this can be a result from IIS. What I mean is that if the code works in a vbscript running as an admin, but then fails running under IIS, then its a permissions issue most likely. I do not kno how your code and IIS are running as for credentials, but if it is anonymous access then IIS will be trying to execute a script in AD running under the anonymous account or the account running your application pool. In either case it will not work. You will likely need to do either delegation combined with integrated auth OR run the app under a single credentials with permissions.

Also as for the code, you could also try using the distinguishedName to bind to the object rather than the ADSPath. AD is funny about that sometimes.

 

[rklein]

IIS is running with Integrated Auth. I had thought that since the problem seemed crop up when our windows 2000 DC was demoted that MDAC needed to be updated. I applied all available security/MDAC/.NET patches and the "Table doesn't Exist" issue has gone away however I'm now getting the following Event Error when people try to use the app:

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10010
Date: 4/11/2007
Time: 9:30:26 AM
User: OBERNT\username
Computer: CALLTRACKER
Description:
The server {834128A2-51F4-11D0-8F20-00805F2CD064} did not register with DCOM within the required timeout.

 

[rklein]

Check that. Still getting Table Does Not Exist, just not the popup on the console anymore (which I assume is because of that DCOM error which refers to mdm.exe

 

[djtech2k]

Is this IIS6 running on 2003? If so, this is probably your app pool. If you are using integrated Auth, the app pool user will still be the one trying to make the change to AD most likely. By default, that is like the local network account, which will not have permissions.

Have you set your web.config file to use impersonation? Are you trying to use impersonation in this scenario? If not then what account will your app use to make changes to AD? If you are wanting to impersonate, there is a list of things that you will need to do. It is kind of a pain at first, but it does work. Its pretty easy as long as you have all the steps done in order.

 

[rklein]

IIS5 on w2k. I have no web.config file. Impersonation sounds like the route to go. I tried to add an admin username and password to the open method within the ASP page but got vague runtime errors noted in the first post.

 

[djtech2k]

hmmm. ok. I have not done this on IIS5. Are you using retro ASP or asp.net?

My description fit for asp.net on IIS6.

Here is a great resource that you should read:

http://forums.asp.net/thread/971665.aspx

 

[rklein]

ASP.NET 2.0 so I think it should still apply.

 

[djtech2k]

Then yes. If it is asp.net, then you should have a web.config file that contains all of your .net configuration. It should be in your web root directory with your pages.

That is one of the places to turn on impersonation. The page I sent you is an excellent reference and should help you with the step-by-step procedure. Be sure to follow it to the letter. Some stuff is not quite clear...ie you will likely have to use setspn to setup servicePrincipalNames for your server/service account. Its not that hard to do, but its confusing the first time around. Also, once its setup it make take a few minutes for it to start working. Your AD has to "catch-up" sometimes. Often I had to reboot my server and wait about 15 mins or so before it began to work as I intended.

The key is that you tell IIS and your code to impersonate. You tell IIS to use a service account (user) for its processing. You then tell AD that the user/server are allowed for delegation. The site I sent you should help.

 

[rklein]

The server is already trusted for delegation.

Since my server is the same as the AD name I don't have to do anything with SetSPN??

6. IIS server name either must match exactly account name in AD, or SetSPN tool should be used in cases where IIS site is set as alternative name (e.g. server is called server01.domain.com, and website is called www.application.com).

This is my web.config file:


<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<identity impersonate="true"
userName="domain\username"
password="password" />
</system.web>
</configuration>


BTW: would the above impersonate change the return value of
Request.ServerVariables("AUTH_USER")? If so then I don't want that and should use this instead?


<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<identity impersonate="true" />
</system.web>
</configuration>

 

[djtech2k]

The user account that you are using to run your IIS app needs to be trusted for delegation as well.
Basically how I used the SPN was as follows:

I added an spn to the machine name that matched what I wanted to use for the site as well as adding the name as an SPN to the user account that I am using as a service account for IIS to run this app. So, here is an example:

server: webserver1
user account: svcuser

SPN's for webserver1:

HTTP/webserver1
HTTP/webserver1.domain.local
HOST/webserver1
HOST/webserver1.domain.local

SPN's for the svc account:

HTTP/webserver1
HTTP/webserver1.domain.local

The user account was then trusted for delegation thru ADUC.

I then set my web.config to use impersonation. I then created a new application pool and told my app to use it. I changed the app pool to use my service account I created and trusted for delegation. IIS should then be set to use integrated auth only for that site. Your web.config should be something like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<authentication mode="Windows" />
<identity impersonate="true" />
</system.web>
</configuration>

With that config, it will pickup the logged in user from the browser and feed it into IIS to run the process in AD as that user. Now, with IIS5, I do not know how to workaround the app pool issue. You could hardcode a login in the web.config and your app will always use that same account to do admin work, but that removes ability to audit who did what.

As for your question about auth_user I do not know that I can answer it. I do not use the hardcoded option because I think it is more vulnerable and makes it difficult to track who did what. The most secure way is to do it over SSL with forms-based authentication. This is where it always prompts each user to login no matter how they are logged into their machine.