SharePoint 4 Developers

Additional reference guide in .NET / SharePoint Development

SharePoint 2013 Workflows - Suspended state HTTP 401 Error

Investigation and Fix on SharePoint Workflow 2013 Suspended state, where HTTP 401 is displayed.

Hi guys,

It is really annoying when you get stuck on something that you cannot identify the real source of the problem. The suspended state with SharePoint 2013 workflows is one of them, really difficult to troubleshoot.

Problem

I was getting this error from the UI, after starting the workflow:

(RequestorId: 0cd909bf-f85a-1da7-0000-000000000000. Details: RequestorId: 0cd909bf-f85a-1da7-0000-000000000000. Details: An unhandled exception occurred during the execution of the workflow instance. Exception details: System.ApplicationException: HTTP 401 {"error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Access denied. You do not have permission to perform this action or access this resource."}}} {"Transfer-Encoding":["chunked"],"X-SharePointHealthScore":["0"],"SPRequestGuid":["0cd909bf-f85a-1da7-b6a7-48f3d5618b90"],"request-id":["0cd909bf-f85a-1da7-b6a7-48f3d5618b90"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"Cache-Control":["max-age=0, private"],"Server":["Microsoft-IIS\/8.0"],"WWW-Authenticate":["Negotiate","NTLM"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"],"MicrosoftSharePointTeamServices":["15.0.0.4481"],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Date":["Tue, 25 Nov 2014 01:13:50 GMT"]} at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContextSystem.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation))

Behind the scenes from SharePoint ULS logs:

Original error: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))    

Troubleshooting

In my case only few users were able to trigger workflows, as Contributors, but others couldn't. They were getting to this "Suspended" state. By checking the user permissions on the Library, of a user that could execute the workflow and one that couln't, permissions were exactly the same as Contributors.

Permissions were not broken, they had access to Workflow History and Tasks Lists, as indicated here:
http://zasharepoint.blogspot.co.nz/2014/05/sharepoint-2013-workflow-gets-suspended.html

By checking the User Profile Services, the synchronization of users were in-place, as suggested here:
http://sharepoint.stackexchange.com/questions/58772/sharepoint-2013-workflow-authentication-error-401

I had also explored these URLs, with no success:
https://social.technet.microsoft.com/Forums/sharepoint/en-US/8671e31e-fde2-454c-aba4-0fc6484dd873/sharepoint-2013-workflow-suspend-with-401-error?forum=sharepointcustomization
https://social.technet.microsoft.com/Forums/sharepoint/en-US/653dcf25-131e-402a-9fd1-f0b3e60e7750/suspended-workflow-in-sharepoint-2013-with-http-401-error?forum=sharepointadmin

This was getting tricky.

Solution

By doing a thorough investigation in this site, OOTB SharePoint groups were mapping both AD Users and AD Groups. There was a good evidence there that I had overlooked, users that were getting to a suspended state were mapped by an AD Group.

When the user was manually added to the SharePoint group, the workflow worked. :)

Going a little bit further, the AD Group was from a different OU that wasn't mapped in the User Profile Synchronization. When the OU path was mapped and the sync was run again...BANG! All the users that couldn't run the workflow, now could.

So it is not only the OU where the users are that need to be mapped with User Profile Sync, but the AD groups OU as well.

Lesson learned! Hope it helps with your troubleshooting!

Cheers,

Marcel Medina

Click here to read the same content in Portuguese.

WAP x ADFS x SharePoint 2013 on Kerberos

This article shows the steps in how to get the new Web Application Proxy role and ADFS v3 of Windows Server 2012 R2 working on Kerberos in SharePoint 2013, by using a Non-Claims aware Relying Party in ADFS.

Hi guys,

Couple of weeks ago I had the chance to provision the new Web Application Proxy role and ADFS v3 on Windows Server 2012 R2. One of my clients wanted to expose their Intranet for external access. Initially I thought about exposing it using SAML, but because they have lots of BI reports using Excel Services and Reporting Services, migrating to SAML would break these solutions. Simply because Claims would need to be converted to Windows authentication. This article explains really well the BI caveats.

To get this working seamlessly, Kerberos comes up. By using Kerberos the backend doesn’t need to be changed. This is what I wanted.

I was looking at the web for resources about implementing WAP, ADFS and SP2013 on Kerberos and found nothing, but if you want to implement SAML, then you will find lots of stuff. Share-n-dipity is your blog for that.

My scenario comprises 2 web sites, Portal, which is a publishing site, and MySite, as the name suggests a mysite host site.

Because users will be allowed to connect from the internal network and from the internet, I have decided to only have the Default zone in use, of course running on a single HTTPS URL. The diagram below displays how users connect to the sites:

diagram 
Figure 1 – Site Configuration

In my lab I have provisioned some servers to have specific roles, all of them on Windows Server 2012 R2, except SP2013 on Windows Server 2012 (it could be Windows Server 2012 R2 if you run SP2013 SP1). Anyways, below is my server/network diagram:

network
Figure 2 – Server/Network Diagram

Where:

  • SUB-SP2013 – SharePoint environment (3-tier, stand-alone, whatever)
  • SUB-DC – Active Directory Domain Services (Domain Controller and DNS)
  • SUB-ADFS – Active Directory Federation Services (same or different server of DC)
  • SUB-WAP – Web Application Proxy

What needs to happen here is described in in the following steps.

 

Step 1 - Configure DNS

1) On SUB-DC, open the DNS manager and create the following A records:

step1a
Figure 3 – DNS Manager

  • portal
  • mysite

(Both referencing the SharePoint 2013 Server IP Address)

step1bFigure 4 – A-record host

 

Step 2 - Configure access to certificate

1) On SUB-SP2013, open the Command, run mmc and add the Certificates snap-in, select computer account.

2) Allow the SharePoint site app pool to have Read access on the certificate private keys.

step2aFigure 5 – Managing Private Keys

step2b Figure 6 – Allow Read access by App Pool

 

Step 3 - Configure the SPNs and Constrained Delegation

1) Open the Command prompt, run the following commands:

Portal

setspn –s http/portal.contoso.com contoso\spapppool
setspn –s http/portal contoso\spapppool

MySite

setspn –s http/mysite.contoso.com contoso\spapppool
setspn –s http/mysite contoso\spapppool

2) On SUB-DC, go to Active Directory Users and Computers, find the WAP server:

delegation1Figure 7 – Active Directory Users and Computers

3) Double-click, then on the Delegation tab tick "Trust this computer for delegation to specified services only" and "Use any authentication protocol". Then add the service account by clicking the Add button.

delegation2Figure 8 – Add Delegation

4) Make sure you reference the account contoso\spapppool, which contains the SPNs. Select All services returned.

delegation2Figure 9 – Select All Delegation

delegation2Figure 10 – Delegation Configured

Step 4 - Configure SharePoint sites on Kerberos

1) On SUB-SP2013, go to Central Admin > Manage web applications.

2) Select the website Portal and click Authentication Providers.

step4a 
Figure 11 – Manage web applications

3) On the Authentication Providers, select the Default zone.

step4b Figure 12 – Default zone

4) Switch the Integrated Windows authentication to Negotiate (Kerberos).

step4c Figure 13 – Switching to Kerberos

5) Repeat the same on MySite.

 

Step 5 - Configure the ADFS Relying parties

1) On SUB-ADFS, open the AD FS Management.

2) On Relying Party trusts, click to Add a Non-Claims-Aware Relying Party Trust:

step5aFigure 14 – Relying Party Trust

3) The Wizard starts, click Start.

step5bFigure 15 – Non-Claims-Aware Relying Party Trust Wizard

4) In the display name, type Portal, then click Next.

step5c Figure 16 – Non-Claims-Aware Relying Party Trust Wizard – Display Name

5) As the identifier, define the URL https://portal.contoso.com, click Add.

step5dFigure 17 – Non-Claims-Aware Relying Party Trust Wizard – Identifier

6) Continue, click Next.

step5eFigure 18 – Non-Claims-Aware Relying Party Trust Wizard - Identifier

7) In my lab I am sticking to the default values, click Next.

step5fFigure 19 – Non-Claims-Aware Relying Party Trust Wizard – Multi-factor Auth

8) This is the second last screen to confirm what you have done, click Next.

step5gFigure 20 – Non-Claims-Aware Relying Party Trust Wizard – Confirmation

9) Let the standard checkbox ticked, click Close.

step5hFigure 21 – Non-Claims-Aware Relying Party Trust Wizard – Finish

10) Now you are able to edit the claim rules for Portal, click Add Rule.

step5i  Figure 22 – Edit Claim Rules

11) Select the rule “Permit All Users”, then click Next.

step5jFigure 23 – Add Issuance Authorization Claim Rule Wizard

12) Click Finish.

step5kFigure 24 – Add Issuance Authorization Claim Rule Wizard – Finish

13) Then click OK.

step5l Figure 25 – Edit Claim Rules – Finish

14) Repeat the same process to create a Non-Claims-Aware Relying Party Trust for MySite.

 

Step 6 - Configure WAP

1) On SUB-WAP, go to Remote Access Management, click Publish.

step6aFigure 26 – Remote Access Management

2) The Publish New Application Wizard starts, click Next.

step6bFigure 27 – Publish New Application Wizard

3) As preauthentication mode, let AD FS selected, as it ensures that requests are authenticated first via AD FS.

step6cFigure 28 – Preauthentication method

4) Select the Non-Claims-Aware Relying Party Portal, created in the previous step 4, click Next.

step6dFigure 29 – Select ADFS Relying Party

5) In this screen specify a Name, External URL (https), External Certificate, Backend Server URL and Backend Server SPN (as created in step 3), then click Next.

step6eFigure 30 – Publishing Settings

6) Click Publish.

step6fFigure 31 – Publish New Application Wizard – Confirmation

7) Close the Wizard.

step6gFigure 32 – Publish New Application Wizard – Final

In the end

After the steps executed above you will be able to log in to SharePoint:

step7aFigure 33 – Proxy Login

step7bFigure 34 – SharePoint Access

The experience is as smooth as that. :)

Hope you have enjoyed this post. I also hope it helps you.

Let me know if you have questions about any variance that I have not covered here. I may be of help.

Cheers,

Marcel Medina

Click here to read the same content in Portuguese.

Leveraging SharePoint Page Apps - Presentation

Learn how to leverage the SharePoint App Architecture by using Single Page Apps. You will get familiarised with the concept, pros, cons and javascript frameworks that make it possible.

Hi guys,

Thanks for those that showed up at the Auckland SharePoint User Group meeting.

Here it is the presentation:

Cheers,

Marcel Medina

Click here to read the same content in Portuguese.