The easiest thing to do would be to switch to Win2K3 server. With that, you
can easily set up an App Pool identity that is a domain account that can be
used to connect to SQL Server. Then, you would just make sure that only
apps that need to use that identity use that App Pool.
This is harder to deal with in Win2K. The other supported way to do this is
to have your ASP.NET application impersonate a known domain identity so that
will be used to connect to SQL, but unfortunately, Win2K requires SYSTEM
level permissions to impersonate a specific user (this is because the
LogonUser API requires Act as part of the operating system privileges on
Win2K to be called), so you'd need to change your ASP.NET processModel from
Machine to System to get that which is a big security risk.
Another option is to do all of your SQL access through a COM+ component that
you configure with a known domain identity.
The other easy option is to give up on SSPI access to SQL and use a SQL
login. Then, be careful with your connection string.
HTH,
Joe K.
"kh" <> wrote in message
news:23E85C78-D1E3-4F69-B926-...
> Hi. I'm designing an intranet application in a heterogenious MS
environment (XP, W2K Server, SQL Server 2K). The perfect security scenario
for me is described in the Patterns & Practices guide entitled "Building
Secure ASP.NET Applications". In the "Intranet Security" chapter [1] the
text describes the "ASP.NET to SQL Server" architecture and recommends that
impersonation be switched off and the machine.config file be amended to
supply a known password for the ASPNET account. We use windows
authentication throughout.
>
> However, the application is one of several on the machine so editing
machine.config is not an option. It is an essential requirement for me to be
able to determine the user's identity when making changes to the database
for audit purposes. How should I proceed?
>
> Many thanks
>
> kh
>
> [1] http://msdn.microsoft.com/library/en...SecNetch05.asp
Similar Threads
