SharePoint Security Best Practices – Article 2

Security and performance at the same time in SharePoint

In my first article, I talked about how Microsoft is an object oriented environment and the objects are stored in namespaces. I discussed the fact that each object has its own list of security permission entries called Access Control Entries (ACE) that determines who can access the object. I also stated that if the list gets too big, access to the object will be slowed down. The question is “how do we provide access to hundreds of thousands of users and still maintain a small list of permissions for a SharePoint object?”

How many standard access levels can you have to a SharePoint object? Think about it. It is really not that many. In a standard setup, you usually use Full Control for the Site Owners group, Contribute for the Members Group, Read for the Authenticated Visitors group, and maybe View Only for Anonymous users.

SharePoint Permission Levels

Security = Groups and Permissions

There are several ways of granting a user access to a SharePoint site and they will all work. Some ways are just more efficient than others. The key to maintaining access performance as your SharePoint Farm scales up to support thousands of users is to keep the Object’s Access Control List as small as possible ie: with few entries. This requirement is based on the two-stage verification and validation process we discussed in the first article. You can achieve this by using Local SharePoint Access Based Groups based on access levels. You then place the Active Directory Global Group with the SharePoint Local Group. Finally, you assign the Local SharePoint Access Based Group an access permission level. In the example below, the Active Directory User is a member of the Active Directory Global Group, which in turn is a member of the SharePoint Local Access Level Read Group, which has been assigned the Read permission level Access Control Entry in the site’s Access Control List.

Leverage Active Directory

What I always advise my clients is that once you setup the SharePoint Group and Permission structure, you should not have to change it. In other words, if you are changing SharePoint Groups and Permissions all of the time it is not setup efficiently. It might still work but there is a lot of performance and management overhead. The main place that group membership should be managed is in Active Directory, a process which is being done already. As a new employee joins the Finance Department, they will get added to the Active Directory Finance Global Group. That will be done by the HR department or the IT’s Active Directory team. In doing so, the new employee will automatically gain access to the SharePoint Finance site without any work required from the SharePoint team. The only change to SharePoint Local Access Level groups would be if you needed to provide access to an employee from another department to your own department site but did not want them to be a member of your own departments Active Directory Global Group because that would grant them automatic access to all of your department’s information. Once your permission levels are in place, you should not have to change them going forward. Moreover, the security architecture will be fully scalable to thousands of SharePoint Site Collections and tens of thousands of users.

What is a good SharePoint Logical Architecture that can leverage this security model? We will discuss that in our next article.

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.