Nintex Custom Actions permissions – Understanding RunWithElevatedPrivileges

When trying to do a simple System.IO.File.Copy inside the context of a Custom Nintex Action I wrote, I found that I couldn’t get the file to copy to a particular Windows Server File Share. Even though I had assigned the user name that was running the Nintex Workflow Read/Write permissions on the share, it would fail with an error indicating lack of access to that folder.

It worked ok if I set “Everyone” with Read/Write permissions. Reviewed the great article on Windows Server 2008 File Share setup at http://www.techotopia.com/index.php/Configuring_Windows_Server_2008_File_Sharing , still it was clear the File Share was just net configured right.

The source of the issue is that in running the File Copy code inside a RunWithElevatedPrivileges block, it is actually using a different account than the one running the workflow. Here is the Nintex Execute Activity function in question:

protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext)
		{
			NWWorkflowContext ctx = NWWorkflowContext.GetContext(
			   this.__Context,
			   new Guid(this.__ListId),
			   this.__ListItem.Id,
			   this.WorkflowInstanceId,
			   this);

			base.LogProgressStart(ctx);
				SPSecurity.RunWithElevatedPrivileges(() =>
				{
					if (!Directory.Exists(ctx.AddContextDataToString(OutputPath)))
						Directory.CreateDirectory(ctx.AddContextDataToString(OutputPath));
					File.Copy(ctx.AddContextDataToString(SourcePath) + ctx.AddContextDataToString(strFileName),ctx.AddContextDataToString(OutputPath) + ctx.AddContextDataToString(strFileName),true);
				});
			}
			catch (Exception ex2)
			{
			    EventLog.WriteEntry("CopyFile Create Exception - Source File [" + SourcePath + strFileName + "] Output File [ " + OutputPath + strFileName + "]", ex2.Message + ", StackTrace: " + ex2.StackTrace, EventLogEntryType.Error, 9999);
			}
			base.LogProgressEnd(ctx, executionContext);
			return ActivityExecutionStatus.Closed;
		}

Two good comments from the MSDN reference at http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx:

The other thing to remember regarding this method call is that the account NAME that is being used is “SHAREPOINT/SYSTEM” and this does not resolve to an actual domain account. Now the only time this becomes and issue is when one is referring to Windows resources outside of SharePoint. Again this is only intended to be used for resources within SharePoint. If your function code is say calling even a SharePoint web service and one sets the web service “Credential” to “System.Network.CredentialCache.DefaultNetworkCredential” that the service call will in fact fail because IIS will not be able to resolve the domain account “SHAREPOINT/SYSTEM”. If the case is one needs to access external data then consider using a Secure Store credential.

And:

I’ve always found that the nuances of RunWithElevatedPrivileges cause much confusion as well as some weird and wonderful behavior if not properly understood. While the documentation here does a good job of explaining how and when to use it, it’s missing a key piece of information and that’s how the mechanism actually works.

Behind the scenes, RunWithElevatedPrivileges impersonates the identity of the current thread. In effect, this means that the delegate will run under the context of the application pool account, in the case of the code being called in the W3P process, or in the context of the SPTimerv4 service, in the case of the code being called in a workflow, timer job or anything else that’s kicked off using the timer. If the code is running in a console application or some other user-initiated app, the delegate will be kicked off using the context of the user who started the application. (Which would be the default behavior anyway).

When using workflows, bear in mind that the workflow may start running under W3P but continue executing under owstimer (SPTimerV4) depending on what it’s actually doing. In this case a delegate executed using RunWithElevatedPrivileges would not neccesarily yeild the same result.

PS nifty trick if you’ve forgotten about it: just add a $ to the end of the share name (rendering it accessible but invisible when people browse the shares).

Incoming search terms:

• sharepoint 2013 runwithelevatedprivileges
• sharepoint 2013 eventlogger
• nintex action impersonate
• nintex set user permission only for workflow
• runwithelevatedprivileges in sharepoint 2013
• sharepoint 2013 runwithelevated
• sharepoint 2013 RunWithElevatedPrivileges sharepoint\system