Global.asax not allowing identity impersonation?

[Doug]

Visual Studio 2005, SQL Server 2000, ASP.NET/VB.NET

Not allowed to use the ASPNET machine account in SQL Server (very
strict environment).

Need to use Windows authentication, so we use "Identity
Impersonate=true" in the web.config file.

Trying to implement a system-wide error trapping mechanism. Nothing
fancy, just writing to a log file. The recommended procedure was to
define "CustomErrors=On" in web.config and manually add a "Global.asax"
file to the solution that included code in the "Application_Error"
section to handle the error.

This worked fine on the development box, but when moved over to the
test environment (the one *without* the ASPNET user account), it fails
with the error listed at the bottom of this post.

Is it because the "Global.asax" file is compiled and the ASPNET user
account is the one that performs those tasks? But what about "Identity
Impersonate"? Is it being overridden? Has the impersonation not taken
place yet? (Again, there is no fancy code in Global.asax; I even
removed all code that I had added and had the same result:

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

(If you wish, you may refer to a prior, related thread located here:
http://groups.google.com/group/micro...d08acd2d6fc85?
)

Please help. Thank you.

[Peter Bromberg [C# MVP]]

Doug,
The error that you report at the bottom of your post has nothing to do with
impersonation-
it has to do with the fact that the connection string you are using for SQL
Server access
wants to log on with the ASPNET account of that machine.
If you are using <identity impersonate="true" then you need to also supply
the other parameters
,e.g. userName = "DOMAIN\user" password="password" in that element -
of the account whose credentials DO have access to SQL Server.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Doug" wrote:

Visual Studio 2005, SQL Server 2000, ASP.NET/VB.NET

Not allowed to use the ASPNET machine account in SQL Server (very
strict environment).

Need to use Windows authentication, so we use "Identity
Impersonate=true" in the web.config file.

Trying to implement a system-wide error trapping mechanism. Nothing
fancy, just writing to a log file. The recommended procedure was to
define "CustomErrors=On" in web.config and manually add a "Global.asax"
file to the solution that included code in the "Application_Error"
section to handle the error.

This worked fine on the development box, but when moved over to the
test environment (the one *without* the ASPNET user account), it fails
with the error listed at the bottom of this post.

Is it because the "Global.asax" file is compiled and the ASPNET user
account is the one that performs those tasks? But what about "Identity
Impersonate"? Is it being overridden? Has the impersonation not taken
place yet? (Again, there is no fancy code in Global.asax; I even
removed all code that I had added and had the same result:

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

(If you wish, you may refer to a prior, related thread located here:
http://groups.google.com/group/micro...d08acd2d6fc85?
)

Please help. Thank you.

[bruce barker \(sqlwork.com\)]

When you set Identity Impersonate=true, this means impersonate during the
request processing. Processing in global.asax is generally outside the
request processing. If you are on server 2003, you should use an application
pool, with identity with access to the serverserver. you could also specify
the account/password in the web.config (use the encrypted registry support).

-- bruce (sqlwork.com)
"Doug" <sp*******@gmail.com> wrote in message
news:11**********************@i40g2000cwc.googlegr oups.com...

Visual Studio 2005, SQL Server 2000, ASP.NET/VB.NET

Not allowed to use the ASPNET machine account in SQL Server (very
strict environment).

Need to use Windows authentication, so we use "Identity
Impersonate=true" in the web.config file.

Trying to implement a system-wide error trapping mechanism. Nothing
fancy, just writing to a log file. The recommended procedure was to
define "CustomErrors=On" in web.config and manually add a "Global.asax"
file to the solution that included code in the "Application_Error"
section to handle the error.

This worked fine on the development box, but when moved over to the
test environment (the one *without* the ASPNET user account), it fails
with the error listed at the bottom of this post.

Is it because the "Global.asax" file is compiled and the ASPNET user
account is the one that performs those tasks? But what about "Identity
Impersonate"? Is it being overridden? Has the impersonation not taken
place yet? (Again, there is no fancy code in Global.asax; I even
removed all code that I had added and had the same result:

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

(If you wish, you may refer to a prior, related thread located here:
http://groups.google.com/group/micro...d08acd2d6fc85?
)

Please help. Thank you.

[Doug]

Peter wrote:

Doug,
The error that you report at the bottom of your post has nothing to do with
impersonation-
it has to do with the fact that the connection string you are using for SQL
Server access
wants to log on with the ASPNET account of that machine.
If you are using <identity impersonate="true" then you need to also supply
the other parameters
,e.g. userName = "DOMAIN\user" password="password" in that element -
of the account whose credentials DO have access to SQL Server.

Thanks, Peter. I changed the line to read:

<identity impersonate="true" userName="(my username)") password="(my
password)"></identity>

The test system is not on a domain, so I didn't add that.

Still getting the error. What should I try next?

[Doug]

bruce barker (sqlwork.com) wrote:

When you set Identity Impersonate=true, this means impersonate during the
request processing. Processing in global.asax is generally outside the
request processing. If you are on server 2003, you should use an application
pool, with identity with access to the serverserver. you could also specify
the account/password in the web.config (use the encrypted registry support).

-- bruce (sqlwork.com)

Not on Windows Server 2003 yet, so I guess I can't use an application
pool?

I tried, as Peter suggested, specifying the account/password in the
web.config... same error.

[Doug]

bruce barker (sqlwork.com) wrote:

When you set Identity Impersonate=true, this means impersonate during the
request processing. Processing in global.asax is generally outside the
request processing. If you are on server 2003, you should use an application
pool, with identity with access to the serverserver. you could also specify
the account/password in the web.config (use the encrypted registry support).

-- bruce (sqlwork.com)

Not on Windows Server 2003 yet, so I guess I can't use an application
pool?

I tried, as Peter suggested, specifying the account/password in the
web.config... same error.

I should also mention that, interestingly enough, the application
starts up just fine if I manually go into the \bin folder and delete
the file "App_global.asax.dll" or "App_global.asax.compiled"... (?!)

[Doug]

Forgot to mention the other reason that led me to believe that it was
related to the ASPNET user. When I add that account back into SQL
Server on the Test Environment, the program works.

[Doug]

Forgot to mention:

- The other reason that made me think it was related to the ASPNET user
was that when I add that account back into SQL Server on the Test
Server, the program works.

- When it worked from the "Development Box", it was hitting the server,
not itself. It would work ONLY from 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.

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

[Doug]

Forgot to mention:

Adding the ASPNET user account back into SQL Server on the Test
Server also makes the program work.

It works from the "Development Box" ONLY from 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.

- We have a System DSN defined on the development box to connect to the

SQL Server (both SQL and IIS are on the 192.168.1.2 server). The DSN
uses
Windows NT authentication.