wcf - 服务器使用用户帐户的 WCF Kerberos 客户端模式

Question

我们有一个 WCF(Windows Communication Foundation)客户端和服务应用程序。我们使用带有 Kerberos 的 Windows 身份验证。

问题是该服务可能在多个帐户之一下运行(可能是网络服务，可能是特定的用户帐户——取决于 IT 组)。该帐户不太可能每天更改，但可能偶尔(可能每隔几个月)更改一次。此外，我们将此客户端/服务包交付给多个组，每个组可能有自己的帐户用于运行服务(这只是让您知道我们无法为单个团队提供自定义解决方案).

现在上述段落成为问题的原因显然是如果服务不是在 SYSTEM 或 NETWORK SERVICE 帐户(即用户帐户)中运行，则客户端必须在其身份中指定用户帐户的名称端点。

有关此限制的更多信息，请参阅:http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/feb6bc31-9a4b-4f8d-a887-ef6d2c7abe41 和 http://www.vistax64.com/indigo/146204-using-localhost-v-s-environment-machinename.html

现在，这似乎很难处理 IT 部门更改运行服务的帐户的情况。如果有的话，处理这个问题的模式是什么？其他人是如何处理的？我想到的一种解决方案是，当服务的用户帐户发生更改时，管理员会发送一封电子邮件，其中包含指向更新客户端或配置文件的应用程序的网络链接，因此客户端会引用新的用户帐户.但这似乎很老套。

不可否认，这很像端点移动的 URI。除此之外，我认为代表人们有更多的期望，即更改 URI 是客户必须知道的事情，但更改运行服务的帐户对客户来说应该是相对透明的。

顺便说一句，如果重要的话，这需要在 IIS 7.0 上托管。

Answer 1

我想你可以设置NegotiateServiceCredential属性设置为 True，以便您的绑定(bind)使用 SPNego而不是硬冷Kerberos .当设置为true时，客户端不需要指定SPN，它可以连接到运行非机器帐户的服务器。

请注意，由于客户端不再请求特定的 SPN，它无法再检测是否连接到服务的被劫持模仿者，但这通常是一个小问题，除非您真的对安全性很偏执。

此外，顺便说一句:WCF 将帐户名作为 SPN 请求的事实基本上是脑放屁。它的客户端应该使用 DsMakeSpn从服务名称、主机和端口组成 SPN 的 API。服务器应在启动时为其自身注册该 SPN，或者让管理员使用 setspn.exe 注册该 SPN。 .这是他们在 Kerberos/ActiveDirecotry/Windows 环境中通过所有传统(表现良好的)服务执行此操作的方式。

更新

第二，虽然我没有看到任何指定客户端必须使用帐户名作为 SPN 的内容。看起来更像是文档监督，而不是记录他们只是推荐基本上是不好的做法的正确方法。或者也许只是论坛的建议不好，因为我没有深入了解 MSDN 绑定(bind)规范实际上对要使用的 SPN 说了什么......

我没有方便测试的 WCF 环境，但也许您可以将客户端配置为请求适当的 SPN，如 YourService/server:port并且您还在服务器端注册了相同的 SPN。手 Action 为留给管理员的练习，或者在服务启动时自动从您的服务中自动注册，并在关闭时取消注册。 正确的方法是让管理员来做，但实际上这很痛苦，大多数服务自己注册 SPN，您也可以遵循这种做法。要注册 SPN，您的服务调用 DsWriteAccountSpn .写入必须传播到 AD 并在 AD 服务器之间复制，这至少是为什么让服务自动注册/自动注销 SPN 是一种有问题的做法的原因之一。

如果您想了解更多关于 SPN 的奇妙世界以及它们如何破坏您的一天，您可以继续阅读 How Service Publication and Service Principal Names Work .

更新

我很确定您可以使用任何您喜欢的 SPN。那里的大多数示例使用帐户名称作为“UPN”(用户主体名称)而不是 SPN，但这只是为了示例的方便，因为使用真正的 SPN 会遇到在用户帐户下设置 SPN 的管理问题(再次，为什么管理员应该这样做...)。来自 Overriding the Identity of a Service for Authentication , 相关强调:

By default, when a service is configured to use a Windows credential, an element that contains a <userPrincipalName> or <servicePrincipalName> element is generated in the WSDL. If the service is running under the LocalSystem, LocalService, or NetworkService account, a service principal name (SPN) is generated by default in the form of host/<hostname> because those accounts have access to the computer's SPN data. If the service is running under a different account, Windows Communication Foundation (WCF) generates a UPN in the form of <username>@<domainName>. This occurs because Kerberos authentication requires that a UPN or SPN be supplied to the client to authenticate the service.

You can also use the Setspn.exe tool to register an additional SPN with a service's account in a domain. You can then use the SPN as the identity of the service. To download the tool, see Windows 2000 Resource Kit Tool : Setspn.exe. For more information about the tool, see Setspn Overview.