Reworking SharePoint Security – Fixing a Bad SharePoint Implementation

This is the first in a series of posts relating to topics that may need to be addressed to recover from a bad SharePoint implementation.

SharePoint security continues to be misunderstood by many SharePoint power users and some Administrators. It was designed to be flexible, and in doing so can lead people down a road to ruin. One of SharePoint’s greatest assets is that it enables site and content owners to maintain their own permissions. Gone are the days that every request has to be routed through a central IS/IT group. Unfortunately I have yet to see this reach its potential. There are numerous reasons; some site owners do not receive the proper training, some are too busy, some just do not buy into the ownership, and others inherit previously built sites.

To take full advantage of the platform’s capabilities owners need to understand and be committed to following through.

Reinforce the Site Owner Contract
Make sure that Site Owners know what is expected of them. If they are responsible for maintaining security for their site(s), then reinforce the specifics since in some cases this may not be fully understood. This should also carry into that group’s resource planning. If people are informally assigned the ownership tasks it may not be figured into their normal work schedule. If it is not part of the resource planning shortcuts will inevitably be taken. Furthermore, I have seen a few site administrators cut during downsizing without any visibility to those responsibilities. What is worse, in many cases nobody assumes that ownership after the resource leaves the organization.

Training
When developing Site Administrator or Site Owner training, be sure to address proper security. Show examples of where it is done correctly, but also where it was done horribly wrong. Be sure to provide different types of training; in person, written, and interactive.

The Microsoft Office site has a great overview that is easily consumable: http://office.microsoft.com/en-us/sharepointtechnology/HA101001441033.aspx?pid=ch100649861033

Perform and Audit
The best way to get a handle on what the current issues are and to generate a plan to resolve those issues is to start by performing an audit. Look at the site collection and subsites and determine what is set to inherit and what is set to be unique. Then look at the individual lists and libraries to review the same.

Most of the issues I’ve seen come from site administrators breaking inheritance at the list/library level without understanding what that means. I have also seen issues in libraries where multiple levels of folders are in place with security being set differently at each folder level. Hopefully groups are used to control the access, but in many cases it is individuals. The easiest way to resolve these issues is to just start over. Work with the site owner/administrator to understand the intent and set it to inherit from the parent object and then go back through the steps to setup the specific permissions required.

Groups versus Individuals
Wherever possible, use groups to provide access to the securable objects. Adding individuals directly to an object does not promote reuse or central management. This creates many of the maintenance issues that lead to problems as sites and content evolves. Using SharePoint Groups versus Active Directory Security Groups has been widely debated so I will not cover it here. Use what is appropriate for your environment.

Summary
Following these recommendations will help transition the system from chaos to something that meets the site owner’s requirements and promotes maintainability. The next post in this series will cover navigation and Information Architecture issues.

Tags: , ,

2 Responses to "Reworking SharePoint Security – Fixing a Bad SharePoint Implementation"

  • Deny says:
  • next_connect says:
Leave a Comment