SharePoint 3.0: Custom Permission Levels

When planning site collection security models for SharePoint deployments, there is certainly a case for simplicity and sticking to the out of box permission levels. Doing this requires the least amount of thought, administrative effort, documentation, and training.



As an added benefit of sticking with the out of box, you can leverage many of the Web based training tutorials and end user, computer based training modules, that are available on the Web with since most of these instructional resources are based on out of box configurations.

Having said that, circumstances and business requirements can require something different than the out of box permission levels. For example, you might want to lock out SharePoint Designer from some users by configuring a permission level that excludes the "Use Remote Interfaces" permission. Or, you might want to prevent content contributors from being able to delete by excluding the "Delete Items" permission. In most cases, having thirty three distinct permissions allows enough flexibility to accommodate.

When I need to utilize custom permission levels, I put a good amount of effort into planning for these and ensure to be consistent with their names, descriptions, and definitions. Below is a sample matrix that I used for planning four custom permission levels, instead of using those which are out of box.

SharePoint 3.0: New AD Group Unavailable for Audience Rules

Description:

When creating a new audience rule...

...a new Active Directory security group is unavailable.

Solution:

* Run a full import of user profiles:

Shared Services Administration > User Profiles and My Sites > User profiles and properties > Start full import

Effective Security Model for SharePoint

Creating an effective, scalable security model and governance plan for a SharePoint implementation is one of the most important and intricate aspects of a SharePoint deployment. Developing a security model usually requires cooperation from from a lot of different people. It requires communication with the business groups for articulating the security requirements of their content, the security people for communicating the policies (such as Sarbanes Oxley), interpreters of these requirements for designing a consistent roles based structure and naming convention (in AD and SharePoint) and IT staff responsible for managing the provisioning and deprovisioning.

Much like the user interface of SharePoint is an open canvas, the security model offers lots of room for creativity, though the efforts are mostly transparent to the end users. When designing a security model, I like to thing about things like what size is the user base, what is the organizational structure of the company, how do the business units interact with each other, what are the security policies in the company, how strict must the security on the content be, is the IT staff willing to accept the responsibilities, etc..

As a rule of thumb (with exceptions of course), I don't create SharePoint users, instead I create SharePoint groups and corresponding AD groups. I like to manage the memberships exclusively in AD. Another thing I try to avoid doing is creating roles based solely on org charts. If an organization is collaborative enough that they are implementing SharePoint, then chances people are interacting outside of their immediate department anyways. Most workspaces and content are custom and besides; departments change and reorganizations happen.

There is a significant effort that goes with keeping the security model in good shape. Limit SharePoint security to roles based groups, keep all of the group membership management in AD, and have a consistent organized pattern and naming convention. When that is all set, spend a some time developing the following two reports:

• A report that shows Sharepoint Site, SharePoint group names, access levels
• A report that shows AD groups, member names, and email addresses, nested groups and their members

...then you have an effective security model.