Essential SharePoint Security Practices: SharePoint Users and Groups

A fundamental task for any IT administrator is security management, and security for Microsoft SharePoint is no exception. SharePoint, however, differs from most other IT systems. For example, SharePoint often grows organically, with little structure or governance. And executives usually want SharePoint to be flexible, enabling it to cater to the dynamic and evolving needs of the organization.Another difference that makes securing SharePoint different from securing other systems is the idea of decentralization. Decentralization means you delegate security tasks to workers outside the IT group, such as content managers. This delegation might sound good, but it can introduce security risks. And if there's a problem, the IT guy usually gets the blame.

This introduction to SharePoint users and groups will help you manage permissions while maintaining a flexible yet secure SharePoint deployment. You'll learn how to break inheritance, how to create custom permission levels, and how to assign permissions to users or groups. I'll also offer recommendations to help ensure you're following the best practices based on your security needs.

Setting Permissions
A site collection is a hierarchy of websites, with each website containing lists and libraries that store content such as files, contacts, announcements, and web pages. A site collection defines a security boundary around this content so that users who have access to any content in a collection exist directly or indirectly as a site collection user. Administrators can grant users access to a site collection directly as a user, or indirectly through an Active Directory (AD) or SharePoint group. If you’re using a custom authentication provider, you can also grant SharePoint access to your specific security principals. Whether users have access to all content in a site collection or a single document library buried deep within it, they are considered site collection users. Permissions in one site collection don't carry over to any other site collection, meaning each site collection is independently secured.

Permissions in a site collection behave similar to NTFS permissions. By default, access permission in a site collection is inherited from the parent site. So, if Alice is granted read permissions at the top-level website in a site collection, this read permission will cascade down to all content within the site collection. Similarly, if Alice is granted Read permissions to a lower-level website, these permissions apply only to this website and websites that fall underneath.

Access to content is assigned through permission levels. Permission levels are easy-to-use combinations of individual permissions. An example of a built-in permission level is Contribute, which means a user has view, add, update, and delete access. You can also create custom permission levels as we’ll see shortly.

A user's actual permission is the sum of all permissions granted. So, if Bob has been granted Contribute and Design permission levels on a website, his effective permission will be both Contribute and Design.

Breaking Inheritance
Initially, SharePoint inheritance is in effect from the top of the hierarchy to the bottom for all content in the site collection. This means that you can change permissions only for the top-level website in the site collection. You can break inheritance by creating unique permissions at the website, list/library, folder, or item level. Figure 1 shows an example of a site collection hierarchy and permission inheritance.

To break inheritance, you first need to access the permissions page, which you can do as follows:

From the permissions page, click Actions, Edit Permissions, and confirm the action by clicking Ok. This will break inheritance and copy all the permissions down to the current level. It also establishes a new inheritance rule for this and lower levels. After inheritance is broken, you can re-establish it, but you'll lose any unique permissions that you created. To re-establish inheritance, click Actions, Inherit Permissions from the permissions page.

Creating a SharePoint Group
As with groups in other systems, SharePoint groups simplify permission assignments. You can place users, AD groups, or security principals from your custom provider into SharePoint groups. Note that although you can create a group within a sub-website, it will be stored in the top-level website. To create a SharePoint group, go to Site Actions, People and Groups. In the New menu, select New Group.

Granting Access to Groups and Users
You can assign permissions at the top-level website of the site collection or at any level at which inheritance has been broken. From the permissions page, select New, Add Users. Select the users or groups for whom you want to assign permissions and select the desired permission levels. In this context, groups can be AD groups or SharePoint groups. On this same page, you can also assign users to SharePoint groups and whatever permissions the group has will apply to the users. Note that SharePoint groups can't contain other SharePoint groups.

Creating a Custom Permission Level
Often, built-in permission levels aren't specific enough for your needs. For example, you might want users to have view, edit, and create permissions only. This permission level is similar to Contribute but without the ability to delete. Although you can change built-in permission levels (e.g. remove delete access for Contribute), it's not recommended. To create a new level, go to the permissions page as outlined earlier, and click Settings, Permission Levels, Add a Permission Level. You can also create a new permission level based on an existing one. Simply select the permission level from the Permission Levels screen. At the bottom of the page, click the Copy Permission Level button.

Understanding the All People Screen
The All People screen is one of the most misunderstood screens in SharePoint. The common misconception is that it represents all users that have some form of permission to content in the site collection. However, that's not true. To better understand, let's look at the three primary ways a user can appear on this list:

Deleting the user from the site collection doesn't necessarily remove access. This works only if the user was assigned direct permission in the site collection. To remove access to a user granted via SharePoint or AD groups, you must remove the user from the group. Removing users from a group doesn't remove their names from the All People list; the list shows users who at some point had access.

Denying Access
Until now, I've talked only about granting access. What if you need to specifically prohibit a user from accessing content? Although this functionality is supported, you can't do it at the site collection level. You must do it at a higher level—the web application. By denying a user access at the web application, you deny access to all content in any site collection within that web application. To deny access, go into Central Administration. Click Application Management, Policy for Web application. From this screen, select the desired web application. Next, select the users or AD groups and what type of deny permission you want. You can either deny write or deny all access. Any policy set here will “invisibly” override any access granted at the site collection level and won't be seen within any site collection.

This screen is also where you can grant full read or full control permissions across all site collections in the web application. This option is useful for a legal team or auditors who need blanket access to all content. Again, this access is granted invisibly.

Changing or Reassigning Site Collection Administrators
A site collection administrator manages a site collection. This role often represents delegated users within the organization (not IT), who are responsible for managing and securing content. These users have full control permissions to all content within the site collection, even if inheritance is broken. When you create a site collection, you must specify at least one, but no more than two users who will become the site collection administrators. An AD group can't be made a site collection administrator. If you need to change who the primary and secondary administrators are, you can do so by going to Central Administration and clicking Application Management, Site collection administrators.

If you want more than two site collection administrators, you can add the users (or AD groups) to the SharePoint group called Owners, but keep in mind that permission inheritance can block access to these users. You can also grant them full control to the web application, as mentioned in the Denying Access section.

Let me also add that SharePoint has one or more farm administrators. These users, by default, don't have access to any site collection but are able to log into Central Administration and add themselves as a site collection administrator. They can also change a web application's policy, so indirectly this is a powerful user.

Recommendations
Now that you understand the essential SharePoint security principles and how to perform several associated tasks, let me share some guidance and best practices in managing your permissions.

When to assign permissions to AD groups. If your organization already has a complete and accurate list of AD security groups that represents the roles in the organization, you should leverage these groups for SharePoint access. Simply add the AD group to a SharePoint group that represents the permission you want to grant. This is the most common form of access and the easiest to manage.

When to add users to SharePoint groups. Use this approach if your organization doesn't have well-managed AD groups or your site collection administrators have no easy way to adjust or request AD group membership changes. An example would be access to project-based websites where you create SharePoint groups for each project.

When to assign permissions to individual users. Individual permissions work well in special situations, such as site owners or for sensitive content, such as payroll data. These permissions are discouraged as it's harder to troubleshoot access or to duplicate access if one user leaves the company and is replaced by another.

Although SharePoint's security model is very granular, breaking inheritance and assigning new permissions throughout your site collections will quickly result in chaos. I encourage you to break inheritance sparingly, so you need to structure your content such that you can leverage inheritance as much as possible.

Unfortunately, permissions reporting (show me everything Alice has access to) or permissions duplication (grant Bob the same permissions as Alice) is something that is lacking from SharePoint out-of-the-box. However, permissions reporting and permissions duplication can be done programmatically using the SharePoint object model. For information on the object model, see “Server and Site Architecture: Object Model Overview” at http://msdn.microsoft.com/en-us/library/ms473633.aspx. There are also many third-party utilities that help simplify these kinds of permission-management needs. Two good examples are Quest Software's Site Administrator for SharePoint and Lightning Tools' DeliverPoint.

Armed with these essential security principles, knowledge about how to perform permissions-related tasks, and best practice guidelines, you should be well on your way to delivering a secure, yet flexible SharePoint environment. And, let’s hope a blame-free one as well!