Asp.net não autenticação contra o serviço WCF no server 2008

Question

Eu estou tendo um momento difícil a implantação de um web site para o IIS 7 no Windows Server 2008. O site fina funciona até que ele tenta fazer chamadas a um serviço WCF hospedado no mesmo host.

Tudo funciona muito bem para o serviço de minha estação de trabalho quando a web é executado no Visual Studio 20008 usando exatamente a mesma web de configuração etc. Assim que eu Déployé da web em um diretório virtual no servidor Bam. Erros de autenticação. Ele também funciona como é quando ambos são implantados em um Windows 2003 Server. o que é diferente sobre Server 2008 que está causando isso? SOCORRO! Por favor.

Em caso é importante, todas as operações de serviço exigem associação de grupo do Active Directory para o ASP.net página do usuário autenticado e são adornados como: [PrincipalPermission (SecurityAction.Demand, Role = "SOAMemberShipService")]

Eu recebo o seguinte erro do web site:

O pedido de token de segurança não pôde ser satisfeita porque a autenticação falhou. Descrição: Uma exceção não tratada ocorreu durante a execução da solicitação da web atual. Examine o rastreamento de pilha para obter mais informações sobre o erro e onde foi originado no código.

Exceção detalhes: System.ServiceModel.FaultException:. O pedido de token de segurança não poderia ser satisfeita porque a autenticação falhou

Fonte de erro:

Linha 919:
Linha 920: SearchMembers HSMembersService.MemberSearchResult pública (HSMembersService.MemberSearch MemberInfoToSearch) { Linha 921: retorno base.Channel.SearchMembers (MemberInfoToSearch); Linha 922:} Linha 923:}

Source File: c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Arquivos temporários ASP.NET \ csrweb \ a4d18657 \ a6d0910d \ App_WebReferences.jgx1svpr.0.cs Line: 921

Stack Trace:

[FaultException: O pedido de token de segurança não pôde ser satisfeita porque a autenticação falhou.] System.ServiceModel.Security.SecurityUtils.ThrowIfNegotiationFault (mensagem Mensagem, alvo EndpointAddress) 6.375.432 System.ServiceModel.Security.IssuanceTokenProviderBase`1.ThrowIfFault (mensagem Mensagem, alvo EndpointAddress) +25 System.ServiceModel.Security.SspiNegotiationTokenProvider.GetNextOutgoingMessageBody (Mensagem incomingMessage, SspiNegotiationTokenProviderState sspiState) 173

[SecurityNegotiationException: O chamador não foi autenticado pelo serviço.] System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (IMessage reqMsg, IMessage retMsg) 4.596.611 System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (MessageData & msgData, tipo Int32) 1713 HSMembersService.IHSMembersService.SearchMembers (MemberSearch MemberInfoToSearch) 0 HSMembersService.HSMembersServiceClient.SearchMembers (MemberSearch MemberInfoToSearch) em C: \ WINDOWS \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Arquivos temporários ASP.NET \ csrweb \ a4d18657 \ a6d0910d \ App_WebReferences.jgx1svpr.0.cs: 921 _default.btnSearch_Click (objecto remetente, EventArgs e) em E: \ \ CSRWeb Default.aspx.cs: 114 System.Web.UI.WebControls.Button.OnClick (EventArgs e) 131 System.Web.UI.WebControls.Button.RaisePostBackEvent (String eventArgument) 140 System.Web.UI.Page.RaisePostBackEvent (IPostBackEventHandler SourceControl, String eventArgument) 39 System.Web.UI.Page.ProcessRequestMain (Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) 3215

web.config web site ASP.net (parte Serviço relevante):

Serviços web.config:

    <!-- Service Endpoints -->
    <!-- Unless fully qualified, address is relative to base address supplied above -->
    <endpoint address ="" binding="wsHttpBinding" contract="HSMembersService.IHSMembersService" bindingConfiguration="wsHttpBindingConfig">
      <!-- 
          Upon deployment, the following identity element should be removed or replaced to reflect the 
          identity under which the deployed service runs.  If removed, WCF will infer an appropriate identity 
          automatically.
      -->
      <!--<identity>
        <dns value="localhost"/>
      </identity>-->
    </endpoint>
    <!-- Metadata Endpoints -->
    <!-- The Metadata Exchange endpoint is used by the service to describe itself to clients. -->
    <!-- This endpoint does not use a secure binding and should be secured or removed before deployment -->
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
  </service>
</services>
<bindings>
  <wsHttpBinding>
    <binding name="wsHttpBindingConfig" >
      <security mode="Message">
        <message clientCredentialType="Windows" />
      </security>

    </binding>
  </wsHttpBinding>
</bindings>
<behaviors>
  <serviceBehaviors>
    <behavior name="HSMembersService.HSMembersServiceBehavior">
      <!-- To avoid disclosing metadata information, 
      set the value below to false and remove the metadata endpoint above before deployment -->
      <serviceMetadata httpGetEnabled="True"/>

      <serviceAuthorization principalPermissionMode="UseWindowsGroups"         />
      <!-- To receive exception details in faults for debugging purposes, 
      set the value below to true.  Set to false before deployment 
      to avoid disclosing exception information -->
      <serviceDebug includeExceptionDetailInFaults="True" /><!-- Change this before deployment -->
    </behavior>
  </serviceBehaviors>
</behaviors>

Answer 1

Ok, há respostas aqui nem nos grupos de subscrição MSDN.

Então, eu tentei de tudo. E eu quero dizer tudo. Depois do que pareceu vários dias, mas na realidade foi provavelmente apenas 20 horas, ele funciona!

Tudo que eu fiz foi mover o caminho físico dos arquivos de serviços ou seja, .dll, .svc etc para um diretório fora do meu c: raiz versus o wwwroot e funcionou. Eu tive que atualizar meu diretório virtual para apontar para ele é claro.

Por que este local causa um problema? Does IIS7.0 / Windows Server 2008 mudar algo que não permite serviços a serem implantados a partir de uma localização física de wwwroot? Eu provavelmente nunca descobrir porque eu nunca tentará implantar um outro serviço de lá.

Eu triple-verificadas todas as permissões de conta / diretório e os do novo caminho físico são idênticos aos que no antigo caminho físico assim, não boa lá.

Se alguém descobrir por que ou sabe porquê. Por favor, deixe-me / nos.

Obrigado,

Eddie

Answer 2

Pode estar relacionado com este .