我们有一个系统，客户希望集成 Windows 身份验证。
这是一个 ASP.NET 3.5 应用程序，连接到 Sql Server 2005。
Web服务器是Server 2003 R2 SP2。
数据库服务器是 Server 2003 SP2（不是 R2）。
在数据库服务器中，我运行了以下脚本，
exec sp_grantlogin 'myDomain\myUserGroup'
USE myDbName
exec sp_grantdbaccess 'myDomain\myUserGroup'
现在 Windows 用户组“myDomain\myUserGroup”中有 3 个用户。 所有三个用户的帐户都被标记为受信任的委派。 AD 中的 Web 服务器帐户被标记为可信任委派。
Web 应用程序被标记为使用 Windows 身份验证（所有其他身份验证均已关闭）。
web.config 有以下行：
<authentication mode="Windows" ></authentication>
<identity impersonate="true" />
<authorization>
<deny users="?"/>
</authorization>
然而，当我尝试使用用户组中的用户连接到 Web 应用程序时，我收到错误：
System.Data.SqlClient.SqlException:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
我的连接字符串是从 Sql ConnectionStringBuilder 构建的，构造如下：
ConnectionStringBuilder.DataSource = "MYDBSERVER"
ConnectionStringBuilder.InitialCatalog = "MYDBCATALOG"
ConnectionStringBuilder.IntegratedSecurity = True
如果我硬编码 web.config 上允许模拟的帐户之一 > 行它有效。 但是，如果我取消硬编码帐户并尝试从客户端计算机传递身份。 我得到了错误。
所以看来我没有为多跳集成登录场景正确配置一些东西，但我不知道是什么。
提前致谢！
we have a system where they client wants integrated Windows authentication.
This is an ASP.NET 3.5 application, connecting to Sql Server 2005.
The web server is Server 2003 R2 SP2.
The db server is Server 2003 SP2 (not R2).
In the db server, I ran the following script
exec sp_grantlogin 'myDomain\myUserGroup'
USE myDbName
exec sp_grantdbaccess 'myDomain\myUserGroup'
I have 3 users in the Windows user group 'myDomain\myUserGroup' right now. All three users' accounts are marked as trusted for delegation. The web server account in ADs is marked trusted for delegation.
The web application is marked as using Windows authentication (all others turned off).
The web.config has the following lines:
<authentication mode="Windows" ></authentication>
<identity impersonate="true" />
<authorization>
<deny users="?"/>
</authorization>
Yet when i try to connect to the web application with a user which is in the user group, i get the error:
System.Data.SqlClient.SqlException:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
My connection string is being built from a Sql ConnectionStringBuilder constructed as such:
ConnectionStringBuilder.DataSource = "MYDBSERVER"
ConnectionStringBuilder.InitialCatalog = "MYDBCATALOG"
ConnectionStringBuilder.IntegratedSecurity = True
If i HARD CODE one of the allowed accounts to impersonate on the web.config <identity /> line it works. But if i take off the hard coded account and try to pass the identity from the client's machine. I get the error.
So it seems that i don't have something configured correctly for the multi-hop integrated login scenario, but i can't figure out what.
Thanks in advance!
发布评论
评论（2）
ASP 计算机已验证通过 NTLM/Kerberos 连接到 IIS 的用户。 身份验证由域控制器保证，域控制器要求原始用户进程 (IE) 提供保证其身份的秘密：他登录框时输入的密码。 身份验证实际上不是由所涉及的进程完成的，而是由所涉及的每台计算机上的本地安全机构（LSA，又名 lsass.exe）完成的。 因为 ASP 计算机上的 LSA 知道身份验证正常，所以它将允许模拟远程用户在所述 LSA 的控制下访问其有权访问的任何内容（换句话说，本地 ASP 计算机上的所有内容） ）。
一旦模拟用户的 ASP 进程再次跳转到新计算机，它就离开了 ASP 计算机上的 LSA 控制的领域。 SQL 机器上的LSA 没有理由信任ASP 机器上的LSA。 因此，它要求它提供一个证据，证明它就是它所声称的人（被冒充的用户）。 不幸的是，ASP 机器无法提供这样的证明，因为它没有用户秘密（其密码）。
解决方法是所谓的“约束委托”。 通过约束委派，域控制器介入 SQL 机器 LSA 和 ASP 机器 LSA 之间的协商，并说“ASP 机器没问题，我为他担保”。 因此，SQL 的机器 LSA 信任身份验证并验证原始的模拟用户。
如何：使用协议转换中描述了如何设置约束委派的技术细节和 ASP.NET 2.0 中的约束委派
请注意，无论何时涉及“双跳”和模拟，无论涉及哪种类型的资源（可以是 SQL 服务器、可以是文件共享、可以是新的后端 ASP 服务）。
The ASP machine has authenticated the user connecting to IIS via NTLM/Kerberos. The authentication is guaranteed by the domain controller that has asked the original user process (IE) to present a secret that guarantees his identity: his password he typed when he logged into the box. The authentication is actually not done by the processes involved, but by the Local Security Authority (LSA, aka. lsass.exe) on each machine involved. Because the LSA on the ASP machine knows that the authentication is OK, it will allow an impersonation of the remote user to access anything it has the rights to access under the control of the said LSA (in other words, everything on the local ASP machine).
As soon as the ASP process that impersonates the user makes another hop to a new machine, it has left the realm controlled by the LSA on the ASP machine. The LSA on the SQL machine has no reason to trust the LSA on the ASP machine. So it ask it to present a proof that it is who it claims it is (the impersonated user). The ASP machine unfortunately cannot present such a proof, since it does not has the user secret (its password).
The work around is something called 'constrained delegation'. Through constrained delegation the domain controller intervenes in the negotiation between the SQL's machine LSA and the ASP machine LSA and says 'the ASP machine is OK, I vouch for him'. So the SQL's machine LSA trust the authentication and authenticate the original, impersonated user.
The technical details how to set up constrained delegation are described in How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
Note that this is true anytime a 'double hop' and impersonation is involved, no matter the type of resources involved (can be a SQL server, can be a file share, can be a new back end ASP service).
如果您使用 Windows 身份验证，则模拟不会经过 ASP.NET 进程本身。 这里有两个选项 - 切换到身份验证流的基本身份验证，或者如果您在 Win2003 或更高版本上运行，则可以使用 Kerberos 和 一些黑客行为在连接时进行模拟
If you're using Windows authentication then Impersonation doesn't flow past the ASP.NET process itself. You have two options here - swap to Basic Authentication, where Identity flows or, if you're running on Win2003 or later, you can use Kerberos and some hackery to impersonate when you connect