SharePoint Permissions Part 2 - Using Security Groups

Photo by Alex Block on Unsplash

In Part 1 of this series we looked at user groups in SharePoint sites, and how they allow you to add member permissions without breaking inheritance. Now we're going to take this a step further and look at adding groups of users to your SharePoint groups, rather than individual members.

Firstly, why would you want to give permissions to a group of users all at once, rather than individuals?  There are a number of reasons:

1. It cuts down on your work by allowing you to add/amend permissions for multiple users at once.
2. You can provide role-based security, which means giving permissions to users based on their role, by using 1 group for each role.
3. Your permissions will be more consistent, as everyone in a group will have exactly the same permissions.
4. A group can be given permission to more than one site, which means adding a new user is as simple as adding them to a group, which then gives them permissions to multiple sites.
5. Security groups can also be used to give users access to shared mailboxes, and Yammer and O365 groups, have specific permissions for documents labelled through Azure Information Protection, and various other elements of the O365 family.

A simple example is having an Administrators group, which your SharePoint administrators are a member of.  If you add this group to the Owners group in your site template, then every time an admin creates a new site using that template, all of the administrators will be in the Owners group for the new site. (I'll cover creating and deploying a site template in a future article).

How do you practically create one of these groups?  O365 allows admins to create security groups, and these security groups can then be added to SharePoint sites as if they were users.  Security groups are created in the O365 Admin portal and contain whichever users you choose.  They can then be given permissions to a SharePoint site collection (or site, list, library, folder or document).  So if you create a security group called Administrators, you can then select this security group when adding a user to the Owners group in your SharePoint site.

When you create a security group in O365, you have an option of selecting either "security group" or "mail-enabled security group".  There is no difference between these, except that you can send email to a mail-enabled security group and it will be sent to the members, which you can't do with a security group.  I haven't yet come across a SharePoint permissions use case where this has made a functional difference, unless you want to be able to send a mail to the group when you change their permissions.  But I still recommend mail-enabled security groups, because it future-proofs your implementation in case you hit a use case where you do need to mail the group.

Make sure that when you create your mail-enabled security group you turn OFF the "Allow people outside of my organization to send email to this Mail-Enabled security group" setting.  This setting is on by default for mail-enabled security groups, distribution lists, and O365 groups, presumably because Microsoft feel the majority of use cases call for this functionality.  There are pros and cons of this for distribution lists and O365 groups, but why would you want people outside your organisation to a) know your security group names (which could be useful information for someone trying to breach your security), and b) send that security group an email? Unless you've got a good answer to these 2 questions, turn this option off.

At the time of writing the O365 Admin portal doesn't distinguish between different types of group very well.  So when you're looking in the Groups option there is no way to tell if "Administrators" is a security group, a mail-enabled security group, or just a plain old O365 group, unless you set the right filter.  This doesn't seem like a big deal, but when you spend a lot of time working with groups, and your users create lots of O365 groups for collaborating, it gets rather frustrating looking through the Groups list and not knowing what type most of them are.  There's also no way to tell what a security group is used for unless you open it and look at the description, which you and your colleagues probably aren't as fastidious about filling in as you should be (I'm not judging, I forget to do it just as often as the next admin).  

To combat this problem you should use naming conventions for your security groups.  Something like "SG-[role name]" will work fine, assuming you're doing role-based security.  You can also/instead incorporate a team name, a function name, or whatever works for you.  But do this up front, and get your admins to stick to it as much as possible.  It'll make your work a lot easier over the years, especially if you have a lot of joiners/leavers/movers, or you regularly have to create new sites.  There's also - currently - no way to tell where a security group is used unless you're willing to use PowerShell, so good naming conventions and descriptions will help you keep track of your security groups.

Now that you're using security groups to add users to SharePoint groups, the next step is to look at reducing your maintenance overhead by introducing dynamic group membership.  We'll look at this in the next article.