SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It only takes a minute to sign up.
Sign up to join this community
From this post - What are the best practices for using SharePoint Groups with AD Security Groups
It was mentioned by Mr Samuel Yates that there are some complications resulting from not using AD groups in SharePoint Group. In reference to larger organizations, with thousands of users, can this point be expanded upon? The example of the indexer was great; can I hear about "the other examples" that you mentioned but did not dig into?
thx
It's a very interesting discussion that comes up a lot in large enterprise. As you state, if you're trying to control thousands of users the manageability almost becomes the most important part in my opinion. We use a homegrown web application to control AD Group membership in a SharePoint-esque way... so our site owners have the ability to easily manage users without having to do it at the AD level. In large enterprise where you might have to control access based on foreign/domestic users, physical site, etc. having that tie to your AD tree is invaluable. We're primarily a WSS house, so you don't take much (if any) of a functional hit on going the AD route vs. physically setting the users up in SharePoint.
Keep in mind that there's a difference between trying to use AD Security Groups and AD Distribution Lists. You can map the former to SharePoint Groups, but not the latter.
One thing that I think is important to consider when deciding between SharePoint groups vs AD groups is whether or not groups of users need to be re-used across site collections.
A SharePoint group is bound to a single site collection, whereas an AD group can be used across many site collections.
Say for example you have 10 site collections, and five of those site collections will have the same set of users assigned permissions, while the remaining five will all have a unique set of users.
For the five that all require the same set of users, it would make sense to use AD groups to manage the users.
For the remaining five, you could either create a SharePoint group within the site collection, or create five distinct AD groups.
Generally I prefer not to have 1-1 mappings of AD groups to site collections, so for the last example there I would go for the SharePoint group option.
You may resort to using AD groups simply because those groups are managed by another team. For instance, webdes03 mentioned having foreign/domestic users. In that case, you may have a team manage that AD group that has nothing to do with SharePoint. You wouldn't want to risk the AD group getting out of sync with the SharePoint group.
