One of the strengths of SharePoint, and one of the main reasons why the platform became so popular in the first place, are permissions. It doesn’t matter if permissions are governed centrally, or if the site owners are allowed to grant permissions themselves: the power, and granularity, of permissions management in SharePoint skyrocketed the platform. Everyone could have it his or her own way: tightly managed, tied on the site collection level, or loosely managed, and broken down to the item-level… no matter what, SharePoint could cut it.
Part 1: SharePoint admin’s dream: Centralized permissions management
Part 2: Batch permissions management with SPDocKit
Part 3: On-the-fly permissions management with SPDocKit
Part 4: Permissions reporting and forensics with SPDocKit
And this is exactly the problem with SharePoint: since it can be done, and since everyone (who has rights) can do it, very often – if there are no policies imposed – SharePoint’s greatest strength turns out to be its greatest weakness, a Gordian knot that can’t be untied without cutting it. One of the strangest SharePoint projects I have ever been in charge of was back in the time of MOSS 2007, when we were contracted to wipe (!!!) all the permissions in a SharePoint farm, develop a new permissions concept, and set the permissions afterward based on that concept, literally cutting the Gordian knot.
We used PowerShell for this task, since there is one thing that SharePoint was never good at: centralized permissions management. Everything is fine, as long as you have only a couple of site collections. But at the moment when an IT Administrator needs to add/delete/change users on several hundred, or even thousand, site collections, things get interesting. Sure, it is always possible to write short PowerShell scripts for such tasks, but when you need to do it on a daily basis, things become more difficult.
Another thing that SharePoint is not good at is something I call “permissions forensics”. In SharePoint environments that are not tightly governed (and good SharePoint implementations are always about maintaining a delicate balance between tight government and self-service and democracy), it can be a challenge to trace the history of the permissions: how did the cleaning lady end up with rights to view this document? Built-in permissions forensics in SharePoint are on a very basic level at best, and permissions reporting is virtually nonexistent. This especially poses a problem with SharePoint 2013, and the famous “share” link, which basically gives the ability to anyone – who has the appropriate rights – to break permissions on the item level on a very easy way. This adds an additional, and rather large, level of complexity to the whole permissions management issue.
Sure, the administrators can write PowerShell Scripts to automate those tasks, and to generate some kind of permission reports. And this is what most of them do. But writing PowerShell scripts for every single task – and the permissions management tasks can be very specific – is time-consuming, and not something that anyone does gladly. And PowerShell scripts are always so final: once you run one, the benefit – or the damage – is done; there is no way to undo the action. Strangely enough, there aren’t that many third party tools that would close this gap with SharePoint permissions. My favorite tool, which I as a consultant recommend to in-house administrators, is SPDocKit (a.k.a. SharePoint Documentation Toolkit), which was one of the first tools to offer permissions reporting. In the last two versions, SPDocKit also includes a wizard-like centralized permissions management tool, which makes day-to-day basic permissions management a much less painful job. SPDockIt is a lightweight Windows Forms tool, which does not tamper with your SharePoint installation in any way (no new items are installed in the Central Administration, nor is your SharePoint farm changed in any way after installing it), and it provides a Swiss Army knife-like tool kit of features for SharePoint governance and documentation.
In the next few blog posts in this series, I will try to outline some key permissions management tasks, and explain how SPDocKit can be used to automate these tasks (almost) completely. All the blog posts will be – to use movie jargon – “based on true stories,” on the use cases with which I was confronted in my SharePoint consultant career.
