none
SharePoint 2013 Workflow Permission

    Question

  • We are running into a problem with SharePoint 2013 and workflows.

    We have the following site collection setup:

    Site Collection
        Subsite A
        Subsite B

    The following are the permissions:

    [Site Collection] Owners
    [Site Collection] Members
    [Site Collection] Vistors

    The members of these SharePoint groups are Active Directory security groups. If we put these AD groups into the SharePoint group we get the following error when trying to run a workflow:

    RequestorId:
    171a693d-7b50-a70a-0000-000000000000. Details: RequestorId: 171a693d-7b50-a70a-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":["171a693d-7b50-a70a-ba75-67ea8bc83fb4"],"request-id":["171a693d-7b50-a70a-ba75-67ea8bc83fb4"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"MicrosoftSharePointTeamServices":["15.0.0.4481"],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1;
    RequireReadOnly"],"Cache-Control":["max-age=0,
    private"],"Date":["Tue, 16 Jul 2013 15:28:13
    GMT"],"Server":["Microsoft-IIS\/8.0"],"WWW-Authenticate":["NTLM"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"]}
    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
    executor, BookmarkManager bookmarkManager, Location resultLocation

    Obviously, this is a permissions issue. I am able to resolve the issue by adding individuals to the SharePoint group 1 by 1, however, I don't want to do this. Can anyone explain why this is acting the way it is?

    Tuesday, July 16, 2013 4:42 PM

All replies

  • Does it happen with all the users or only specific users?

    You could try and see the permission on the app pool or the service account for workflow manager.


    Philip

    Tuesday, July 16, 2013 8:03 PM
  • Can you also give us more information on what the workflow is doing?  There might potentially be permission issues if it's trying to access external items or content.

    Cheers,

    Steven Andrews

    SharePoint Business Analyst

    Blog: Steve's SharePoint Space  Twitter:   LinkedIn:   Facebook:

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, July 16, 2013 11:44 PM
    Answerer
  • This happens with ALL users. Even the farm account.
    Tuesday, July 30, 2013 7:24 PM
  • it seems that your workflow has a CodeActivity which is breaking. could you please have a look on code that is written in Code Activity.


    Amit - Our life is short, so help others to grow.....

    Whenever you see a reply and if you think is helpful, click ♥Vote As Helpful♥ And whenever you see a reply being an answer to the question of the thread, click ♥Mark As Answer♥

    Wednesday, July 31, 2013 12:44 PM
  • Hi,

    I am also running into this issue and am stuck in solving it.

    I have a list workflow that runs on item change event, checks if a certain value is true and then should create a new list item in a list on a different site.

    Site structure is the same as Hhancocks:

    Site Collection
       Subsite A => workflow
       Subsite B => list where new item should be created

    With the same HTTP REST call I can create a new item on any list of Subsite A, but as soon as I try to create the item on a list in Subsite B, I get the response Code "Unautherized" and the response:

    {"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."}}}

    I found the following blogs on the internet, none of which solved my issue:
    http://www.sharepointviking.com/system-unauthorizedaccessexception-when-running-sharepoint-2013-workflows/

    http://www.sharepointmaestra.com/Blog/Post/1/Workflow-2013-Not-Starting-on-Incoming-Email

    According to this thread: http://community.office365.com/en-us/forums/148/p/178921/527970.aspx the REST calls don't work in SharePoint online which would explain the behaviour in one of our environments, but the error also occurs for our on prem environment. The user triggering the workflow has full control on both subsites.

    Any hints would be really appreciated.


    • Edited by Gáski Friday, August 2, 2013 1:38 PM permissions updated
    Friday, August 2, 2013 11:25 AM
  • Hi,

    I am also having the same issue however it bounces between the users original error and the following:

    RequestorId: 5145b770-177f-48cd-b11e-723ae64e4b27. Details: System.ApplicationException: HTTP 401 {"Transfer-Encoding":["chunked"],"X-SharePointHealthScore":["0"],"SPClientServiceRequestDuration":["46"],"SPRequestGuid":["5145b770-177f-48cd-b11e-723ae64e4b27"],"request-id":["5145b770-177f-48cd-b11e-723ae64e4b27"],"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":["Tue, 10 Sep 2013 22:09:33 GMT"],"Server":["Microsoft-IIS\/7.5"],"WWW-Authenticate":["NTLM"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"]}   at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context)   at

    Investigating has also found only adding person directly to a sharepoint group gets around this. We have 500 users so i'm not two excited about adding them all individually to a sharepoint group and the ongoing maintenance of new users.

    Can we please get an official response from an expert indicating that this is by design and you must add these people to the group individual and then assign that group to the list that contains the workflows.

    Regards.

    Simon.

    PS - Was glad to finally find someone with same issue. Was worried it was just my setup as I've been on this for a good couple of weeks and found nothing to help resolve it.

    Tuesday, September 10, 2013 10:33 PM
  • I have same problem.  Workflows will fail unless user is directly a member of the SharePoint group. 
    Thursday, September 12, 2013 7:50 PM
  • The workflow 2013 not recognize permission of user groups of AD DS, you should add permission to user account. 
    Tuesday, November 19, 2013 5:31 PM
  • The workflow 2013 not recognize permission of user groups of AD DS, you should add permission to user account. 

    Hi,

    That is fair enough however what happens if i wish to grant 1000 people access to a list/form that contains these workflows. You cannot you be expected to grant all these users permissions individually or add all these users to a sharepoint group then grant permissions to the group.

    How would you manage this scenario? It must be a very common situation as i'd expect ever implementation that uses infopath to utilise these workflows.

    Thanks.

    Tuesday, November 19, 2013 9:29 PM
  • Has anyone got such an known issue sorted out? I'm having the same issue in which workflow can't start with the AD group. It only works if I directly add domain users to SharePoint group. 


    Thuan Soldier
    A 23-year-old man loving Microsoft technologies and making crazy ideas on business journey.
    SharePoint Vietnam | Blog | Twitter

    Thursday, November 28, 2013 10:50 AM
  • I got the issue sorted out by adding NT AUTHORITY\Authenticated Users to the same SharePoint group with the AD group.

    Thuan Soldier
    A 23-year-old man loving Microsoft technologies and making crazy ideas on business journey.
    SharePoint Vietnam | Blog | Twitter


    Thursday, November 28, 2013 11:56 AM
  • I'd like to bring up this issue again. I am facing the same problem, the workflow raises an UnauthorizedAccessException when executed by a user who is not a direct member of a SharePoint group but belongs to an ActiveDirectory group, which in turn is member of a SharePoint group.

    Is there still no workaround than adding all users via NT AUTHORITY\Authenticated Users to a SharePoint group? I think that's is definately not an appropriate way for user management.

    Cheers

    Thursday, January 9, 2014 4:52 PM
  • Same issues here. Any resolution?

    Personal Blog: http://thebitsthatbyte.com

    Tuesday, January 14, 2014 4:22 PM
  • We have been having the same issue as well. We've had SharePoint 2013 installed since the middle of last year. The workflow is extremely basic (document review).

    The only way we've resolved the issue is doing what others suggested, moving individuals into the SharePoint group. This causes permissions to become unmanageable. I really wish Microsoft would resolve this issue.


    • Edited by hhancock Tuesday, January 14, 2014 7:14 PM
    Tuesday, January 14, 2014 7:09 PM
  • Hi,

    I'm facing the same issue and can't find any workaround. Could you possibly explain what you mean by moving individuals into the Sharepoint group? I get the  Access
    denied. You do not have permission to perform this action or access this
    resource error for even the Site Collection owner's account when the workflow runs and tries to read data from a list in another sub-site.

    Thanks in advance.
     
    Monday, January 20, 2014 4:00 PM
  • "Moving individuals to SharePoint Groups" means that you add the AD user directly (not the AD group) to a SharePoint group. Therefore you have to manage all your SharePoint groups  seperately and you can not take advantage of your Active Directory.
    Monday, January 20, 2014 6:05 PM
  • I am also stuck in it. If the user is directly added in SharePoint group, it works fine but if the AD security group is added it gives unauthorized access exception

    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."}}}

    is there any update from Microsoft on it. 

     
    Thursday, February 13, 2014 3:44 PM
  • Still no workaround nor official statement regarding the interplay of these two essential functions (AD + workflows)? Has anyone already tried SP1?
    Wednesday, March 12, 2014 5:49 PM
  • This solved my issue. But now anyone in the domain can access the site if they know the url.
    Monday, March 17, 2014 11:26 PM
  • least you can do to assign Edit rights just on workflow list, task list and workflow history list.

    can you please verify from central admin if the "Workflow Service Application Proxy" is connected. just click on the service application and it would show the status

    Central admin->Application Management ->Manage service applications

    Tuesday, March 18, 2014 12:49 PM
  • Still no workaround nor official statement regarding the interplay of these two essential functions (AD + workflows)? Has anyone already tried SP1?

    Hopefully going to try it in the next week or so. We will see if it solves this issue...
    Wednesday, March 19, 2014 1:24 PM
  • Has anyone tried giving their workflow App Permissions? See below link:

    http://msdn.microsoft.com/en-us/library/office/jj822159(v=office.15).aspx

    • Proposed as answer by kittycatbytes Tuesday, September 15, 2015 2:47 PM
    Wednesday, March 19, 2014 1:27 PM
  • I tried it but it didn't work

    I also found this and i think its right

    By first look App Step looks just like a normal Step which behaves like a Container for workflow actions but it actually provides a very powerful functionality. As you might know that each workflow unless specified runs under the permission of Workflow initiator and (logical AND) that of Workflow itself.In case one of the lists or libraries that is restricted for the workflow initiator is used being by the workflow, the user might see access denied or the workflow might stop. App Steps solves this problem by letting all the actions in it run under Workflow App permission which is Read/Write to all site lists.

    Read more: http://www.learningsharepoint.com/2012/12/20/sharepoint-designer-2013-the-new-app-step

    Wednesday, March 19, 2014 5:44 PM
  • This was a suggested solution mentioned on another post. Has anyone tried this yet?

    "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"

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


    • Edited by Teena Coad Wednesday, March 19, 2014 9:55 PM
    Wednesday, March 19, 2014 9:52 PM
  • Have you tried looking at your Claims to Windows Token Service?  (Best practice indicates that it should be running as a service account).  We are seeing issues where A/D users directly on SharePoint are working, but A/D groups added to sharepoint are not allowing.  I am getting ready to try setting Claims to Windows Token Service to run as a domain service account, and see if that fixes it.  Will try to update this thread when I find out.
    Wednesday, April 23, 2014 3:51 PM
  • I had the same issue and authenticated users were part of Visitor group with read access. I am part of site collection administrator group but still workflow was suspended the with HTTP 401 error.

    I added myself to Site Owners/Members group and now workflow completes without error.

    Not sure why being a site collection administrator I couldn't start the workflow.

    I was not directly added to site collection admin group but through an AD group.


    -- The opinions expressed here represent my own and not those of anybody else -- http://manojvnair.blogspot.com

    Monday, April 28, 2014 10:21 AM
  • I have been struggling with this problem since we upgraded to SharePoint 2013 back in February. I have even logged a case with Microsoft that has been open for almost a month now which they have escalated.

    While I have been waiting for the escalation team to call me back I have been doing more research and trying more things to find a solution. I found the below thread on stack exchange. The answer didn't seem incredibly clear to me but it did seem similar to some things I had read somewhere else about nested OUs. So I checked and sure enough, I was using nested OUs. So on my test system, I removed the nested OU, and added a top level OU, and tried it and it worked. I didn't have to do a UP sync or anything. Instant fix. Apparently workflows can't resolve nested AD groups.

    sharepoint.stackexchange.com/questions/58772/sharepoint-2013-workflow-authentication-error-401

    Wednesday, May 7, 2014 3:26 PM
  • If you are using Send Email activity and sending email to a SharePoint group you may get this error. Its because the visibility of the SharePoint Group isn't set to everyone. If the visibility of the group cannot be set to everyone then you have to remove SharePoint group from email activity and add individual users. It is discussed in this Microsoft KB article:

    http://support.microsoft.com/kb/2839070/EN-US


    -- The opinions expressed here represent my own and not those of anybody else -- http://manojvnair.blogspot.com

    Tuesday, May 13, 2014 9:19 AM
  • You should setup a UPA (User Profile Service Application) and sync the OUs that contains BOTH user and security groups.

    The service is one of the requirements for WFs. Please refer to my blog for further details. It's in portuguese but you should be able to understand the context. 


    Abraços

    David

    SharePoint Support Engineer

    Blog: http://spinternals.blogspot.com.br/ 

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, June 13, 2014 4:08 PM
  • Did Microsoft ever get back with you on this issue? I'm experiencing the same issue.

    Tuesday, September 2, 2014 5:46 PM
  • Yes.  Still looking for the answer too. 
    • Edited by CBER Wednesday, September 3, 2014 7:17 PM
    Wednesday, September 3, 2014 5:08 PM
  • The problem is with the Workflow 2013 itself and not with Infopath. Unfortunately users are added manually, it sucks I know, but even before SP1 this problem existed. I do not know if this problem has been fixed.
    Thursday, September 11, 2014 2:52 PM
  • We haven't installed SP1 yet and I haven't tested to see if SP1 resolves the issue in a development environment. Right now, we place individuals into a SharePoint group which is really unmanageable. We are hoping to have some sort of resolution soon.
    Tuesday, October 14, 2014 9:59 PM
  • In my farm, decided to install SP1. Install SP1, in my opinion, is an important installation.
    Wednesday, October 15, 2014 2:40 PM
  • I had a the same problem. In a SharePoint Designer Workflow I was creating a task and assigned it to a SharePoint group. Then I got the error:

    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

    I checked the permissions of the SharePoint group. Set the permissions of the group "Who can view the members of the group" set this to Everyone. ....

    Further details: http://wp.me/p1fg2Y-gaM

    Thursday, March 12, 2015 9:48 AM
  • Just refreshing this, as it seems to be lost to oblivion. 

    Has anyone found a work around to this. I have a customer that is in need of resolving this. He too finds the maintenance of the adding all his AD group users to the site permissions as a workaround to be unacceptable as do I, of course.

    Below has all been attempted without resolution:
    ================================
    I am currently running SP 1 (not a resolution) 
    I have implemented the suggestions of APP permissions (not a resolution)
    I have attempted the App Step suggestion (not a resolution)
    User Profile Synchronization - Full Sync (not a resolution)
    "Who can view the members of the group (not a resolution)

    While, yes, the adding of users directly is a workaround (definitely NOT a resolution)

    Washing away the purpose of Active Directory groups by suggesting to just add the users directly to the site seems irresponsible to suggest, given that most windows networks utilize Active Directory as Enterprise security. This forces the consumer of SharePoint systems to be required to maintain multiple facets of security implementation points. 

    This is a maintenance pain in the A@# and also provides an infrastructure where standards implementations are prone to fail easily due to multiple points of failure in the enterprise infrastructure.

    Microsoft - PLEASE FIX THIS ISSUE.

    Chris Stanga Interstates Control Systems, Inc.


    • Edited by Stanga, Chris Monday, May 18, 2015 7:16 PM Signature Change
    Monday, May 18, 2015 7:13 PM
  • Did you try my suggestion from March 12? As also described on my blog http://wp.me/p1fg2Y-gaM
    Tuesday, May 19, 2015 8:38 AM
  • I guess he tried, since it is mentioned in the "not a resolution" part:

    "Who can view the members of the group (not a resolution)

    Tuesday, May 19, 2015 9:13 AM
  • Just sync the security groups, that's all. It's by design and a requirement if you work with security groups.

    Abraços

    David

    SharePoint Support Engineer

    Blog: http://spinternals.blogspot.com.br/ 

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    • Proposed as answer by David Amenda Wednesday, May 20, 2015 12:40 PM
    Tuesday, May 19, 2015 9:37 AM
  • Yes, this was already set and does not affect the outcome, Thanks.

    Chris Stanga Interstates Control Systems, Inc.


    Tuesday, May 19, 2015 1:52 PM
  • As a followup with reproducible steps:  (please see previous reply in this thread if something is missed)

    "BUT STILL UNRESOLVED"

    Summary:

    • SharePoint 2013 based workflows fails to resolve Active Directory group membership when executing steps within.
    • The Active Directory group operates appropriately when granting permissions to site and list
      • The Active Directory group fails at the point of the workflow trying to resolve permissions of the user executing the workflow.
        • The person adding an entry to the list that the workflow is assigned to.
    • The Active Directory group is resolved through SharePoint group membership.
    • Unacceptable workaround from Microsoft currently is to explicitly add users directly to the SharePoint group instead of allowing resolution through Active Directory group.
      • This is unacceptable due to the extreme “Domain Users” or alternate group focus that is already in place in Active Directory
      • There is NO inclination to add thousands of users explicitly to a SharePoint group thus replicating an already established Active Directory system.

    Steps to reproduce:

    • Users are stored in an Active Directory Group
    • A SharePoint list has been created utilizing the “Site_Members” group as permissions
      • This group grants “Contribute” rights to the data entry list and underlying “Workflow History” and “Workflow Tasks” lists.
    • Within this “Site_Members” group the Active Directory group has been added as a member.
    • A SharePoint 2013 based workflow has been created with a single step to email a specific users (myself)
    • A test Active Directory user was created specifically to test this issue
      • This user was also added to the Active Directory group to provide a common baseline membership as other users
    • Using this newly created user, I have logged into the Internet Explorer browser
    • I used this browser session to create a record into the SharePoint list that the Workflow has been assigned to
      • This entry results in the workflow execution to send an email.

    Failure point:

    • This is where the workflow should have sent an email to me
    • Workflow execution instead results in a 401 Access Denied Error

    Steps attempted to overcome:

    • SharePoint was installed from MSDN with SP1 slipstreamed (originally)
    • Added associated domain OU nodes to User Profile Synchronization service
      • The nodes added were related to the Active Directory Group container
      • Active Directory node “User Profiles” were confirmed as Synchronizing (Test user confirmed)
    • https://msdn.microsoft.com/en-us/library/office/jj822159(v=office.15).aspx
      • Granting full control permissions to a workflow. (SharePoint 2013 specific)
    • Added “App Step” wrapper to workflow email step
    • All of these steps to debug and overcome this issue result in same issue. 401 Error

    Chris Stanga
    Interstates Control Systems, Inc.






    Tuesday, May 19, 2015 1:59 PM
  • Hi Chris, it works in my environment even with nested groups. Please perform a full sync and check the sync steps for related events (e.g. access denied) in MIISClient. http://blogs.msdn.com/b/spses/archive/2010/04/01/sharepoint-2010-provisioning-user-profile-synchronization.aspx

    Abraços

    David

    SharePoint Support Engineer

    Blog: http://spinternals.blogspot.com.br/ 

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    • Proposed as answer by David Amenda Wednesday, May 20, 2015 12:40 PM
    Tuesday, May 19, 2015 2:24 PM
  • Further Background Info: 

    Full Sync has been accomplished across all connections:

    UPS Connections are as follows

    Each is "Separate" connection:

    Alternate Domains:
    Domain (A) (Connection 1)
    Domain (B) (Connection 2)
    Domain (C) (Connection 3)
    Domain (D) (Connection 4)
    Domain (E) (Connection 5)

    Operational Domain(SP): (Connection 6)
    (SharePoint System) 
    Domain (SP) Group (A): Contains:
    Domain (A) Group (A)
    Domain (B) Group (A)
    Domain (C) Group (A)
    Domain (D) Group (A)
    Domain (E) Group (A)

    Domain(SP) is also configured with appropriate OU synchronized
    MIIClient reports "Success" on all fronts.


    As stated this group architecture operates accurately with regard to site and list permissions. Just not with regard to workflow access permissions.


    Chris Stanga Interstates Control Systems, Inc.


    Tuesday, May 19, 2015 2:47 PM
  • Hi Chris, i suggest to open a incident with the MS support. You can also check in MIISClient if Forefront synced those groups and / or (don't do this in production) check the Membergroup table in your ProfileDB.



    Abraços

    David

    SharePoint Support Engineer

    Blog: http://spinternals.blogspot.com.br/ 

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, May 19, 2015 3:30 PM
  • Without stating the words (obviously its still not working) :) 

    This may or not be why?

    My UserProfile_DB/Member Group table is empty. 

    What am I missing? (I realize that this may be a broader question)

    Where do I start resolving that groups aren't syncing?

    I sincerely appreciate this assistance.


    Chris Stanga Interstates Control Systems, Inc.

    Tuesday, May 19, 2015 4:14 PM
  • You can get some interesting issues in more modern AD functional levels as they give more granular and flexible settings to see who can view membership of groups. It's not common but it can happen.

    The more obvious issue is if you aren't running your UPS sync. I believe it can take a few runs to pull through AD gropus.

    Tuesday, May 19, 2015 4:20 PM
  • Folks,

    it takes one full sync to pull the security groups and the table should contain the security groups as shown below:

    1. Check the connections maybe those OUs containing the security groups where excluded from the sync.

    2. Check for sync filter.

    3. Contact the responsable for the AD.


    Abraços

    David

    SharePoint Support Engineer

    Blog: http://spinternals.blogspot.com.br/ 

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    • Proposed as answer by David Amenda Wednesday, May 20, 2015 12:39 PM
    Tuesday, May 19, 2015 4:29 PM
  • Thanks for the assistance - but still not working. 

    • We have now been able to successfully populate the Sync_DB MemberGroup table (Proper User Profile Service Settings)
    • We have NOT however been able to execute a SharePoint 2013 based workflow. (Remains at Permission Denied)
    • SharePoint 2010 workflows HAVE completed successfully

    I have created three almost identical workflows for testing:

    1. SharePoint 2013 (Basic)
    2. SharePoint 2013 (AppStep)
    3. SharePoint 2010 (Basic)

    All the above have a single step to email a user

    The 2013 workflows end with a 401 permission denied error. 

    Just a current update - still debugging.


    Chris Stanga Interstates Control Systems, Inc.

    Tuesday, May 26, 2015 2:28 PM
  • Give this a shot. Do an iisreset on all your servers that are running sharepoint (Web front ends, and App Servers).  Then run the Refresh Trusted Security Toke Service Metadata feed.  

    Go to Central Admin

    Click on Monitoring

    Click on Review Job Definitions

    Click on Refresh Trusted Security Token Service Metadata feed.

    Click on Run Now

    Tuesday, May 26, 2015 2:58 PM
  • Hi Chris,

    Please provide the ULS logs for further analysis.


    Abraços

    David

    SharePoint Support Engineer

    Blog: http://spinternals.blogspot.com.br/ 

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, May 26, 2015 4:14 PM
  • I am also experiencing the same problem. 

    The user can only run the workflow without errors if they have been given permissions via adding their User, instead of via adding an AD group to which they belong. 

    It doesn't work if the AD group is a member of a SharePoint group, and it also doesn't work if the AD group has been granted permissions (without a SharePoint group involved). 

    Effective permissions show they have Full Control of the site even when it's a 'failing' scenario.

    Wednesday, June 17, 2015 8:57 PM
  • What I missed when this problem was happening was in the setup of the AD connections for the User Profile Service. Go back to the AD connection and look at the containers. Make sure your groups container has a check mark by it.  Once I put a check next to all of my SharePoint Groups in AD then ran a full sync, it started working.
    Wednesday, June 17, 2015 10:18 PM
  • Hi H Hancock did you ever get a resolution to this issue?

    Works on our test environment but not production? Same 401 error and believe it to be permissions.

    Same AD groups on both but not happy about having users added directly to SP Groups to resolve when we have a test environment working so its quite frustrating.

    Had SP2013 since Sept 2014 and patched to SP1

    Thank you.

    Thursday, February 11, 2016 9:57 AM
  • I know - really old but since it took me forever to find this and I had hte same problem i am posting this for others who may come along. 

    https://msdn.microsoft.com/en-us/library/office/jj822159(v=office.15).aspx 


    Tasks

    Sunday, February 28, 2016 8:44 AM
  • So I know this thread is old and I know that the last update has been a while ago, but I also know it is still showing up when people are dealing with this problem so I wanted to post an answer that worked for us.

    We had the exact same problem.  All of our settings in UPS were correct.  We had the correct active directory OUs selected and were syncing groups and users.  But for some reason, none of our groups were working.  The problem was finally determined that UPS was in fact pulling groups in, but it wasn't pulling them in from the OUs we had selected.  It only pulled in groups within the Users OU.  We had also selected a separate OU that contains all the Groups used exclusively for SharePoint.  To fix it, we de-selected the SharePoint OU and then re-selected it. Re-ran a full sync and the groups started populating in the database.

    More details can be found here: http://prairiedeveloper.com/2016/06/sharepoint-2013-workflow-failing-immediately-starting/

    Hope this helps others.


    Best Regards,

    David Drever BSc, MVP, MCST

    Senior SharePoint Conultant

    Blog: http://www.prairiedeveloper.com  Twitter:   LinkedIn:

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, June 22, 2016 4:19 PM
  • In my farm, decided to install SP1. Install SP1, in my opinion, is an important installation.

    I've installed SP1 in my production SharePoint and it still has that problem, the only way to resolve this was by adding user directly and not with through theirs AD FS groups just as Diego answered. Unless there is a way to sync. user in AD FS group with SharePoint group. This will be still a problem when creating this workflow for a lot of users.

    Ariwibawa

    Friday, September 29, 2017 10:05 AM
  • Make sure that the SecurityTokenServiceApplication is running under the Farm account (a.k.a. OWSTimer service)

    Change it in the Central Administration page if it is not using the same account.
    Wednesday, September 19, 2018 4:28 PM