Permissions Management in SharePoint 2013

Overview

When talking about security, we can identify two major steps in every system: authentication and authorization.

• Authentication is the process when the system identifies me, gets answer to the question “Who are you?”, and verifies if you really are who you say you are.
• Authorization is the process of verifying what you can see or do, or in other words —“you are permitted to do what you are trying to do.” Authorization always presupposes successful authentication.

As SharePoint does role based on access control, the next thing to be aware of and understand is the role assignment. Role assignment has three main components in SharePoint:

• User or Group – the person or group of persons who gets the role.
• Security Scope – the subject
• Permission Level – the level of permission(s) the user or group is assigned to the subject.

Let me show you some examples:

• “Jeff needs to edit this document.”
  • User: Jeff
  • Security Scope: this document
  • Permission Level: edit
• “Chris has to change the settings of this list.”
  • User: Chris
  • Security Scope: this list
  • Permission Level: change the settings (admin)
• “HR and Marketing have to be able to read everything on this site.”
  • Groups: HR, Marketing
  • Security Scope: this site
  • Permission Level: read
• “Why Gary can see these files in ‘Search’?!”
  • User: Gary
  • Security Scope: these files
  • Permission Level: read

SharePoint Role Assignment

In SharePoint, there are several levels of available security scopes. These levels are organized into a well-defined hierarchy; therefore, we have a very clear inheritance — by default, all the permission settings are inherited from the parent level to its children.

These levels are:

• Site
• List/Library
• Folder
• Item/Document

It’s also worth noting that we have permission inheritance by the site hierarchy as well, by default; every site inherits the role assignment from its parent.

In this case, using the default settings, every list and document library inherits the role assignments from the site (and the site inherits from its parent site), as well as the folders, subfolders and items inside. These settings can be, for example:

• Group Marketing has contribution (read or write) access to everything;
• Group Sales has read access to everything;
• Jeff, Joe and Jim have contribution access to everything (regardless of their group membership).

If you use the default settings (inheritance) on each level, these groups will have read (Marketing) and contribution (HR) access to every list and library, every folder and subfolder, every item and document. For example, if you have a document library “Campaigns” with a folder for each year (2013, 2012 etc.), the Marketing group, Jeff, Joe, and Jim can add new documents, open and edit the existing ones, while the members of the Sales group will be able to read these documents but not modify them.

But of course, you can break this inheritance by defining custom role assignment, on any level. In this case, you have the default role assignment on the site level (either set on this site or inherited from its parent site), but it’s not inherited to, and below the folder where you create the custom role assignment.

For example, let’s say we have the very same role assignment on site level:

• Group Marketing has contribution (read or write) access to everything;
• Group Sales has read access to everything;
• Jeff, Joe and Jim have contribution access to everything (regardless of their group membership).

But you have a specific folder in the document library “Campaigns” for the current year (2014) where you want the group ‘Sales’ to have contribution access as they might have to add or modify the current documents. In this case, you have to break the permission inheritance. The default role assignment after this will be identical with the current settings, but you can change it according to your needs:

• Group Marketing has contribution (read or write) access to everything;
• Group Sales has contribution (read or write) access to everything;
• Jeff, Joe and Jim have contribution access to everything (regardless of their group membership).

Of course, you can do this on any level. On one hand, this is good as you can have as custom and complex permission settings on your content as you want. On the other hand, it’s a very big challenge and might be a huge risk due to its complexity.

Note: In SharePoint 2013 and Office 365, it’s very simple to share documents or even folders, lists and libraries with your colleagues. This makes the end users’ lives much easier, but can be a real challenge for the administrators.

SharePoint Groups vs. Active Directory Groups

A small side note on the groups.
As you likely know, you can create groups in SharePoint, and sometimes, this might lead to confusion. When your SharePoint farm is domain integrated and AD authenticated, you have AD groups as well. The similarities of AD and SharePoint groups might be confusing, as well as the differences. Let me clarify some points here:

• AD groups can contain (AD) users, of course, but they can also be organized into hierarchy: every AD group can contain other AD group(s). They are always managed outside of the scope of SharePoint; domain admins have the responsibility to add, remove or modify groups and manage the memberships.
• With SharePoint groups, the picture is a bit different. SharePoint groups can contain (AD) users and AD groups. There’s no hierarchy of SharePoint groups – a SP group cannot contain any other SP group. It’s a big limitation. But on the other hand, SharePoint groups are administered inside SharePoint; therefore you don’t need to contact the domain administrators for every single change like group membership changes.

Permission Levels

When working with role assignments, Permission Levels are the next thing we have to understand. The most commonly used and known are ‘Read’, ‘Contribute’ and ‘Full Control’ in SharePoint, but there are many more. Outside the box, we get the following Permission Levels:

For the full reference of these levels, please refer to this TechNet article: User permissions and permission levels in SharePoint 2013

Each of these permission levels is a combination of elemental permissions. These elemental permissions can be organized into three groups:

• List Permissions
• Site Permissions
• Personal Permissions

For example, the Contribute Permission Level consists the following:

1. List Permissions:

• Add Items
• Edit Items
• Delete Items
• View Items
• Open Items
• View Versions
• Delete Versions
• Create Alerts
• View Application Pages

2. Site Permissions:

• Browse Directories
• Use Self-Service Site Creation
• View Pages
• Browse User Information
• Use Remote Interfaces
• Use Client Integration Features
• Open
• Edit Personal User Information

3. Personal Permissions

• Manage Personal Views
• Add or Remove Personal Web parts
• Update Personal Web Parts

Besides using these OOTB levels, you can create your custom levels too. For example, you might have a requirement for a permission level that has the basic Contribute permissions except ‘Delete’. It is used very often at customers who have specific policies for version management and item deletion.

Action Plan

As you can see, Permission Management is a complex task in SharePoint, and needs a complex solution supporting:

• User and Group Management
• Role Management
• Checking and consolidating Role Assignments

Except documenting SharePoint farm settings, Documentation Toolkit for SharePoint provides a detailed SharePoint permissions explorer and options to create and export permission reports and this is why it is a very good and useful solution that can be used during a SharePoint permissions management process.

Performance with SharePoint 2010 Large lists – List view throttling

SharePoint 2010 lists and libraries can hold a maximum number of 30,000,000 items. In a SharePoint site the list view threshold is 5000 for users and 20,000 for auditors and administrators.

SharePoint large list and libraries operations like Delete/Update are one of the top performance killers.

What can we do if the server is overloaded when we access large lists and libraries? One solution is list view throttling.

A. List view throttling

List view throttling protects the server from unintentional load by limiting the number of list items returned per view. When the list view is greater than throttle limit, users receive a message that all the data cannot be retrieved.

Resource throttling monitors CPU %, Available Memory, ASP.NET Queue and Wait time in Queue. Every 5 seconds a timer job is checking resources. Throttling will begin after 3 unsuccessful checks. This throttling period will end after one successful check of the resources.

During a period of active throttling, HTTP GET requests and Search Robot requests will generate a 503 error and will be logged in the event viewer and no new timer jobs will begin.

Resource throttling counters can be changed via PowerShell commands. More in this article

Activate List throttling

Remark: Is recommended to configure at the Web Application level

– Go to SharePoint Central Administration

– Click on Application Management, and then click on Manage Web Applications.

– Click on a single web application to select it, then in the ribbon click on the General Settings drop down and select the Resource Throttling menu item

– A new page will open with the following fields:

– List View Threshold – this is the maximum number of items that can be retrieved in one request, all operations that exceed this limit are blocked. The default value is 5,000, the smallest is 2000.

– Object Model Override – this option needs to be enabled in order to enable auditors or administrators to retrieve items through the object model

– List View Threshold for Auditors and Administrators – this is a special limit for “super users”. Allow super users to retrieve up to the number of items set in this property via object model. Object model override needs to be activated. More in this article

– List View Lookup Threshold – This feature limits the number of Lookup, Person/Group, or Workflow Status fields that a query can perform. It should not be greater than 8

– Daily Time Window for Large Queries – this option allows you to create a block of time during the day, typically when usage is low, that you will allow queries to run and not enforce the list throttling limits.

– List Unique Permissions Threshold – This is the maximum number of unique permissions allowed per list or library

– Turn Backward-Compatible Event Handlers on or off. By default, this is off. If you have a large amount of development work in SharePoint Server 2007 that leveraged event handlers for lists or libraries, you will want to turn this on. You should check with your developers if you are upgrading from SharePoint Server 2007.

– Configure HTTP Request Monitoring And Throttling. This changes the setting in IIS for all Web servers in the farm for this Web application. You can turn request throttling off to allow services like search to run uninterrupted on the farm.

– Change Log constraints, do not to reduce this too much because it will negatively affect servers that rely on history information for sites contained in the Web application

– Click on Ok

Before applying list view throttling is recommended to test the functionality in a test environment by performing different stress tests.

B. SharePoint indexed columns

Another important step to improve list performance is indexing SharePoint columns. This option with query throttling strategies can help you to improve the performance of large lists.

You can index up to 20 columns but be aware that not all of the columns types are supported to be indexed. Here you have a complete list.

Activate Indexed columns

Remark: Before applying the following operations be sure you are doing them during the “Daily time Window” if List throttling is active, because creating an index requires accessing all the items in the list.

– Navigate to your SharePoint list and library

– In the ribbon, under List Tools or Library Tools, click the List or Library tab

– In the Settings group, click List Settings or Library Settings.

– Under the Columns section, click Indexed columns.

– On the Indexed Columns page, click Create a new index.

– Do one of the following:

To create a simple index:

– In the Primary Column section, under Primary column for this index, select the column.

– Click Create.

To create a compound index:

– In the Primary Column section, under Primary column for this index, select the column.

– In the Secondary Column section, under Secondary column for this index, select a different column.

– Click Create.

Thank you for reading this article.

Software Boundary Guidance for SharePoint 2013 Gotcha’s (Don't do this)

Recently published on Microsoft TechNet (30 October) were the Software boundaries and limits for SharePoint 2013.  Some noticeable adds are in this guidance so please take the time and familiarize yourself with the changes.  Some of the guidance however did not change and a couple in particular I want to reference due to the fact on pretty much every engagement I go on with a customer these areas are not adhered to and in some cases blown completely out of the water.

List view lookup   threshold	8 join operations per   query	Threshold	Specifies the maximum   number of joins allowed per query, such as those based on lookup,   person/group, or workflow status columns. If the query uses more than eight   joins, the operation is blocked. This does not apply to single item   operations. When using the maximal view via the object model (by not   specifying any view fields), SharePoint will return up to the first eight   lookups.
List view threshold	5,000	Threshold	Specifies the maximum   number of list or library items that a database operation, such as a query,   can process at the same time outside the daily time window set by the   administrator during which queries are unrestricted.

To give an example of what I see customers do:

 Notice where I highlighted. 

These two setting changes will provide you with the opportunity one day to bring your farm to its knees and in most cases will also cause you to pick up the phone and contact Microsoft to open a case.  This is a case that can easily be avoided.. How?   By reading the Software Boundaries and Limits for SharePoint 2013.   We put this guidance out for a reason and the teams aren’t just randomly selecting numbers
out of the air and filling in the charts. We do extensive testing on our products with many different hardware configurations that we expect our customers to run under.  These boundary numbers are areas where we
will see performance degradation occur.  Also notice that some of these are soft boundaries and some are hard.   The Hard boundaries are supportable stop points and should not be exceeded.  The Soft boundaries fall in line with the example above.  This is a throttling limit we set.  You can adjust it if you like but you will face issues down the line.  Depending on your hardware you may not run into it for some time past
the limit.  But I can guarantee you that in some time you will run into an issue here. 

So let’s go through an example of what this customer faced.  The background here is that I was there for a week performing a Microsoft RAP (Risk Assessment Program) and this is one of the test cases that we
run. 

Disable event firing/Working with List Event Receivers

The "List event receivers" are also defined as event handlers for the list. These events are triggered when something gets changed in the SharePoint list items and become very useful when a user wants to access the list item data using events before and after properties to do some important tasks. I thought of writing this blog to share my experience with the process of creating/deleting these list event receivers and also to mention some important points to remember while dealing with them. Some of the different types of event receivers which can be attached to the list are:

• Item Adding: This event occurs when a user is creating a new item in the list.
• Item Added: This event occurs after the user has created a new item in the list.
• Item Updating: This event occurs at the time when the data in the list is the state of modification.
• Item Updated: This event occurs after the data in the list has been modified.
• Item Deleting: This event occurs when the user is in the process of deleting an item in the list.
• Item Deleted: This event occurs after the user has deleted an item in the list.

Adding an Event Receiver

The event receivers contain the event information and the item information on which the event occurred. The event receivers can be attached to the list in the following manner:

list.EventReceivers.Add( SPEventReceiverType, assemblyName, sClassName);

Where the different parameters are:

• List - This is the list to which you want to attach the event receiver.
• SPEventReceiverType - The first parameter would be the type of event receiver you want to attach. In the example above, the event type is ItemAdded.
• assemblyName - This would be the name of the assembly containing the class which overrides the event receiver class of the list, e.g.:

private const string assemblyName = "ListEventReceiver, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3dc9djfae2d341bf";

• sClassName - This variable defines the name of the class which overrides the existing event receiver class( SPItemEventReceiver) methods for the list e.g.

private const string sClassName = "ListEventReceiver.EventReceiver";

Important points to remember in the process of adding an event receiver to the list:

• The assembly should present in the GAC.
• The referenced assembly should have a strong name i.e. sign an assembly before using it.
• Update the list to which you have attached the event receiver using list.Update();

The SPItemEventReceiver base class provides methods for event receivers in the Windows SharePoint Services object model and this class is never instantiated. The overriding methods can disable the firing of some other event while this event handler method is in processing using SPEventReceiverBase.DisableEventFiring (). This method will prevent events from being raised and also the infinite loop.

OR

In detail, I have a list which has an ItemUpdated Event Receiver (Custom one, which developed by the developer). On the event receiver, we are trying to update some of the columns based on the entered column value. i.e., based on Column1, I am calculating the value for the Column2 and update the list item on the Event Receiver. In that case, what happens is, again and again, the Event Receiver triggers as ends up with a bottle neck

  

OR

Normally you disable / enable eventfiring in you ItemUpdated or ItemAdded to prevent recursive calls of the event receiver. So it only prevents events from getting raised in between your code blocks Disabling and Enabling. After ItemUpdated have been finished working the next event receiver regarding the sequence number will be raised.

It's only event receiver internaly and you have to make sure if EvenFiring is diabled that the enabling code will get hit. Otherwise it will disable the event on some items.

Follow the code below to override the event receiver method:

public class EventReceiver : SPItemEventReceiver

 {

    public override void ItemUpdating(SPItemEventProperties properties)

        {

            try

            {

                //Stop other events from firing while this method executes

                this.DisableEventFiring();

                 //Add your code here

            }

            catch (Exception ex)

            { }

             finally

            {  //Re-enable event firing

                this.EnableEventFiring();

            }

          }

    }

When user needs to access the data associated with event receivers, they access it using event receiver properties. The SPItemEventProperties contains the after and before property of an item which can be used to access the item value before/after the change occurred. The event receiver property also contains an important field called ReceiverData which can be used to store the custom data. This data can be used to pass any information which is not present in the properties itself.

The table below shows the values contained in the SPItemEventProperties properties when the specific event occurs for the list:

List	properties.ListItem (Before property value)	Properties.afterProperties
ItemAdding	Null	New Value
ItemAdded	New Value	New Value
ItemUpdating	Old Value	New Value
ItemUpdated	New Value	New Value
ItemDeleting	Old Value	Null
ItemDeleted	Null	Null

In the table above:

• Properties.ListItem values denotes the item value before the event occurred
• AfterProperties denote the values of item after event occurred.

Deleting an Event Receiver

The event receiver can be deleted from the attached list in the following manner:

list.EventReceivers[eventReceiverGuid].Delete();

or

list.EventReceivers[x].Delete();

Where the different parameters are:

• List - This is the list to which you want to attach the event receiver.
• eventReceiverGuid - This denotes the GUID of the specific type of event receiver.
•  x- This i denotes the position of the event receiver in the list of event receivers.

The important points to remember while deleting the event receivers:

• Allow the safe updates on the web using list.ParentWeb.AllowUnsafeUpdates = true;, as it is required to make any deletion to the list.
• Update the list after you delete an event receiver using list.Update();
• Finally in the end make the list.ParentWeb.AllowUnsafeUpdates = false; to prevent any security risks.

Difference Between Sequential Workflow & State machine workflow?

Sequential workflow

A sequential workflow represents a series of steps. The steps are performed one after another until the last activity is completed. Sequential workflows are always strictly sequential in their execution. Because they can receive external events, and include parallel logic flows, the exact order of execution may vary. The following illustration shows an example of a sequential workflow.

The sequential process will look like this: 

State machine workflow

A state machine workflow represents a set of states, transitions, and actions. The steps in a state machine workflow execute asynchronously. This means that they are not necessarily performed one after another, but instead are triggered by actions and states. One state is assigned as the start state, and then, based on an event, a transition is made to another state. The state machine can have a final state that determines the end of the workflow. The following diagram shows an example of a state machine workflow.

The state machine process will be: 

Referenced Links

MSDN Link

https://www.nothingbutsharepoint.com/sites/eusp/Pages/SharePoint-State-machine-or-sequential-workflows-What-is-the-future-of-business-processes.aspx