With the rise of claims based authentication in SharePoint we’ve faced new challenges in how to interact with web services hosted on those environments. Claims based authentication allows many different scenario’s with a mixture of Windows, Forms and SAML Authentication.
When you’re working with Nintex Workflow you’re faced with authentication in Actions such as “Call Web Service” or “Web Request”.
If you’re just using Windows Authentication (NTLM, Kerberos, Basic) on your site then Nintex will handle that authentication just fine for you and use the credentials you specified (manually entered or stored credentials).
However you might have to deal with different or multiple authentication mechanisms such as Forms Based Authentication, ADFS or a combination. In such cases you’ll get a 403 FORBIDDEN regardless of the credentials you enter.
Overcoming this hurdle can be challenging.
- Use a different URL zone (with windows authentication) to make the call
- Pass an authentication cookie along with the request
Use a different URL zone (with windows authentication) to make the call
Nintex Actions execute on the server, not on your -already authenticated- client. The connection information you’ve entered (URL, username, password) is used to construct a connection and execute the operation. Since the Action executes locally on the server it can make use of a different URL to do the call. It is a best practice/requirement to have the Default Zone of your Web Application configured with -just- Windows Authentication in order to get things like Search to work properly. Why not make use of this and use that URL in your Actions?
Define a set of credentials that can be used in “Call web service” or “Web Request” Actions and have it execute against the URL that has Windows Authentication. If this option is available to you it probably is the preferred way of working.
Pass an authentication cookie along with the request
If the above is no option for you things get trickier and “specific”, meaning it is specific to a certain scenario but might not be possible for yours.
In MY case I have a SharePoint 2013 on-prem environment with “mixed” authentication (Windows and Forms Based). SharePoint issues a FedAuth cookie when the user successfully authenticates. If you send this cookie along with the web request it will work just fine. Note that the “Call web service” action does NOT allow you to specify additional headers so the “Web Request” Action becomes your new best friend here.
Using the “Web Request” Actions allows for much more flexibility, but you’ll have to build the request message yourself. I our case that means the SOAP message.
Once you have all of that in place the “Web Request” will happily call out to the web service. See it here working with the FedAuth cookie I “borrowed”.
Getting the FedAuth cookie
The base premise is that you need to ‘replay’ the authentication mechanism in code to get the FedAuth cookie. Once you have this you can send it along with future requests from Nintex Workflow. Again this is really specific to my case and may not be possible for you because of additional security or complex authentication schemes.
For my SharePoint 2013 on-prem environment with “mixed” authentication (Windows and Forms Based) I force the call to do Windows Authentication:
public static class AuthHelper
public static Cookie GetFedAuthCookie(Uri uri, ICredentials credentials)
Cookie result = null;
// Emulate the authentication via a request to the /_windows/default.aspx page using the provided credentials
HttpWebRequest request = WebRequest.Create(uri.GetLeftPart(UriPartial.Authority) + "/_windows/default.aspx?ReturnUrl=%2f_layouts%2fAuthenticate.aspx%3fSource%3d%252FDefault%252Easpx&Source=%2FDefault.aspx") as HttpWebRequest;
request.Credentials = credentials ?? CredentialCache.DefaultNetworkCredentials;
request.Method = "GET";
request.CookieContainer = new CookieContainer();
request.AllowAutoRedirect = false;
// Execute the HTTP request
HttpWebResponse response = request.GetResponse() as HttpWebResponse;
if (null != response)
result = response.Cookies["FedAuth"];
I actually made this available as a Web Service so that it can be called from with a Nintex Workflow.
public class AuthService : IAuthService
public string GetFedAuthCookie(string requestUrl, string userName, string password)
string result = null;
NetworkCredential credential = !String.IsNullOrEmpty(userName) ? new NetworkCredential(userName, password) : null;
Cookie cookie = AuthHelper.GetFedAuthCookie(new Uri(requestUrl), credential);
if (cookie != null)
result = cookie.Value;
catch (Exception ex)
result = null;
And now I can call my Authentication service prior to the other services.
It feels like it must be possible to use access tokens that can be passed along similar to the FedAuth cookie. Considering this is how the App model works in SharePoint 2013, there has to be a way to leverage this for what we’re trying to accomplish. But that’s for another post.
Recently I helped out a colleague with an issue in a load balanced SharePoint 2013 environment with Nintex Workflow 2013 on it. All the workflows that were started on WFE1 worked fine, but all started on WFE2 failed on start with the following issue logged to the SharePoint ULS logs:
Load Workflow Class: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidOperationException: The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.
at System.Diagnostics.PerformanceCounter..ctor(String categoryName, String counterName, String instanceName, Boolean readOnly)
at System.Workflow.Runtime.PerformanceCounterManager.CreateCounters(String name)
at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices..ctor(SPSite site, SPWeb web, SPWorkflowManager manager, SPWorkflowEngine engine) -
-- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture)
at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object args, CultureInfo culture, Object activationAttributes, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object args, CultureInfo culture, Object activationAttributes)
at System.Reflection.Assembly.CreateInstance(String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object args, CultureInfo culture, Object activationAttributes)
at Microsoft.SharePoint.Workflow.SPWorkflowManager.LoadPluggableClass(String classname, String assembly, Object parameters)
If you look up this issue you’ll find a lot of references to SharePoint 2007, but it seems that this is still possible in a SharePoint 2013 / Windows Server 2012 environment as well.
An incorrect registration of the Windows Workflow Foundation performance counters will cause this. You can easily verify this by opening up perfmon, adding a counter and looking for the category “Windows Workflow Foundation”.
Register the performance counters on each affected server:
lodctr C:\Windows\Inf\Windows Workflow Foundation 220.127.116.11\perfcounters.ini
That restores the counters and will make your workflows start again!
Nintex Workflow is able to send emails via the Send notification action.
A question often asked is if it can send emails to SharePoint groups or Active Directory groups. The answer is; Yes it can!
There are some things you need to know though…
Send to an Active Directory group
You can use AD security groups, but they must have a (dummy) email value configured or the workflow will fail on this.
The email will only be sent to the direct users in the AD group. Nested AD groups will be ignored.
Send to a SharePoint group
This works about the same as AD groups. The email will be sent to direct users in the SharePoint group, and to direct users of any nested AD group in the SharePoint group. It won’t go into nested AD groups of the AD group though (same as above).
Also, you cannot nest SharePoint groups.