Asp.net not authenticating against wcf service on server 2008

Question

I am having a tough time deploying a web site to IIS 7 on Windows Server 2008. The site works fine until it tries to make calls to a WCF service hosted on the same host.

Everything works great for the service from my workstation when the web is ran in Visual Studio 20008 using the exact same web config etc. As soon as I deploye the web in a virtual directory on the server Bam. Authentication errors. It also works as is when both are deployed on a Windows 2003 Server. What is different about Server 2008 that is causing this? HELP! Please.

In case it is important, all of the service operations require Active Directory group membership for the ASP.net page's authenticated user and are adorned as: [PrincipalPermission(SecurityAction.Demand, Role = "SOAMemberShipService")]

I get the following error from the web site:

The request for security token could not be satisfied because authentication failed. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.ServiceModel.FaultException: The request for security token could not be satisfied because authentication failed.

Source Error:

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

Source File: c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\csrweb\a4d18657\a6d0910d\App_WebReferences.jgx1svpr.0.cs Line: 921

Stack Trace:

[FaultException: The request for security token could not be satisfied because authentication failed.] System.ServiceModel.Security.SecurityUtils.ThrowIfNegotiationFault(Message message, EndpointAddress target) +6375432 System.ServiceModel.Security.IssuanceTokenProviderBase`1.ThrowIfFault(Message message, EndpointAddress target) +25 System.ServiceModel.Security.SspiNegotiationTokenProvider.GetNextOutgoingMessageBody(Message incomingMessage, SspiNegotiationTokenProviderState sspiState) +173

[SecurityNegotiationException: The caller was not authenticated by the service.] System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) +4596611 System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) +1713 HSMembersService.IHSMembersService.SearchMembers(MemberSearch MemberInfoToSearch) +0 HSMembersService.HSMembersServiceClient.SearchMembers(MemberSearch MemberInfoToSearch) in c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\csrweb\a4d18657\a6d0910d\App_WebReferences.jgx1svpr.0.cs:921 _default.btnSearch_Click(Object sender, EventArgs e) in 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

ASP.net web site's web.config (relevant Service portion):

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

Nope. I need AD authentication.

Answer 2

Okay, no answers here nor on the MSDN subscription groups.

So, I tried everything. And I mean everything. After what seemed like several days but in reality was probably only 20 hours, it works!

All I did was move the physical path the services files i.e. .dll, .svc etc. to a directory off of my c:root versus the wwwroot and it worked. I had to update my virtual directory to point to it of course.

Why did this location cause a problem? Does IIS7.0/Windows server 2008 change something that doesn't allow services to be deployed from a physical location of wwwroot? I'll probably never find out because I will never try to deploy another service from there.

I triple-checked all account/directory permissions and the ones in the new physical path are identical to the ones in the old physical path so no good there.

If anyone finds out why or knows why. Please let me/us know.

Thanks,

Eddie

Answer 3

It might be related to this.