Implement a better performing and easier to management Microsoft SharePoint platform through solid permissions - Part 1

1/9/2018

Solid Permissions create a Microsoft SharePoint Platform that Delivers Better Performance and is Easier to Manage

I often tell course Attendees that once they implement a solid Microsoft SharePoint permission construct that they should never have to manage permissions again. The challenge is that here are several ways to assign permissions within the SharePoint environment - some are not so good and some are best practices. Although some accomplish the same end result some approach are simply better than others especially in the long run. Let me explain.

You First Need to Understand how Security Works in the Microsoft World to Select the Best Approach

Microsoft lives in an Objected Oriented world were everything is stored in some form of a database. Even the NTFS file system is a form of a database where objects include Volumes, Folders, Files and more. SharePoint environments have many objects like Site Collections, Sites, Lists, Libraries, Items, and Documents to name a few. Each object is like a record in a database that is made up of fields of information; fields like Name, Date, Created By and so one. One of those fields is called the Security Descriptor. The Security Descriptor field contains two components or lists: SACL and the DACL. The former is the System Access Control List and the latter is the Discretionary Access Control List. Here is a definition from Microsoft:

• An access control list (ACL) is a list of access control entries (ACE) ie: permissions for a User or Group.

• A discretionary access control list (DACL) identifies the trustees that are allowed or denied access to a securable object.

• A system access control list (SACL) enables administrators to log attempts to access a secured object.

One the other side of equation are Users and Groups, both of which are each uniquely identified by a number sometimes referred to as a GUID or Global Unique Identified. When a User logs into a Microsoft environment such as a workstation or SharePoint website a SAT or Security Access Token is created for them within each workstation and server through which they access a file or an application. The Security Access Token defines for that server or application who the User and what Groups they belong to via their collective GUIDs. The SAT also contains a list of Privileges the User has based on their membership in pre-defined Groups or that have been uniquely assigned to them, the latter approach being in bad form.

So Users have Security Access Tokens that say who they are, what Groups they belong to and what Privileges they have. And Objects have Permission and Auditing Lists so the system knows who has and does not have access as well as whose successful and failed access attempts to record in the audit log.

Windows Securing SharePoint Objects

In the middle between them there is the Security Reference Monitor and Object Manager. The Security Reference Monitor is part of the Windows Kernel that performs User access checks, generates audit log entries, and manipulates User rights (privileges). The Object Manager component works with the Security Reference Monitor to determine if a User generated process has sufficient rights to execute a certain type of action, like Read or Delete, on a object. It is important to note that the Security Reference Monitor will never grant more or less access than requested by a User's process.

Windows Security Architecture

Security Performance Rules

In order for the User to be granted access to an object two passes or parts of the calculation have to be done. First the Security Reference Monitor has to compare the granted permissions in the user's Security Access Token and the permissions in the Object's Discretionary Access Control List and doing so pull out all of the ones that are in both places. Then the Object Manager has to determine if the User's process request has permission to do what it wants to do to the object by going through and doing the math between matching permission within the SAT and the Object in order to make the Access / No Access determination. Now imagine if the Object in question had thousands of DACL Access Control Entries (ACEs) that the security evaluation process had to go through in the first pass before even getting to the second security access determination pass. Do you think it would slow down the security determination process? The answer would be yes.

This brings on a further question: How many Access Control Entries should an Object have within its DACL? The correct answer is a few as possible.

The next question would be: How many Access Control Entries are required to provide the normal number of access methods? The correct answer is about five:

• Read (with possibly Limited View)

• Read & Write

• Read & Write & Execute & Delete

• Design

• Full Control

When granting access to objects Microsoft recommends that you use Users and Groups that are closest to the object. In a combined Active Directory and SharePoint environment there several ways a User can be granted access to an object like a Site or Document Library:

1. The Active Directory User can be granted permission to the Object directly.
2. The User can be placed in an Active Directory Group and that group can be granted permission to the Object directly.
3. The Active Directory User or Group can be placed in a Local SharePoint Group that has permission to the SharePoint Object via a DACL entry.

The Third Option is the Microsoft recommended approach, not just for SharePoint but for managing NTFS file systems as well. The rule is to always assign permissions to local groups and then place Active Directory Users and / or Groups within the local group. There are two main benefits to taking this approach:

1. Access to the Object is fast to get resolved because the Security Reference Monitor and Object Manager can look at the DACL and compare it to your Security Access Token that was generated at login without having to check with Active Directory.
2. When you use Local Groups to assign permissions and the Local Groups is deleted then the next time the Object is opened the Local Group will be removed from the DACL automatically. If you assign Active Directory Users or Groups as an Object DACL then you need to manually remove them from the Object DACL when the Active Directory Users or Groups are deleted - it will not happen automatically.

In our next blog post we will demonstrate how to leverage the above approach to security within SharePoint Site Collections in order to minimize administrative overhead associated with security permissions.