03-25-04 02:51 PM
In addition to what Ken said, why do you really need to authenticate each
user to SQL? Doesn't the AP.NET application control what each user can do?
They're not accessing SQL directly right? FWIW, in my shop we never do it
that way. We use one service account for all connections to SQL -
simplifies admin and gives us great performance with connection pooling.
--
Tom Kaminski IIS MVP
http://www.iistoolshed.com/ - tools, scripts, and utilities for running IIS
http://mvp.support.microsoft.com/
http://www.microsoft.com/windowsser...ty/centers/iis/
"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:OeBe8agEEHA.2408@TK2MSFTNGP10.phx.gbl...
> a) if you do this, you will lose the benefits of connection pooling, as a
> separate connection will be used for each security context (each user
> account will have it's own pool). So, this solution will not scale to a
> large number of users. It's OK if you have a small number of users
>
> b) the problem is double-hop authentication. When using IWA, the webserver
> does not have the user's password. It just gets a token from the DC, but
the
> token does not have permission to logon to network resources.
>
> Options:
> a) if you are using a Windows 2000 Domain, you can enable delegation. This
> allows the IIS server to impersonate the Windows account, and logon to the
> backend SQL Server. You need to use Kerberos authentication for this (not
> NTLM v2)
>
> b) if you are using a Windows 2003 Domain, when you enable constrained
> delegation, you can use Protocol Transition. This allows the user to
> authenticate using any of a number of mechanisms to the IIS server (eg
> Digest, or NTLM), and the webserver can still get an Kerberos token to
logon
> to the SQL Server.
>
> Here are a few articles to get you started:
>
> IMPORTANT:
> Read chapter 12 from the Building Secure ASP.Net Application Book - it has
> very good information about building scalable, secure ASP.Net applications
> (eg using a trusted subsystem model):
>
http://msdn.microsoft.com/library/d...r />
rame=true
>
> http://support.microsoft.com/?id=319723
> INF: SQL Server 2000 Kerberos support including SQL Server virtual servers
> on server clusters
>
> http://support.microsoft.com/defaul...kb;en-us;810572
> HOW TO: Configure an ASP.NET Application for a Delegation Scenario
>
> http://support.microsoft.com/?id=294382
>
> Authentication May Fail with "401.3" Error If Web Site's "Host Header"
> Differs from Server's NetBIOS Name
>
> http://support.microsoft.com/default.aspx?kbid=325894
> HOW TO: Configure Computer Accounts and User Accounts So That They Are
> Trusted for Delegation in Windows Server 2003 Enterprise Edition (also
> includes Windows 2000 instructions)
>
>
http://www.microsoft.com/resources/...ter.as
p
> Configuring Users and Computers for delegation (there's a couple of
pages -
> use the links in the nav bar to get to them)
>
> Windows 2003 Protocol Transition
>
http://www.microsoft.com/technet/pr...el.msp
x
>
>
> Cheers
> Ken
>
>
> "corndog" <gwc@abc.com> wrote in message
> news:29C456D6-EE1E-40D6-B92A-C16F414F891D@microsoft.com...
> : We are running SQL Server 2000 and IIS 6 on separate machines. We are
> building an intranet application and want to use integrated Windows
> authentication in order to identify the users and validate them in SQL
> Server because their security role determines what they can do in the
> application. We have enabled integrated authentication on the IIS server.
> In the web.config file we have <identity impersonate = "true"/> and
> "<authentication mode="Windows" />" inside the <system.web> tags. When we
> run the application we get the error: "Login failed for user 'NT
> AUTHORITY\ANONYMOUS LOGON'". Article Q320354 indicates this is a bug, but
> the workaround does not solve our problem because it involves using
> annonymous access. Is there any way to make integrated Windows
> authentication work with SQL Server?
>
>
[ Post a follow-up to this message ]
| 
