SharePoint 2013 Workflow (SPD 2013) fails for Active Directory Group members

Question

Hi
I have a SharePoint 2013 site called "Team Meetings". There are a number of lists and an InfoPath form library.
The site's SharePoint Group "Team Meeting Members" has two Active Directory groups (All Club Managers and All Club Police) as members. Those two AD groups contain all the people that I want to have  access to the library and list, except for
a few additional folk who I have made individual members. 
My PROBLEM:
I  have created a SharePoint 2013 Workflow using SPD 2013 associated with the  Form Library. Workflow is set to start on new or modified item. The first action is to write to history list, then determine the status (Submitted or Pending) of
the form and go to different Stages depending on that status.
The workflow works perfectly for any user who has been added directly to the SharePoint group (Team Meetings Members) BUT FAILS at the very first action for anyone who is a member of one of the AD groups. I know the Workflow is fine because I've tested it
with numerous people who are direct members of the SharePoint Group, but whenever a person who is a member of the AD group tries it the Workflow just fails.
Here's a print of the info from the Workflow Status page (I don't have access to server logs):
RequestorId: 4494760f-92ff-2e8c-90d2-cc7df0e6baa4. Details: System.ApplicationException: HTTP 401 {"Transfer-Encoding":["chunked"],"X-SharePointHealthScore":["0"],"SPRequestGuid":["4494760f-92ff-2e8c-90d2-cc7df0e6baa4"],"request-id":["4494760f-92ff-2e8c-90d2-cc7df0e6baa4"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"MicrosoftSharePointTeamServices":["15.0.0.4420"],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1;
RequireReadOnly"],"Cache-Control":["max-age=0, private"],"Date":["Mon, 10 Mar 2014 01:31:42 GMT"],"Server":["Microsoft-IIS\/8.0"],"WWW-Authenticate":["NTLM"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"]}
The HTTP response content could not be read. 'Error while copying content to a stream.'. at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance
instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor 
Members of the SharePoint Group "Team Meetings Members" have Contribute Access to both the form library and another list that the workflow writes to as well as the Workflow History list (which in SP 2013 uses the credentials of the
user who started the workflow, unlike 2010 which used System Account).
All members of the Team Meetings Members group, whether they are individual members or part of one of the AD groups, have no problems opening and saving forms etc. It's just the Workflow that doesn't like them...
I am stumped. I've spent many hours searching for a reason for this. There are about 200 people in the two AD groups so I really don't want to have to add them all individually - especially when these groups are managed in AD for a whole bunch of other reasons
and using the AD groups means I'll basically never have to worry about modifying the SharePoint access permissions.
Does anyone have any ideas why this is happening and what I can try to fix it?
Mark

Answer 1

Hi Lars,
I'm afraid not so far but we are trying a few things today so I will post back with results.
First thing we are doing is making the AD Group universal because one of our (external provider) gurus remembers seeing something about that. He also sent me a link to a post where they were talking about earlier
versions but having similar issues and their solution was to make sure the app pool account has sufficient permissions in AD::
http://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
This part of that thread looks interesting but we haven't checked it yet as were trying the universal setting first:
"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."
I'll update when we try these ideas. If you have any luck please do the same.
Mark
(sorry about formatting - using my phone....)
Mark