2

我们有一个 WCF 数据服务，它在 Windows 服务（不使用 IIS）下自托管，我们目前正在努力使用 SSL 和 Windows 身份验证来保护它。

在使用 netsh 和服务器证书一段时间后，我们现在使用 SSL 保护服务，并且我们还在 app.config 中的 webHttpBinding 上启用了 Windows 身份验证 - 但是我们现在在尝试对某些用户进行身份验证时看到一些奇怪的行为 -有些人可以正常登录，有些人的凭据被拒绝，并提示 HTTP 400 错误。

经过一些测试和挖掘之后，我们可能会遇到这个问题，其中 Kerberos 使用的身份验证标头可能大于某些用户的最大允许标头长度（我相信是 16k） - 尽管有记录在案的 IIS 解决方法，似乎没有可用于自托管服务或 app.config 的等效设置 - 除非我遗漏了什么？我们尝试将 maxReceivedMessageSize 和 maxBufferSize 字段设置为其最大值，以查看这是否会产生任何影响，但显然不会。

绑定配置：

  <webHttpBinding>
    <binding name="DataServicesBinding"
             maxReceivedMessageSize="2147483647"
             maxBufferSize="2147483647">
      <security mode="Transport">
        <transport clientCredentialType="Windows" />
      </security>
    </binding>
  </webHttpBinding>

我们已经设法通过在绑定中设置 clientCredentialType 来临时解决此问题，以使用 Ntlm，但出于显而易见的原因，我们希望尽可能让 Kerberos 正常工作。

4

2 回答 2

2

因此，事实证明，这是由于我们的服务没有配置 SPN（服务主体名称）造成的。这可以使用带有 Windows Server 的 setspn 工具来完成。（有关详细信息，请参阅此 MSDN 文章。）

应用 SPN 后，Kerberos 身份验证开始按预期工作。

于 2013-09-11T08:21:51.047 回答
0

使用wireshark 查看客户端发送的内容。确保此输入正确，然后返回。

于 2013-08-14T06:41:10.717 回答