0

I have Workflow Manager (for 2013 workflows) installed and connected and everything seems to be working. I have created a few workflows using the site collection admin and they run perfectly fine.

But when I started testing with users the workflows wouldn't run. Users had been added to a SharePoint groups via an AD group.

enter image description here

After some research and testing I discovered that workflows will run as expected when the user is added directly to the SharePoint Group. Which isn't feasable if you have 2000 users and with a daily turnover.

  • Workflow Proxy is Connected.
  • User Profile Service is running and imported all users from AD
  • Permissions double and tripple checked
  • Services and Job are running smoothly

I couldn't find anything in regards to this issue and are completely stumped. I can't imagin this being purposely done by MicroSoft. They're surely must a way to have AD groups run workflows.

I'm considering now a way of have an automated process to import all users into a SP group, but the thought just doesn't sit well with me.

Any help is greatly appreciated.

0

If the users participating in the workflows have been added to the SharePoint site via Active Directory groups, SharePoint has to update the user’s security token periodically by connecting to the domain controller. By default, the token times out every 24 hours. But if the application pool account did not have the right permissions on the domain controller to update the user’s token, user will keep getting the access denied error. The error was intermittent because when the user browsed to any page other than the workflow form, the token was getting updated successfully.

You can try to fix it through granting the application pool account the appropriate permission by adding the account to the group “Windows Authorization Access Group” in Active Directory.

Similar issue posts for your reference:

https://social.technet.microsoft.com/Forums/ie/en-US/b568b4ab-52b4-40c5-887b-56a5ebd9144d/sharepoint-2013-workflow-spd-2013-fails-for-active-directory-group-members?forum=sharepointcustomization

https://social.msdn.microsoft.com/Forums/sharepoint/en-US/27a547da-5cc0-49d7-8056-6eb40b4c3242/failed-to-start-workflow-access-is-denied-exception-from-hresult-0x80070005-eaccessdenied

| improve this answer | |
  • Hi Lisa, Thanks for the pointers. I will check on these now. I have a question in regards to the token timing out. I have reduced the time from 24 hours to 1 hour. Is that somethig that should be done? – Jaitsujin Jun 26 at 0:43
  • More findings. The url in the screenshot above is accessible. for any account. didn't matter if the account was given permission directly or through a group. So it's not the account that created the new item that can not access the _api call, it's the SharePoint App Account (AppPoolAccount? not sure if these are the same). Do you know how to grant access? – Jaitsujin Jun 26 at 3:10
  • Adding App Pool account to the “Windows Authorization Access Group” did NOT resolve it. @Lisa, any other suggestions? – Jaitsujin Jun 30 at 0:49
0

Finally,

Nothing worked so far, and I'm still not sure what's causing this, but i figured out a way that works for me. May not for everyone though.

I tried the following suggestions and NONE of these worked for me.

Option 1: In IIS, go to advanced settings for Security Token Service Application Pool and change "Load User Profile" to true. Recycle application pool. From https://social.msdn.microsoft.com/Forums/sharepoint/en-US/27a547da-5cc0-49d7-8056-6eb40b4c3242/failed-to-start-workflow-access-is-denied-exception-from-hresult-0x80070005-eaccessdenied -> NO GO

Option 2: The workflow authentication can fail if the user is given permission through active directory group and the container for this group is not selected to be synchronized in the active directory connection. I added the AD security group to my User Profile Service Synchronization configuration, performed a sync, and I can resume the suspended workflows. From www.blog.houratious.com/2014/06/sharepoint-2013-workflow-server-was.html -> NO GO

Option 3: If the users participating in the workflows have been added to the SharePoint site via Active Directory groups, SharePoint has to update the user’s security token periodically by connecting to the domain controller. By default, the token times out every 24 hours. But if the application pool account did not have the right permissions on the domain controller to update the user’s token, user will keep getting the access denied error. The error was intermittent because when the user browsed to any page other than the workflow form, the token was getting updated successfully.

 $sts = Get-SPSecurityTokenServiceConfig $sts.WindowsTokenLifetime
 $sts.WindowsTokenLifetime = (New-TimeSpan -Minutes 120)
 $sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -Minutes 120)
 $sts.Update() $sts.WindowsTokenLifetime 

From https://social.technet.microsoft.com/Forums/ie/en-US/b568b4ab-52b4-40c5-887b-56a5ebd9144d/sharepoint-2013-workflow-spd-2013-fails-for-active-directory-group-members?forum=sharepointcustomization -> NO GO

Option 4: Grant the application pool account the appropriate permission by adding the account to the group “Windows Authorization Access Group” in Active Directory From https://social.msdn.microsoft.com/Forums/sharepoint/en-US/27a547da-5cc0-49d7-8056-6eb40b4c3242/failed-to-start-workflow-access-is-denied-exception-from-hresult-0x80070005-eaccessdenied -> NO GO

Option 5: FIX Claim ID issue

  <d:element m:type="SP.KeyValue">
     <d:Key>SPS-ClaimID</d:Key>
     <d:Value></d:Value>  // SPAppPool
     <d:ValueType>Edm.String</d:ValueType>
  </d:element>

From https://help.k2.com/kb001627.aspx -> NO GO

SOLUTION (Only works if you have Plumsail Workflow Action Pack or something similar installed)

I knew I had to have individual users listed in a group. AD groups wouldn't work. The workflow works if your first App Step adds the current user to a specific group and then proceeds. enter image description here

I also had to uncheck the "Automatically update the workflow status..." enter image description here

Again, this is not the greatest solution, but it does work nicely for me. Especially now I can review who has created workflows and use this group for further actions.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.