Re: ASP.NET, Win2k, SQL 2k on an intranet (w/Kerberos?)

From: Mike Lerch (
Date: 05/22/03

Date: Thu, 22 May 2003 15:02:29 -0400

>Impersonation has a big drawback, and this is, that you loose connection
>pooling on SQL server.

That is an excellent point. A pretty big deal, too.

>I would in your case, leave windows authentication,
>but avoid impersonation. This way your application would act on behalf of
>ASPNET account. Grant ASPNET account logon rights to SQL server and limit it
>just to one database. Next, for security purposes, program all DB access
>trough stored procedures and give ASPNET account just execute permission on
>stored procedures. In this way you would get security, because what ASPNET
>account does is limited to stored procedures and secondly you get
>performance, because SP's are faster.

That's pretty much what's advocated in the top of that Intranet
Security document. Later on they do talk about the Kererbos (I was
mistaken when I implied that that document didn't talk about that
technique) in a section called "Flowing the Original Caller to the

The thing I don't like about making the ASPNET account just have
execute permission instead of the users is that some of the pages are
doing to require the users to enter data that will be stored in the
database. Other pages will report on information from a very large
pool of data, but filter it according to the user's identity (i.e. an
Eastern Sales Manager will see his stuff, a Western Sales Manager will
see her stuff).

Maybe I could combine those: have IIS validate the user using Windows
Authentication, have the ASP.NET process acount hit the database, and
use IPrinciple to pass the user's name as a parameter to the database
instead of impersonation. Hmm.