This topic introduces three security features that work together to control user access to sites and content on sites, and what level of access you have to have yourself in order to work with those features.
Note This article is designed to provide a conceptual overview to the elements that make up permissions. For a step-by-step walkthrough of how to change permissions settings for your site, see Roadmap: Grant permissions for a site. For a step-by-step guide to how to set permissions for a list, library, or item, see Edit permissions for a list, library, or individual item.
In this article
Visualize the scope of permissions settings
Three features—security groups, permission levels, and permissions inheritance—interact behind the scenes to determine what sites and content people can see and use. Collectively, they are referred to as permissions settings.
If you work on a site, you are working inside a site collection. Every site exists within a site collection, which is simply a group of sites and content that are located under a single top-level site.
A site collections’ initial permissions settings are created by the site collection administrator. By default, the settings that the administrator sets for the site collection apply to all the collections sites and sub-sites. Most sites have one or more site owners who can change the settings established by the site collection administrator.
Here is an illustration of a site collection, along with the types of sites and content that a site collection might contain.
A site collection administrator determines initial permissions settings for the whole site collection. All the sub-sites and content in a collection inherit the permissions settings that the site collection administrator chooses for the top-level site.
If you are a site collection administrator, this means the following:
- You should work closely with the people who create your site collection.
- You are responsible for deciding who has access to important intellectual property stored on your organization’s sites (that is, for setting site-collection level permissions).
If you are a site owner, or are responsible for restricting access to a specific item of content, you can work with the permissions settings for your sites to customize the permissions settings for your area.
To learn more, see Plan your permissions strategy.
Visualize the components of permissions
At the most basic level, you manage permissions settings by granting or restricting user access. This is true for many different roles, whether you are a site collection administrator, a site owner, or just someone who works with a single document. To grant user access, you work with three interrelated features:
- Security groups
- Permissions levels
- Permissions inheritance
The best place to start is with security groups. In most circumstances, you can do everything you need to do about controlling access simply by working with security groups. Permission levels and permission inheritance run smoothly behind the scenes.
A security group is a collection of people—known as users—who all need to perform similar types of tasks on your site. For example, some people might only need to see information on your site, while another group might need to edit it, as well.
Groups give you the power to control access to sites for many people at once.
- Streamlines your site maintenance for you and your successor site owners,
- Ensures that people performing similar tasks have the same levels of access, and
- Helps you make sure that people have only the access they need, not more.
Group people when they have tasks that require similar levels of access
Here are some examples of tasks that the users of a site might have to perform:
You can organize these users into the default SharePoint groups to group them by the kinds of tasks that they will have to perform on the site. To learn how to work with SharePoint groups, see Manage membership of SharePoint groups.
Security groups can be composed of many individual users, can hold a single Windows security group, or can be some combination of the two.
You can organize users into any number of groups, depending on the size and complexity of your organization or Web site. Groups are created and managed at the site collection level.
Top of Page
Example: Default SharePoint groups group people by likely tasks and access levels
The most frequently used default groups on a site are the following:
These groups help you easily sort people who will use your site in similar ways. Some people just have to review content on the site, other people have to edit content, and some have to add or edit elements of the site itself.
Or, as shown in the following illustration, you could assign people to groups as follows:
How permission levels assigned to groups determine the group’s level of access
The permission levels that are assigned to a group make sure that group members have the access to the sites and content that they need.
Each default security group is assigned a default permission level, but you can also create new groups or assign different permission levels for any existing group.
Note You can create SharePoint groups from Windows security groups, but not from distribution groups, also known as distribution lists.
Anyone assigned to a permission level that includes the Create Groups permission, which is included in the Full Control permission level by default, can create custom SharePoint groups.
For information about working with the security and distribution groups that are included in Active Directory Domain Services, see Choose security groups (SharePoint Server 2010).
Security groups are assigned permission levels. Permissions levels are combinations of tasks that people need to be able to perform on your site, such as “view pages on the site,” and “view items in a list”; or, “create a list,” or “add an item to a list.”
By grouping commonly associated tasks into permission levels, you can grant security groups permissions to perform many tasks on a site or content item at once.
A permission is the right that you can grant to a person to do something on your site: to view, create, delete, or edit something. You might grant permissions for a person to work with a list, or a library, or a sub-site, for example.
You never grant a single permission to a group or a person – instead, you assign permission levels, which are combinations, or sets, of permissions.
Site, List, and Personal permissions are combined to create permission levels
There are three kinds of permissions:
- List permissions give people the right to do things with lists and with list items, such as adding or deleting lists, adding or deleting columns in lists, or adding or deleting items in lists.
- Site permissions give people the right to do things at the site and subsite level, such as adding pages or subsites, or managing permissions for other users.
- Personal permissions give people the right to manage their own personal view of the site, creating personal views of lists, libraries, and add or delete personal Web Parts.
Permissions levels are combinations of individual permissions.
In the same way that people are grouped into security groups by the kinds of tasks they need to perform, individual permissions are grouped into permission levels designed to suit the security groups – that is, the people -- who will need to use them
Default permission levels correspond to default groups, to match access with tasks
For example, the Full Control permission level is designed for people who need to manage the site itself, so it includes the greatest number of site permissions. People will the Full Control permission level can perform tasks on the structure and components of the site itself, including granting permissions, as well as performing all the tasks associated with lists, libraries, and items.
All the default security groups (such as Visitor, Member, and Owner) are assigned default permission levels (such as Read, Contribute, and Full Control). That is, each group of people is granted access to specific toolsets that are appropriate to the tasks they need to perform.
The most commonly used default permission levels are designed to build on one another:
- The Read permission level has the fewest permissions.
- The Contribute permission level includes all the permissions in the Read level, plus some more.
- The Full Control permission level includes all the permissions in the Contribute level, plus some more:
Top of Page
Review the permission levels on your site
To see the permission levels assigned to groups for your site:
- Click Site Actions, then click Site Permissions to see the permissions page.
On the permissions page, you can see descriptions of each permission level.
- On the permissions page, click Permission Levels.
The Permission Levels page opens, with a description of each Permission level and a link for editing the permission level.
To see which individual permissions are included in that permission level:
- Click the name of a permission level in the Permission Level column.
If the default permission levels don’t have what you need, you can create your own permission levels.
By default, sites and content inherit groups and permission levels from the site above them in the site hierarchy—from their parent site. Permissions inheritance gives you the power to manage all your permissions for a site and all its sub-sites and all the content on it and its sub-sites, from one place—the top site—quickly and efficiently.
Control user access efficiently with permissions inheritance
Take advantage of permissions inheritance to make changes to your entire site in one place and have them ripple through to all the people who use it and the content they use.
SharePoint sites are constructed in hierarchies, with a parent at the top.
In a SharePoint site collection, all sites and content under a parent inherit permissions from that parent – that is, everything under the parent uses the same user groups and permission levels that the parent does, unless you specifically change them:
Fig. 2 By default, permissions on lists, libraries, folders within lists and libraries, items, and files are inherited from their parent site.
You can give any item – whether it’s a subsite, a library, a folder in the library, or a document in the folder – any item at any level in the whole hierarchy -- its own unique permissions: this is called breaking inheritance.
Site B has broken inheritance from the parent site. All Site B’s subsites inherit the new permissions settings from site B.
For ease of maintenance and administration, we recommend breaking inheritance as rarely as possible. Often this just means organizing your site in such a way that all sensitive material is located in the same place. Then you can break inheritance once, for that specific site or library, rather than having individual documents scattered through various sites or libraries with unique permissions that you have to maintain and keep track of.
The yellow status bar appears to inform you when the site you are looking at does not inherit permissions from its parent. In this case, it is said to use “unique permissions.”
When you break the inheritance from the parent, the item with the new, unique permissions at first has a copy of the parent’s permissions, which you can edit. No change you make to the item with the broken inheritance affects the parent.
Permissions inheritance means that managing permissions of a parent site affects not only the parent site, but all subsites that inherit from the parent site, so it is important to carefully consider any changes to permission levels.
Caution Owners of subsites that inherit permissions from the parent site can edit the permissions of the parent. Ensure that any changes you make to the permissions on the parent site are appropriate for the parent site, and for all the subsites that inherit those permissions.
Edit permissions for a list, library, or item: Break permissions inheritance
In some cases, your site might contain content that only certain people or groups should be allowed to access. For example, if you have a list on your site that contains sensitive data, you might want to restrict who can see it.
To do this, you break permissions inheritance, and then edit permissions for the content on its own permissions page.
For a step-by-step procedure on how to restrict access, see Edit permissions for a list, library, or individual item.
Top of Page