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.
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:
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.
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.
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:
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:
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:
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.