SharePoint permissions are confusing for most new site admins. At my company I see the majority of site admins (we call them site owners) struggle with them. The topic is complex because SharePoint provides so many options for managing permissions. Between the various permissions levels, inheritance, site/list/item-level permissions, version control, draft item security, Active Directory (AD) groups, and SharePoint groups, explaining the best way to manage permission would take several articles.

With that in mind, I want to focus on one particular area—SharePoint groups. Use of SharePoint groups is key to effective permissions management in SharePoint. Without them, sites quickly become overrun with dozens of individual users that have varying degrees of access, including the dreadfully unhelpful “limited access” permission level.

What are SharePoint Groups?

A SharePoint group is a “container” that allows site admins to group users so certain tasks are easier to manage. Examples of SharePoint groups include:

• All authenticated users – they should have read access to all department top-level sites. They would be added to the Visitors groups of those sites.
• All members of a department – they all need contribute access to the department site so they can upload and update team documents. They would be added to the Members group of their department site.
• All C-level executives (CEO, CFO, COO, CIO, etc.) – they need special access to a site with sensitive documents that nobody else can access. They would be added to the Members group for the special site.
• All SharePoint Admins – they need full access to the root of the site collection. They would be added to the Owners group for the site collection.

A good site administrator uses SharePoint groups to assign permissions to users that need similar access to the same sites, lists, and libraries. They can also be used in workflows to assign tasks to groups of people instead of just individuals. Even if only one person needs to have special access to something, it’s a good idea to create a SharePoint group and add that person to the group. You may need to give others the same special access in the future, and adding them to a group is quick and easy; you also have the benefit of giving the group a descriptive name and a description with a link to the site/list/library that has the special access.

SharePoint does an OK job for you by creating an Owners, Members, and Visitors group when you create a site (unless of course you choose to inherit permissions from the parent site). However, when your permissions get more complex, it’s important that you not only manage your permissions, but also manage your groups and use them effectively. As you start creating more specialized groups beyond the default Owners, Members, and Visitors groups that SharePoint creates, you should follow some best practices to ensure that you can easily keep track of the groups over time. The information below applies to both SharePoint 2007 and 2010 except where noted.

Group Settings

SharePoint groups have several settings that can be changed, including the Name, About Me, and Group Owner fields. To modify group settings, go to the People and Groups page for the site (/_layouts/people.aspx), select the group you want to modify from the Group Quick Launch, and go to Settings > Group Settings.

By default any groups you create manually and any groups that SharePoint creates as part of the site creation process are initially owned by you. This means you can add and remove people from the group and change the various settings for the group.

However, you will want to change the Group owner of every group to another group and make sure that this other group contains at least two people. By doing so, you ensure that if any one person in the owning group is unavailable, the other person(s) in the owning group can perform any tasks for that group.  This applies to the default Owners group for the site as well; you can even set the Owners group to own itself (this is what I usually do).

Sometimes you might want to let the members of the group manage themselves; this way the owner(s) of the group don’t always have to be bothered with every request to add or remove members. For example, if you create a team site, you might want to let the team add/remove people from the site’s Members group. To do this, select the “Group Members” radio button in the Who can edit the membership of the group? field on the Group Settings page for the Members group.

Notice the naming convention that SharePoint uses when it creates groups. The name of the group includes the site name—“External Affairs” in the screenshot above—along with a brief description of the role or access level of the group—“Owners.” Just by looking at the name of this group, a site admin can quickly determine that the group most likely has full control access to the External Affairs site.

Also take note that the About Me field in the previous screenshot has a description that SharePoint generated automatically. This is a great practice to follow when creating your own groups to meet more complex permissions requirements.

For example, let’s say you create a group called “External Affairs Blog Approvers.” This group includes several users who are responsible for approving comments on the blog site for the External Affairs department. You could include a description that says “Use this group to give people approve permissions to the comments list on the SharePoint site External Affairs/Blog.” I also recommend making the name of the site into a hyperlink to the site itself.

Why is this important? It lets other people know what the group is used for and provides a quick way for them to view the specific site that the group is being used on without having to hunt for it. When viewing the list of all groups on the /_layouts/groups.aspx page, the About Me information is displayed next to the group, providing a one-click link to get to the site that the group is being used on.

Active Directory and Groups

Depending on your environment, you might have Active Directory (AD) groups that you can use to manage permissions in SharePoint. You could assign permissions directly to the AD groups themselves; this practice sounds good on paper—why re-create groups when they are already created and maintained by the IT department? However, there are a couple of caveats with this approach.

I suggest reading http://sympmarc.com/2011/02/16/active-directory-groups-vs-sharepoint-groups-for-user-management-a-dilemma/ and http://sympmarc.com/2011/02/22/active-directory-groups-vs-sharepoint-groups-for-user-management-the-denouement/ to learn about some of the advantages and disadvantages to using AD groups. To sum it up, AD groups do not let you look “inside” them from the web UI in SharePoint. You have no idea who is in the AD group, which could be a problem for site admins. SharePoint groups do allow you to look inside them, and you can even display all members of a group using the Site Users web part. This is a handy feature for collaboration sites that I’ll cover in a moment.

Neither way is right or wrong, just different. You could even create a SharePoint group with all of the members, and then you could add the AD group to it as well for redundancy.

Set Up Groups and Group Quick Launch

When you create a new site and use unique permissions, SharePoint asks you if you want to use existing groups or create new ones. It also asks you to assign either the new groups or existing groups as the Visitors to this Site, Members of this Site, and Owners of this Site as shown in the screenshot below. This seems like no big deal, right? You tell SharePoint to create new groups (or re-use groups if you already have some made), and it assigns Read, Contribute, and Full Control access to each group accordingly.

Although this is convenient, it doesn’t seem all that special at first glance. However, the Members of this Site setting in particular has a few “extra” features for My Site profiles and the Site Users web part (more on this below).

The Visitors and Owners group settings don’t provide any “cool” features like this; they simply assign Read and Full Control access to the respective groups. However, this is still a convenient way to set permissions if you decide to change which groups you use on the site for Visitors and Owners.

The My Site Profile and the Members Group

When a user is in the Members group for a site, and that members group is used in the Members of this Site field, the SharePoint will list the site on the user’s My Site profile page. When someone else views that user’s profile, they can see that he/she is a member of the SharePoint site. This can be useful for networking or looking up contacts for a particular site.

The Site Users Web Part and the Members Group

When I build an ad-hoc site for a project, I like to add the Site Users web part to the home page and have it display all people in the site’s Members group. A lot of project teams get a kick out of this because it lets them see who’s busy (via Office Communicator presence) and also lets them look up someone’s phone number or email. Often these sites are being used by people across departments, and not everyone knows each other. Using the Site Users web part in this manner gives them a convenient way to look up contact information for their teammates.

To do this, add the Site Users web part to the page. Modify the web part and select the option to “Show people in this site’s member group.” The web part will now display all of the people who are in the Members group for the site, with presence information.

The web part also displays a convenient link for adding new users to the Members group:

Group Quick Launch

When I’m on the People and Groups page, I always make sure that every group I need to work with for the site is included in the Group Quick Launch. This provides a one-click shortcut to view the members of each group being used on the site. SharePoint includes the Owners, Members, and Visitors groups by default, and it will also include any new groups you create if you create them from the current site. Unfortunately it does not automatically include groups if you created them on another site and decide to add them to the current site’s permissions at a later date.

You can remedy this by adding the groups to the group quick launch. In SharePoint 2007, on the People and Groups page for your site, go to Settings > Edit Group Quick Launch.

In SharePoint 2010 this option isn’t on the People and Groups page. Navigate to the People and Groups: All Groups page (accessed at _layouts/groups.aspx or by clicking on the “Groups” link at the top of the Group Quick Launch or the “More…” link at the bottom), then you’ll see the option in the Settings menu.

From here you can add any additional groups that you’d like to manage on the site. This is site-specific, so you’ll need to do this for every site and sub-site individually (when creating new sub-sites that inherit permissions, the sub-site will have all of the groups that the parent site has). I’m a bit of a neat-freak, so I also use this page to re-order the groups alphabetically and by access level.

Now all of your groups will be included in the Group Quick Launch for convenient access when you need to manage them!

Full Control – Use Caution!

Before we wrap up, I strongly recommend keeping your Owners group(s) to a small number of people. Owners groups are usually set up to have full control access to a site, which means that people in the Owners group can give others full control access, who in turn can give even more people full control access. You can see how this could quickly explode into a permissions nightmare if the people in your Owners group(s) don’t understand your permissions strategy. By keeping the Owners group(s) to just a few people, you can help to uphold the governance policies of your sites.

All too often I’ve seen sub-site sprawl because a director didn’t have time to manage a site and gave full control to his/her subordinate managers, who in turn gave full control to some of their employees because they also didn’t have time. Instead of two or three people with full control access to the site, all of a sudden 15 people had access and were creating sub-sites for bowling leagues, picnic photos, book clubs, etc. It’s not that these kinds of sites are bad, it’s just that they should be planned and built with a little bit of strategy in mind instead of having silos of uncontrolled, totally organic sub-site sprawl for every team in the department.

Let’s Review

• SharePoint groups allow you to manage permissions for multiple users at the same time while keeping things more organized.
• Always manage permissions with groups; if an appropriate group doesn’t exist, create it, even for a single person—at the very least you can add a description for what kind of access the group/person has, and at best you can easily grant the same access to additional people as-needed.
• Use standard naming conventions—site name + access level or role.
• Use a description that includes a hyperlink to the site(s) or lists/libraries that the group has access to.
• Never set the owner of a group to an individual person; if that person is unavailable, it will be more difficult to manage the group. Typically you’ll want to use the Owners group of the current site as the owner of all groups used on that site.
• You can use AD groups to manage permissions, with some caveats. You can also include AD groups inside SharePoint groups.
• Make sure that Visitors, Members, and Owners groups are established on the Set Up Groups for This Site page. For SharePoint 2010, use the Make Default Group option in the Settings menu to set the Members group for the site.
  • SharePoint will list the site on the members’ My Site profiles.
  • The members can be automagically listed in the Site Users web part.
• Include all groups for your site in the Group Quick Launch, that way you can quickly and easily access them to manage group membership from the People and Groups page.
• Keep your Owners group membership to a minimum. Anyone with full control access can grant full control access to others, so permissions can get out of control if too many people have full control and don’t understand your permissions management strategy.

I hope these best practices can help you to manage your SharePoint groups as they start to grow in complexity. They’ve definitely helped me over the past few years! Keep in mind that this is mostly based on MOSS 2007, but the principles still apply for WSS and SharePoint 2010.

Please note: This article is a finalist entry for the Aspiring Authors Competition 2011. To vote for this article as the winner, please use the Like button below, or read the contest details on http://sharepointmagazine.net/aspiring-authors-competition-2011.

[wpfblike]