locked
SharePoint Groups vs AD Groups RRS feed

  • Question

  • I've seen quite a few people recommend using SharePoint groups for security and that's the way I'm leaning but Microsoft recommends only using AD groups. So I'm thinking we use a mix - AD groups for sites that are managed by IT or other admins like publishing/intranet sites, SharePoint groups for team sites, project sites and other content managed by the users themselves.

    So creating new sites would fall to an admin and they'd be responsible for choosing the correct options - either create new SharePoint groups using the owner, member, viewer standard that SharePoint employs or have AD groups created beforehand and give them direct rights. Or IT can just be responsible for provisioning all sites...

    How do you guys handle this? I need a good governance plan.

    Thursday, February 24, 2011 3:55 PM

Answers

  • Are your end users and content managers going to be aware of all people moving and changing roles/departments? Are they going to want to spend the time to manage there sites at that granular a level (especially when they'd for the most part just be replicating what IT is already doing)?

    While it sounds like a good idea in theory, in practice I've found that approach always end up with users complaining about overhead and ending up just adding everyone everywhere defeating the purpose of security groups.


    SharePoint 2010 Extensions - http://sp2010ext.codeplex.com/ My Blog - http://www.withinsharepoint.com Twitter - http://twitter.com/#!/withnsharepoint
    • Marked as answer by Wayne Fan Wednesday, March 2, 2011 3:28 AM
    Friday, February 25, 2011 5:03 PM

All replies

  • A couple thoughts.

    If you use AD groups, then 'someone' outside of the site collection admins/owners can modify the membership.  In our case, we create many site collections for different groups and the administrive burden for managing the groups would be too high.

    If you're using FBA, then of course AD groups are out.

    If you only have a few site collections (or a set number), and you expect the group membership to be fairly static and your IT department wants to manage them, then go for it.


    GregM
    Thursday, February 24, 2011 6:13 PM
  • No FBA. I am getting pressure to abide by the MS best practices though (even though that disables some of the functionality built into SharePoint like site membership on My Site, opening Office docs directly, etc). The wording in that doc is pretty strong.

    I guess this is just another case of Microsoft saying "do as we say, not as we do" (as in the default single server install).

    On a side note - do you have issues with so many site collections? I'm getting a lot of demand for common business reference data stored in lists but it has to be available to all site collections. I haven't figured out an easy way to hop over collections yet.

    Thursday, February 24, 2011 10:52 PM
  • Go with AD groups and nest them within sharepoint security groups. This makes your security a lot easier to maintain and a lot more flexible. Generally a lot of the groups you need are already created in AD as well. This also makes it so when people move organizational units and get added and removed to/from appropriate groups in AD sharepoint is automatically 'aware' of the new changes.

    I've had no issues with many site collections, just good idea to segment off your site collections into reasonable content db's before hand. This you can determine based on sizing best practices for content databases.


    SharePoint 2010 Extensions - http://sp2010ext.codeplex.com/ My Blog - http://www.withinsharepoint.com Twitter - http://twitter.com/#!/withnsharepoint
    Friday, February 25, 2011 12:59 AM
  • Yeah I've already got my site collections separated into different databases. Good advice though.

    The problem with using AD groups inside SharePoint groups is that the end user can't see the members. And if they can't grant rights to users, then it's going to be a constant struggle between the business and IT to collaborate on the groups and members. We'd prefer to turn that all over to the users who manage each site.

    Plus our AD groups were named with IT in mind so the names are very long and convoluted. We'd have to put the "real" groups inside placeholder groups with friendly names, then put those inside SharePoint groups. That sounds to me like a recipe for disaster.

    If we use AD groups for the top level sites and the publishing sites (all the "non-user" content") then the user will get moved to the right department automatically when a change happens like you say. It's up to the content managers in those departments to be sure he's removed from the old content.

    Make sense?

    Friday, February 25, 2011 2:41 PM
  • Are your end users and content managers going to be aware of all people moving and changing roles/departments? Are they going to want to spend the time to manage there sites at that granular a level (especially when they'd for the most part just be replicating what IT is already doing)?

    While it sounds like a good idea in theory, in practice I've found that approach always end up with users complaining about overhead and ending up just adding everyone everywhere defeating the purpose of security groups.


    SharePoint 2010 Extensions - http://sp2010ext.codeplex.com/ My Blog - http://www.withinsharepoint.com Twitter - http://twitter.com/#!/withnsharepoint
    • Marked as answer by Wayne Fan Wednesday, March 2, 2011 3:28 AM
    Friday, February 25, 2011 5:03 PM
  • We're a medium sized company - usually no more than 100 users per department.  Less than 1000 altogether. Most department content managers will know every person in their group personally so I don't think it'll be too much work to manage.

    We also have a few departments that use SharePoint a lot and a lot that hardly use it at all (a fact we're trying to change with our 2010 upgrade). For those using it daily, the current managers have often put individual permissions on item level objects (individual docs and list entries). It's not the fully normalized IT way of doing things but they seem to prefer the control that provides.

    I think I will use the combined scheme. Thanks for helping me solidify it in my head. :)

    Friday, February 25, 2011 10:12 PM