By default, access permissions are set at the Site Collection level and then inherited downwards, to all libraries (and document sets), lists and documents on the main page and to all subsites and their libraries (and document sets), lists, and documents.
The default permissions are usually:
- Site Owner (full control of the site)
- Site Members (can add and edit)
- Site Visitors (can view only)
Breaking the inheritance model of access permissions is relatively simple to do but can create confusion and, if not done correctly, make content completely inaccessible even to the Site Owner. Breaking the inheritance model on documents is particularly dangerous as there is no easy way to identify or manage access restrictions applied across the farm.
Simple access controls via de-inheritance
The simplest way to limit access to a site or the content on a site is to de-inherit the access permissions. To change this on:
- Sites, go to Site Actions – Site Permissions
- Libraries/Lists, go to Library/List – Library/List Permissions
- Document Sets or documents, click on the down arrow next to the name and click on Manage Permissions
… then choose ‘Stop Inheriting Permissions’. If that option is not there, then the Site, Library/List, Document Set or Document may already have permissions on it. (You may see the following statement: ‘Some content on this site has unique permissions which are not controlled from this page. Show me uniquely secured content’).
But there’s a catch, creating the first layer of confusion. When you stop inheriting permissions, the same permission groups remain on the page. But didn’t you just STOP inheriting those permissions?
The reason I think Microsoft left the default permission groups there is so you don’t inadvertently lock yourself out of the Site, Library/List, Document Set or Document – if no group is left and you navigate away from that page, you will almost certainly be denied access. The really good thing to note is that, if you have realised you are about to make something inaccessible (and before you navigate away), you can click on ‘Inherit Permissions’.
So, after you stop inherited permissions the next things you need to do are (a) remove any groups you no longer want to access the site, and then (b) add or create a group you want to access the site. To do that, you click on ‘Grant Permissions’. The dialogue box that appears asks you to select users or groups, and then grant the specific permissions. A group must exist to add it and these are added at the Site Collection or Site Level.
Note that a created group does not on its own have specific permissions, it is only a group of names. You create the permissions when you give that group access to the site, library/list, document set, or document. If you have a group already, you can add new names to that group.
I’d recommend you create a group at the Site Collection level because it will appear there anyway and you need to understand what impact that has – any new group you create will have access to anywhere else in the site by default UNLESS you break the inheritance model.
Slightly complex access controls via de-inheritance and groups
The most common use case for slightly complex access controls are at the library/list, document set or document levels. That is, there is a business requirement to restrict access to one of those, or provide access to a specific document set and nothing else. For the sake of this posting, we will consider the case of a library, in a second level sub-site, that contains multiple document sets, each with multiple documents. The business area wants to restrict access to one of the document sets to a specific group of people.
This is where you need to exercise great care as, without careful planning, you could inadvertently allow all the members of that group to access anything else across the entire site collection where access is inherited. This is because, when you create an access group, the group will appear across the entire site collection.
To allow access to a document set only within a site collection (and assuming there are multiple sub-sites each of which inherit from the top level), you need to first understand access permissions already set.
First, break inheritance on all sub-sites; by default this will leave the default groups plus the new one you have created, so you you only need to remove that new group on all sub-site access permissions. This will remove the new group from all libraries/lists, document sets and documents on each site.
Second, you need to add the group to the specific document set. To do that, stop inheriting the permissions, which leaves the default access permissions, then add the new group by clicking on Grant Permissions.
Now, if you go to the site permissions, you will see the new group listed (which can be a bit disconcerting), and the statement (against a yellow background): ‘Some content on this site has unique permissions which are not controlled from this page. Show me uniquely secured content’.
What this means is that members of the group you have added:
- Cannot access the site, or site collection (they will get an ‘Access Denied’ message).
- Can see the document set they have been given access to (but no other document set or document in the same library)
- Can see the site’s libraries and lists but cannot see any content in those lists. This is a good reason for being careful about naming those libraries.
As noted already, access permissions can be very difficult to manage and very easy to get wrong. Careful planning will help to ensure you don’t lock yourself out.
Records about the world 