Symptoms
Assume the following scenario: User A is Member of Group 1 User B is Member of Group 1 User A is not allowed to use the workflow. User B is allowed to use the workflow. If user A added directly to the workflow permissions, everything works fine. If user A removed again, he is not able to start the workflow or access the work list item. Issue occur for some users when process rights granted via group but as soon as you grant process rights directly to user it works fine.
Diagnoses
This is most likely caused by the fact that K2 group membership cache is not fully updated. All current versions of K2 (upcoming 4.7 including) rely on identity cache (Identity.Identity table) for wide range of operations as direct calls to AD DS or any other provider are very expensive (i.e. have high latency). Consequently if you just added your user to some group it is not immediately reflected in K2 cache and cached results will be returned to you. Both user and group has corresponding entries in Identity.Identiy table and in this case we want to look at user's ContainersResolved flag and group's MembersResolved flag. For example if your group has MembersResolved flag = 0 it means that no group membership information has been ever requested yet (no such information in cache) and first use of this group which requires it to be resolved (i.e. use of this group in a destination rule with the "Resolve groups/roles to members" option selected or execution of UMUser_GetGroupUsers SmO) will trigger synchronous call to AD DS to resolve group membership to AD DS, this is the only time when we waiting response from AD DS. Once it is completed this information is recorded to the cache and returned by K2 to requesting component. From now on we have MembersResolved=1 and all subsequent calls will be served from identity cache and cache will be updated only after group cache interval expire (by default 1 hour + time to fully resolve your group). Subsequent calls (after first time synchronous resolution) will be served from cache even if it is expired and in parallel asynchronous call to AD DS will be performed and cache will be updated with any changes as soon as this process will be completed, this is why at the very least your group membership will be updated only in 1 hour + time to resolve your group.
NOTE: It is normal for Domain Users group to have MembersResolved=0 flag as this group is rarely being used in K2 in a way which requires it to be fully resolved. Possible corrective actions: 1) Make sure that user's group membership is resolved for affected user (ContainersResolved=1 for specific user). You either have to wait ~8 hours (assuming default settings, where ContainersCacheTimeout set to 8 hours) till group membership cache of specific user will be resolved. Or just use Force Identity Refresh tool against affected user. Cached information about user's group membership is stored in one of the auxiliary tables and essentially relation between user and group and group and user is represented by the same entry. So forced user cache refresh should resolve issue with the non working permissions grant which was made via group unless some issues with AD DS connectivity/config are preventing this at the time when you do refresh operation. Once again: Containers expiration interval for users is 8 hours by default, meaning that automatically this operation will happen not earlier than in 8 hours since last cache refresh + time to resolve user (should be relatively small if there is no issues with AD DS connectivity). If forced user refresh does not help here, then you have to check ADUM logs and see if there are any related errors. Often there may be intermittent problems with AD DS connectivity, inter-domain trust configuration and so on which in turn prevent normal resolution/cache updates. AD DS is quite stable technology and more often than not those problems which you may notice in ADUM logs are intermittent but given cache update frequency from K2 side they may be quite noticeable/disruptive for K2. If K2 unable to resolve group membership you obviously get access denied/no rights error. * Here the problem is that if let's say there was 2 minutes issue with AD DS and K2 was not able to resolve cache it will try to resolve it again only in 1 hour and you keep getting access denied error. But good thing is that what was already cached works for you (till cached data expiration at least). 2) When dealing specifically with process rights where all users should be able to start it, you can make use of the "Everyone" group. This is a special K2 group which you can use to indicate that all users should be able to do the configured rights without the overhead of going to the provider (AD DS) or making use of cached data. This special group is surfaced when configuring process rights in Workspace. This "Everyone" group provides similar functionality as "Authenticated Users" special identity from Windows/AD but it is not a windows group or something this special K2 object. Solution 2 is recommended if your use case is to grant some process rights to all users.
Resolution
See details above. You either have to perform forced identity refresh for affected user or wait till next identity refresh interval (assuming there is no issues with ADUM users' resolution) or (in case your scenario is to grant some process rights to all users) use built-in K2 "Everyone" group.
You can find additional details here about K2 identity cache here:
