Skip Ribbon Commands
Skip to main content

Team Blog

Go to Homepage
DocAve.com > DocAve.com Team Blog > Posts > Permissions Deployment with DocAve Administrator

Permissions Deployment with DocAve Administrator

By : Sanjeet B.On : 3/10/2011 11:57:00 AMViews : 1558
March 10

Sharepoint is becoming the overwhelming first choice -as the collaboration platform for enterprises big and small. Even on a SharePoint deployment of a small size, there are typically hundreds of users with each user performing hundreds of actions per week at the very least, based on their permission level within a given scope. These actions could include something as simple as viewing a document or a list to something as complex as creating a site with specific design elements (think themes, columns, etc.) and functional elements (think web parts, lists, etc.) each having some customization. The flexibility and facile usability of SharePoint on the front end leads to a plethora of configurations and permissions settings with respect to SharePoint objects (Webapp, Site Collections, Sites, Lists, Libraries, and Items).

 

While the configuration settings in SharePoint for its various objects help to not only ensure a consistent end-user experience and a stable platform, it is the permissions policy regime and enforcement that determines the integrity of your SharePoint platform. With IT infrastructure security being primary concern of any enterprise, addressing permissions management deserves more than just a passing thought. In fact, a survey of our 5000+ customers indicated that a majority of them use the DocAve Administrator primarily to manage permissions and securities for their farms!
 
As one would agree, permissions in SharePoint come into being in a pretty much ad-hoc manner - user creates a list or a library or site and selects who all get to access it and what kind of access does each one have (view only, read only, …, full control). Microsoft encourages designing permissions at the site level in such a way that the need to break inheritance does not arise as users or groups are added to lower level objects within the site - this is considered a best practice.  However, permissions inheritance gets broken quite frequently. While sometimes there is a justifiable need to create custom permissions at other times it is merely the flexibility that SharePoint offers in terms of assigning permissions to users or groups as they are added to an object that leads to a break in permissions inheritance. This can lead to a host of problems - the ones that come to mind right away are inadvertently adding or removing access to sensitive data, site lock-out, content deletion and duplication of efforts. Also, since usually permissions are broken within a site, there is no direct way for a farm  or site collection administrator to know how many custom permissions exist and where, whether they have been assigned , which user or group has manage permissions permission, etc. What can make the situation worse is that permissions can be broken at the list or list-item level for every site in every site collection for every webapp! The mere possibility of this can make a seasoned admin's head spin. Every time a permission inheritance is broken means that there exists a user or group with custom permissions who can accidentally delete, corrupt, update, move or change content. What makes the situation worse is that SharePoint does not offer a way to know about the details of the permissions structure you have in your farm.
 
Enter DocAve Administrator. This tool has a feature called Security search that proves to be quite a power tool enabling permissions deployment, management and control. This feature allows you to run a search for permissions for all or specific users and/or groups (including AD and FBA groups) at all or specific levels of SharePoint objects in a farm. The hidden value of this feature is not just in the granularity of results returned or that the results can be exported to various common formats (pdf, csv, xml) but rather in the fact that results can be exported to excel for editing or acted upon directly from within the DocAve GUI. This allows for a plethora of possibilities not only in terms of discovering the permissions regime within your farm but also for acting on it as needed. Some of the common queries about ones' farm - how many and which list/library/folders have unique permissions? where all have permissions inheritance been broken? how many users/groups have unique permissions? how many distinct SharePoint Groups do you have? - can now all be answered. How about if  your mission is to restore or even to break permissions inheritance? To do this, individually for each object can be a drag. However, with this tool, all you need to do is run the security search with the relevant parameters and once report is generated, you can break or restore permissions inheritance in batch mode with just a click. Since, each security search can be scheduled, you can now do this periodically. Nice!
 
That's not all, for me, the aha! moment came when I discovered that you can batch manage or batch deploy permissions at any level in your farm. Just run a security search with the specific parameters of interest, export it for editing via a single click, make changes to the excel file as needed and import it back to DocAve Administrator to re-deploy the changed permissions.
 
Now, that's powerful stuff!

 

top

Comments

There are no comments for this post.

bottom

Add Comment

*
 
About DocAve | Contact | Site Map | RSS Feed | Follow us on Twitter | Add us as a friend on Facebook
© 2001-2013 AvePoint, Inc. All rights reserved.
Line

Register Now

Register now to join the conversation on AvePoint’s community portal! Read our latest blog posts, watch new product videos, participate in vibrant discussion forums, learn SharePoint best practices, and more. You’ll also receive exclusive access to the AvePoint Knowledge Base for all of your technical and troubleshooting questions.

Line

Archive

Line

Community Guidelines

  • We reserve the right to address factual errors.
  • We will reply to comments when appropriate.
  • If we disagree with other opinions, we will do so respectfully.
  • You may not post anything that is spam, abusive, profane, or defamatory toward a person, entity, belief, or symbol.
  • While we support lively and open discussion, we reserve the right to delete comments at our discretion.