Escaping SharePoint Permissions Purgatory

If you use SharePoint 2007 extensively as a collaboration tool, you’re probably having some trouble managing permissions. And if you upgraded your environment from Windows SharePoint Services (WSS) 2.0 or SharePoint Portal Server 2003, your challenges are likely even more extensive. Permissions management is a requirement in the world of SharePoint. Almost every organization must break permission inheritance at the site level to take advantage of the security features available in the platform. List and List Item custom permissions are also extremely common, regardless of your infrastructure or even knowledge. When breaking permission inheritance in SharePoint, you increase flexibility but often at the expense of maintainability.

My goal in this article is twofold. First, I want to shed some light on how the problem can manifest, while providing some advice about how to manage problems or decrease the rate at which this problem grows Second, I’d like to share the thought process that my company went through on its way to a solution that brought permissions back to a more manageable state, and I'd also like to provide some options for periodically reporting on the current status.

The problem I refer to is a lack of central management of permissions, leading to a significant number of custom permission levels and permission assignment across a large number of sites. This can easily lead to inadvertently adding or removing access to sensitive data, site lock-out, content deletion, and duplication of efforts. A consistent management and naming convention for permissions, combined with selective use of the Manage Permissions role, can help halt these problems

How Permissions Work

Although SharePoint 2007 offers extensive flexibility in the realm of permissions management, this flexibility can create a breeding ground for maintenance problems—particularly when site owners don’t fully understand how permissions work and what potential damage can be caused. SharePoint uses several approaches to permission management: base permissions, permission levels, permission assignment, inheritance, and item-level permissions.

Figure 1: Personal permissions

Base permissions. At the root level, a series of base permissions dictate specific rights, and sets of these rights make up permission levels. These hard-coded, out-of-the box base permissions—which can't be added to represent the building blocks of creating rights for users and groups. Figures 1, 2, and 3 show these permissions. SharePoint administrators have some control over the use of these Base Permissions, but this requires some education. For example, the Full Control permission level is a common role and it includes some potential dangers such as the Manage Permissions Base Permission. This gives users the right to create their own custom Permission Levels as described below.

Figure 2: List permissions

Permission levels. Permission levels are groups of base permissions bundled together to assign to users or groups. More than one permission level can be assigned to a user, Active Directory (AD) group, or SharePoint group. Figure 4 shows a sample of permission levels, including a custom one I created. These should be familiar to most users.

Figure 3: Site permissions

Permission assignment. When SharePoint groups, users, or AD groups are assigned or used in SharePoint, they must be given a permission level within the site collection. You assign rights to content in SharePoint by assigning one or more permission levels to users and groups. Figure 5 shows an example, including a custom group with multiple permission levels assigned.

Figure 4: Permission levels

Inheritance. All the above permissions information might seem straightforward, but two important permission-related factors remain. The first is inheritance. SharePoint wouldn’t be very useful if all sites and content were forced to share the same permissions. By default, all sites and content inherit all the permissions from the site above it—all the way to the root web in the site collection. SharePoint provides mechanisms to break this inheritance at any or all of the sites and to add custom permission assignments. Generally, this capability might manifest itself as removing certain groups and adding new ones. These groups are often appropriately named for their level of access permissions relative to the site. If you have a large number of sites, this process can generate a significant number of SharePoint groups. If you choose not to use groups, you must assign rights to individual users or AD groups, which can create additional overhead.

Figure 5: Permission assignment

Breaking inheritance often leads to the perceived need for additional permission levels, as well. For example, site owners might want certain users to be able to add items but not edit or delete them, but they might not want others to have access to version history. If site owners contain the Manage Permissions right in their permission level, they can create a custom permission level at will. One of the most important elements of this action is that permission levels created in sites with broken inheritance live only within that site. Therefore, site collection administrators have no idea how many custom permissions have been created, have been assigned, or have control, because the Manage Permissions right can give any user the same power to create groups and permissions.

Item-level permissions. If the previous options weren’t enough to make you nervous, knowing that inheritance can be broken at the site, list, or list-item level for each and every site in each site collection in all web applications should raise the hairs on your neck. The upshot is that each item in your lists and document libraries has its permissions managed individually, including adding and assigning custom permission levels to custom groups.

Where’s the Problem?

Considering the flexibility inherent in the above functionality, you’ll often find a significant amount of unintended abuse of the permission assignments in SharePoint. In WSS 2.0 and SharePoint Portal Server 2003, the concept of a permission level didn’t exist as it does in SharePoint 2007. So, SharePoint farms that have gone through upgrades containing unique permission assignments ran headlong into a complicated situation. Those permissions automatically rolled up into new permission levels during the upgrade—but the "Permission Level" name is generic, thus essentially displaying permissions with no useful name to identify their intentions. These permission levels are also created at the individual subsite level, making them difficult to find.

Previous versions of SharePoint also allowed Microsoft Outlook integration, which could expand groups into individual users and assign them all to SharePoint. It’s not unheard of to see 1,000 or more users all assigned with the same permission level to a site or list. Ideally, these users are added to a group to more easily identify and manage access to content.

One important question to ask is, “Do you know the status of your own SharePoint environment?” Of course, wrapped up in that question are numerous related questions: How many users have the Manage Permissions right? How many lists or list items across your farm have unique permissions? How many distinct SharePoint groups exist? How many locations have broken inheritance? At what level—just site, or list and list items? How many permission levels have been created without your knowledge with duplicate names but not duplicate rights, or duplicate rights but not duplicate names? How do you keep track of this?  

Perhaps you still want to know why this is a problem. The main problem with permissions run amok is maintenance and security. Users accidentally delete, update, corrupt, move, or change content and sites. This scenario creates a burden on administrators who are tasked with protecting and managing the SharePoint environment.

The easy problems are those that are identified; the difficult problems are those that go unseen. For example, say a site owner gives inexperienced users additional rights to a team site, and that team site is accidentally deleted. The problem is identified and corrected after a certain amount of effort depending on the backup-and-restore strategy in place. But what happens if that user is accidentally deleting list items or documents? Those items might go unnoticed and cause unforeseen catastrophic issues for which there is no visible explanation. From a security perspective, giving too many rights to manage permissions also leads to giving unintended access to content.

What’s the Solution?

The problems I’ve described create varying levels of complications for different types of organizations. To assist with this problem in my environment, I ended up building a small application to identify the underlying data, analyze the permissions status, and create a system for fixing the permissions. Although some third-party applications can assist with viewing, copying, and managing permissions, I resorted to writing my own application because nothing I found was robust enough for what I wanted to accomplish.

The application isn’t the focus of this article, but SharePoint development experience will be necessary should you choose to write your own. Ultimately, this was the only solution that met all the requirements to fix our problem—even after we researched commercial applications—but individual organizations will have different needs. Hopefully, some of the experience and insight I offer in this section will compel you to take measures now that prevent your organization from resorting to extreme measures to correct permissions problems. Now, here are the steps our team took.

Figure 6: Creating a matrix

As you can see, most of the permissions are similar and it became easy to bucket them into permission levels. We were able to look at 11 unique sets of rights and see that they were all intended to be a Read right. An added benefit of the Read right is consistency: We could make sure all the base permissions assigned to this level were standard across all sites.

After identifying all the unique rights, we were able to match them all down to a reasonable number. The only out-of-the-ordinary levels we had to account for were some additional rights for surveys to restrict the ability to delete or edit items, and some administration rights to restrict the ability to manage permissions and create subsites. By limiting the permission levels to specific rights with proper naming conventions, we also simplify the viewing of site permissions. For example, a SharePoint group might be assigned to the following levels: Site Owner, Manage Permissions, and Create Sub-site. We have been very careful granting Manage Permissions rights moving forward.

How Did We Do It?

Let's walk through the application at a high level so that you can understand how we accomplished all that. The application iterates through each site, list, and list item in the site collection and looks for broken inheritance. If it finds a broken permission, it stores the specifics of any role assignments for the given object in the database. Role assignments in the object model involve attaching a user or group to a permission level on a certain item (e.g., site, list, list item).

In this step, we also capture the specifics of the item, including permissions. So, in essence, we’re cataloging all the places permissions are set and storing the data in a SQL Server database. Doing so allows us to build and run some relatively simple SQL queries to see all the unique permissions across the site collection. Once we’ve gathered the data, we can use it to build the matrix, then update the database to tell the application that each unique permission level should actually be mapped to the new consolidated level.

Now, we had the basis for where we wanted everything to end up. Plus, we had a catalog of what was stored in a database. The next step was to build the code that would implement all the desired changes across the site collection. This was the tricky part, because we had to re-inherit a site structure in order to centrally manage these new permission levels and ensure that they were propagated to all sites. Therefore, we had to ensure that we had properly stored all our broken permissions so that they could be re-applied with the new permission levels.

As a part of this step, we had to write code to look at the role assignments to consolidate users into groups. Groups didn’t exist in many cases, so we created them dynamically based on a naming convention of site name and permission level. Then, we added all users with that set of permissions to the new group. We did this after we ran the matrix to ensure that the new manageable permission levels had been created.

When we finished, we were able to meet the goals I outlined earlier: limiting certain unneeded permissions, rolling users into properly named groups, reassigning all existing permissions into the new matrix, and managing permission levels centrally.

Long-Term Considerations

As long as users have the Manage Permissions right, they will slowly be able to undo this work. I recommend limiting this right to only users who need it and understand the implications. One of the benefits of building a custom application is that you can periodically run the analysis portion to see how your work is holding up. The analysis will quickly identify the location of additional rogue permissions and any users assigned this permission—enough data to track down where problems are so that they can be fixed before the problems get too large to handle manually.