Asp.net n'authentifiant pas sur le service wcf sur le serveur 2008

Question

Je ne parviens pas à déployer un site Web sur IIS 7 sous Windows Server 2008. Le site fonctionne correctement jusqu'à ce qu'il tente d'appeler un service WCF hébergé sur le même hôte.

Tout fonctionne parfaitement pour le service de mon poste de travail lorsque le Web est exécuté dans Visual Studio 20008 en utilisant exactement la même configuration Web, etc. Dès que je déploie le Web dans un répertoire virtuel sur le serveur Bam. Erreurs d'authentification. Il fonctionne également tel quel lorsque les deux sont déployés sur un serveur Windows 2003. Quoi est différent à propos de Server 2008 qui est la cause? AIDEZ-MOI! S'il vous plaît.

Si cela est important, toutes les opérations de service nécessitent l'appartenance au groupe Active Directory pour la Les utilisateurs authentifiés de la page ASP.net sont ornés comme suit: [PrincipalPermission (SecurityAction.Demand, Role = & Quot; SOAMemberShipService & Quot;))]

J'ai le message d'erreur suivant sur le site Web:

La demande de jeton de sécurité n'a pas pu être satisfaite car l'authentification a échoué. Description: une exception non gérée s'est produite lors de l'exécution de la demande Web en cours. Consultez la trace de la pile pour plus d'informations sur l'erreur et son origine dans le code.

Détails de l'exception: System.ServiceModel.FaultException: la demande de jeton de sécurité n'a pas pu être satisfaite car l'authentification a échoué.

Erreur source:

Ligne 919:
Ligne 920: public HSMembersService.MemberSearchResult SearchMembers (HSMembersService.MemberSearch MemberInfoToSearch) { Ligne 921: return base.Channel.SearchMembers (MemberInfoToSearch); Ligne 922:} Ligne 923:}

Fichier source: c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Fichiers ASP.NET temporaires \ csrweb \ a4d18657 \ a6d0910d \ App_WebReferences.jgx1svpr.0.cs Ligne: 921

Trace de pile:

[FaultException: la demande de jeton de sécurité n'a pas pu être satisfaite car l'authentification a échoué.]    System.ServiceModel.Security.SecurityUtils.ThrowIfNegotiationFault (Message message, cible EndpointAddress) +6375432    System.ServiceModel.Security.IssuanceTokenProviderBase`1.ThrowIfFault (Message message, cible EndpointAddress) +25    System.ServiceModel.Security.SspiNegotiationTokenProvider.GetNextOutgoingMessageBody (Message incomingMessage, SspiNegotiationTokenProviderState sspiState) +173

[SecurityNegotiationException: l'appelant n'a pas été authentifié par le service.]    System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (Demande IMessage, Retrait IMessage) +4596611    System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (MessageData & Et msgData, type Int32) +1713    HSMembersService.IHSMembersService.SearchMembers (MemberSearch MemberInfoToSearch) +0    HSMembersService.HSMembersServiceClient.SearchMembers (MemberSearch MemberInfoToSearch) dans c: \ Windows \ Microsoft.    _default.btnSearch_Click (Expéditeur d'objet, EventArgs e) dans 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 du site Web ASP.net (partie Service pertinente):

                                                                                                            

Services 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

D'accord, pas de réponses ici ni sur les groupes d'abonnement MSDN.

Alors, j'ai tout essayé. Et je veux dire tout. Après ce qui semblait être plusieurs jours mais en réalité ce n’était probablement que 20 heures, ça marche!

Je n’ai fait que déplacer le chemin physique des fichiers de services, à savoir .dll, .svc, etc., dans un répertoire situé entre c: root et wwwroot. Je devais mettre à jour mon répertoire virtuel pour le désigner, bien sûr.

Pourquoi cet emplacement a-t-il causé un problème? Est-ce que IIS7.0 / Windows Server 2008 modifie quelque chose qui empêche le déploiement de services à partir d'un emplacement physique de wwwroot? Je ne le saurai probablement jamais car je n'essaierai jamais de déployer un autre service à partir de là.

J'ai vérifié trois fois toutes les autorisations de compte / répertoire et celles du nouveau chemin physique sont identiques à celles de l'ancien chemin physique, donc rien de bon là.

Si quelqu'un découvre pourquoi ou sait pourquoi. Merci de me le faire savoir / nous.

Merci,

Eddie

Answer 2

Cela pourrait être lié à this .