|
Home > Archive > IIS Server Security > March 2004 > IIS6 Authentication Problem with SQL Server 2000
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
IIS6 Authentication Problem with SQL Server 2000
|
|
| corndog 2004-03-24, 5:57 pm |
| 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 app
lication 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 Wi
ndows authentication work with SQL Server?
| |
| Ken Schaefer 2004-03-24, 8:36 pm |
| 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....asp?frame=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/...el_computer.asp
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...y/constdel.mspx
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?
| |
| Tom Kaminski [MVP] 2004-03-25, 9:51 am |
| 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....asp?frame=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/...el_computer.asp
> 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...y/constdel.mspx
>
>
> 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?
>
>
|
|
|
|
|