Securing SharePoint 2013: Understanding Authorization and Permissions - Part 2

This post is the fourth in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running but are looking at built-in features and third-party solutions to secure their sensitive information.

---

 

Understanding Security Scopes and their Limits

Understanding SharePoint permissions and using them effectively means you need to understand the concept of "security scopes" and their limits.  When unique permissions are assigned to a container or item, SharePoint creates what is called a security scope. This is an important concept to understand because there are limits to how many security scopes can be created, and there are limits to the size of the security scope before SharePoint performance starts to be adversely affected.

 

Each site collection initially contains one (1) security scope, related to the initial permissions at the site collection level. Each time permission inheritance is broken a new security scope is created. So, in Figure 1 above, the “Demo” site collection has four security scopes: one at the site collection level, another at the site level, another on a library, and a fourth on a document. All other sites, libraries, documents and items in the diagram inherit their permissions and therefore no security scope is created for those levels. The size of the security scope refers to the number of principals in the security scope. Remember, a principle is a user, group or claim. To view another example, refer to Figure 2 below to see how security scopes are created as permission inheritance is broken.

In previous versions of SharePoint, there were various limits documented around how many security scopes a library or list should contain before performance would be adversely affected. These numbers tended to vary depending on the article and there was a lot misunderstanding around them. In SharePoint 2013, each list or library can contain up to 50,000 security scopes before performance begins to be impacted (this change actually came about in SharePoint 2010, Service Pack 1 and the latest cumulative updates, but it has only been documented in SharePoint 2013). This is a significant improvement over previous versions and when you think about it, it’s a very large number to work with. This means that a single library can have up to 50,000 documents or items which each have their own unique permissions. In addition to this, a library can also contain other documents which inherit permissions from the library level (or site or site collection).

 

In order to actually create unique permissions on up to 50,000 documents or items in a library/list, a SharePoint farm administrator must adjust a setting called the “List View Threshold”. Modification of this setting requires these steps:

1.      Log into the SharePoint Central Administration console

2.      Click “Application Management” on the left hand side, then click “Manage Web Applications”

3.      Select the web application you wish to modify

4.      In the ribbon click “General Settings” to activate the menu

5.      In the menu select “Resource Throttling”

6.      Find the “List View Threshold” setting and modify it to the appropriate value (the default is 5000)

If you do plan to modify this setting to support more unique permissions, ensure that your environment is sized appropriately to handle the additional query load. As well, ensure that you test your environment under realistic conditions with this setting in place to ensure that users will not be affected by potential performance issues.

 

Another important limit to understand in SharePoint is the size of the security scope.  The size of a security scope refers to the number of users or groups assigned with unique permissions for a particular scope.  Limits on this size have remained consistent between SharePoint 2010 and SharePoint 2013. Each security scope can contain a maximum of 5000 principles. This means, each time you specify unique permissions on an item or document there can be no more than 5000 users, groups or claims specified. Once again, in reality this is quite a large number to work with.

 

These limits of course depend on the architecture of your SharePoint 2013 farm and the hardware/configuration used. For more information on SharePoint 2013 boundaries and limits please refer to the following Microsoft article:

http://technet.microsoft.com/en-us/library/cc262787.aspx.

Limited Access Permissions

When permission inheritance is broken and unique permissions assigned to a particular item, let’s say a document, SharePoint will automatically create what is called a ‘Limited Access” permission on its parent and all the way up the hierarchy up to the root site collection. The Limited Access permission will contain the same principles (users, groups and claims) as the unique permission assigned, however using the pre-defined Limited Access permission level. The purpose of this Limited Access permission is to give the user just enough permissions to navigate to the item on which they were just granted permissions (even if they did not have access to the folder, library or site previously). This occurs automatically, as part of the process of assigning unique permissions.

 

The challenge with Limited Access permissions is that they never get removed or cleaned up in any automated way. Even if you cause a particular document or item to re-inherit permissions from its parent library, the limited access permissions will remain in place. Therefore, it is important to monitor how many Limited Access permissions are created because this does contribute to the limits discussed in the previous section.

 

The following diagram illustrates how security scopes and Limited Access permissions are created:

 

 

 

Figure 2. SharePoint security scopes are created when permission inheritance is broken.

There has been quite a bit of literature written in recent years about security scopes and their limits, not all of it accurate.  I highly recommend that you review the latest document from Microsoft (link above) on the limits in SharePoint 2013 because that will be the most up to date documentation.

 

   -Antonio

 

Securing SharePoint 2013: Understanding Authorization and Permissions - Part 1

This post is the third in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running but are looking at built-in features and third-party solutions to secure their sensitive information.

---

 

Authorization is an important concept to consider when securing sensitive information in Microsoft SharePoint. Looking at this concept broadly, it’s helpful to understand the differences between authentication and authorization. As mentioned, authentication is the process of determining if a user is who they say they are. Authorization is the process of determining what resources a user can access and what actions can they perform with those resources. Just because a user has access to a system doesn’t necessarily mean they should have complete access to everything within that system.

Within Microsoft SharePoint, authorization is enforced through permissions. With SharePoint 2013 there are some important new changes that are important to understand.

Understanding Permissions
The underlying permissions system within SharePoint 2013 is, in most respects, the same system it has always been. Permissions can be used to secure access to any item or document within SharePoint, as well as any container (folder, list, library, site, site collection).

A permission has 3 components:

§  An information object to which it is assigned (item, document, or container)

§  A principal (user, SharePoint group, AD group, or a claim)

§  A permission level (read, full control, contribute, design or a custom permission level)

Permissions are assigned to items, documents or containers by selecting a user or group and then selecting a permission level. For example, items or containers could have the following permissions assigned to them:

§  User John Smith has Read access to a document

§  AD Group Finance has Full Control access to a library

§  SharePoint Group Project_Team has Contribute access to a Folder

§  User Engineering_Contractor has Contribute access to a site

As an advanced feature, SharePoint 2010 and 2013 allow a permission to contain a “claim” instead of a user or group. As described earlier, a claim is a trusted user attribute that is retrieved when that user logs in. Attributes could include data like the user’s email address, their group memberships, their security clearance, etc.

A permission containing a claim would look like the following:

§  Users with the claim Security_Clearance=Secret have Read access to a document

In this example, when a user logs into SharePoint, if an attribute is retrieved about that user which contains the value Security_Clearance=Secret then the user will be granted Read access to the document. SharePoint needs to be configured for Claims Based Authentication for this to occur.

 
Hierarchical Permission Model
SharePoint 2013 continues to have a hierarchical permission model, which means permissions are organized according to a hierarchy. Permissions are initially assigned by SharePoint at the site collection level. As a result, all sites, libraries, lists, folders and content below that site collection will automatically receive those permissions. The lower level containers or items “inherit” their permissions from the level above if no specific permissions are assigned to that object.

At any level within SharePoint, a user can break permission inheritance and assign specific permissions to that level. For example, a site collection called “Demo” contains a SharePoint group called “Demo Members” which has been assigned with the Read permission. So, any member of the “Demo Members” group will have read permissions to the site collection and anything below it. The “Demo” site collection contains 3 sites, one which breaks permission inheritance so that members of the AD group “Finance_Team” has Edit permissions. As a result, all content below this site (all libraries, folders, content, etc.) will inherit the “Finance_Team” permission from their parent site, unless something below the site also break inheritance.

The following diagram illustrates this point:

Figure 1. SharePoint containers and items with broken permission inheritance.

   -Antonio

Securing SharePoint 2013: Plan for Authentication

This post is the second in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running and are looking at built-in features and third-party solutions to secure their sensitive information.

---

 

Microsoft SharePoint 2013 comes with a variety of authentication options to fit your organization’s requirements. At its most basic level, authentication is the process of determining that a user is who they say they are. This usually occurs at login, and typically with a simple username/password match. So, when a user presents a username and password, SharePoint will then verify that the username/password combination matches what it has in its database. If it does then the user is authenticated.

Considering authentication a little more broadly, authentication can also be seen as the process of validating a user’s identity against an identity provider. Identity providers include Active Directory - Directory Services (AD DS), LDAP directories, or Active Directory Federation Services (AD FS). The use of identity providers becomes important when we look at new methods of authentication like Claims Based Authentication, which is discussed further below.

Within Microsoft SharePoint, the authentication method is configured uniquely for each web application. It’s important to note that authentication is configured when a web application is created through the Central Administration console. However, it cannot be modified through this console after a web application has been configured. To modify the authentication configuration of an existing web application, a SharePoint farm administrator will need to use the appropriate PowerShell commands.

Very similar authentication options are available in Microsoft SharePoint 2013 compared to those that were available in SharePoint 2010. However there are 2 big differences:

1.      When creating a new web application in SharePoint 2013 the default authentication method is now Claims Based Authentication.

2.      The configuration options for Windows Authentication has been removed from the Central Administration console. It can only be done through Windows PowerShell.

The authentication options available in Microsoft SharePoint 2013 are: 

§  Claims-Based Authentication (SAML Token Based)

Microsoft introduced Claims Based Authentication as an option in SharePoint 2010, in part to better support third-party authentication providers and multi-vendor environments that support internet, federated partners, or cloud computing models. Traditional authentication mechanisms did not support these environments well. With claims based authentication, once authenticated a user obtains a digitally signed security token from a commonly trusted identity provider. The token contains a set of attributes about the user—or claims—and each claim represents a specific piece of data about the user such as their name, group membership, role, title, security clearance, or even age. Applications like SharePoint which support claims based authentication receive a security token from a user, as opposed to credentials, which they use to determine user access to resources. This can be accomplished without having to make separate queries to directory services such as Active Directory.

Some of the more traditional Windows domain authentication protocols, such as NTLM and Kerberos, may also be used along with claims-based authentication. When using these protocols in conjunction with claims based authentication, SharePoint 2013 will make an authentication request using the classic protocol and the response (a Windows NT Token) will then be translated to a new SAML token by the SharePoint Security Token Service (STS).

As mentioned, claims based authentication is now the default authentication method within SharePoint 2013 when new web applications are created. This, combined with the fact that classic Windows Authentication has been removed from the Central Administration console and is only configurable through PowerShell, is a significant move by Microsoft. It indicates that Microsoft believes strongly in the power and robustness of claims based authentication and that it is highly recommending claims based authentication moving forward.

§  Forms-Based Authentication

Forms-based authentication validates users that enter their credentials (usually) on a web login form. It is typically used in extranet deployments of SharePoint, where external users need to log in to access SharePoint resources but those users do not have accounts in Active Directory.

Forms-based authentication is enabled through claims-based authentication and the use of a custom ASP.NET membership and role provider. Forms-based authentication can be used against credentials that are stored in various accounts sources including: a database (such as SQL Server), an LDAP directory, or even Active Directory.

§  Classic Windows Authentication

Classic Windows authentication makes use of the classic Windows authentication protocols that are supported by Windows domains to validate user credentials, such as NTLM, Kerberos, Digest Authentication and Basic Authentication. This is sometimes referred to as Integrated Windows Authentication.

Configuring Classic Windows Authentication for a SharePoint 2013 web application requires the use of PowerShell as the configuration interface has been removed from the Central Administration console.

In addition, it’s important to be aware that several caveats exist when continuing to use Classic Windows Authentication with SharePoint 2013 web applications. For example: if migrating a system using Office Web Apps with a SharePoint 2010 web application with classic mode authentication, the SharePoint web application must be migrated to the 2013 claims-based authentication method for it to continue working with Office Web Apps. Viewing and editing with Microsoft Office Web Apps will not work on SharePoint 2013 web applications that use classic mode authentication.

§  Anonymous Authentication

SharePoint 2013 also supports Anonymous Authentication for users who do not need to authenticate any credentials in order to access site resources. Anonymous Authentication is often used for public facing SharePoint sites.

Anonymous Authentication is disabled by default.  It must be enabled on each web application separately by performing the following steps:

1.      In the Central Administration Console select Application Management on the left side and then select Manage Web Applications

2.      Select the web application you are interested in, then select Authentication Providers in the ribbon, select the zone and then check Enable Anonymous Access

3.      Click Anonymous Policy in the ribbon bar

4.      Select a network zone and an Anonymous User policy

Once these steps are complete, site owners or site collection administrators for specific sites still need to enable anonymous access for individual site collections or sites.  Until this is done, no site collections, sites or libraries will be available for Anonymous Access.  This is accomplished through the following steps:

1.      A site collection administrator accesses the site targeted for Anonymous Access

2.      Select Site Settings and then select Site Permissions

3.      In the ribbon select Anonymous Access

4.      Finally select if an anonymous user can view the entire site or simply lists or libraries

For additional detailed information on the authentication options available in Microsoft SharePoint 2013, please visit the following Microsoft TechNet article:

http://technet.microsoft.com/en-us/library/cc262350.aspx.

   -Antonio

A First Experience with Microsoft Office 365 and SharePoint Online

Early this year I had my first experience with Microsoft Office 365, in particular with SharePoint Online, and I have to say the experience was excellent.  To set the stage, due to the nature of most of our customers at the time (primarily military and government) I typically worked with on-premises SharePoint deployments, but I was researching the capabilities offered by SharePoint Online for a specific project I was assigned and I needed to get up and running quickly.

The setup process was simple, fast and without any hassles.  It took about 45 minutes to get a new Office 365 tenant setup and using SharePoint Online.  SharePoint Online is part of Microsoft Office 365 and your first step to getting setup is to purchase an Office 365 subscription, which can be done here:  http://office.microsoft.com/en-us/business/compare-office-365-for-business-plans-FX102918419.aspx.

 

As it was my first experience, I signed up for a free trial which is also possible at this site.  When purchasing a subscription there are several plans to choose from, starting as low as $5.00 per user per month (for the Small Business subscription) and ranging up to $20.00 per user per month (for a full blown Enterprise E3 subscription).  There are several levels available between those depending on your needs and your business.

Once you’ve registered for a trial or purchased a subscription, you’ll be taken to an Administrative Center portal page.  This page allows you to manage all administrative functions for your shiny new Office 365 tenant.  It contains a number of tasks you need to perform to get setup – these include:

·        Adding Domains

Adding a domain is one of your first steps.  If you already own a registered domain name you may use it.  The Administrative Portal guides you through the process of verifying ownership and setting up the appropriate DNS records to point to your Office 365 tenant.

 

·        Adding User Identities

Next you’ll need to add users to your Office 365 deployment.  You can add users one at a time, specifying various attributes for each user.  Alternatively you can add users in bulk by uploading an appropriately formatted CSV file.  As well, depending on your subscription you can Active Directory Synchronization to allow existing users to use their existing AD credentials to access SharePoint Online (only available with an Enterprise level subscription plan).  As well, you can enable Single Sign On through Active Directory Federation Services (ADFS) to allow users to access SharePoint Online using their existing credentials and not requiring them to enter their credentials again. In order to enable Active Directory Synchronization and Single Sign On there are a number of steps to complete, and you should follow the Microsoft guidance provided on these very helpful articles:  Prepare for Single Sign On http://technet.microsoft.com/en-us/library/jj151786.aspx and Using Active Directory with Microsoft Office 365 http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/SIM320. 

 

·        Configuring a SharePoint Team Site and Web Site, or Adding Additional Sites

Once SharePoint Online is setup it will contain 2 sites by default: a team site and a web site.  A team site is an internal SharePoint site, where teams and groups of users can exchange documents, connect with one another, store and retrieve content and generally collaborate.  A web site is a SharePoint site which represents a public facing web site for your business, where external partners and customers can retrieve information about your organization.  SharePoint Online provides both sites by default, and allows you to create additional SharePoint sites as needed from the available templates.  These default sites as well as new sites can be configured as needed, with additional libraries, lists, views, apps, web parts, etc.  At this point you can configure the default sites, or add additional sites for various purposes.

 

·        Creating Groups and Configuring Permissions

Once end users are created it will be necessary to configure those users with the appropriate permissions to access the content they need to perform their daily tasks.  The simplest and most manageable strategy to accomplish this is through the use of groups.  As opposed to assigning permissions to users directly, it is recommended that administrators create security groups, they add end users to those groups and then assign permissions to the groups. When first starting out with SharePoint Online this is an effective strategy to allow administrators to more easily track of which users have access to specific sites or content.  Security groups can often represent teams or roles within the organization that have certain types of access to content – for example, finance team members can be part of a “Finance” group that has the Full Control permission level assigned to the organization’s financial documents. 

SharePoint Online uses the same permission model as on-premises deployments.  So, administrators can expect to work with permission levels which are assigned to security groups or users and to content, and which are made up of predetermined permissions like View, Open, Edit, etc.  As well, they can expect to work with permissions that are inherited from libraries, lists and sites, or with unique permissions that are assigned to specific information objects like documents.

·        Configuring External Access (if required)

If required by the business, an administrator can configure SharePoint Online to allow external users to access the organization’s SharePoint Online sites.  This can be configured through the Administration Center portal by accessing Settings and selecting Manage External Users.  Once configured here than individual site collection administrators or site owners are able to configure external users to access to their site collection’s sites (it is still disabled by default and must be configured for each site collection).  They must provide the email address of each external user that is to be granted access, and they are able to send email invitations to these users to access content which has been shared to them.   This is an extremely useful option if you have business partners outside of your domain that you wish to have access to specific content within some specific site collections.

·        Adding Content to SharePoint Online

At this point you’ll likely want to start moving content into SharePoint Online.  Once you’ve figured out which content needs to move into SharePoint, you have several options available for uploading content:  uploading a single document at a time, uploading multiple documents at one time, accessing SharePoint through the Windows Explorer view to add multiple files and folders at one time, or dragging and dropping multiple files onto a SharePoint 2013 library in the web browser.  Typically, you need to think about moving other forms of content as well, such as announcements, contacts, lists, business data, databases, appointments and even business workflow.

There are of course many other options available during the setup process which are not discussed here, including configuring Microsoft Exchange for business email, Microsoft Lync for unified communications such as online chat and Skype, as well as enabling mobile access.  As well, it’s important to understand that before proceeding to get your entire organization up and running with Microsoft Office 365 and SharePoint Online, many of these steps require careful planning to ensure that they fulfill the business needs of the organization - for example:

·        Understanding which features are included with each subscription and selecting the plan is right for your business

·        Determining which users need access to SharePoint Online, which user attributes are important to configure for those users and determining if single sign on is a real requirement for the business

·        Determining which types of team sites are needed, and by which user communities

·        Determining if all corporate content needs to move to SharePoint Online, or if some content that has not been accessed for a long periods of time can be archived instead

·        Etc…

The main point I wanted to get across in this article is that Microsoft has made the process of getting up and running with Office 365 and SharePoint Online extremely easy.  As I started off mentioning, I was able to easily get a demonstration SharePoint Online instance up and running, with some users, some required customizations and some sites and content in about 45 minutes following many of the configuration steps mentioned above.  This was possible even without having much knowledge about Microsoft Office 365 and SharePoint Online to start off with. 

I highly recommend you go through the process yourself and learn all that Microsoft Office 365 has to offer – you can begin here: http://office.microsoft.com/en-us/business/compare-office-365-for-business-plans-FX102918419.aspx.

   -Antonio