Almost every week I welcome a new class at the CPLS where I work. Every week I have to teach people – who thougth they knew sharepoint security – some fundamental knowledge about security. This is a article to try and explain some of the main points.
Sharepoint security can be devided into three basic areas: Groups & Users, Permissions and Securable objects. Groups and users are thought to be straigt foward. Users are present in a database, and can be devided into groups. Groups do not have any permissions. Permissions are then set in access list at each securable object. A securable object is basicly list item, list, library, site or site collection.
- Groups are “global” (site collection)
Microsoft have made it easy for us to find to People and Groups from every sites administration section. This is a bit confusing since it’s easy to belive that the groups are defined for each site, however when creating a group its always created in the site collection. A group name is therefore also global “Owner” is not a good name, it does not describe what that person ownes and where – “Global Finances Site Owner” would be a better name. If you are used to WSS 2.0 there were something called Site Groups which were groups on the site level – this feature is NOT availiable in WSS 3.0.
- Group membership do not change on site level
If you are member of the Approvers group you are a member of the approvers group everywhere in the site collection. The actual site permissions may vary, but you are always member of the Approvers group. I think the above mentioned link adds to this confusion. I think that if you where member of the Approver group that you would have Approver rights in the whole portal; so even if groups are named “Global Finances Invoice Approver” and is used mainly on the Global Finances site it’s still global.
- Groups are not the same as permissions
When you are the member of a group, no permissions is actualy assigned by the group membership. Most standard groups have default permission set. Permissions are set at the securable object level. This is made worse I think by the default groups in sharepoint as Approver: this falsely gives you the impression that if you are a member of that group you will get a specific permission; I will admit that in standard configuration this is true but not practical. What is that person to Approve? Perhaps you would create a “Global Finances News Approver” group which would be assigned the Approve permission level on the Global Finances site – but not a right to globaly approve everything.
- Access list and inheritence
By default access lists are inherited to subordinate securable objects (except when a web application policy overrides). Groups are global, so they are not “inherited”. When breaking the inheritance a copy is created of the access list; this cannot be partly inherited – either broken inheritance or not! Permission levels are also inherited, and still inherited even if we break the access list inheritance. To break the permission level inheritance that also must be broken – almost never needed. You are always free to restore inheritance – when you do: ALL subordinate permissions and access lists are also reset to inherit!
- Some accounts are special
There is some accounts who get access even though they are not in the access lists. This is true for the Primary and Secondary site collection administration accounts. This is setup elsewhere. Members of the built in Administrators group also have access for instance.
I hope this clears up some aspects of Sharepoint security administration.
More detailed information can be found at Office Online