Howdy,
Ran into this queer situation, hoping someone can explain why.

Setup:
ASP.NET application connecting to a SQL database.
Implements Impersonation (SQL account credentials passed in a connection
string).
Website installed on Win2K3

When connected to the SQL database on Win2K,
I found that Impersonation can be turned on or off, it doesn't matter. I
found this to be surprising since I thought that impersonation is managed in
IIS6 on the Win2K3 machine, so it should have mattered whether impersonation
was enabled or not.

When connected to the SQL database on Win2K3,
The Impersonation setting <does> matter, must be enabled.

I would have thought that it should not have mattered whether the database
was located on Win2K or Win2K3, it should have mattered whether the <website>
was deployed on Win2K or Win2K3.

TIA,
--
Tony Su
www.su-networking.com
ISA
SBS

[quoted text, click to view]

¤ Howdy,
¤ Ran into this queer situation, hoping someone can explain why.
¤
¤ Setup:
¤ ASP.NET application connecting to a SQL database.
¤ Implements Impersonation (SQL account credentials passed in a connection
¤ string).
¤ Website installed on Win2K3
¤
¤ When connected to the SQL database on Win2K,
¤ I found that Impersonation can be turned on or off, it doesn't matter. I
¤ found this to be surprising since I thought that impersonation is managed in
¤ IIS6 on the Win2K3 machine, so it should have mattered whether impersonation
¤ was enabled or not.
¤
¤ When connected to the SQL database on Win2K3,
¤ The Impersonation setting <does> matter, must be enabled.
¤
¤ I would have thought that it should not have mattered whether the database
¤ was located on Win2K or Win2K3, it should have mattered whether the <website>
¤ was deployed on Win2K or Win2K3.

If you're using SQL authentication and not Windows authentication then the impersonation setting
shouldn't matter. Are you certain you're using only SQL authentication?

The default account used (no impersonation) for application processes under IIS 6.0 is Network
Service instead of ASPNET (as under IIS 5.0).


Paul
~~~~

Actually, the impersonation setting does matter and the reason why is because
the User isn't logging in with the SQL account which would be passed to SQL,
the User is logging in with an account stored in a custom membership provider
(stored in a SQL table). For the purposes of creating the IIS <> SQL database
connection, dotNET uses a different set of credentials (the SQL credentials).
We choose to do it this way instead of using a trusted Windows account such
as "Network Service" or "ASPNET"

In other words... Impersonation would not be a factor if the User's
credentials are passed directly to SQL for authentication (It doesn't matter
if you're passing Windows account or SQL account credentials), but
Impersonation is a factor if you're not passing credentials to be
authenticated by SQL, instead using a set of separate "shared" credentials
solely for the purposes of making the connection, <then> authenticating the
user by some other non-SQL process.

Further clarification on my original post, I'm wondering although
impersonation is set within the ASP.NET application, why it doesn't affect
making a database connection to SQL on Win2K, but does make a diff connecting
to SQL on Win2K3.

It would seem to me that if Impersonation is entirely a "Frontend" IIS
configuration what I'm seeing is all backwards... There should not have been
any difference whether SQL is running on Win2K or Win2K3.

--
Tony Su
www.su-networking.com
ISA
SBS
Enterprise Mobile Solutions Architect


[quoted text, click to view]