I have been working on an issue for several weeks now together with Microsoft Support to investigate a case where the Check Permissions function in SharePoint 2013 is not returning correct information for several users.
Let me first describe the exact situation.
We have a site collection with a standard team site template. We have setup the default SharePoint groups for defining access, such as the Visitors, Members and Owners groups. In these groups we are adding Active Directory groups. Pretty straight forward so far. As is expected, Active Directory users that are members of the added Active Directory groups have access to the SharePoint team site. No problem there. Those same users can do all actions that have been defined by the permissions as well.
So in normal circumstances, when we want to check the permissions for a user in a specific document library, we would expect something like the image below
Well, in my case the permission levels returned was “None” even though the user was a member of the “Team Members” group.
To make a long story short, the issue turned out to be caused by SidHistory. The customer had previously migrated its Active Directory users and groups to a new domain and used SidHistory during the migration. After the migration, these sidhistory attributes were not cleaned up properly by the Active Directory team.
Now, SharePoint does not behave well if you still have groups that have SidHistory attributes specified on them because SharePoint tries to resolve these SID’s which may not be possible anymore because the domain the original SIDD belongs to is no longer available. In this case SharePoint gives up on the call. Unfortunately no error message is returned is generated so no error is returned. Instead SharePoint shows “None” as the permission level as it did not receive a correct answer to the group membership resolution
Now to be sure that you are not experiencing the same issue, you need to verify all groups that the user you are having the same issue with is a member of and make sure that the sidhistory attribute is cleared. Also check nested group membership.
Hope this helps anyone.
For my customer’s case the issue was classified as a bug in SharePoint 2013