none
WCF authentication issue: request was forbidden with client authentication scheme 'Negotiate'

    Question

  • I didnt really know the appropriate place to post my problem, so I thought I might try here since technically it is a WCf problem. I am trying to write a Windows Worflow foundation Service activity which in itself is meant to communicate with a sharepoint WCF admin service ( currently installed locally on my dev machine which is on a domain). Initially due to not being able to get this going, I tried writing a simple WCF service, adding the sharepoint admin service and using the generated SOAP client to for example invoke the createSite operation, which successfully was able to communicate with the shareppoint service using the following config file:

    <?xml version="1.0"?>
    
    <configuration>
    
    
    
     <system.web>
    
     <compilation debug="true" targetFramework="4.0" />
    
     </system.web>
    
     <system.serviceModel>
    
     <bindings>
    
      <basicHttpBinding>
    
      <binding name="AdminSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
    
       receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false"
    
       bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
    
       maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
    
       messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
    
       useDefaultWebProxy="true">
    
       <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
    
       maxBytesPerRead="4096" maxNameTableCharCount="16384" />
    
       <security mode="TransportCredentialOnly">
    
       <transport clientCredentialType="Windows" proxyCredentialType="None"
    
        realm="" />
    
       <message clientCredentialType="UserName" algorithmSuite="Default" />
    
       </security>
    
      </binding>
    
      </basicHttpBinding>
    
     </bindings>
    
     <client>
    
      <endpoint address="http://localhost:40771/_vti_adm/Admin.asmx"
    
        behaviorConfiguration="ClientImpersonation"
    
      binding="basicHttpBinding" bindingConfiguration="AdminSoap"
    
      contract="SharePointAdminService.AdminSoap" name="AdminSoap">
    
      <identity>
    
       <dns value="localhost" />
    
      </identity>
    
      </endpoint>
    
     </client>
    
     <behaviors>
    
      <endpointBehaviors>
    
      <behavior name="ClientImpersonation">
    
       <clientCredentials>
    
       <windows allowedImpersonationLevel="Impersonation" />
    
       </clientCredentials>
    
      </behavior>
    
      </endpointBehaviors>
    
      <serviceBehaviors>
    
      <behavior name="">
    
       <serviceMetadata httpGetEnabled="true" />
    
       <serviceDebug includeExceptionDetailInFaults="false" />
    
      </behavior>
    
      </serviceBehaviors>
    
     </behaviors>
    
     <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
    
     </system.serviceModel>
    
     <system.webServer>
    
     <modules runAllManagedModulesForAllRequests="true"/>
    
     </system.webServer>
    
     
    
    </configuration>
    
    
    
    

    After this I created a simple workflow project, did the same adding of the service reference, added the newly generated activites to create a site (this is what is done automatically when a service reference is added) and then using the similar web.config bindings have been constantly unable to contact the service to create a site.

    Web.config used (note after some googling, replaced localhost with <NameOfMyMachine>):

    <?xml version="1.0" encoding="utf-8" ?>
    
    <configuration>
    
     <system.web>
    
     <compilation debug="true" targetFramework="4.0" />
    
     </system.web>
    
     <system.serviceModel>
    
     <bindings>
    
      <basicHttpBinding>
    
      <binding name="AdminSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
    
       receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false"
    
       bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
    
       maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
    
       messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
    
       useDefaultWebProxy="true">
    
       <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
    
       maxBytesPerRead="4096" maxNameTableCharCount="16384" />
    
       <security mode="TransportCredentialOnly">
    
       <transport clientCredentialType="Windows" proxyCredentialType="None"
    
        realm="" />
    
       <message clientCredentialType="UserName" algorithmSuite="Default" />
    
       </security>
    
      </binding>
    
      </basicHttpBinding>
    
     </bindings>
    
     
    
     <client>
    
      <endpoint address="http://<NameOfMyMachine>:40771/_vti_adm/Admin.asmx"
    
        behaviorConfiguration="ClientImpersonation"
    
      binding="basicHttpBinding" bindingConfiguration="AdminSoap"
    
      contract="AdminSoap" name="AdminSoap" >
    
      <identity>
    
       <dns value="<NameOfMyMachine>" />
    
      </identity>
    
      </endpoint>
    
     </client>
    
     
    
     <behaviors>
    
      <endpointBehaviors>
    
      <behavior name="ClientImpersonation">
    
       <clientCredentials>
    
       <windows allowedImpersonationLevel="Impersonation" />
    
       </clientCredentials>
    
      </behavior>
    
      </endpointBehaviors>
    
      <serviceBehaviors>
    
      <behavior name="">
    
       <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
    
       <serviceMetadata httpGetEnabled="true"/>
    
       <!-- 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="false"/>
    
      </behavior>
    
      </serviceBehaviors>
    
     </behaviors>
    
     <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
    
     </system.serviceModel>
    
     <system.webServer>
    
     <modules runAllManagedModulesForAllRequests="true"/>
    
     </system.webServer>
    
    </configuration>
    
    
    
    

     

    I constantly get the following exception every time the create site activity is invoked:

    "System.ServiceModel.Security.MessageSecurityException"
    
    "The HTTP request was forbidden with client authentication scheme 'Negotiate'."
    
    
    
    " at System.ServiceModel.Activities.CorrelationRequestContext.TryGetReply()
    
     at System.ServiceModel.Activities.InternalReceiveMessage.ClientScheduleOnReceiveMessageCallback(NativeActivityContext executionContext, ActivityInstance completedInstance)
    
     at System.Activities.Runtime.ActivityCompletionCallbackWrapper.Invoke(NativeActivityContext context, ActivityInstance completedInstance)
    
     at System.Activities.Runtime.CompletionCallbackWrapper.CompletionWorkItem.Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)"

    I am confused as I am very new to WCF and have been trying this for many days now. Any help or direction would be greatly appreciated

     Also I am suing the WCF test client to test the WF4 service, run when the project is debugged

     

    Wednesday, March 02, 2011 2:51 AM

Answers

  •  have found the issue. The problem is with the windows workflow foundation itself. Apparently, when adding a service reference to a WF project, instead of generating the usual wcf stubs, generates a set of activites to represent each service contract operations. These can be seen by selecting the "Show all file operations" in the VS2010 solution explorer and then expanding the service reference (usually under a node named along the lines of '*.svcmap'). Openeing up any of these activites, I noticed that the send request operation within the workflow activity within was implementing its own TokenImpersonationLevel setting. Unless changed manually from that location, I was quite shocked at the way this is implemented in windows workflow, since I cant seem to find any other way of changing it apart from manually within the workflow activity itself, which is pretty bad. Maybe my relative nubeity at WWF4 is the cause 

    But however in this case, the default option selected there was 'Identity'. Changing that to 'Impersonation' in my case worked fine. I might blog about this for future devs facing the same problem as well.

    • Marked as answer by pirahawk Wednesday, March 02, 2011 10:48 PM
    Wednesday, March 02, 2011 10:47 PM

All replies

  • Hi,

    I will move this thread to WCF forum for better support.

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Wednesday, March 02, 2011 5:44 AM
  •  

    Is your wcf is hosting in VS RUN TIME environment integrated Web Server ... in that case do your asp.net development server process running with admin privilege. 

    Can you host it within IIS? 

    Is your machine assigned to a domain? Try removing it from domain and then reset iis and run it. 

    As you are using Message level security ... do u have a certificate installed? 

     


    Tanvir Huda
    Wednesday, March 02, 2011 6:08 AM
  • Thank you for your reply. Yes at this point it is running within the asp development server for debugging purposes. Also I am not using an installed certificate at this point, since currently I am not too concerned about security  as opposed to getting it working

    Wednesday, March 02, 2011 7:40 PM
  •  have found the issue. The problem is with the windows workflow foundation itself. Apparently, when adding a service reference to a WF project, instead of generating the usual wcf stubs, generates a set of activites to represent each service contract operations. These can be seen by selecting the "Show all file operations" in the VS2010 solution explorer and then expanding the service reference (usually under a node named along the lines of '*.svcmap'). Openeing up any of these activites, I noticed that the send request operation within the workflow activity within was implementing its own TokenImpersonationLevel setting. Unless changed manually from that location, I was quite shocked at the way this is implemented in windows workflow, since I cant seem to find any other way of changing it apart from manually within the workflow activity itself, which is pretty bad. Maybe my relative nubeity at WWF4 is the cause 

    But however in this case, the default option selected there was 'Identity'. Changing that to 'Impersonation' in my case worked fine. I might blog about this for future devs facing the same problem as well.

    • Marked as answer by pirahawk Wednesday, March 02, 2011 10:48 PM
    Wednesday, March 02, 2011 10:47 PM