SharePoint Security

The SharePoint security model allows your org to re-use your existing roles already populated in your AMS or CRM solution.  You likely already have roles defined as committees, groups, chapters, councils, special interest groups, communities of practice, or any other logical grouping of users.

SharePoint can honor those roles and provide access to specific locations of your Site with varying levels of permissions based on the location and role combination.  You can also leverage your existing Active Directory Security Groups.

To successfully accomplish any of this, you need an understanding of the SharePoint security model and how to tailor it to suit your org’s specific needs.  Understanding best practices related to SharePoint security will save you a lot of overhead with respect to ongoing security management.

SharePoint Site Groups

A SharePoint Site Group is just a group of users.  You add users to each SharePoint Site Group.  SharePoint Site Groups can be thought of as Roles with varying levels of permissions to various locations of your Site.

For example, you may have a SharePoint Site Group called “HR Staff” which has Read permission in most sections of your intranet.  However, in the HR Site, your “HR Staff” SharePoint Site Group has been granted Read, Add, and Delete permissions.

This same principle applies throughout SharePoint and across the different permutations of the platforms’ uses – whether you are using SharePoint for an intranet, extranet, member community, public-facing website, or all of these permutations.

You can create your own SharePoint Site Groups.  Let’s first look at the default SharePoint Site Groups available with any new Site.

• Visitors – Use this group to grant read permissions.
• Members – Use this group to grant contribute permissions.
• Approvers – Members of this group can edit and approve Pages, List Items, and documents.
• Owners – Use this group to grant full control permissions.
• Designers – Members of this group can edit Lists, Document Libraries, and Pages in the Site. Designers can create Master Pages and Page Layouts in the Master Page Gallery, and can change the behavior and appearance of each Site in the Site collection by using master Pages and CSS files.
• Hierarchy Managers – Members of this group can create Sites, Lists, List Items, and documents.
• Restricted Readers – Members of this group can view Pages and documents but cannot view historical versions or review user rights information.
• Style Resource Readers – Members of this group are given read permission to the Master Page Gallery and the Restricted Read permission to the Style Library. By default, all authenticated users are a member of this group. To further secure this Site, you can remove all authenticated users from or add users to this group.

Active Directory (AD) will almost certainly be used to store some of your users who access your SharePoint solution.  In fact, most orgs end up looking something like this:

• Intranet Solution = User accounts in AD.
• Extranet Solution = Staff user accounts in AD while non-staff user accounts in AMS/CRM system.
• Public-facing Website Solution = Staff user accounts in AD and non-staff user accounts in AMS/CRM system.  Users without user accounts can simply register to create an account in your AMS/CRM system.

Therefore, SharePoint’s built-in ability to honor your existing Active Directory (AD) Security Groups not only saves time but also prevents you from having to manage individual user account permissions in multiple places.  For example, you can simply define in SharePoint the existing AD Security Group (like Domain Users) which has Add, Modify, and Delete permissions in a particular Site.

You will undoubtedly have the need to create your own SharePoint Site Groups.  A SharePoint Site Group can be thought of as a Role, and your org will need specific Roles (SharePoint Site Groups) different from those created by default during installation.

A key benefit of SharePoint Site Groups is that it’s easier and faster to manage permissions at a Group level rather than at the individual user or Item level.  Think in terms of “groups of users” who need the same permissions in a given location (Site, Subsite, Document Library or List).

When “Bob the Accountant” leaves your organization to spend time practicing Yoga in the Himalayas, how much work do you want to do ensuring his replacement has all the same permissions that Bob had throughout the Site?  It would be nice to simply add the new person’s account to the correct AD Security group(s) or make sure the new guy’s account belongs to the same SharePoint Site Groups.

If you chose to ignore SharePoint Site Groups and configure permissions for individual accounts, you will need to figure out every single location where you granted rights to “Bob the Accountant.”  You will need to determine what permissions were granted at that location, remove Bob’s account, and add the new person’s account with the same permissions.

This is not even a realistic option.  Without a third-party utility or writing scripts, you would need to manually check every single Site, Subsite, Library, List and Item.  It’s just not going to happen.  Plan out your SharePoint Site Groups and stick to your plan when adding new users to your Site.

Here are the fields you fill out when creating a new SharePoint Site Group:

• Name and About Me Description – Type a descriptive name for your Site Group and add a description for the group.  Do not skip the description even though it’s not required.  Take the extra 30 seconds and fill it out accurately.  You will thank yourself 12 month later when you try to figure out why that Site Group was created.
• Owner – The owner can change anything about the group, such as adding and removing members, or deleting the group. Only one user or group can be the owner.
• Group Settings – Specify who has permission to see the list of group members, and who has permission to add and remove members from the group.
• Membership Requests – Specify whether to allow users to request membership in this group and allow users to request to leave the group. All requests will be sent to the e-mail address specified. If auto-accept is enabled, users will automatically be added or removed when they make a request. Caution: If you select ‘yes’ for the Auto-accept requests option, any user requesting access to this group will automatically be added as a member of the group and receive the permission levels associated with the group.
• Give Group Permission to this Site – Specify the permission level that you want members of this SharePoint group to have on this Site. If you do not want to give group members access to this Site, ensure that all checkboxes are unselected.
  • Full Control – Has full control.
  • Design - Can view, add, update, delete, approve, and customize.
  • Contribute – Can view, add, update, and delete List Items and documents.
  • Read – Can view Pages and List Items, and download documents.
  • Approve – Can edit and approve pages, List Items, and documents.
  • Manage Hierarchy - Can create Sites and edit Pages, List Items, and documents.
  • Restricted Read – Can view Pages and documents, but cannot view historical versions or user permissions.
  • Records Center Web Service Submitters – Can submit content to this Site using Web Services.

SharePoint Permissions

SharePoint permissions can be divided into three main categories:  List Permissions, Site Permissions and Personal Permissions.

The separation of permission categories is for organization purposes only.  You can certainly mix any two or more permissions as needed.

Site Permissions

• Manage Permissions - Create and change permission levels on the Web Site and assign permissions to users and groups.
• View Web Analytics Data – View reports on Web Site usage.
• Create Subsites – Create Subsites such as team Sites, Meeting Workspace Sites, and Document Workspaces.
• Manage Web Site – Grant the ability to perform all administration tasks for the Web Site, as well as manage content.
• Add and Customize Pages – Add, change, or delete HTML Pages or Web Part Pages, and edit the Web Site using a Microsoft SharePoint Foundation-compatible editor.

• Apply Themes and Borders – Apply a theme or borders to the entire Web Site.
• Apply Style Sheets – Apply a style sheet (.CSS file) to the Web Site.
• Create Groups – Create a group of users that can be used anywhere within the Site collection.
• Browse Directories – Enumerate files and folders in a Web Site using SharePoint Designer and Web DAV interfaces.
• Use Self-Service Site Creation – Create a Web Site using Self-Service Site Creation.
• View Pages – View pages in a Web Site.
• Enumerate Permissions - Enumerate permissions on the Web Site, List, folder, document, or List Item.
• Browse User Information – View information about users of the Web Site.
• Manage Alerts – Manage alerts for all users of the Web Site.
• Use Remote Interfaces – Use SOAP, Web DAV, the Client Object Model or SharePoint Designer interfaces to access the Web Site.

• Use Client Integration Features – Use features which launch client applications. Without this permission, users will have to work on documents locally and upload their changes.
• Open – Allows users to open a Web Site, List, or folder in order to access items inside that container.
• Edit Personal User Information – Allows a user to change his or her own user information, such as adding a picture.

List Permissions

• Manage Lists – Create and delete Lists, add or remove columns in a List, and add or remove public views of a List.
• Override Check Out – Discard or check in a document which is checked out to another user.
• Add Items – Add items to Lists, and add documents to document Libraries.

• Edit Items – Edit items in Lists, edit documents in document Libraries, and customize Web Part Pages in document Libraries.
• Delete Items – Delete items from a List, and documents from a document library.
• View Items – View items in Lists and documents in document Libraries.
• Approve Items – Approve a minor version of a List Item or document.
• Open Items – View the source of documents with server-side file handlers.
• View Versions – View past versions of a List Item or document.
• Delete Versions – Delete past versions of a List Item or document.
• Create Alerts – Create alerts.
• View Application Pages – View forms, views, and application pages. Enumerate Lists.

Personal Permissions

• Manage Personal Views - Create, change, and delete personal views of Lists.
• Add/Remove Personal Web Parts – Add or remove personal Web Parts on a Web Part Page.
• Update Personal Web Parts – Update Web Parts to display personalized information.

SharePoint Permission Levels

You’ve guessed it right; SharePoint Permission Levels are logical collections of permissions!  Therefore, you could create a new Permission Level called “Chapter Leaders” and add the appropriate permissions to your new Permission Level.

​