I'm trying to decide how to handle requirements I have for removing security groups and permission levels that are added by activating the SharePoint Server Publishing Infrastructure (SSPI) feature with a custom feature.

Considerations I can come up with include

  • whether to put a dependency on SSPI for my feature or check for existence of groups, etc...
  • whether and/or how to restore them during retraction of my custom feature
  • whether I can get away with simply "hiding them" with CSS or jQuery (or whether this is even necessary or better in any way)

Specifically, the customer has requested removal of the Manage Hierarchy permission level and the Hierarchy Managers, Restricted Readers, and Style Resource Readers groups. They also would prefer that some permissions not be assignable to people directly (through the "Grant Permissions" ribbon button that brings up aclinv.aspx in a dialog)

This is not a how-to-code question - I've found plenty of resources for that. It's a question of the risks and impacts of deleting or removing access to those groups and permission levels and reasoning behind restoring them during feature retraction (other than it's just "best practices").

I understand that the customer want the hierarchy locked down (and actually the content approval too) to very select people that also having full control, while having all the other content types and features that come with SSPI - not sure if that helps. EDIT We've also removed access to the masterpage gallery and theme customization (both through permissions and HideCustomAction, where applicable) end edit

Question: What are the impacts of deleting permission levels and groups created by SSPI?

1 Answer 1


SharePoint feature driven groups are "to-be-used" for "so-and-so" purposes and they are "not" responsible for the working of the entire site.

To elaborate this further "to-be-used" groups are the ones you have mentioned in your question that are enabled by SSPI. These groups have certain permission levels for the current site.

For an impact analysis check you can refer here :- http://technet.microsoft.com/en-us/library/cc262690.aspx

The only troublesome group can be Style Resource Readers as MS has mentioned an existing dependency as quoted from Technet

Rights - Members of this group are given Read permission to the Master Page Gallery and Restricted Read permission to the Style Library. By default, all authenticated users are a member of this group.

Note- Do not remove all authenticated users from this group. Because Master Page Gallery and Style Library are shared across all sites in the site collection and must be accessible to all users of all sites. If you remove all authenticated users from the group, anyone with this permission level on a subsite will not be able to render the site. SharePoint will not automatically add or remove users of subsites to or from this group as needed.

So you can choose to remove the other three provided you create appropriate groups with necessary permission levels assigned to them.

For permission levels its better you leave the default ones as it is and create new ones based on them and make changes. That's why we have the button that says "Copy Permission Level" since this can be the closest option one can have while creating new permissions and it also gives you the basis of each permission assigned for different types of activities one can perform in the site.

As mentioned once again in the same Technet article, MS has been pretty explicit regarding the second part of your question as well.

Do not customize the default permission levels if your organization has security or other concerns about a specific permission that is part of the permission level. If you want to make that permission unavailable for all users assigned to the permission level or levels that include that permission, turn off the permission for all Web applications in your server farm, instead of change all of the permission levels

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.