What are the best practices for using SharePoint Groups with AD Security Groups

Question

Does anyone here have a best practices when applying security policy to SharePoint groups? Do you use security enabled Distribution Lists in your SharePoint groups? Do you say to heck with that and add users manually?

Answer 1

Depends who you want to control permissions/access levels to your SharePoint sites. For example: If you control access with AD security groups added into SharePoint groups you might typically only have IT personnel i.e. domain administrators that can add and remove people to those AD security groups. This might result in a cumbersome security model. Using SharePoint groups with individual users you can delegate control to business/end users who may be able to add and remove users to SharePoint groups as required. This might result in security chaos…

One thing I can say is if you want some of the useful collaboration functionality to work - such as 'My SharePoint Sites' to appear in your Save As dialogues from Word, Excel etc., and for the My Site site memberships to list the sites you are a member of, you need the users be individually added to a site members groups. You can add the AD security groups here to make sure people have the right level of permissions but these other collaboration features don't seem to work unless each user is in the SharePoint Group.

Answer 2

Hey there.. I'm the PM responsible for permissions management in SharePoint

This is one of those things where there is no real best answer - both have their advantages.

AD groups are often great to use because they're updated by some backend system when people join the company, move orgs etc

SharePoint groups are useul because they let you manage their membership online

Nick raises a good point about how some of our client functionality works - this applies to the "memberships" on mysites as well

Answer 3

In addition to some of the other pros and cons that have already been mentioned one point in favor of using AD groups inside of SharePoint groups is that in large environments it tends to scale better. Here's one concrete example of this related to the indexer for the MOSS search engine (there are certainly other examples as well).

As you might expect from the name, and incremental crawl will only need to handle changes, so it can usually be run pretty frequently with minimal impact, leaving you with a nice fresh search index. However, if you have large, complex site collections with lots of SharePoint groups and unique ACLs on sites, libraries, etc, you'll find that your incremental crawls are taking a long time to complete even when very little content has changed. That's because the incremental crawl also has to map any security changes that have happened into the index so that search results are security trimmed properly. Since the index has a farm-wide scope, it doesn't really know about all the site-collection level SharePoint groups, which means that anytime the membership of one of those groups changes, it needs to "explode" all the members and reset the permissions accordingly on any items where that SharePoint group is used. However, if a SharePoint group contains an AD group, it just looks like a single "user" to SharePoint, and you can change the membership in AD to your heart's content, without worry about the performance impact to the search engine.