I often take the basics for granted, but throughout my consulting realize that in some cases even the most basic of concepts can have a large effect on an enterprise and their governance plans for SharePoint.
In this instance, I’m referring to permissions with a specific focus on SharePoint Site Groups vs Active Directory Groups, their use, pro’s and con’s and so forth.
I had this discussion with one of my customers just the other day and decided to share some of my notes with you.
Permission
So, before we get into that, let’s look at the various elements that can have permissions assigned to them, they are Site Collection, Site, List and List Item and relate to one another as follows:
For the Site Collection piece you can simply add / remove an overall administrator and for all the other levels, you can work with the full permissions levels of Full Control, Contributor, Reader etc.
These items obviously exclude Farm related elements such as service applications, web application policies and the like, but I just wanted to keep this short post practical and specific to how a Portal will function.
SharePoint Site Groups vs Active Directory Groups
In a nutshell, SharePoint Site groups allows for the grouping of users in a group and the assignment of permissions to the group rather than individuals. Active Directory groups are the equivalent, but specific to Active Directory. Active Directory groups are managed by domain administrators (via Active Directory) and SharePoint Site groups are managed on SharePoint.
SharePoint Site groups can contain Active Directory groups, but not the other way around.
Okay, so when do I use which one and how?
Active Directory Groups
For large corporates with an established plan for governance, I would suggest creating Active Directory groups and adding them into SharePoint Site groups. This allows for IT staff to manage permissions from within Active Directory without ever touching SharePoint.
This approach is recommended to be implemented in the more formal or publishing area (where permissions seldom change) of your portal as changes might need to go via formal change control.
A combination of direct assignment and SharePoint Site groups should be used for team sites and areas that change often.
SharePoint Site Groups
Smaller companies that need flexibility and quick turnaround times on changes, I would recommend a pure SharePoint Site group approach. Large corporates will also utilise SharePoint Site groups, but purely in the their team site / divisional site areas, not for the entire portal.
Utilising only SharePoint Site groups can be hugely effective, but an extra step is required when new people join the company as the onboarding process (usually done via IT) won’t be able to assign permissions across the company (via AD) in one go. Unless of course you use an awesome tool such as @K2onK2. ![]()
In a nutshell
Ultimately SharePoint Site groups should always be used to manage permissions on SharePoint. The consideration is just whether or not to assign users directly into it or via Active Directory groups. If you have a large formal publishing area in your intranet, I suggest using AD groups within SharePoint Site groups and getting your IT department to manage the members of those groups. For the teams / divisional site collections, I suggesting the use of SharePoint Site groups only as this gives the SharePoint administrators (that are more often than not, NOT Active Directory domain admins) the ability to manipulate permissions.
Resources
For a summary (in pictures) of what I’ve explained here, please have a look at a presentation that I uploaded to slideshare – Permissions Overview.
Veronique, from Let’s Collaborate has also done a really cool poster on end user permissions, download it here – Poster – Site Permissions for End Users (Thanks V!)
