I’ve written about this before, but today I found myself explaining the whole permissioning thing to a colleague, and put together a diagram which shows how inheritance works. Permissions and groups are inherited as follows:
This shows “Administrative” rights, but can equally be applied to other permissions at any level below a site collection. Dotted boundaries show where the inheritance are optional (and shouldn’t really be called inheritance either).
To explain this a little further let’s start at the top:
Web application level
The Policy for Web Application setting allows you to give Active Directory users and groups rights over all Site Collections in that Web Application. If you give a user or group Full Access permissions at this level, they will have access to all the settings pages for all sites in the web application. These users and groups names do not show up in any Sharepoint groups or permissions pages.
Site Collection level
When creating a site collection you can set Primary and Secondary Site Collection Administrators. These can only be set as Active Directory user accounts. These users get access to all settings pages for the sites within the site collection (including the root site /). Emails sent by Sharepoint relating to sites in the site collection appear to come from the Primary Site Collection Administrator.
To update all your Site Collection Administrators in one go, take a look at my Sharepoint 2007 PowerShell scripts.
This is the level that the groups you can administer within Sharepoint become available, and what most people think of when they think of permissions in Sharepoint.
An important point to note is that there is always a root site within a site collection – this is accessed at the root of the site collection directory (/). All other sites in the site collection are subsites (or subsites of subsites) of this site. The groups and permissions you set up for this root site can be used by the other sites in the collection.
This all gets a bit complicated, so lets use an example to illustrate.
We’ve got a site collection with a root site at http://dunxd/sites/teams/. Within this site there are two subsites – a and b. Site a has a subsite 1.
When we create the site collection (and root site), Sharepoint will set up the following groups:
- Teams owners – this is for users who can administer the root site. They won’t see the Site Collection admin links unless they are included in one of the higher level permissions described above.
- Teams members – this is for users who need to be able to work on content in the site
- Teams visitors – this is for users who only require read access to the site
When we create subsite a, we have the choice of using the same permissions as the parent site. If we choose that, subsite a will not have any additional groups created. Owners of the Teams site will also be owners of the a site, and so on.
Note that here we are simply using the groups – once these have been set up, we can change the permissions those groups have for site a without changing the permissions they have for site Teams. Also note that if we add a user to the Teams owners group, that user will also have the Owner permissions on site a.
We also have the choice of using unique permissions. If we choose that, additional groups may be created, or we may use existing groups for each of the Owner, Member and Visitor roles. The default options in this situation are to share the parent Visitors group, and create new Member and Owner groups specifically for the site.
When we come to create a subsite of site a called site 1, we get the same options for using parent permissions or unique permissions. If we use the parent permissions, we get whatever we set for the parent site – if we used the permissions for Teams in site a then site 1 will also have Teams owners as owner and so on. If we select to use unique permissions for site 1, we can create 1 Owners etc, or we can use a owners, or even Teams owners. A site can access all the groups in the parent sites above it.
This is quite a major departure from the way that normal file system permissions work. It’s also quite difficult to explain. I hope this post helps you if you need to understand this, or explain to someone else.
With any luck you didn’t need to read 800 words – the diagram explained it for you.