SharePoint Adventures : Access Denied errors when using RS 2012 with a Claims SharePoint Site

I actually ran into this issue back in late April.  I wanted to get this out sooner but life happened.  This issue has started to crop up a lot more as more people are starting to use Reporting Services 2012 in SharePoint Integrated mode.  Here is the run down.  This issue is specific to a Claims Auth SharePoint site.  I encountered it with both Reporting Services and PowerPivot, but I’m going to focus on Reporting Services as there are other issues with PowerPivot in a Claims site and isn’t going to work regardless.

You can see this Access Denied error in different area and essentially occurs when you try to work with anything in a document library.  For example, you can create a Reporting Services Data Source and it will perform the Test Connection operation successfully.  But, once you try to open it up after saving it, you will see:

Throwing Microsoft.ReportingServices.Diagnostics.Utilities.AccessDeniedException: , Microsoft.ReportingServices.Diagnostics.Utilities.AccessDeniedException: The permissions granted to user 'BATTLESTAR\asaxton' are insufficient for performing this operation.; 

From Report Builder, if we try to reference that Data Source, we see the following:

If we try to deploy a report from a SQL Server Data Tools project, we see the following:

There is effectively the same in all circumstances and occurs when we try to go call the SharePoint API to get an item from the document library.  This is actually a SharePoint permission issue of sorts.

If you enable Verbose Logging for the SharePoint Foundation – General Category, you will see the following:

PermissionMask check failed. asking for 0x00010000, have 0x00000000

We can see that the PermissionMask is empty, but it is requiring OpenWeb (0x00010000) – SPRights Enumeration. So, this explains the Access Denied as it looks like I’m coming in as Anonymous.  The other puzzling piece here is the fact that it labeled ‘BATTLESTAR\asaxton’ in the error messages instead of the claims user which looks different.

I looked at the UserInfo table of the content database and saw the following:

Some how I’m in there twice with both my claims user and my Windows user.  And, it looks like it is picking up the Windows User when I’m getting the access denied instead of the claims user.  Listing the users within SharePoint using https://admadama:81/_layouts/people.aspx?MembershipGroupId=0 also shows both users.

You can click on the users until you see the user with the Windows User  instead of the claims user.

At this point we can delete this user and leave the claims user.  The Windows User will still show in the UserInfo table, but it sill show a value of 3 for tp_Deleted

After that, everything should start working as expected.

Of note, this issue is being addressed in SP1 as indicated in Tristan’s response here.

***** UPDATE – 7/13 *****

Of note, this only seems to really affect the Farm Admin account.  The BATTLESTAR\asaxton account is what I used when I setup SharePoint and Reporting Services.  When hitting this error, if I add another user, for example to the Members group, it only shows up once.

And, the items worked fine where as for asaxton they do not.  This should limit the impact to the organization.  If you think you are hitting this issue, you can use the people.aspx URL to check (https://admadama:81/_layouts/people.aspx?MembershipGroupId=0) or look at the UserInfo table to see if you see a claims entry and a Windows logon entry for the same user within the Content database for that Claims site.

Adam W. Saxton | Microsoft Escalation Services
https://twitter.com/awsaxton