SharePoint: Resolving Access Denied errors for Site Owners

Recently, I experienced a very strange problem while working on a client’s SharePoint 2007 install. SharePoint’s permission management isn’t always the easiest or most intuitive, but for the most part it works pretty well. And then there are the head-scratchers, which make absolutely no sense until the cause of the problem is discovered.

The Problem

Users belonging to the Site Owners group were receiving “Access Denied” errors on a particular site. The Site Owners group has Full Control permissions, so logically they shouldn’t be receiving “Access Denied” for any reason, unless a specific page or library does not inherit its permissions from the site. Thus, this was the first thing I checked. All of the lists in the site were indeed inheriting permissions, so this could not possibly be the issue.

The “Access Denied” error made it clear that the users in the Site Owners group did not have permissions to access something, but what could it be? After Googling around for a while, I found a blog post detailing a similar issue and the possible solution. In the case detailed by the blogger, the Master Page Gallery for the site collection had been set up with custom permissions. Even though users had Full Control of the site, they did not have permissions to load the Master Page, causing the Access Denied error throughout the site. This prompted me to check the Master Page Gallery permissions on my client’s site, but I found this was not the cause.

What could possibly be the cause?

With no other ideas, I decided to look in the SharePoint Group settings and make sure they were configured correctly. I noticed that all of the groups were set up so that only the group members could view membership of a group. Essentially, this means that someone in the Site Owners group cannot see which users are in the Site Members or Site Visitors groups, or any other custom groups that may be configured.

Somehow, SharePoint was trying to view group membership of a group to which the logged-in user was not a member. I toggled the group settings so that so that everyone could view group membership, and Voila! The “Access Denied” error went away.

Now that I’d identified the source of the error, I needed to identify the root cause. Why was SharePoint trying to view group membership using the current logged-in user?

This particular site had many custom web parts built by a third-party, so I started there. I set the groups back so that only members could view group membership, and then removed the custom web parts from a page. Once this web part was removed, the “Access Denied” error did not occur, meaning that the custom code in the web part was the culprit. It apparently was written to access SharePoint groups through the SharePoint Object Model, but was using the current user’s credentials instead of using elevated privileges or impersonation.

Attack of the poorly written web part

The moral of this story is to make sure your custom SharePoint solutions use the proper privileges when appropriate. The web part cannot do any more than the permissions it is given, and oftentimes a user, even a Site Owner, does not have privileges to perform many of the actions available in the SharePoint Object Model. Properly written code can mitigate this problem, while still maintaining proper security throughout the site. Poorly written code can cause headaches for everyone, especially Site Owners.