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:
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.