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

From: Tom Kaminski [MVP] ((A_at_T))
Date: 05/22/03


Date: Thu, 22 May 2003 14:51:01 -0400


Ah - yes pooling, I failed to mention that. Pooling is per connection, so
if each user authenticates separately they don't share a pool. Using a
single account (such as ASPNET) would allow all connections to be pooled.

"Matjaz Ladava" <matjaz@_nospam_ladava.com> wrote in message
news:eiAE9GJIDHA.1608@tk2msftngp13.phx.gbl...
> I would just add some thoughts if Tom doesn't mind:
>
> Impersonation has a big drawback, and this is, that you loose connection
> pooling on SQL server. 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.
> Use impersonation only if your application needs to access some COM
objects
> using your identity in case you are checking roles rough COM+.
Impersonation
> also adds on administration overhead as you have to control each user.
>
> The second approach would be to do a forms authentication and then program
> your logon to AD as explained in
>
(http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHT02.asp?frame=
> true)
>
> Regards
>
> Matjaz Ladava
>
> "Tom Kaminski [MVP]" <tomk (A@T) mvps (D.O.T) org> wrote in message
> news:baj1co$kvq6@kcweb01.netnews.att.com...
> > "Mike Lerch" <mlerchNOSPAMTHANKS@nycap.rr.com> wrote in message
> > news:sp0qcv85qt9i7n5o2sd9otj9jj6d1ija4j@4ax.com...
> > > Also a more general question: are there inherent security risks in
> > > using kerberos/delegation?
> >
> > I can't answer that - but in an intranet environment I never understood
> the
> > point of the extra layer of security of authenticating the users to the
> DB.
> > Write your web app such that users must authenticate to IIS and only
have
> > access to the appropriate DB functionality. Just give your devs and
> admins
> > access to the database, plus a dummy "service" type account to be used
in
> > the web app connection string. This is much easier to manage.
> >
> > --
> > Tom Kaminski IIS MVP
> > http://www.iistoolshed.com/ - tools, scripts, and utilities for running
> IIS
> > http://mvp.support.microsoft.com/
> > http://www.microsoft.com/windowsserver2003/community/centers/iis/
> >
> >
> >
>
>



Relevant Pages

  • Re: ASP.NET, Win2k, SQL 2k on an intranet (w/Kerberos?)
    ... Ah - yes pooling, ... > Impersonation has a big drawback, and this is, that you loose connection ... I would in your case, leave windows authentication, ... Grant ASPNET account logon rights to SQL server and limit ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • understanding chkrootkit: sshd section
    ... Rhosts Authentication disabled, originating port will not be trusted. ... Secure connection to %.100s on port %hu refused%.100s. ... Warning: Remote host refused compression. ... Received RSA challenge from server. ...
    (comp.os.linux.security)
  • understanding chkrootkit: sshd section
    ... Rhosts Authentication disabled, originating port will not be trusted. ... Secure connection to %.100s on port %hu refused%.100s. ... Warning: Remote host refused compression. ... Received RSA challenge from server. ...
    (comp.security.unix)
  • (fwd) FreeBSD Security Advisory FreeBSD-SA-01:39.tcp-isn (fwd)
    ... susceptible to attack than other unencrypted sessions. ... > incoming connection is being established, ... > All versions of FreeBSD 3.x and 4.x prior to the correction date ... > requiring other authentication of the originator are vulnerable to ...
    (FreeBSD-Security)
  • Re: understanding chkrootkit: sshd section
    ... Connection will not be encrypted. ... > Rhosts Authentication disabled, originating port will not be trusted. ... > Could not request local forwarding. ... Remote host failed or refused to allocate a pseudo tty. ...
    (comp.security.unix)