Windows 身份模拟未持续进入 Sql 可信连接
Windows Identity Impersonation not persisting into Sql Trusted Connection
我继承了一个使用模拟连接到数据库的 WCF Web 服务，在尝试获取自动化测试时 运行我注意到任何这些命中服务的测试实例都失败了有 401 响应。
使用 Fiddler 捕获响应我能够看到它正在尝试使用 NT AUTHORITY\ANONYMOUS LOGON 打开数据库连接。
我最终在连接打开前获得了远程调试设置和断点，我使用即时 window 检查当前主体，结果如下：
?System.Security.Principal.WindowsIdentity.GetCurrent().Name
"myDomain\myUser"
这正是我期待看到的。在此之后，我检查了我们的连接字符串的内容，它是：
Data Source=myDbServer;Initial Catalog=devDb;Integrated Security=True;User ID=;Password=;Asynchronous Processing=False;Connect Timeout=300;Application Name=myApp
这又是预期的结果。
我的下一步是禁用模拟并查看当时正在尝试连接的用户：
?System.Security.Principal.WindowsIdentity.GetCurrent().Name
"NT AUTHORITY\NETWORK SERVICE"
不过这次401报错是用户myDomain\myDevServer没有权限
该服务 运行 在 IIS 7 的网络服务下，这是预期的。虽然我确实尝试过在域用户下使用它 运行，但看到了完全相同的结果：SQL attempted login with NT AUTHORITY\ANONYMOUS LOGON
我的问题与 this question 上遇到的问题密切相关。
但是，使用相同的直接 window 技术，我验证了我的模拟级别，这确实是委托：
?System.Security.Principal.WindowsIdentity.GetCurrent().ImpersonationLevel
Delegation {4}
那么什么会导致受信任的 sql 连接获得与当前主体中显示的用户完全不同的用户？
更新：
我已验证 DC 上的设置，机器帐户配置为无约束委派，我的用户帐户未标记为敏感。
我也逐步完成了 this article 我确实注意到在双跳部分下他说应该启用 ASP.NET 模拟身份验证提供程序，但是这样做会导致服务器立即 return 500，它永远不会进入托管代码。
附加信息：
所有服务都应用了 [OperationBehavior(Impersonation = ImpersonationOption.Allowed)] 属性并且 web.config 文件具有 <serviceAuthorization impersonateCallerForAllOperations="true" />
服务有一个用于 restful 调用的 webHttpBinding 和一个用于 soap 调用的 basicHttpBinding，两个端点都遇到相同的问题。
尝试在模拟上下文下对远程资源进行身份验证需要委托。遵循 Delegation and Impersonation with WCF 中的委派指南（这些步骤需要域管理员）：
On the domain controller, clear the Account is sensitive and cannot be delegated check box for the account under which the client application is running.
On the domain controller, select the Account is trusted for delegation check box for the account under which the client application is running.
On the domain controller, configure the middle tier computer so that it is trusted for delegation, by clicking the Trust computer for delegation option.
On the domain controller, configure the middle tier computer to use constrained delegation, by clicking the Trust this computer for delegation to specified services only option.
如果您使用的是 Windows Server 2012 环境，请参阅 How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation。
如果您想了解有关此问题的更多信息，google for "Kerberos double hop" 您会找到大量资源，包括此处关于 SO 的许多答案。
最可能的原因是 SQL 服务主体名称 (SPN) 配置错误。当直接连接到 SQL（例如从 Management Studio）时，错误配置的 SPN 会导致回退到 NTLM（即不会被注意到）。但是在授权情况下回退是不允许的，这会导致身份验证失败，因此授权是针对匿名登录完成的，就像在 OP 中看到的那样。 SQL Server Kerberos and SPN Quick Reference 是个好资源。
我继承了一个使用模拟连接到数据库的 WCF Web 服务，在尝试获取自动化测试时 运行我注意到任何这些命中服务的测试实例都失败了有 401 响应。
使用 Fiddler 捕获响应我能够看到它正在尝试使用 NT AUTHORITY\ANONYMOUS LOGON 打开数据库连接。
我最终在连接打开前获得了远程调试设置和断点，我使用即时 window 检查当前主体，结果如下：
?System.Security.Principal.WindowsIdentity.GetCurrent().Name
"myDomain\myUser"
这正是我期待看到的。在此之后，我检查了我们的连接字符串的内容，它是：
Data Source=myDbServer;Initial Catalog=devDb;Integrated Security=True;User ID=;Password=;Asynchronous Processing=False;Connect Timeout=300;Application Name=myApp
这又是预期的结果。
我的下一步是禁用模拟并查看当时正在尝试连接的用户：
?System.Security.Principal.WindowsIdentity.GetCurrent().Name
"NT AUTHORITY\NETWORK SERVICE"
不过这次401报错是用户myDomain\myDevServer没有权限
该服务 运行 在 IIS 7 的网络服务下，这是预期的。虽然我确实尝试过在域用户下使用它 运行，但看到了完全相同的结果：SQL attempted login with NT AUTHORITY\ANONYMOUS LOGON
我的问题与 this question 上遇到的问题密切相关。 但是，使用相同的直接 window 技术，我验证了我的模拟级别，这确实是委托：
?System.Security.Principal.WindowsIdentity.GetCurrent().ImpersonationLevel
Delegation {4}
那么什么会导致受信任的 sql 连接获得与当前主体中显示的用户完全不同的用户？
更新：
我已验证 DC 上的设置，机器帐户配置为无约束委派，我的用户帐户未标记为敏感。
我也逐步完成了 this article 我确实注意到在双跳部分下他说应该启用 ASP.NET 模拟身份验证提供程序，但是这样做会导致服务器立即 return 500，它永远不会进入托管代码。
附加信息：
所有服务都应用了 [OperationBehavior(Impersonation = ImpersonationOption.Allowed)] 属性并且 web.config 文件具有 <serviceAuthorization impersonateCallerForAllOperations="true" />
服务有一个用于 restful 调用的 webHttpBinding 和一个用于 soap 调用的 basicHttpBinding，两个端点都遇到相同的问题。
尝试在模拟上下文下对远程资源进行身份验证需要委托。遵循 Delegation and Impersonation with WCF 中的委派指南（这些步骤需要域管理员）：
On the domain controller, clear the Account is sensitive and cannot be delegated check box for the account under which the client application is running.
On the domain controller, select the Account is trusted for delegation check box for the account under which the client application is running.
On the domain controller, configure the middle tier computer so that it is trusted for delegation, by clicking the Trust computer for delegation option.
On the domain controller, configure the middle tier computer to use constrained delegation, by clicking the Trust this computer for delegation to specified services only option.
如果您使用的是 Windows Server 2012 环境，请参阅 How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation。
如果您想了解有关此问题的更多信息，google for "Kerberos double hop" 您会找到大量资源，包括此处关于 SO 的许多答案。
最可能的原因是 SQL 服务主体名称 (SPN) 配置错误。当直接连接到 SQL（例如从 Management Studio）时，错误配置的 SPN 会导致回退到 NTLM（即不会被注意到）。但是在授权情况下回退是不允许的，这会导致身份验证失败，因此授权是针对匿名登录完成的，就像在 OP 中看到的那样。 SQL Server Kerberos and SPN Quick Reference 是个好资源。