由于身份验证失败，无法满足对安全令牌的请求；一种安装有效，一种无效

Question

一些背景：

我们正在将一个相当复杂的 Web 服务架构迁移到更新的 Windows 服务器。作为其中的一部分，一些网站/服务已从 IIS6 移至 IIS7。所以新机器，相同的配置，可能是不同版本的IIS。

所有代码都已重新编译（未更改）到 VS2012/.NET 4.0。 这是 C# 和 VB.NET 的混合体。

我们有一个具有以下配置的 WCF Web 服务。

<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
<extensions>
  <behaviorExtensions>
    <add name="caller" type="xxx.CallerBehaviorExtensionElement, xxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  </behaviorExtensions>
</extensions>
<behaviors>
  <endpointBehaviors>
    <behavior name="caller">
      <caller />
    </behavior>
 <clientCredentials>
  <serviceCertificate>
   <authentication revocationMode="NoCheck" />
  </serviceCertificate>
  <windows allowedImpersonationLevel="Delegation" />
 </clientCredentials>
</behavior>
  </endpointBehaviors>
  <serviceBehaviors>
    <behavior name="xxxWcfBehavior">
      <serviceMetadata httpGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="false" />
    </behavior>
  </serviceBehaviors>
</behaviors>
<services>
  <service behaviorConfiguration="xxxWcfBehavior" name="xxxWcf">
    <endpoint address="" behaviorConfiguration="caller" binding="wsHttpBinding" contract="xxxWcf">
      <identity>
        <dns value="localhost" />           
      </identity>
    </endpoint>
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
  </service>
</services>

从 ASMX Web 服务 (1) 调用它可以正常工作。 从 ASMX Web 服务 (2) 调用它不起作用，返回以下异常：

System.ServiceModel.Security.SecurityNegotiationException：调用者未经服务验证。 ---> System.ServiceModel.FaultException: 由于身份验证失败，无法满足对安全令牌的请求。

这是客户端的 web.config：

 <system.serviceModel>
  <extensions>
    <behaviorExtensions>
      <add name="caller" type="xxxx.CallerBehaviorExtensionElement, xxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
    </behaviorExtensions>
  </extensions>
  <behaviors>
    <endpointBehaviors>
      <behavior name="caller">
        <caller />
      </behavior>
    </endpointBehaviors>
  </behaviors>
  <bindings>
    <wsHttpBinding>
      <binding name="xxxDataWcf" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384"/>
        <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false"/>
        <security mode="Message">
          <transport clientCredentialType="Windows" proxyCredentialType="None" realm=""/>
          <message clientCredentialType="Windows" negotiateServiceCredential="true" algorithmSuite="Default" establishSecurityContext="true"/>
        </security>
      </binding>
    </wsHttpBinding>
  </bindings>
    <client>
        <endpoint address="http://xxxDataWcf.svc"
            binding="wsHttpBinding" bindingConfiguration="xxxDataWcf"
            contract="xxxDataWcf" name="xxxDataWcf">
            <identity>
                <dns value="localhost" />
            </identity>
        </endpoint>

    </client>
</system.serviceModel>

但是 (1) 和 (2) 之间有什么区别？ 我什么都不建议。多人比较了 IIS 配置（这发生在 v6 和 v7 中），比较了 web.configs，创建了测试项目并比较了权限。

我一直在纠结是否包含 CallerBehaviorExtensionElement。我确定它不相关，但已将其包含在内，因为删除它会使配置无效，以至于无济于事。所有这些都是在不依赖委托/ASP.NET 身份验证的情况下跨跃点传递用户名的欺骗。需要明确的是，这不会形成授权，也不会以任何方式与 Windows 的授权基础结构进行交互。我们只是用它来用调用者的用户名标记最终记录。

根据我们之前的调查：

• 我们不会跨域
• 我们不想降低安全性，因为这 是典型的反应 WCF: The request for security token could not be satisfied because authentication failed

似乎股票对错误的反应是削弱安全性，我们不愿意这样做。这在 IIS6 配置中运行良好，并且在 IIS7 下的本地开发机器上运行良好（奇怪的是，即使跨机器/操作系统边界）。所以它原则上是有效的。

我们正在努力寻找社区的提示。如果您需要任何具体信息，请询问。这是 WCF，我相信您会意识到配置可能非常嘈杂。

Answer 1

根据您的最后评论，我认为您很可能遇到此处描述的问题：http://blogs.msdn.com/b/distributedservices/archive/2009/11/10/wcf-calling-wcf-service-hosted-in-iis-on-the-same-machine-as-client-throws-an-authentication-error.aspx