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