First, I'm fairly certain I mostly understand the issue, I'm looking for information on working around, or fixing it.
The environment is an extranet that uses mix authentication (Windows NTLM and ADFS Claims) to allow internal and external users to access. We are having an issue in Nintex Workflows that attempt to use the "Call Web Service" or "Web Request" actions to start a workflow on a list item.
We have a scheduled Site Workflow that is batch processing child items and is supposed to start a list workflow in the item if conditions are met. This requires us to use the "Call Web Service" or "Web Request" actions to start the workflow on the items. This action is failing whenever the workflow is ran and returning a error that reads;
Error returned from server: The remote server returned an error: (401) Unauthorized.
We've tried using a user account, as well as a service account and they all return this error. The weird thing is, when using the "Test Connection" button in the action returns a "OK" message, and the "Refresh" button in the action returns the list of available web services to populate and be selected. It is only when the actual call is attempted that it returns with a (401) Unauthorized response.
When researching, we found a few things pointing out that Web Service calls on a SharePoint environment using mixed or claims based authentication may not work.
This second post (https://community.nintex.com/docs/DOC-3221) gives the option to use a X-FORMS_BASED_AUTH_ACCEPTED header to force Windows Authentication, but when I attempt to use it I still get a 401 Unauthorized response.
I finally found this write up (http://www.sharepointblogs.be/blogs/vandest/archive/2014/09/12/calling-web-services-in-nintex-workfl...) and tested using a Web Request action and passing a FedAuth Cookie value as a header. This Worked! The action ran successfully. However, since we are using a service account and scheduling the Site Workflow, I'm not sure if using this workaround would be a valid solution. How would a FedAuth Cookie be retrievable for a service account when the workflow is activated by a schedule and not a user's browser?
The other option of using a different URL Zone is a big change to the client, and something that I'm hesitant to recommend.
Has anyone else solved this sort of issue? Did you use one of the above methods or is there a better way to fix this?
I believe we've encountered this issue before with mixed authentication. Infrastructure implemented an extension of the web application that only allowed windows auth.
Thanks Ryan, that is what a few of the sites suggested. Something came to light today though. It appears that the same issue occurred on another web application using only Windows Authentication. They all appeared to have started regularly failed around the same day. This may throw out our assumption that it was due to mixed authentication. We are trying to find out what may have changed back when this happened.
Any idea why web service calls may stop working in general? Is there a setting in Nintex on CA that may dictate what web apps it works or doesn't work on?
Microsoft very much wants you to be using Claims Authentication rather than Classic (Windows). We're coming across all sorts of issues with a web application that was created for AX integration with SharePoint that uses Classic. Problems include SSRS and Social. It wouldn't surprise me if it affected web services too although I haven't yet had to test this theory.
Did you ever resolve this? I have a site workflow that starts a list workflow using a web service call and After this latest patch cycle, I have started getting 401 Unauthorized on web service calls to start other workflows. I don't think I have the luxury to change authentication methods at this time.
Hi Josh! Great to see you on here.
We have not implemented a fix, but know of a method for getting it to work.
Through additional testing, I can that confirm that our issue was due to mixed authentication. I confirmed the behavior through an entirely different environment that also had mixed authentication set up. The same 401 issue occurred there. The difference on this other environment was that we had already extended it to have a new URL zone to force / use only Windows Authentication when hit. When I set up the web service to use that URL instead, it would work as expected.
I would advise setting up a separate URL zone like described in this blog post. The FedAuth cookie solution also worked in testing, but you would have to develop a custom web service to provide a cookie to a workflow and that may be too much work for some to do. The new zone is the quickest and simplest way to fix the issue we had.
I hope that helps.
I think the error occurred because I have both provider on the same application web NTLM and Ldapmember but I don't know how forcing to use Ntlm authentification for the account service
Someone Can help me please?