none
SharePoint: Security Groups versus Distribution Lists RRS feed

  • Question

  • Hello All, I am trying to drive home the point in our organization about using Security Groups as a central point of managing users consequently cascading that security group token to SharePoint. Right now this is not being done where distribution lists are being managed in addition to indivdual SharePoint Users permissions, ultimately creating duplicate process and inefficient way of managing, cascading permission to SharePoint.

    Aside from single point of management through Modifying the Security Group through Address book within Outlook, what are the enterprise benefits to switching to Security Groups as opposed to DL's. I will have to make the argument to drive this change and need some help from the community where the key efficiencies will be from a technical perspective.

    From a support standpoint, I understand using security groups will reduce permissions helpdesk calls however will have to define process for this.

    Thanks in advance for any hints.


    SharePoint Solution Architect | MCTS
    Tuesday, December 28, 2010 7:39 PM

Answers

  • I disagree with Love Dot Net.  I consider the best practice to use AD Security Groups in conjunction with SharePoint groups.  SharePoint groups only exist within a single site collection while AD groups span the entire farm and even multiple farms IN ADDITION to being usable on shared drives and any other Microsoft product for access.  If you ONLY use SharePoint groups, then you are severely limiting yourself.  Additionally, the org using DLs instead of SGs is very limiting, because the DL gives you nothing that an SG can't give, yet it can't be used for permissions in Microsoft systems, namely SharePoint.  I've had to go through this same thing as a consultant with my current big client, and luckily they were on board with the idea.  It has been a challenge getting the AD admins to think differently, but it's working very well.  When a new group is requested, instead of creating a DL, we create an email-enabled SG (this is critical for use in SharePoint) and put all the users in it.  ADDITIONALLY, we set an owner of that group so that the help desk doesn't have to get involved when users need to be added/removed.  Instead, the owner of that group, which can be a regular end user, can manage their own group whenever they want through Outlook.  This works very, very well, and the membership of that group cascades all throughout the entire SharePoint farm as well as the shared drives.  SharePoint groups then play a role by being the containers within which SGs and individual users get added for assigning permissions.  We don't add SGs directly to the site permissions, but rather add them to SharePoint Groups, which have the permission assignments.

    I can't imagine recommending only to use SharePoint groups unless AD is not being used at all.

    Mark, hopefully you've gotten some benefits from what I wrote, but here are some bullets:

    • SGs provide all the capabilities of DLs without any cons, including email capability, which must be utilized for SharePoint purposes.  There really is no use for a DL after moving to SGs (that I know of).  DLs cannot be used in SharePoint at all for anything except that they are retrieved during the profile import and can be seen with the GetUserMembership method of the UserProfileService.asmx.
    • SGs allow for centralized management of permissions across the Microsoft stack, including SharePoint AND shared drives
    • Unlike SharePoint Groups, SGs are usable farm-wide.  SharePoint Groups only reside within a single site collection.  If you have multiple site collections, then you have to re-create and individually manage those SharePoint Groups on each one - this is not even worth considering, imo
    • SGs can be put inside SharePoint Groups - and they should be - for providing permissions to the members of a group.  SharePoint Groups provide the flexibility of including one more groups with one or more individual users, so there is no limitation here.
    • SGs can be managed by regular users very easily through Outlook as long as an Owner is assigned (one should be).  That way, the group owner can decide who is in his/her group, and it cascades that membership throughout the entire SharePOint farm as well as the shared drives.  A different person could own the SharePoint Group for determining if that group is even included at all, which is outside the purview of the SG owner (as it should be).

    ROI points:

    • Less reliance on the help desk for setting permissions across SharePoint and shared drives
    • Less reliance on the SharePoint admin team for setting permissions across SharePoint and shared drives
    • Consistent, consolidated permissions management across the entire organization
    • Ability to manage a single group for both permissions and for notification.  For instance, I use SGs to assign permissions in my solutions AND to then notify the members of that SG via workflow emails, because they show up in the SPD email picker.  This is very efficient and allows non-SharePoint/non-IT/non-techie people to maintain solutions without actually touching the solutions.

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Wednesday, December 29, 2010 12:10 AM

All replies

  • Hello,

    As best practices, it's recommended to create SharePoint Groups rather than Active Directory Security Groups, because in SharePoint, you may have to create a big number of groups, which you don't want to flood your active directory with, in addition to that, if you centeralize all your groups into active directory, then you will need to contact AD administrators each time you need to make a change to users/groups assignments.

    Unless you have some requirement that forces you not to use SharePoint groups, and use AD groups instead, I advise you not to do it.

    I hope I understand your question, please let me know if you require any more help.

    Tuesday, December 28, 2010 7:48 PM
  • Hello Love Dot Net, thanks for your reply however your answer is actually not correct based on a test I just performed prior to sending this. My administrator here was under the same impression that Security Groups could not be managed through the same DL type interface using Address Book in Outlook and to test we created one security group and one DL.

    Once both were created, with me as the Owner, I was able to add/delete/Modify membership through Outlook Address book for the SG same as one does for DL. So, users today manage their DL's through this interface and as SharePoint permissions in this current envrionment today are anything but organized, I was thinking the best approach would be to modify this DL hierarchy to Security Groups allowing for the RE-use of those converted DL's within SharePoint.

    From my perspective, the benefits are to

    • reduce permissions/support calls
    • allow single point of management through an already understood interface
    • streamline administration efforts
    • efficiently manage employee attrition

    SharePoint Solution Architect | MCTS
    Tuesday, December 28, 2010 8:01 PM
  • Hi Mark,

    the best practice on planning those groups topic can be found: http://technet.microsoft.com/en-us/library/cc262939.aspx
    It explains a lot when to use what.

    From my practice i only can say it really depends on how to use what. I'm a big fan of SharePoint Groups for securing SharePoint Sites and i also understand when to use Security Groups. It also depends on how your active directory is structured and how you have organized your active directory.

    If you plan a portal where your already have the organisational permissions stored in active directory to secure your portal. This will also come handy if you have team sites and teams definde in your active directory.

    In other cases where your have high flexible groups and group memberships like you might have in project team sites then might SharePoint groups is the weapon of choice. The Project leader normaly should know who is in the project team and should be permissioned. Communities of practice can be another use case for SharePoint Groups.

    In my opinion there is no general guideline of SharePoint Groups vs. Security Groups. It really depends on the organisation for your organisation in AD and the use cases you want to cover.

    Hope this helps.
    Kind regards Stefan

     


    http://www.n8d.at/blog
    twitter: n8design
    MCTS - SharePoint / WSS Configuration and Development
    Tuesday, December 28, 2010 9:19 PM
  • I disagree with Love Dot Net.  I consider the best practice to use AD Security Groups in conjunction with SharePoint groups.  SharePoint groups only exist within a single site collection while AD groups span the entire farm and even multiple farms IN ADDITION to being usable on shared drives and any other Microsoft product for access.  If you ONLY use SharePoint groups, then you are severely limiting yourself.  Additionally, the org using DLs instead of SGs is very limiting, because the DL gives you nothing that an SG can't give, yet it can't be used for permissions in Microsoft systems, namely SharePoint.  I've had to go through this same thing as a consultant with my current big client, and luckily they were on board with the idea.  It has been a challenge getting the AD admins to think differently, but it's working very well.  When a new group is requested, instead of creating a DL, we create an email-enabled SG (this is critical for use in SharePoint) and put all the users in it.  ADDITIONALLY, we set an owner of that group so that the help desk doesn't have to get involved when users need to be added/removed.  Instead, the owner of that group, which can be a regular end user, can manage their own group whenever they want through Outlook.  This works very, very well, and the membership of that group cascades all throughout the entire SharePoint farm as well as the shared drives.  SharePoint groups then play a role by being the containers within which SGs and individual users get added for assigning permissions.  We don't add SGs directly to the site permissions, but rather add them to SharePoint Groups, which have the permission assignments.

    I can't imagine recommending only to use SharePoint groups unless AD is not being used at all.

    Mark, hopefully you've gotten some benefits from what I wrote, but here are some bullets:

    • SGs provide all the capabilities of DLs without any cons, including email capability, which must be utilized for SharePoint purposes.  There really is no use for a DL after moving to SGs (that I know of).  DLs cannot be used in SharePoint at all for anything except that they are retrieved during the profile import and can be seen with the GetUserMembership method of the UserProfileService.asmx.
    • SGs allow for centralized management of permissions across the Microsoft stack, including SharePoint AND shared drives
    • Unlike SharePoint Groups, SGs are usable farm-wide.  SharePoint Groups only reside within a single site collection.  If you have multiple site collections, then you have to re-create and individually manage those SharePoint Groups on each one - this is not even worth considering, imo
    • SGs can be put inside SharePoint Groups - and they should be - for providing permissions to the members of a group.  SharePoint Groups provide the flexibility of including one more groups with one or more individual users, so there is no limitation here.
    • SGs can be managed by regular users very easily through Outlook as long as an Owner is assigned (one should be).  That way, the group owner can decide who is in his/her group, and it cascades that membership throughout the entire SharePOint farm as well as the shared drives.  A different person could own the SharePoint Group for determining if that group is even included at all, which is outside the purview of the SG owner (as it should be).

    ROI points:

    • Less reliance on the help desk for setting permissions across SharePoint and shared drives
    • Less reliance on the SharePoint admin team for setting permissions across SharePoint and shared drives
    • Consistent, consolidated permissions management across the entire organization
    • Ability to manage a single group for both permissions and for notification.  For instance, I use SGs to assign permissions in my solutions AND to then notify the members of that SG via workflow emails, because they show up in the SPD email picker.  This is very efficient and allows non-SharePoint/non-IT/non-techie people to maintain solutions without actually touching the solutions.

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Wednesday, December 29, 2010 12:10 AM
  • Hello Clayton, one again, thank you for the thorough response. You response is completely inline with what I am trying to accomplish. Sounds like I am going through now what you just went through with your client.

    Currently I am experiencing much resistance to change especially being new to the company. Embedded methodologies don't seem to mesh well with best practice recommendation and ultimate efficiency gains and long term cost savings. I believe your post will dramatically help drive a positive effort aligned in acheiving this.

    As for your process, did you design a Help Desk process where agents interact with AD/Exchange Admin directly OR did you design some sort of request form?

    Thanks again.


    SharePoint Solution Architect | MCTS
    Wednesday, December 29, 2010 12:33 AM
  • Hello Clayton, one again, thank you for the thorough response. You response is completely inline with what I am trying to accomplish. Sounds like I am going through now what you just went through with your client.

    Currently I am experiencing much resistance to change especially being new to the company. Embedded methodologies don't seem to mesh well with best practice recommendation and ultimate efficiency gains and long term cost savings. I believe your post will dramatically help drive a positive effort aligned in acheiving this.

    As for your process, did you design a Help Desk process where agents interact with AD/Exchange Admin directly OR did you design some sort of request form?

    Prior to rolling out SharePoint, I pushed heavily on creating a taxonomy ahead of time, which included the management of permissions through AD.  Our team then put together a list of nearly 300 groups that needed to be created according to the org structure, which is how we built our site structure, and then we used a pre-built STSADM script to build each site collection and every subsite with unique permissions, created groups for each subsite and assigned the relevant SGs to each group.  Once we went live, all new requests for groups still go through the normal process through the Help Desk, but we have educated the AD admins on the importance of creating email-enabled SGs.  Additionally, we have educated the Exchange team to make sure that new groups allow for receiving anonymous emails (simple checkbox), since SharePoint emails (workflows, alerts, etc) are sent unauthenticated.
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Wednesday, December 29, 2010 12:42 AM
  • Hello,

    Yes guys I was wrong, I had a client who's SharePoint Admins don't have AD permissions, so it was hard to depend on Active Directory groups, I projected from that scenario even it's not very common.

    One benefit of using Windows groups is that the group membership is updated when the user account changes. so if you delete the user account, the Windows group membership is automatically updated.

    The best strategy is to make the user a member of an Active Directory group. Make that Active Directory group a member of a SharePoint group and then assign permissions to the SharePoint group.

    Thanks for the correction,

    Wednesday, December 29, 2010 7:40 AM
  • Hello Clayton,

    Thank you very much.

    Wednesday, December 29, 2010 8:12 AM
  • I am new to SharePoint and I have created Groups within SharePoint and need to have the same people who are in these Groups moved or imported to an existing Team LIST on SharePoint.  Can someone tell me how to do this? or If it is possible?

    Thank you very much!

    Murraca

    Friday, July 6, 2012 4:34 PM
  • Hello Murraca,

    1. Setting up AD security groups is the easiest way as if you are the owner or manager, you can manage the people within that group directly through outlook, thus when you need those same people added somewhere else, you would simple add the group name
    2. Another way is to go to that group in Site Permissions, selelct the multiple check box option at the top of the list, then select the Actions option, then email selected users. Once your email populates with all the users, copy and paste those into your List.

    SharePoint Business Solutions Architect | MCTS 2007, 2010

    Monday, July 9, 2012 7:33 PM