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:
- For a website, go to Site Actions, Site Settings, Advanced Permissions.
- For a list or library, go to Settings, List (or Library) Settings, Permissions.
- For a folder or item, access the item's context menu, and click Manage Permissions.
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.