When Full Control doesn't mean you have Full Control

Quick note on some confusion you may run into when trying to manage permissions in SharePoint 2010: Sometime the permission group 'Full Control' doesn't really mean 'Full Control' in the way you might think.

Remember that Site Collections are security boundaries. You can certainly create libraries or lists or subsite and break the permission inheritance, but you may run into some unexpected issues, either with folks who have access who you think should not (Site Collection Administrators) or folks you think should have rights but do not (Members of the Admins group of a subsite which does not inherit permissions).

Consider this first case:

A site collection administrator creates subsites for different projects and is able to add users to the groups at the root of the site (Members, Visitors) and everything is working as expected. One day, a request comes to make a subsite for a very special project. The project is called "Layoff List", which sounds very ominous to the site collection administrator, but she creates the subsite, wondering what this will be used for. Later, she is asked to change the permissions for this subsite so that only a small group of people -- herself not included -- are able to access the site. Easy enough to do, she thinks, but wonders about the order of operations since she doesn't want to remove her own permissions before she is finished setting up the site.

First step is breaking inheritance, which is really just copying the existing permissions from the parent site collection and preventing any changes from the site collection permissions from changing the subsite. Click, acknowledge warning and done. Now on to the groups. Since the request is only to have a few people access this site, the easiest way appears to be to remove the Sub Site Visitors Group and the Sub Site Members group and manage the permissions with the one remaining group, the Sub Site Owners group. A few more clicks and we're there, with the requested members in the Sub Site Owners Group.

Did this work? Not really. If the expectation was that the only folks who could access the subsite were the accounts or AD groups listed in the Sub Site Owners Group, we've failed here. Because the site collection owner(s) will always have access to the sub site, even if they are not explicitly listed in one of the groups in a subsite which does not inherit permissions. In this case, you would need to create a separate site collection.

Next consider this similar case:

Sub Site with permissions which are not inherited. Site Collection administrator has "full control" as we have noted in the case above. This time the request is to delegate some work to the "owner" of the subsite. So again, we have broken the inheritance as requested and we have the three groups for permissions, Owners, Members and Visitors.

For a good test case -- and it's great when admins have the ability to do this -- the site collection owner makes sure her admin account a site collection administrator so she can use her normal user account for testing.

So using her account as a test case, she adds her account to the Owners group on the sub site and tries to test the functionality that this sub site needs: Her delegate with an account in the sub site owners group can add users to that group as well as the Members and Visitors groups.

Testing with the Owners group works great: Her account can add other accounts to that group. Since the description of the permission group says "Full Control" she figures everything is great and reports to her customer that the sub site is good to go.

Unfortunately, it's not.

Here's the problem: By default, the SharePoint groups are set so that only the owner of the group can add members. And only the members of the group can see the membership of the group. So, for our request here to delegate the job of adding users to groups to a sub site we've failed: The delegate who is in the Owners group -- which shows "Full Control" -- cannot modify the groups in the sub-site.

What's the solution to both these cases? Site collections.

If you have a need for vastly different site permissions, you probably need a separate site collection.