locked
BizTalk WCF-BasicHTTP Adapter connecting to SharePoint 2013 web services RRS feed

  • Question

  • Hi All,

    I have BizTalk Server 2010 application which uses SharePoint 2010 lists web service. It uses WCF-BasicHttp with SecurityMode=TransportCredentialOnly and TransportClientCredential Type as "Windows" which has been functioning well from last couple of years. Recently there has been an upgrade to SharePoint 2013 and from then on the web services started intermittently working and not working. Failing with the below error:

    The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.

    Is there any way to make this working permanently. I can change the setting but the problem is whey does it work sometimes and not some other times.

    Is there a solution to this?

    Monday, March 7, 2016 5:16 AM

Answers

  • Did you ever find a resolution for this?  We are experiencing the same issue.

    Hi,

    What are the authentication schemes set for the sharepoint set ? Ask ur sharepoint admin to set:

    Basic

    Negotiate

    NTLM

    and then restart the IIS.

    If u r on a sharepoint farm then make sure to have the settings changed on all the servers on the farm.



    Pi_xel_xar

    Blog: My Blog

    BizTalkApplicationDeploymentTool: BizTalk Application Deployment Tool/

    Friday, October 28, 2016 7:08 PM
    Answerer
  • Hi, no it has not been fixed. But we have now configured the SharePoint site to "Basic" authentication and the BizTalk send port to same (need to provide username and password in send port which has permissions in SharePoint list)

    Basic authentication works without any problem but if you are concerned about data being exchanged in plain text (as is with Basic auth), then there can be custom encryption set up at IIS level (which is what we have done). 

    Hope this helps.

    Surprisingly Microsoft says that it cannot look at this issue as there is no compatibility between SharePoint 2013 and Biztalk which is non-sense.

    Regards


    Saturday, October 29, 2016 5:28 AM
  • The problem could be that the user is not having access to the root of the SharePoint server. When BizTalk 2013 WSS adapter tries to access the document library it first tries to access the root and then dives in to the libraries for the action. A look at the SharePoint logs will give the necessary information.

    Refer the article: BizTalk 2013 and SharePoint 2013 Integration Issue (401:Unauthorized)


    Rachit Sikroria (Microsoft Azure MVP)

    Monday, March 7, 2016 5:57 AM
    Moderator
  • From your comments it would seem that SharePoint is configured for NTLM based Authentication and not Kerberos...

    Anyways SharePoint additionally sets up some user based cookies which got setup during your interactive session as a result of which subsequent calls are going through. Or it could be a simple case that on login the permissions cache (profile) got refreshed with the correct permissions.

    So maybe as part of the setup, one should connect to the servers with the BizTalk Instance Host A/C and browse the SharePoint site.

    Regards.

    Thursday, March 17, 2016 5:00 AM
  • This is a authorization issue. What you need your SharePoint Administrators to check is the permissions that have been granted to the BizTalk Service Account (this is the account under which the host instance is running. This Host Instance would have a send handler which is what permits it to be bound to the send port for WSS). Intermittent access implies that permissions are there on some lists and not on others.

    If you ask the Site Administrators to give the service account permissions at the site level and ensure that for all the lists the site permissions are inherited !!

    Regards.

    Monday, March 7, 2016 9:02 AM
  • If there is ONE list then please ensure that the host instance has "Full Control" or equivalent permissions. Do not play around with "contributor" or similar partial access.

    Secondly as has been suggested, check for permissions on the "site".

    Regards.

    Monday, March 7, 2016 9:44 AM
  • Hi,

    Intermittent failures on one SharePoint list is quite strange but this is definitely a permissions issue and this is something which needs to checked by the SharePoint administrator. 

    You have to check the SharePoint logs they will definitely give you some clue.

    Also as suggested already you have to provide Full control access to the user under which the adapter host is running plus access to the root site as well.


    Rachit Sikroria (Microsoft Azure MVP)

    Monday, March 7, 2016 11:20 AM
    Moderator
  • Have you checked about "claims-based authentication" enabled on SharePoint ??? If that is what you're up against then the OOTB SharePoint behavior will not (??) work. Have a look at http://www.stuartcharles.co.uk/securing-a-wcf-service-in-biztalk-by-roleclaim-using-windows-or-claims-based-authentication/ on implementing a custom WCF behavior to overcome this.

    Regards.

    Tuesday, March 8, 2016 10:04 AM

All replies

  • The problem could be that the user is not having access to the root of the SharePoint server. When BizTalk 2013 WSS adapter tries to access the document library it first tries to access the root and then dives in to the libraries for the action. A look at the SharePoint logs will give the necessary information.

    Refer the article: BizTalk 2013 and SharePoint 2013 Integration Issue (401:Unauthorized)


    Rachit Sikroria (Microsoft Azure MVP)

    Monday, March 7, 2016 5:57 AM
    Moderator
  • Thanks for your prompt response but if the root does not have permissions, how come this web service works occasionally? I will forward this to our SharePoint administrator to try this.

    Do you think its a KeepAlive flag issue? Is there a way of setting this flag in BizTalk send port or does it need to be set in IIS of SharePoint site?

    Thanks for your help. 


    Monday, March 7, 2016 7:53 AM
  • This is a authorization issue. What you need your SharePoint Administrators to check is the permissions that have been granted to the BizTalk Service Account (this is the account under which the host instance is running. This Host Instance would have a send handler which is what permits it to be bound to the send port for WSS). Intermittent access implies that permissions are there on some lists and not on others.

    If you ask the Site Administrators to give the service account permissions at the site level and ensure that for all the lists the site permissions are inherited !!

    Regards.

    Monday, March 7, 2016 9:02 AM
  • Thanks Shanlycheil, but I am sure the permissions on the BizTalk host instance account do exist for the SharePoint list. I am only talking about one SharePoint list here. BizTalk can retrieve data from this list however it fails occasionally on the same list.
    Monday, March 7, 2016 9:14 AM
  • If there is ONE list then please ensure that the host instance has "Full Control" or equivalent permissions. Do not play around with "contributor" or similar partial access.

    Secondly as has been suggested, check for permissions on the "site".

    Regards.

    Monday, March 7, 2016 9:44 AM
  • Hi,

    Intermittent failures on one SharePoint list is quite strange but this is definitely a permissions issue and this is something which needs to checked by the SharePoint administrator. 

    You have to check the SharePoint logs they will definitely give you some clue.

    Also as suggested already you have to provide Full control access to the user under which the adapter host is running plus access to the root site as well.


    Rachit Sikroria (Microsoft Azure MVP)

    Monday, March 7, 2016 11:20 AM
    Moderator
  • Thanks all.

    Now our SharePoint Admin has given full right access to the group this Host instance user is in.

    The results are very strange.

    Tested from DEV environment with DEV host instance account. It works fine.

    Tested from PRD environment with PRD host instance account. It fails.

    More over the two accounts DEV and PRD are in the same group on the site permissions which has full access rights.

    Here is the iisLog on the sharePoint site. Can anyone throw light on why DEV account works and not the PRD account.

    2016-03-08 00:14:40 10.41.11.60 POST /_vti_bin/lists.asmx - 80 0#.w|uXXXe\_BIZTK_DEV_ACCT 10.41.11.102 - - 200 0 0 203
    2016-03-08 00:24:44 10.41.11.60 POST /sites/UCSCL/_vti_bin/lists.asmx - 80 UXXXE\_BIZTK_PRD_ACCT 10.41.11.102 - - 401 0 0 124

    You can see 200 on DEV account and 401 on PRD account log. Its the same application that is installed on both DEV and PRD environments.

    Thanks in advance.

    Tuesday, March 8, 2016 1:41 AM
  • 2016-03-08 00:14:40 10.41.11.60 POST /_vti_bin/lists.asmx - 80 0#.w|uXXXe\_BIZTK_DEV_ACCT 10.41.11.102 - - 200 0 0 203
    2016-03-08 00:24:44 10.41.11.60 POST /sites/UCSCL/_vti_bin/lists.asmx - 80 UXXXE\_BIZTK_PRD_ACCT 10.41.11.102 - - 401 0 0 124

    The paths are different ?!? If the prod user was added later to the group then ideally the prod host instances should be re-started.

    A better way of checking/resolving this would be to logon as the said user and access the sites.

    Regards.

    Tuesday, March 8, 2016 5:04 AM
  • The host instances in PROD are restarted many times after adding the PROD account.

    Yes, we did open the IE as "run as" the PROD account and the results are quite inconclusive.

    The DEV account I said worked in the morning does not work now. :-( The results are very inconsistent.

    More details in regards to SharePoint server, it is load balanced on two servers. Do you think only one server is working and the other server is not. When I see the SharePoint logs, the server that worked today failed yesterday etc, so I cannot even pursue that path. Tomorrow I am planning to test URL of individual server and see if that server throws some light on this.

    Does anyone think it is claims based authentication in SharePoint that does not work any more with TransportCredentialOnly and Windows authentication setting in BizTalk send port. Do I need to change my sendport config of SharePoint?

    In IISLogs I see "0#.w" in front of username when the request worked and that's missing when the request did not work.

    Tuesday, March 8, 2016 9:49 AM
  • Have you checked about "claims-based authentication" enabled on SharePoint ??? If that is what you're up against then the OOTB SharePoint behavior will not (??) work. Have a look at http://www.stuartcharles.co.uk/securing-a-wcf-service-in-biztalk-by-roleclaim-using-windows-or-claims-based-authentication/ on implementing a custom WCF behavior to overcome this.

    Regards.

    Tuesday, March 8, 2016 10:04 AM
  • Hello all,

    I had raised a support ticket with Microsoft to help us fix this. After as week of investigations, this is what I got from them.

    BizTalk Server 2010 supports these two versions of WSS:

    • SharePoint Foundation 2010
    • Windows SharePoint Services 3.0 with SP2

    Hence, I would suggest to upgrade Biz Talk 2010 to Biz Talk 2013.

    I don't know whether to laugh or cry. Do ya all think the same?

    Regards

    Maithili

    Wednesday, March 16, 2016 3:12 AM
  • To get the applications in prod going, I am creating a .NET wcf service temporarily to be a bridge between BizTalk 2010 and SharePoint 2013. Does anyone else have a better idea.

    Thanks in advance.

    Wednesday, March 16, 2016 3:21 AM
  • Don't hide the SharePoint calls behind code... use the SOAP/WCF endpoints directly.. that way you would be able to address the error handling better through your orchestrations...

    You would land up making additional calls to retrieve list id, etc. which would be a bummer but in net a smaller price to pay.

    Regards.

    Wednesday, March 16, 2016 7:23 AM
  • That's a good point Shankycheil, but I would not need to make a call to retrieve a ListId. When the SharePoint request is created in BizTalk, it already contains list id etc which comes from BizTalk config.

    I am doing this so there is minimal change in BizTalk code and all I do is change the URL and probably " soap action" may be and use the send port/wcf-basichttp/message tab settings to extract the SharePoint request and response.

    But if that does not work, you have given me a good alternative to call SharePoint API with in BizTalk .net assembly.

    Appreciate your help. Thanks

    Wednesday, March 16, 2016 7:45 AM
  • Today morning, we accidentally browsed the SharePoint Lists URL on the BizTalk Non prod servers (DEV/UAT) individually. The respective windows logon although has the permissions on this list, IE when browsed the list, still asked for the Credentials, when supplied the same windows credentials, it successfully displayed the list URL.

    We then tried from BizTalk, all of a sudden the list URL starts working !!

    So tried the same method for all another SharePoint lists and all worked.

    Don't know what IE sent to the URL though which then starts recognizing the credentials.

     The question now is

    1) Is this problem fixed permanently ?

    2) Is this going to reoccur again?

    3) Is there anyway else that this problem can be fixed permanently.

    There has been no changes anywhere either in BizTalk or in SharePoint.

    Thursday, March 17, 2016 1:29 AM
  • From your comments it would seem that SharePoint is configured for NTLM based Authentication and not Kerberos...

    Anyways SharePoint additionally sets up some user based cookies which got setup during your interactive session as a result of which subsequent calls are going through. Or it could be a simple case that on login the permissions cache (profile) got refreshed with the correct permissions.

    So maybe as part of the setup, one should connect to the servers with the BizTalk Instance Host A/C and browse the SharePoint site.

    Regards.

    Thursday, March 17, 2016 5:00 AM
  • Did you ever find a resolution for this?  We are experiencing the same issue.
    Friday, October 28, 2016 6:04 PM
  • We are experiencing this same issue.  I don't believe that connecting to the servers with the BizTalk Instance Host A/C and browsing to the SharePoint site will work as after awhile the session must timeout and we start receiving the error again.
    Friday, October 28, 2016 6:06 PM
  • Did you ever find a resolution for this?  We are experiencing the same issue.

    Hi,

    What are the authentication schemes set for the sharepoint set ? Ask ur sharepoint admin to set:

    Basic

    Negotiate

    NTLM

    and then restart the IIS.

    If u r on a sharepoint farm then make sure to have the settings changed on all the servers on the farm.



    Pi_xel_xar

    Blog: My Blog

    BizTalkApplicationDeploymentTool: BizTalk Application Deployment Tool/

    Friday, October 28, 2016 7:08 PM
    Answerer
  • Hi, no it has not been fixed. But we have now configured the SharePoint site to "Basic" authentication and the BizTalk send port to same (need to provide username and password in send port which has permissions in SharePoint list)

    Basic authentication works without any problem but if you are concerned about data being exchanged in plain text (as is with Basic auth), then there can be custom encryption set up at IIS level (which is what we have done). 

    Hope this helps.

    Surprisingly Microsoft says that it cannot look at this issue as there is no compatibility between SharePoint 2013 and Biztalk which is non-sense.

    Regards


    Saturday, October 29, 2016 5:28 AM
  • BizTalk 2013 has the same issue, Microsoft cannot escape by telling it is compatibility issue

    Regards

    Vivek

    Wednesday, January 18, 2017 3:02 PM