In most cases, SharePoint users are authenticated and authorized through Active Directory.   Within SharePoint, there are several alternatives to authorizing users:

• Creating a SharePoint group and mapping roles such as Contributor, Designer, Reader, etc. to the group.  Members of the group are authorized based on the group.
• Creating a SharePoint group and adding an Active Directory group to its members…this allows anyone in the Active Directory group to participate in the SharePoint group
• Mapping roles directly to Active Directory groups and not using SharePoint groups at all.
• Mapping roles directly to individual users

So which is best practice?  Which provides the best governance?  The answer, as always, is it depends.    The one that we discourage the most is mapping roles to individual users.  But when evaluating using SharePoint groups or Active Directory groups, the answer isn’t as clear cut.

While some bloggers have talked about feature set differences (see Alexander Brutt’s post for example for a clear explanation of the implications on how SharePoint behaves), there are some also implications on how the platform is governed:

	Active Directory		SharePoint Groups
	Using Active Directory as a directory entails that the AD itself has to be well governed, e.g. with high quality directory data, everyone provisioned centrally, and good de-provisioning processes.		SharePoint Group management can be delegated, while Active Directory management is typically centralized.  If you have many site owners who all want to make ad hoc permissions changes then this can bottleneck your IT department if you insist on using AD groups in all cases.
	Active Directory groups are a reusable asset for the entire enterprise.		SharePoint groups cannot be nested within each other.
	SharePoint requires a significant number of groups.  Enforcing the rules that all these groups need to mapped to Active Directory groups implies that there will many many groups created in Active Directory for localized permissions (e.g. permissions on a single document library)		SharePoint groups can be provisioned as part of the site creation process.  By default for collaboration sites, three groups are created: SiteName Owners (Full Control); SiteName Members (Contribute); and SiteName Visitors (Read).  For publishing sites, there are more groups created.
	Provisioning and de-provisioning processes can be centralized if using Active Directory groups.  Removing someone from an existing group removes their access in SharePoint as well as all other dependent systems across the enterprise.  Disabling their account will disabled their access in SharePoint altogether		SharePoint groups display individual group members in lists of users.  With Active Directory groups, SharePoint displays only the group name.

There are no policy enforcement mechanisms in SharePoint that allow you to specify the particular practice for your organization – if you have the authorization to change permissions, you can use any of the options listed above.  If you want to restrict your organization to a specific set of policies or practices, this has to be enforced by business process, not my system level policies.

Here are our general best practices for reaching the right balance between using SharePoint groups and Active Directory groups based authorization:

• Assume all users are authenticated.  Anonymous access generally breaks down in anything other than a basic reader scenario.
• Don’t use generic or shared accounts – there are too many cases where a user’s ID is stored for historical purposes, meta-data, etc.
• Avoid mapping to individual users as much as possible – use a group instead so that multiple people can be added or removed from existing groups.
• For other permissions, these CAN be assigned to already established Active Directory groups. We recommend this approach over assigning individual permissions for the following reasons:
  • It keeps authorizations consistent across the organization outside of SharePoint
  • A user that is provisioned or de-provisioned within a AD group will then lose or gain SharePoint access centrally
  • Existing auditing processes at the AD level can be still used and visibility to changes is centralized within AD
  • In general, we recommend where possible to use AD groups, especially for global authorization models such as intranet readers, global editors, etc.
• For truly ad hoc, local only authorizations, using SharePoint groups is advised especially if the authorization for that site is delegated to a business user.  It’s simply easier than creating AD groups for every ad hoc scenario.
• Existing AD groups should be published so that individual site owners can use these existing groups as a reusable asset.  In many cases, site owners create their own groups simply because they don’t know the existing group structure.
• Permissions management should be delegated appropriately to those who understand it.  Permissions management is not a simple concept and changes can make big impacts.    In many cases, site owners are provided the “Full Control” permission when the “Design” role would be sufficient to create lists, manage content, etc. while keeping them from being able to change the authorization model.

We don’t believe in the purist approach to permissions management – in our experience this is simply not practical.  We have seen both extremes – All Active Directory groups and All SharePoint Groups and both approaches don’t seem to work as well as a balanced approach.  In all cases, training and good policies are key to ensuring that the organization has a consistent approach to authorizing users.

This post was written by Chris Woodill
Christopher Woodill is the Vice President, Public Sector for Navantis. With over 15 years of experience planning, managing and implementing technology strategies in both the public and private sector, Christopher is responsible for public sector sales, strategy and delivery of solutions for our clients in healthcare, government, municipalities and education.