0

我正在开发一个需要在双跳场景中进行委派的项目。我们有一个桌面客户端，使用 net.tcp 绑定连接到 WCF 服务，连接到另一台服务器上的 SQL 数据库。我们的目标是使用用户的凭据来访问 SQL 数据库。

WCF 服务和 SQL 数据库都在同一个域用户下运行，该用户为 SQL 数据库启用了委派。已按照此处的说明进行操作，但没有成功。

现在，我们的日志中记录了一些详细信息： SQL 数据库上使用的登录名显示为运行 WCF 服务的用户，并使用 Kerberos。WCF 服务器上使用的登录名显示为客户端用户，但使用的是 NTLM。使用[OperationBehavior(Impersonation = ImpersonationOption.Allowed)]或using (ServiceSecurityContext.Current.WindowsIdentity.Impersonate())导致命令在 WCF 服务器上作为客户端运行。这让我相信模拟工作正常。

那么，什么可能导致第一个跃点回退到 NTLM？我们怀疑这是 SPN 问题，但我们已将 WCF 服务和 SQL 服务的 SPN 注册到共享域用户。此外，按照上面列出的说明，我们已将 SQL 服务设置为受信任的域用户委派。

我们EndpointIdentity.CreateSpnIdentity在 WCF 服务上使用了设置 SPN，这就是我们向域用户注册的 SPN。

有什么建议么？提前致谢！

编辑：我们发现了一些可能存在问题的东西——我们没有EndpointIdentity.CreateSpnIdentity在客户端上使用过。设置后，我们收到错误“调用 SSPI 失败”，内部异常“目标原理名称不正确”。但是我们在客户端和服务端设置的 SPN 匹配，并且都匹配服务的主机名。如果我们将客户端和服务器 SPN 都设置为完全不同的值，或者如果客户端指定的 SPN 与服务器的 SPN 不匹配，则身份验证会像以前一样回退到 NTLM。我们已经对该错误进行了研究，但找不到其原因。有什么建议么？

我们还对这两种情况进行了数据包捕获——回退到 NTLM 以及当我们收到“调用 SSPI 失败”错误时。在这两种情况下，都会发送和接收类似的数据包，直到其中一个提到 NTLM。另一方面，“TURN CHANNEL”数据包从客户端发送到服务器。这些数据包不包含任何人类可读的内容，除了服务器的 IP 地址，直到提到 NTLM，发送用户名和计算机名称，或者发送“TURN CHANNEL”数据包，其中包含似乎是 SPN 的内容，可能还有主机名。似乎没有任何人类可读的错误代码或错误消息。关于在数据包中寻找什么有什么建议吗？

4

1 回答 1

0

我们发现了我们的错误 - 客户端正在使用服务器的 IP 地址创建连接。将 IP 切换为完全限定域名后，第一跳始终使用 Kerberos 进行身份验证。

IP 地址解析为我们在两个 SPN 中使用的相同字符串，但我想客户端会在执行任何其他检查之前检查连接字符串是否与斜杠后面的 SPN 部分匹配。

我们使用网络服务和我们的域用户测试了我们的结果，只要 SPN 分别注册到计算机或用户，就没有问题。

希望这个答案可以为其他人节省一些时间和麻烦！


附加说明：虽然这为所有连接启用了 Kerberos 身份验证，但我们后来发现这在我们的情况下是不必要的。我们与数据库的部分连接不在模拟 using 块内，这导致表读取失败。此后，我们删除了所有委托和 SPN 相关代码，并且数据库连接继续正常工作。我们的第一跳是使用 NTLM。我们不确定在 SQL 服务器上是如何使用凭据的，因为我们的连接似乎正是所谓的双跳场景，这应该需要 Kerberos 和委派，但很难争论什么是有效的。我怀疑这可能与本文档中授权下的注释有关：

当客户端使用与后端服务上的 Windows 帐户对应的用户名和密码对前端服务进行身份验证时，前端服务可以通过重用客户端的用户名和密码对后端服务进行身份验证. 这是一种特别强大的身份流形式，因为将用户名和密码传递给后端服务可以使后端服务执行模拟，但由于未使用 Kerberos，因此不构成委托。Active Directory 对委派的控制不适用于用户名和密码身份验证。

如果有人对它的工作原因有任何其他建议，我很想听听他们的意见。但是，我觉得不值得再提出一个问题。

于 2012-09-18T00:15:41.613 回答