If no ASPNET user account, can I use Global.asax for application-level error trapping?

[Doug]

Using Visual Studio 2005, SQL Server 2000, and ASP.NET/VB.NET for a Web
Application.

We have a System DSN using Windows NT authentication defined on the
development box to connect to the SQL Server (both SQL and IIS are on
the 192.168.1.2 server).

We have "Identity Impersonate=true", and "CustomErrors mode=On" and
"defaultRedirect="ErrorHandler.aspx" in web.config.

(Note: We are NOT using userName = "DOMAIN\user" password="password" in
"Identity Impersonate" section. We tried it and it didn't seem to make
a difference.)

The Problem: it ONLY works from the "Development Box" via the IDE.
If I hit the server (192.168.1.2) from the development box
(192.168.1.3) directly through
Internet Explorer, it will fail with the following error:

"Error [28000] [Microsoft][ODBC SQL Server Driver][SQL Server]
Login failed for user '<machine-name>\ASPNET'"

Adding the ASPNET user account back into SQL Server on the Test Server
"fixes" the problem. However, for security reasons, we are not allowed
to have this account on the production server.

Removing the "Global.asax" file and republishing the web site "fixes"
the problem. But then we have no error handling other than a generic
redirect page (i.e., no ability to log/e-mail the errors).

There are other options for application-level error handling, but this
seemed to be the most straightforward. Can anyone offer any help with
this problem? Thanks.

(P.S. Sorry for the duplication. My old thread had a slightly dif't
subject line and I thought that this described the problem more
accurately and succinctly)

 

[Norman Yuan]

See a few comments inline.

Using Visual Studio 2005, SQL Server 2000, and ASP.NET/VB.NET for a Web
Application.

We have a System DSN using Windows NT authentication defined on the
development box to connect to the SQL Server (both SQL and IIS are on
the 192.168.1.2 server).

Why use ODBC DSN? Since you use SQL Server, you should use SQL Server native
provider and take advantage of System.Data.SqlClient namespace. Any specific
reason forces you to use ODBC?

We have "Identity Impersonate=true", and "CustomErrors mode=On" and
"defaultRedirect="ErrorHandler.aspx" in web.config.

(Note: We are NOT using userName = "DOMAIN\user" password="password" in
"Identity Impersonate" section. We tried it and it didn't seem to make
a difference.)

The Problem: it ONLY works from the "Development Box" via the IDE.
If I hit the server (192.168.1.2) from the development box
(192.168.1.3) directly through
Internet Explorer, it will fail with the following error:

"Error [28000] [Microsoft][ODBC SQL Server Driver][SQL Server]
Login failed for user '<machine-name>\ASPNET'"

Since the IIS/Web app is on the other machine, of course SQL Server will not
recognize the user account "Machine\ASPNET". Obviously, the SQL Server uses
Windows security. If the QL Server has a login mapped to a domain
useraccount, then you can impesonate the Web app to run under that domain
user account. Or you can enable the SQL Server's mixed security mode, so
that you can pass username/password pair as SQL Server login.

Adding the ASPNET user account back into SQL Server on the Test Server
"fixes" the problem. However, for security reasons, we are not allowed
to have this account on the production server.

Removing the "Global.asax" file and republishing the web site "fixes"
the problem. But then we have no error handling other than a generic
redirect page (i.e., no ability to log/e-mail the errors).

Why this SQL Server access has something to do with Global.asax? Do you
actually open Connection inside Global.asax or build ConnectionString in it?
I am confused.

 

[tdavisjr]

Hi,

In your IIS property settings for the virtual directory, if you click the
Directory Security Tab and Edit the Authentication settings, is Enable
Anonymous Access access "unchecked" and Integrated Windows Auth "checked" ??

Doing this should impersonate your user correctly.

 

[Doug]

Hi,

In your IIS property settings for the virtual directory, if you click the
Directory Security Tab and Edit the Authentication settings, is Enable
Anonymous Access access "unchecked" and Integrated Windows Auth "checked" ??

Doing this should impersonate your user correctly.

Tried that. Still didn't work.