Pros and Cons using SharePoint groups and Active directory groups, in the following post I am pointing out the Pro and Cons of using either SharePoint Groups or Ad groups as the main security container.
- Centrally managed.
- Groups can be nested.
- AD Distribution Lists or Groups can be re-used as Security Groups.
- New Users can be modeled based on exiting User.
- A Change in one AD group will impact all SP site collections referencing the group.
- Multiple applications may use the same AD groups.
- Support – not only the SharePoint team can provide assistance on security or queries regarding AD groups status.
- Only IT can manage AD security groups.
- Can’t see members inside the groups.
- External users needs to be part of AD.
- Automation will require Custom coding.
- Moving back to SP groups will be a challenge.
- AD reporting tools.
- Site owners may manage security.
- OOTB Automation.
- Easier to create exceptions on a roll based security groups.
- Visibility to security group members.
- Can contain non associates.
- Adding new user to different sites based on departments will require modifying all the groups within the departments.
- Site collections groups can’t be reused across multiple site collections.
- Can’t have nested groups.
- Sp groups only serves SharePoint.
- Naming convention can be hard to maintain.
Active Directory Groups if…
- We already have established AD groups that can be reused across multiple applications.
- We want to have strict control over security in the SharePoint environment.
- Our information architecture/site security model relies on company verticals/departments (i.e. HR Department, IT Department, Finance, etc.)
- Low number of exceptions in the security model.
- User name convention SP_SiteName_DL_Roll
- Long term solution
- Ownership and/or site information should be including in AD group properties/ how to track ownership changes ( external list ?)
SP Groups if…
- Governance model shifts control to the site owners and allows them to be in charge of who can have or cannot have access or…
- Want to use OOTB automation for access requests.
- Matrix Based / Project or collaboration sites with a lot of exceptions.
- Can be used as a short term solution ( testing environment )
In my experience allowing the end-user to manage their own team, or even worst, department sites security, may become a messy job, especial, when using SharePoint groups. even though the burden of managing security is no longer on your (IT) laps you are for a treat a few months down the road when the site owner leaves the company and you are trying to figure out the security structure. the other problem is that it is messy, you will see users in groups with weird names that are no longer in the company. Each site owner may have their own idea ( or not ) of what security should look like, so across the farm you will have multiple type of security ( roll base vs content base vs combination of the two) .