SharePoint 2010 Permissions

SharePoint Permissions Overview

Users within SharePoint are granted permissions to objects such as Sites, Lists, Folders and List Items. The permission that the user receives can be granted in many ways such as directly against the user account, against a SharePoint Group that the user happens to be a member of, or by Active Directory Group. Active Directory Groups can also be nested within a SharePoint group. There are many circumstances that can affect a user’s permissions to a particular object which may not be obvious to you when trying to establish what permissions a user really has.

There are many different permissions that people can receive to a particular object. These permissions are split into three categories:

• · Site
• · List
• · Personal

The Site permissions effect what you can do with the Site itself and include permissions such as: Manage Web Site, Apply Themes and Borders, and Create Subsites. List permissions effect what you can do with a list and include that of: Add Items, Edit Items, and Delete Items. Personal permissions control the ability to create personal views, Add personal web parts, or update personal web parts.

In total there are around 12 List Permissions, 18 Site Permissions and 3 Personal Permissions. To make your life easier, permission levels exist that already contain many of these permissions. For example, the Contribute Permission Level includes the ability to Add items and Edit Items amongst many others. Therefore you do not usually have to be concerned with granting individual permissions to each SharePoint user. Permission Levels that exist Out-of-the-Box include:

• · Full Control
• · Design
• · Contribute
• · Read
• · Limited Access
• · View Only
• · Approve
• · Manage Hierarchy
• · Restricted Read

Note: These permissions levels are explained in detail later on within this whitepaper.

As well as the Out-of-the-Box permissions levels, you will find that you can also create your own custom permission levels. For example, you may want a permission level somewhere between Read and Contribute that perhaps doesn’t offer permissions such as Delete Items or Manage Personal Views.

You can probably imagine how difficult it would be to keep track of hundreds of individuals who are granted different permission levels. Therefore there is a more logical way to organize users into groups, and then assign the permissions to the groups instead of against a user directly. Your organization may make use of Active Directory Groups that already exist, as well as making use of SharePoint Groups.

To summarize, the below diagram details how permissions may be granted to users within your SharePoint Sites. Permissions may be assigned to Users or Domain Groups via a SharePoint Group or they can be assigned a permission level directly.

 

Figure 1 – The diagram shows how permissions are assigned to users either directly or via SharePoint Groups.

Throughout your Site Collection, each object will have an Access Control List (ACL). The ACL contains the assignment of Permissions to each account for the object. When a new object such as a sub site, list, folder or list item is created, its ACL is inherited from the parent object. Therefore, a user who has contribute permissions to a site, will be granted permissions to each list, folder and list item within the site unless permissions inheritance is broken. The below diagram shows how permissions are inherited and where permission inheritance may be broken.

 

Figure 2 – An example Site Collection showing how objects within a site collection can have broken or inherited permissions

Throughout this whitepaper, you will learn how to create and manage SharePoint Groups as well as Permission Levels, Manage Permission Inheritance and understand the permission reports.

SharePoint Groups

SharePoint Groups act as a method of containing a number of users or domain groups as a single entity. As a single entity, permissions can be assigned to the group against objects such as Team Sites, Libraries, Lists and List Items. Assigning permissions to a single entity rather than multiple user accounts or domain groups makes management of permissions easier. Users can be added or removed from the group(s) which will immediately affect the permission that they were granted.

During the provisioning of a new Team Site, you will be able to click the ‘More Options’ button and choose whether permissions are inherited or not from the parent site. If you select the radio button to allow unique permissions, you will have the opportunity to create up-to three new SharePoint groups which will be scoped at the newly provisioned site. If you select to inherit permissions, you will inherit the groups from the parent site.

Figure 3 – Permission inheritance options when creating a new team site

Three groups can be created:

1.     1. Owners of this Site

2.     2. Members of this Site

3.     3. Visitors to this Site

The owners group is granted Full Control permissions by default, the Members group will be assigned Contribute Permissions and the Visitors Group should you opt to create it will be assigned Read permissions. By default, the account that you are signed in as will become a member of the Owners and Members groups. However, at this stage you have the ability to change the memberships of these groups.

Figure 4 – Default SharePoint Groups.

Within the next section, we will explore the default SharePoint Groups and how you manage the memberships of them.

Default Groups

There are three default groups when you first create a sub site (sub web) from a parent site if you have opted for unique permissions. Each group by default is named with a the Team Site name as the prefix followed by Owners, Members and Visitors. As described above, the Owners site is granted Full Control, Members is assigned Contributors and Visitors is assigned Read permissions. You can change the permission level that these groups are assigned, but that will get confusing the larger your environment gets.

Figure 5 – Default SharePoint Groups.

There is a More… link on the same People and Groups – Permission Members page that will show other groups defined within the current site collection. By clicking that more link you will be presented with the other groups and for some will also be able to see at which site they are scoped at. This screen is often confusing as it is not clear which of these groups will only affect this particular site. By changing other groups members, you will be changing the members permissions not just to this site but to other objects as well.

Figure 6 – Site Collection Groups list

Custom Groups

SharePoint Groups are often better understood if they are named after a role. This way you can apply better business logic when assigning permissions to SharePoint objects. E.g. within a Team Site provisioned for managing a Customer, you may have Sales Executives, Sales Managers, and Accounts. Each of these groups may be assigned a different permission to the team site itself and the objects within the team site. Although typically you would have such groups defined within your Active Directory, it is sometimes the case that you want smaller sets of users within your groups who perhaps work at a particular location or division of the organization.

When you create a new group, you can provide a name and description. Providing a detailed description is advisable so that users know exactly what the purpose of that group is. The Group Owner can manage the members of the group. This is quite a powerful feature as you as a Site Owner can create a group allowing another member to manage it. E.g. It may make more sense for a Sales Manager to manage the Sales Executives group that it would for the IT Department. It is important to note that you can only add one person as the group owner. In some circumstances, it would make sense to add a Active Directory group as the owner rather than an individual. That way the group can be managed by multiple Sales Managers. Plus if the only Owner leaves the organization, you cannot change the membership easily.

You can also control who can view the group membership. Group Members is the default, but it can be changed to Everyone.

Editing the group members can also be done via other group members if you set Group Members radio button in the ‘Who can edit the membership of the group?’ section.

Depending on the type of group, you may want to enable users to request to join a group in which case the Group Owner can approve the request. You can also allow people to subscribe themselves by allowing Auto-accept requests. You can specify which email address the requests should go to within the properties of the new group.

Figure 7 – Creating a new custom group

Finally, you can set what permissions the group will have to this site. Note that you are controlling the permissions to just this site, and that the group can be used against other objects and therefore be assigned other permissions to those other objects.

Managing Groups

To add new users to your group, choose Site Settings, from the Site Actions menu and the People and Groups. You can then click New, Add Users to add a new user to the group.

Figure 8 – Adding a user or domain group to a SharePoint group

Enter the name of the user that you wish to add, and then click onto the Check Names button or press CTRL+K.

Figure 9 – Adding a user to a group.

Removing a user from a group is also quite simple. You can check the check box against the user that you wish to remove, and then choose Actions, Remove Users from Group.

Figure 10 – Removing a user from a Group.

SharePoint Permission Levels

SharePoint Groups or accounts such as a domain user or domain group can be assigned permissions to a SharePoint object such as a Site, List, Library, Folder or List Item. Permission Levels such as Contribute and Read are made up of individual permissions. Within this section we will explore the Out-of-the-Box permissions levels before exploring how we can create custom permission levels.

Out-of-the-Box Permission Levels

To access the Out-of-the-Box permissions, choose Site Actions, Site Permissions. You will be able to see a list of users/groups that have permission to your team site. Within the Permission Tools ribbon, click Permission Levels to see the existing permission levels.

Figure 11 – Accessing Permission Levels

The Out-of-the-Box permission levels include:

Full Control	User will receive every SharePoint Permission unless the permission has been removed via a Permission Policy. The permission level cannot be modified.
Design	Users with Design Permissions can virtually do everything with the exception of Manage Permissions on the Site, View Web Analytics Data, Create Subsites, Manage Web Site, Create Groups, Enumerate Permissions and Manage Alerts. Users with this permission level can create, edit and delete list items as well as make design changes to the Shared views of the site and lists.
Contribute	Contributers can create, edit, and delete items within lists and libraries. They have the same restrictions as Design plus they cannot manage the look and feel of sites or shared views. They cannot apply themes, styles, or modify pages.
Read	Readers have the same restrictions as Contributers. In addition they cannot Create, Edit or Delete Items. They can only open items to read them. They also do not get any personal permissions and therefore cannot add or remove personal web parts, manage personal views or edit personal user information.
Limited Access	Limited Access provides you enough permissions to navigate to an item that you do have permission to. For example, you may have been granted Read permissions to a Document within a library that had broken permission inheritance. If you did not have permissions granted to you for the site or library that contained the document, you would be granted limited access which allows you to navigate to the document without seeing any other content. Limited Access is often incorrectly reported in the permission reports. E.g. A user may have Full Control to a Site via a Domain Group. They are also granted permissions directly to a document. The user would then be listed as having Limited Access instead of Full Control to the Team Site.
View Only	The same as read but cannot download documents. Can only view them in the browser.
Approve	Very similar to contribute but also has Approve Items permission.
Manage Hierarchy	Virtually the same as Full Control but does not have Design change options such as apply theme. Used by users who are likely to move sites around.
Restricted Read	Can view pages and documents, but cannot view historical versions or user permissions.

Creating Custom Permission Levels

You can change the existing permission levels or create your own permission levels at the root site level in the site collection only. In SharePoint 2007, this could be done at sub site level. It is possible to break permission level inheritance but only through the Object Model but that is beyond the scope of this article. You will find a good explanation here: http://stackoverflow.com/questions/7038444/programatically-break-permission-level-inheritance

Note: I would recommend never changing the existing permission levels as that would be very confusing to users who expect a permission level to behave within a certain way.

The reason for creating a custom permission level will be specific to your needs. It might be that you want for example a permission level that lies somewhere between Read and Contribute. Perhaps you want users to be able to Add and Edit items but not Delete.

You can create a custom permission level in two ways. Firstly, you can create them from scratch and select each permission that you would like the permission level to have. Or you can copy an existing permission level, provide it a new name, and then apply the changes to the new copy.

To create a new permission level from scratch:

1.     1. Ensure that you are a Site Owner with the Manage Permissions role.

2.     2. Click Site Actions, Site Permissions.

3.     3. Click the Permission Levels button

4.     4. Click the Add a Permission Level action button.

5.     5. Provide a Name and Description for your custom permission level.

6.     6. Check the Site, List, and Personal permissions that you wish to grant to the permission level.

7.     7. Click Create.

Figure 12 – Creating a custom permission level from scratch.

To create a custom permission level by copying an existing permission level:

1.     1. Ensure that you are a Site Owner with the Manage Permissions role.

2.     2. Click Site Actions, Site Permissions.

3.     3. Click the Permission Levels button

4.     4. Click on an existing permission level such as Contribute.

5.     5. Scroll to the bottom of the page.

6.     6. Click the Copy Permission Level button.

Figure 13 – Copying a Permission Level.

7. Provide a Name and Description for your custom permission level.

8. Make the desired changes by selecting or deselecting the permissions check boxes.

Assigning Permissions Levels

Permission Levels can be assigned to Users, Local Groups or Domain Groups as well as SharePoint Groups. There are different opinions on what you should do. However, my personal preference is to use add domain groups to SharePoint Groups in order for permissions to be granted rather than assigning domain groups permissions directly. Within your environment, you may find granting permissions directly to Active Directory users or groups works best.

To assign permissions to a SharePoint Group:

1.     1. Choose Site Actions, Site Permissions.

2.     2. Check the box of the group that you would like to modify.

3.     Click the Edit User Permissions button

Figure 14 – Editing permissions for a SharePoint group

3. Check the permission level that you would like to grant to this SharePoint Group.

Figure 15 – Assigning the custom permission level

4. Your SharePoint Group will now have permissions to the Site and anything that inherits permissions from the site such as sub webs or Lists/Libraries.

Assigning permission to Active Directory Groups or Users:

1. Click Site Actions, Site Permissions.
2. Click the Grant Permissions button on the ribbon.
3. Enter or lookup the name of the user or group that you wish to grant permissions to.
4. Select the radio button to Grant Permissions directly.
5. Check the required permission for the user or group.

Figure 16 – Granting permissions to a user or group directly.

SharePoint Permissions

As has already been explained, permission levels are collections of permissions that can be assigned to Users/Groups or SharePoint Groups. It is important to understand not just what each permission level can do in general, but to have an understanding of each permission that can be made available to a permission level.

Permissions are organized into three different categories. We will discuss each permission’s behaviour within the below tables.

Site Permissions

Manage Permissions	Can create and change permissions for users and groups and change permission levels.
View Web Analytics Data	View the analytical reports available through site settings
Create Subsites	Have the ability to create sub sites (webs) or workspaces such as meeting workspaces or document workspaces beneath this site.
Manage Web Site	Can manage the site settings within the site
Add and Customise pages	Add, Remove, Modify pages of the Site using an editor such as SharePoint Designer.
Apply Themes and Borders	Apply a theme to the site
Apply Style Sheets	Apply a CSS style sheet to the site
Create Groups	Create new SharePoint Groups
Browse Directories	Browse the files and folders through SharePoint Designer or WebDav interfaces
Use Self Service Site Creation	Self Service Site Creation can be turned on or off in Central Administration and allows users to be able to create their own Site Collections
View Pages	Can view the pages within the site
Enumerate Permissions	Can view the permissions reports against the site/lists and libraries/items and documents
Manage Alerts	Can Manage Alerts for users within the site.
Use Remote Interfaces	Access the site programmatically through the object model/web services.
Use Client Integration Features	Use integrations features through Microsoft Office which are launched through SharePoint. Without this permissions, users will need to upload documents.
Open	Allows users to open a Web site, list, or folder in order to access items inside that container.
Edit Personal User Information	Allows a user to change his or her own user information, such as adding picture.

List Permissions

Manage Lists	Can create/Delete lists. Add remove columns within a list and access most settings on the List settings page
Override Check Out	If someone has a document checked out, you can override the checkout although their changes will be discarded.
Add Items	Can add items to a list
Edit Items	Can edit items in a list including pages in a pages library
Delete Items	Can delete items
View Items	Can view items in lists and documents
Approve Items	Can approve a minor version of a document or list item
Open Items	View the source of documents
View Versions	View previous versions of a list item or document
Delete Versions	Can delete previous versions
Create Alerts	Can create alerts
View Application Pages	Can view other aspx pages such as View Forms, Views, and enumerate lists.

Personal Permissions

Manage Personal Views	Sites are made up of Shared and Personal Views. With this permission you can create, edit and delete your personal views
Add/Remove Personal Web Parts	You can add, configure and remove web parts on personal web part pages
Update Personal Web Parts	Can set personal properties on Web Parts that affect only you.

Check Permissions

The permission reports within SharePoint 2010 can be very confusing especially when you consider that there are users who inherit permissions and also when Active Directory groups are used to assign permissions to people directly or through SharePoint Groups. Quite often for example, you will see users listed as having ‘Limited Access’ when in fact their level of permission is much higher. The reason for this is that when running a permission report, you cannot see users that have permissions via Active Directory groups. You can only see that the group itself has permission. If a user of that Active Directory Group is assigned permissions uniquely to an object such as a Library, Folder or List item, they will be granted Limited Access to the site. Limited Access is therefore what will be reported in the permission report. To verify these permissions you can use the Check Permissions option.

Take for example Dmitry below who is reported as having ‘Limited Access’

Figure 17 – Permission report showing Limited Access for user: Dmitry

If we check the permissions for Dmitry, we will see that his permissions to the site are actually higher than what is reported:

Figure 18 – Running Check Permissions against the user account ‘Dmitry’.

We can see clearly that Dmitry has Contribute permissions to the team site through a group called Developers. This is still difficult to work out or double check since you cannot see Dmitry is a member of the Developers domain group without checking Active Directory.

NOTE: This is a problem that is resolved using our DeliverPoint Permissions Management tool which can be seen below:

Figure 19 – Using DeliverPoint to check Permissions you can see the correct permission reporting and enumerate Active Directory groups.

Permission Inheritance

As already mentioned at the start of this article. Almost every object in SharePoint can inherit or have unique permissions. The default when you create a new subsite is for the site to inherit permissions from the parent subsite. All of the Lists and Libraries within that site will also inherit permissions from their parent which would be the site itself. Likewise as you begin to create folders, list items and documents, they will also inherit permissions from their parent container. Nested folders will also inherit permissions from the folder that contains it. Permissions can be broken at any level. When you break the permission inheritance, a copy is made of the permissions from the parent but can now be changed. Therefore you can grant new permissions without affecting the parent. A common mistake is to think that the groups are now independent. If you add a user to a group within an object that has broken permission inheritance, the object will be affected as the new user will gain permissions to it, but the scope of the group will be defined at a higher level and therefore the user will also receive permissions to other object that have permissions granted to that group.

To break permission inheritance within a site:

1. Choose Site Settings, Site Permissions
2. Click the Stop Inheriting Permissions button on the Permission Tools ribbon.

Figure 20 – Breaking permission inheritance at Site Level.

3. The button will toggle allowing you to re-inherit permissions.

To break permissions within a Library or List:

1. Navigate to the List or Library
2. Click List under List Tools
3. Click the List Permissions button on the ribbon
4. Click Stop inheriting Permissions.
To break permissions within a list item or folder:
1. Navigate to the list or library containing the list item or folder.
2. Hover the mouse over the Title of the list item/document or folder.
3. Click Stop Inheriting Permissions.

Understanding where you have inherited or broken permission inheritance is difficult without a third party tool such as DeliverPoint.

 

SharePoint 2010 Menu IDs

I have found this interesting article about sharepoint 2010 menu hiding.

Menus in 2010? Isn't there a ribbon now?

SharePoint 2010 has ribbons everywhere… except for the Picture libraries and Surveys. Those two lists seem to have been overlooked in the upgrade process. Also the Site Actions button and the Welcome button still display menus and use the same techniques as commonly documented for SharePoint 2007 to hide, show and manipulate these menus.
If you are writing client side JavaScript code to interact with the SharePoint menus you will need to know the IDs of the <ie:menuitem> tags. Below are several tables with some of the IDs used by menu items. Remember that in the SharePoint page these will include a prefix that might look like "zz22_" or “ct100_”.
If the ID you need is not listed in the tables below then view the source of your SharePoint page and search for the name of the menu item (“Edit Page”) or the text "ie:menuitem" until you find the one you need.
 
You would then find the menu item using JavaScript or jQuery routines such as the examples below. Add the code to a single page using a Content Editor Web Part or SharePoint Designer, or add the code to the master page to impact all pages in the site.

JavaScript:

<script type="text/javascript">
 var doc = document.getElementsByTagName('ie:menuitem'); 
 for (var i = 0; i < doc.length; i++)
  {
    itm = doc[i];
    if (itm.id.match('OpenInExplorer') != null)
      {
        itm.hidden=true;
        break; 
      }
  } 
</script>

jQuery:

$('ie\\:menuitem[id*=OpenInExplorer]').attr("hidden","true")

The is a list of items created in a typical Team Site home page (v4.master) for the Site Actions and Welcome menus:

Menu ID name	Menu	Menu text
ID_ersonalInformation	The Welcome menu	My Settings
ID_LoginAsDifferentUser	The Welcome menu	Sign in as Different User
ID_RequestAccess	The Welcome menu	Request Access
ID_Logout	The Welcome menu	Sign Out
MenuIItem_EditPage	Site Actions	Edit Page
MenuItem_TakeOffline	Site Actions	Sync to SharePoint Workspace
MenuItem_CreatePage	Site Actions	New Page
MenuItem_CreateDocLib	Site Actions	New Document Library
MenuItem_CreateSite	Site Actions	New Site
MenuItem_Create	Site Actions	More Options…
MenuItem_ViewAllSiteContents	Site Actions	View All Site Content
MenuItem_EditSite	Site Actions	Edit in SharePoint Designer
MenuItem_SitePermissions	Site Actions	Site Permissions
MenuItem_Settings	Site Actions	Site Settings

This is a list of menu items created by a picture library view page:
(all of the above table plus the following)

Menu ID name	Menu	Menu text
NewFolder	New	New Folder
_Upload (1)	Upload	Upload Document
MultipleUpload	Upload	Upload Multiple Pictures
EditPictures	Actions	Edit
DeletePictures	Actions	Delete
DownloadPictures	Actions	Download
SendPictures	Actions	Send To
ViewSlideShow	Actions	View Slide Show
OpenInExplorer	Actions	Open with Windows Explorer
OfflineButton	Actions	Connect to Outlook
TakeOfflineToClient	Actions	Sync To Computer
ViewRSS	Actions	View RSS Feed
SubscribeButton	Actions	Alert Me
AddColumn	Settings	Create Column
AddView	Settings	Create View
ListSettingsMenu_t	Settings	Settings
ModifyView	View	Modify this view
CreateView	View	Create view

(1) Prefix the keyword "Upload" with the underline to not confuse with "MultipleUpload"

Mike Smith's Tech Training Notes: SharePoint 2010 Menu IDs

Four Levels of Branding

I want to open up the branding process of a SharePoint 2010 site from a designers perspective. Let’s face it, branding is expensive. Branding takes hours of hard work and with a product like SharePoint, frustration is constantly in the air. I present the idea of using the 80/20, or Pareto Principle on branding the SharePoint.

When branding a site, the most important aspect for the client is that the audience or the end users recognize the brand. Eighty percent of the visitors will be satisfied by using 20% your time when branding the site. To satisfy the remaining 20%, it would require 80% of your time. Usually that is not beneficial for your client, your client’s client and yourself. I have divided the SharePoint branding experience to four levels that will help you on your work estimates. Instead of going thoroughly through how the branding on each of these levels is done, I’m just presenting the basics of the concept here:

Four Levels of Branding - The line should be drawn between System Master and Ribbon

Level One: Logo & Theme

The first step in branding, is of course the logo, typography and color scheme. Uploading the logo, using themable or alternative CSS it’s a maximum of a few days task. Looks terrible but works on intranets and extranets.

Level Two: Modifying the Site Master Page

This is the level where you should usually stop and say: game over. This will satisfy the aforementioned 80% of the visitors. Here you modify or create a site from a mininal master page, use your own styles and override some of the core styles. Style a consistent look for web parts and page layouts and your’re all set. Usually this is a weeks job, depending on the complexity of the page layouts.

Level Three: The System Master

With SharePoint 2010 it’s trivial to use the Site Master as a System Master but the easy part ends there. There is a tonne of new styles to re-brand and you will be moving pixels back and forth a lot. This is where the project starts to fail as this is the first step to re-branding the SharePoint UI. Let your client know that the risk starts here. With work estimates, we’re talking anything from one week to four weeks here and the outcome? A few people in the client’s public relations department will be happy.

Level Four: Customizing the Ribbon & UI

Don’t go there. This is the Ultimate no-no. It’s okay to add or remove features in the Ribbon but if you choose to revamp the whole UI to your branding, you’ve lost it. There’s no way of coming back once you take this step. You will be bombarded with bugs and requests for making yet another button thats visible only on full moon to obey the brand. At this point you may ask yourself; what is the brand and what should it cover? Has the product that you’re using to satisfy your clients demand become your clients product?

“If you change everything, it is harder for end users to follow general SharePoint guides and instructions.”

Work estimate? Somewhere between one month and eternity.

 

SharePoint Security and Permission System Overview

SharePoint Permission and Security Mechanisms

From time to time, our customers ask us about how SharePoint security and permission features work, and how should they be utilized. In this post we try to walk through the basic permission and security features of SharePoint. This post is not intended to be a complete description of every security and permission related feature in SharePoint, but we try to gather all the essential pieces here. We took many screenshots to illustrate what each setting or feature means in practice, enjoy the ride, !

Additional Resources:

• Basics: What are permissions?

Farm Administrators

Farm Administrators group is a group that is managed centrally via SharePoint Central Administration web-site:

Farm Administrators include by default SharePoint Farm -account, SharePoint installation account and BUILTIN\Administrators group. Farm Administrators have basically “all rights” in SharePoint Farm (or at least they have the ability to get them).

You can give Farm Administration rights to AD groups and AD users:

Additional Resources:

• Choose administrators and owners for the administration hierarchy (SharePoint Server 2010)

Authentication Providers

With authentication providers you can control how you would like to have your users authenticated in a web application. You can also enable/disable anonymous access and client integration and control client object model permission requirements among others:

Additional Resources:

• Plan authentication methods (SharePoint Server 2010)

Web Application Level Permission Policies

With web application level permission policies you can control centrally, with Central Administration, what kind of permission policies you want to apply to all site collections and sites under specific web application. By default SharePoint gives us four predefined policies:

Our recommendation is that you should not edit the default policies, but instead go ahead and create a new policies, if the out of the box policies are not what you are looking for. Policies itself do not grant any permissions unless you attach users or groups to that policy. Policies are just a definitions what the user who has granted the policy can do in the entire web application. With web application policies you can either Grant or Deny the permission.

Here is an example of adding a new web application level permission policy:

Additional Resources:

• Manage permission policies for a Web application (SharePoint Server 2010)

Web Application Level User Policies

User Policy is the place where the magic happens in a web application level. User policy is basically a AD user or AD group mapping to certain Web Application Level Permission policy. You can even define a Zone in which the policy is applied. For example you can use different policy for users who use the SharePoint sites from your internal network (intranet zone), and different policy for those who access the sites through public internet (internet zone), or just apply to “All Zones”. User policies are especially useful for service accounts and in development/integration environments where you probably recreate site collections often (maybe with TFS autobuild scripts).

Here is a screenshot of applying Manage Content -policy to Content Editors AD group:

Additional Resources:

• Manage permissions for a Web application (SharePoint Server 2010)

Web Application Level Anonymous Policy

You can also define web application level anonymous users’ policy through Central Administration -site (but you can only select the policy from a three predefined policies):

Additional Resources:

• Manage permissions for a Web application (SharePoint Server 2010)

Web Application Level User Permissions

This is just a checkbox list from where you can manage what kind of permission levels can be used in a web application and site collections (by default all check boxes are checked, and in general we rarely need to modify the selections):

Site Collection Administrators

Site Collection Administrators have full control of a specific SharePoint site collection. You can only use AD users (not AD groups, at least with the UI) as site collection administrators (We don’t actually know why it is like that, do you?). With Central Administration site, you can define two users as site collection administrators, but in site collection settings you can add more site collection administrators. Here is a screenshot of Central Administration site collection administrators settings page:

Additional Resources:

• Add or remove site collection administrators (SharePoint Server 2010)
• Choose administrators and owners for the administration hierarchy (SharePoint Server 2010)
• Permissions for site collection administrators

Anonymous Access Permissions

You can control what parts of your site the Anonymous users can access with Anonymous Access Setting:

Anonymous access can further be restricted by enabling View Form Pages Lock Down -feature. Our advice is to enable this feature in every public SharePoint site. More about this feature and some other anonymous access suggestions, please consult the following article:

• Plan security for an external anonymous access environment (Office SharePoint Server)

Site Collection Level Permission Levels

Like in Web Application level permission policies, these are the actual permissions that SharePoint will check when user accesses resources in a SharePoint site. This time we have Grant only abilities (in Web Application Level Permission Policies you could use Grant and Deny). In itself permission levels are only definitions that group the more fine grained permissions together in a more useful entity.

By Default SharePoint has these permission levels defined in site collections (levels can be a little bit different depending on what features have been enabled in a site collection):

You can also define your own permission levels, if predefined levels do not match the requirements. As a general principle, it’s not a good idea to modify predefined permission levels (it will only cause confusion). Own permission levels can be created in similar fashion as web application level permission policies:

Additional Resources:

• User permissions and permission levels (SharePoint Server 2010)
• Determine permission levels and groups (SharePoint Server 2010)
• Edit, create, and delete permission levels
• Download a chart of default groups and permission levels

SharePoint Groups

SharePoint groups are a little bit like AD groups, but these groups are managed in SharePoint instead of Active Directory. SharePoint groups can be used to delegate rights management for the site owners instead of system administrators. Whether this is a good thing or not… well it depends on what you want to archive. SharePoint groups are global to the whole site collection. You cannot specify SharePoint group that exists only in a (sub-)site level. SharePoint groups cannot be used over the site collections. One thing SharePoint groups do support that AD groups do not, is membership requests. You can control SharePoint groups’ permission levels whenever you want to use that group. Basically SharePoint group is just a collection of AD groups and AD users with attached permission level(s). While permission level can change for the group the members are globally defined (site collection wide).

Here is a small clipping of Group creation settings (not all settings are visible, but you get an idea):

SharePoint Groups do no directly give any rights to ad users or ad groups (unless you use some predefined group that already has for example site level permissions attached to it). You have to use that group somewhere. Next we walk through all the places where you can use SharePoint Groups, AD Groups and AD users to actually give the permissions.

Additional Resources:

• Determine permission levels and groups (SharePoint Server 2010)
• Manage membership of security group
• About security groups
• Download a chart of default groups and permission levels

Site Permissions

Site permissions is where all the permission management begins. More specifically the root site permissions (root site is the top site in a site collection). These are the permissions that all sub-items (sub-sites, libraries and lists, folders and document sets, documents and items) will inherit. That’s why it is important to carefully design the site permissions as the whole site will use these by default (unless the inheritance chain is broken). Our advice is to try to find some general permissions so that you do no need to break inheritance chain too often.

When you grant site permissions you can use AD groups, AD users and SharePoint groups. You can either add users to some of SharePoint groups or grant the permissions directly (aka attach permission level to user or group). I’m not sure why Microsoft recommends granting permissions though SharePoint Groups, because in many cases it makes a little sense. Probably because of in-built functionality that is attached to SharePoint groups or that when using SharePoint groups, you are able to move your site more easily to different domain (for example from development to cloud service, BPOS anyone?). Our advice is that go with SharePoint groups or grant directly, but try not to overuse SharePoint Groups as it only causes confusion in the end.

Here is a screenshot of SharePoint site level permission granting screen (this exact same functionality is also used in other levels described below):

Each sub site can break the permissions inheritance chain and specify their own permissions, just like you specify them in a root site.

Additional Resources:

• Plan site permissions (SharePoint Server 2010)
• Roadmap: Grant permissions for a site
• About permissions inheritance

Library or List Permissions

Library and List permissions can be managed though list settings. Basically the management works exactly the same as with Site permissions. First you break the inheritance chain and then you start to manage individual list’s or library’s permissions. You can grant rights for AD users, AD groups and SharePoint Groups. By default libraries and lists inherit their permissions from parent site.

With lists and libraries you have also some other security related features.

For example you can control Draft Item Security:

You can also control item/document scheduling, enable audience targeting and content approval (with or without workflows):

Additional Resources:

• Control access for a specific piece of content
• What is uniquely secured content?
• Plan content approval and scheduling

Folder or Document Set Permissions

Like with library and site permissions, folders and document sets can be granted with their own permissions by breaking the permissions inheritance chain.

Document Set and Folder permissions can be accessed from drop-down menu:

Additinal Resources:

• Consult the links provided in Library or List Permissions

Document or Item Permissions

Last level in SharePoint site structure hierarchy is document or item. Document and item permissions can also be granted just like you did with structures above that (folders, libraries, sites…).

You can access document and item level permission settings page directly from the object you are interested in:

Additinal Resources:

• Consult the links provided in Library or List Permissions

Miscellaneous Security and Permission Features

Web Part security settings can be configured at web application level:

SharePoint Designer permissions can be controlled with web application level settings:

See also: Managing SharePoint Designer 2010

Browser File Handling and Web Page Security validation can be controlled at web application level:

See Also: Security Validation and Making Posts to Update Data

You can also control blocked file types list (aka restrict of uploading certain file types):

See Also: Manage blocked file types (SharePoint Server 2010)

Self-Service Site Creation that is basically used for my sites is a way to give users a permission to create a new site collections in certain URL namespaces. This can be controlled through Central Administration -web site and the setting is for a web application:

See Also: Turn on or turn off self-service site creation (SharePoint Server 2010)

With SharePoint auditing features you can gather logs and get reports on what the users have been doing on the site collection:

This is a little bit unrelated to security, but as a note, SharePoint has also a two level recycle bin:

See also: Plan to protect content by using recycle bins and versioning (SharePoint Server 2010)

What Was Not Covered in This Article

There is also Windows Rights Managements Services integration in SharePoint… let’s discuss about that in a separate article, or give us a link to some article that discusses SharePoint/RMS integration! We could also talk a little bit about SharePoint managed accounts, but those are more of a infrastructure side. And what about security settings that some of SharePoint services contain? As you can see, SharePoint is a very flexible platform in these kind of things, but this flexibility comes with a price. That price is complexity. Hopefully this article clears some of that.

What we also didn’t discuss that are somewhat related to security are for example:

• Quotas and Locks
• Service Application specific security settings
• Code Access Security
• Zones
• Personalized Web Part Zones
• Claim Based Authentication
• SharePoint User Profile Service
• Microsoft Forefront Thread Management Gateway 2010
• Microsoft Forefront Unified Access Gateway 2010
• SharePoint Secure Store Service
  • Plan the Secure Store Service (SharePoint Server 2010)
  • Configure the Secure Store Service (SharePoint Server 2010)
• Trust Relationships between farms
  • Exchange trust certificates between farms (SharePoint Server 2010)
• Sandboxed Solutions
  • Developing, Deploying, and Monitoring Sandboxed Solutions in SharePoint 2010
  • Sandboxed Solutions
• Anything else? Give us feedback?

Whether to use AD Groups or SharePoint Groups as a Main Mechanism to Grant Rights?

Well, Everything starts from Active Directory. If Active Directory is a mess, it should be fixed before designing how to manage rights in SharePoint. If Active Directory is well maintained it also benefits the other applications that integrate to AD (for example normal file sharing and NTFS permissions, or systems like Microsoft CRM).

Use SharePoint groups sparingly. Try to utilize the predefined SharePoint groups that are created in SharePoint sites, if possible. Think twice before defining new Web Application policies or Site Collection Permission Levels, and create new ones only if there isn’t better way around it.

SharePoint List Query performance gotcha

There is BIG difference between calling SPList.GetItemById() and SPList.Items.GetItemById(). The latter causes all items to be loaded into memory and then filtered. This can cause severe performance issues for lists with large number of items.
Below is the code that takes 5 hours to run on a dual core box when run against a list with 5500 items.

   1:  SPList theList = GetList();

   2:   

   3:  List<int> itemIds = new List<int>(); 

   4:   

   5:  foreach(SPListItem item in theList.Items)  

   6:  { 

   7:   itemIds.Add(item.ID);

   8:  }

   9:   

  10:  foreach(int itemId in itemIds) 

  11:  {

  12:   

  13:    SPListItem theItem =  theList.Items.GetItemById(itemId); //this will cause severe performance issues for large lists

  14:   

  15:  }

To fix this issue we need to change the code in line 13 to:

  13:  SPListItem theItem =  theList.GetItemById(itemId);

Now the above code will run in minutes.

So while doing programing for list object, avoid using SPList.Items.GetItemById() method.