So you have a new SharePoint Site and you need to allow access so people can actually use this site. It’s not always as easy as it sounds, but while it can seem overwhelming if you haven’t done it before, there is an easy way to start looking at this.
Throughout this blog, I will break down the basics in a fashion that works for SharePoint 2007, 2010 and the newest iteration 2013. This guide assumes that you have a working knowledge of Active Directory Users and Computers and you have already created User Objects and you have a fresh SharePoint Install ready to be populated with users.
Make sure to continue reading my blog to learn more about Permission Management. In my new Blog, I describe how to remove access properly;
Without further ado, let me introduce:
Default Permission Levels
First, it is important to know that there are five Default Permission levels that are available in all versions of SharePoint since WSS 3.0 (Windows SharePoint Services 3.0 – 2007).
|Full Control||This permission level contains all available permissions in your chosen version of SharePoint. By default, this level is assigned to the Site name Owners SharePoint group. This permission level cannot be customized or deleted.|
|Design||Can create lists and document libraries, edit pages and apply themes, borders, and style sheets in the Web site. Not assigned to any SharePoint group, by default.|
|Contribute||Can add, edit, and delete items in existing lists and document libraries. By default, this level is assigned to the Site name Members SharePoint group.|
|Read||Read-only access to the Web site. Users and SharePoint groups with this permission level can view items and pages, open items, and documents. By default, this level is assigned to the Site name Visitors SharePoint group.|
|Limited Access||The Limited Access permission level is designed to be combined with fine-grained permissions to give users access to a specific list, document library, item, or document, without giving them access to the entire site. However, to access a list or library, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted. Limited Access cannot be assigned and is automatically assigned by SharePoint to accommodate for this reason.|
Note: The Design, Contribute, and Read Permission Levels can be customized to meet your needs, but it is best practice to leave all default permissions, and create new ones as needed rather than edit the default levels. This gives you an “easy out” should you run into problems with custom permission levels as you would be able to reference the original default levels.
Site Collection Administrators
The Site Collection Administrator has Full Control to everything in the Site Collection. This means that it is not necessary to Grant Permissions granularly on the site or to add to any Groups or Permission Levels because they already have complete access to everything and Site Collection Administrators permission will override ANY other permissions set for the account. These users can be assigned in two locations:
- Central Administration
- Application Management– in the Site Collections section, click Change Site Collection Administrators. On the Site Collection Administrators page, click the arrow next to the site collection name and then select Change Site Collection if the site collection you want is not already selected. Choose the Appropriate Site Collection or click Change Web Application to find the correct Site Collection.
- You can set a Primary site collection administrator and a Secondary site collection administrator here. The advantage of this is that if anything happens to the Site Collection Settings that contain the additional Site Collection Administrators, these users will not be affected. It is often a good idea to set one of these to a dedicated Admin Account that is not a normal user account and store these credentials in a safe place.
- Site Collection Site Settings
- On the Parent Site, go to Site Settings – under Users and Permissions click Site Collection Administrators. In the box, enter users separated by semicolons and click the checkmark to check the names. Shortcut: Ctrl+K will also perform this function in most Microsoft Products. Try it in Outlook!
You can add as many additional accounts as you want to the SharePoint Site Collection administrators group, but only the primary and secondary site collection administrators will receive administrative alerts for the site collection. All members of the SharePoint Site Collection Administrators group have full administrative permissions to the site collection. Site Collection Administrators permission will override ANY other permissions set for the account.
Think of the structure of your site. What links lead to what pages? You will find the main terms assigned to these pages below.
This is the main site. An example of this would be www.example.com. There are no additional directories we are viewing on this site, just the Root Site.
The Root Site is the Parent of all other Sub Sites. Each level you navigate to has a parent preceding it.
This is an additional directory off of the Parent Site. An example of this would be www.example.com/sales. You can even embed a Sub Site within a Sub Site, such as www.example.com/sales/proposals of which /sales would be the Parent. This is common of Lists and Libraries within a Site.
Lists and Libraries
SharePoint lists are web based editable tables. They provide the ability to work with structured data in the same fashion you would manipulate a spreadsheet.
SharePoint libraries are a specialized type of Lists. Libraries are used to store documents and files. A library is a list, but has one (and exactly one) file associated with each item.
Both types allow the ability to add fields, properties, and columns. For our purposes, be aware that it is possible to allow a user access to only certain lists or documents in a library without access to an entire site. This ability is outlined later in this blog.
Again, think of the structure of your site. Since Microsoft has based almost their entire product catalog on Hierarchical Systems, a good way to think of SharePoint is like folders on your computer. By default, all sites, lists, and libraries in a site collection inherit permissions from whatever folder contains it. This means a site inherits permissions from the Root site, or Parent, of the site collection, and a sub site inherits permissions from its parent site. A list inherits permissions from the site that contains the list. A list item inherits permissions from the list to which it belongs.
If the default configuration is not changed, permissions are inherited through the whole site collection. In a way, each element (site, subsite, list, library, item, etc.) inherits permissions from the root site of the site collection.
In instances where certain Users or Groups should not have access to a resource, you will perform what is known as Breaking Inheritance, which is outlined a little further along in this blog. A best practice for inheritance is to inherit as far as possible into the structure of your site. This makes it easier to administrate. If you need to break inheritance often in your site, it is a good idea to keep this documented somewhere. Microsoft Visio is a fantastic tool to use for this purpose, but pen and paper works too.
Manage Access Requests
The ability for users to request access to sites is turned off by default, but some administrators like the ability to allow users to do this. This step is optional and by no means a requirement for SharePoint to function. If you want your users to get a request access page when they browse to a site they do not have permissions to, then follow the steps below to configure this.
- This configuration is for the entire site. There are no settings for individual libraries and lists. Access requests for all lists or libraries all go to the same person.
- The automated email sent to the site administrator contains a convenient link to ‘grant’ access to the resource (list or library). If you are using groups to manage permissions, you should not use the ‘grant’ link to manage the permission, though it can be helpful to see which resource the user is requesting access to. Consider, disabling automated access requests entirely, in favor of forcing the user to make a specific request (outside of the automated system). At the very least, be mindful that the automated request system is not aware of your grouping setup.
Click Site Actions, then Site Settings.
Click Advanced permissions.
Click Access Requests.
Allowing user requests (through the automated form), is optional. Change the email address to the desired site administrator.
2010 and 2013
Go to Site Actions – Site Settings – Site Permissions. Click Manage Access Requests in the ribbon.
This is to allow request for permission to the site. If granted, it will default to permission given directly as limited access. Now you can edit user permissions, or it is recommended to add them to the appropriate group you identified earlier in your planning.
Managing Users and Groups
Now that you have an understanding of the basics discussed above, you will need to start adding users to the SharePoint site. At this point, let’s assume that only the Site Collection Administrators have been created. Since they do not need to be granted any additional permission and have full control, we can use them to begin Granting Permissions to additional users.
This process is essentially the same in each version of SharePoint, but the locations and names of options may be different. We will start at our Root Site and branch out from there, but be aware that you can navigate to any resource that will have permissions and manage them from the Site Settings – Permissions option of that location.
Start on your Root Site. To view the permissions for a 2010 or 2013 site, go to Site Actions – Site Settings – Site Permissions. In 2007 you would go to Site Actions – Site Settings – Advanced Permissions. At this point, you can either Grant Permissions directly to the site and assign the appropriate Permission Level for this user, or begin working with Groups.
If you will have many users that share the same permission level, it would be best practice to use Groups to accomplish this. Again, think of a group like a Folder. The folder contains the permissions, and each member in that folder inherits the permissions assigned to the Group. When a site is built or added to a site collection, three groups are created by default.
|Group Name||Permission Level|
|Site Name Owners||Full Control|
|Site Name Members||Contribute|
|Site Name Visitors||Read|
You can begin populating these groups, creating new groups or granting permissions directly. In any case, the buttons you will be looking for are in the Ribbon spanning across the top of the page.
For the purpose of Granting Permissions directly to the site, Add Users would be the same as Grant Permissions. If you have a previously created a group, you can also Grant Permissions to the already established group. If you need to create a group and have it automatically assigned to the site you are viewing, then Create Group would be the option to choose. To add users to an already established Group, you will click Add Users or Grant Permissions and Choose the Group they belong to.
Sub Sites will inherit permissions from their parent. As an example, /sales, /sales/proposals, /hr and /hr/policies will have the same User Permissions that have been Granted on the Root site, www.example.com. Each Sub Site can also manage their permissions independently by breaking inheritance from the Parent.
So let’s say that HR members should not have access to proposals. To accomplish this, we will be Breaking Inheritance at the /proposals site. If you plan to break inheritance on your site, it’s a good idea to organize your content to limit the number of locations that have uniquely defined permissions.
Consider organizing your content by security level, from less sensitive to most sensitive. You might place documents that are more sensitive on a separate sub site or in a single library. This organizational structure is easier to maintain than managing many documents that are located across many sites or libraries, each with unique permissions.
Once you are at www.example.com/sales/proposals, in 2010 or 2013 site, go to Site Actions – Site Settings – Site Permissions. You will then click Stop Inheriting Permissions.
In 2007, you would go to Site Actions – Site Settings – Advanced Permissions. You will then click Actions – Edit Permissions.
You can follow these steps on any sub site to manage what permissions Users and Groups will have to sections of the SharePoint Site.
If you break permissions inheritance for a list or library and then define new permission settings, the list (or library) becomes a parent for items in it. The items inherit the new permission settings (unless the items have uniquely defined permissions.)
To perform the same function for a List or Library and break inheritance to restrict access to it, follow these steps;
- Open the list or library in which you want to add users or SharePoint groups.
- On the Settings menu, click Document Library Settings or List Settings.
- On the Customize page, in the Permissions and Management column, click Permissions for this document library or Permissions for this list.
2010 and 2013
- Navigate to the site that contains the list and open it.
- Choose the List tab to open the list ribbon.
- Click Settings, and then choose List Settings.
- On the Settings page, under Permissions and Management, click Permissions for this list to open the permissions page for the list. The permission page displays a status bar across the top that indicates the list inherits permissions from its parent site, and then gives the name of the parent.
- To break permissions inheritance from the parent, click Stop Inheriting Permissions. This disconnects the list (or library) from the parent site.
Wrapping Things Up
Now that you have gone through these steps and configured some permissions throughout the SharePoint site, it is a good idea to test your work. What I like to do is use Internet Explorer to perform all my administrative work and use Google Chrome (or any alternate browser) to test the permissions of the Users and Groups you have created. This guide is by no means an All-Inclusive guide, but it will get you started. If you would like to learn more you can check out the resources below.
- Permission levels and permissions in SharePoint 2007
- User permissions and permission levels in SharePoint 2010
- User permissions and permission levels in SharePoint 2013
- What is Permissions Inheritance?
- Create and manage SharePoint groups in SharePoint 2013
Now that you have a grasp on the topics above. There will come a time when you need to remove users from SharePoint. To learn how, read my Blog: