Workflows not starting for AD Groups

Question

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.

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.

Answer 1

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.

I also had to uncheck the "Automatically update the workflow status..."

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.

Answer 2

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