Sunday, 20 May 2018

SharePoint Permissions Part 3 - Setting up Dynamic Security Group Membership

Photo by Henry Be on Unsplash

In part 1 we looked at how permissions inherit and cascade, and using SharePoint groups to avoid inheritance problems.  In part 2 we covered using mail-enabled security groups in O365 to make your permissions more consistent.  Now it's time to look at reducing your maintenance burden by using dynamic security group membership.

This sounds quite complicated, but in reality it simply means letting Azure Active Directory (AAD) handle group membership based on attributes like department or role.

If you set this up then when people join, move, or leave they will automatically be added to or removed from security groups.  If you're using security groups in SharePoint, this will lower your maintenance burden considerably.  It also allows you to set up a permissions strategy that doesn't require everyone who deals with user accounts to know the ins and outs of what permissions any given user requires. Dynamic security group membership is a "set it and forget it" system where AAD will handle putting people in whichever security groups are appropriate based on their user profile attributes.

This doesn't mean it doesn't need management, as you'll need to add the dynamic membership requirements to new groups, and change the requirements for existing groups if/when your organisation's structure changes.  But, after you've set it up for the existing groups, that's all you'll have to do in the future.

Here's how to add dynamic membership to a group.
  1. Open AAD and find your security group:


    (If you've not done this before, open the O365 Admin portal, select Azure Active Directory in the left hand launch panel, and there is a "Find a group" option in the default dashboard view.)

  2. Click on the group to select it.  The menu on the left hand side will display the options for that specific group. Click Properties:


  3. The Membership type of your group will be displayed:


  4. Change the Membership type from "Assigned" to "Dynamic User".  A confirmation dialogue will pop up; click Yes on this:

    WARNING: Doing this will remove existing users from your group.


  5. Click the new Add dynamic query option that has appeared at the bottom of the Properties panel, and create your rule from the dropdowns:


  6. Click Add query at the bottom of the panel to add the query to your group.  AAD will then populate the group membership with all users who match your query.
If you want to add more than one query (e.g. department = Sales AND Location = New York) then instead of adding the query through the dropdowns you'll need to click on the Advanced rule tab.  This provides a code window for you to enter a more complicated query.  

Microsoft have provided a thorough overview of the syntax and valid terms for advanced queries which I encourage you to work through.  It might appear intimidating initially (especially if you're not used to command line or PowerShell scripting) but it's really quite simple once you understand the logic.  Being able to write multi-part queries will significantly increase your options for dynamic membership, especially if you have situations where some, but not all, members of a team need to be in a group.

Once you've added the appropriate membership rule to a group, you've finished.  Your group now has a dynamic membership that will change automatically based on user attributes.

Between SharePoint groups, security groups, and dynamic group membership, you've got all the tools you need to make sure that the right users have the right access to the right SharePoint areas, all done automatically based on their user attributes.  However, knowing how to do this is just the technical side of permissions.  You also need to understand who should have access to what, and why.  This is the function of a permissions strategy, which we'll look at next.


Saturday, 12 May 2018

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, rather than individual members.

Firstly, why would you want to give permissions to a group of users, 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.



Monday, 7 May 2018

SharePoint Permissions Part 1 - Understanding Inheritance and Cascading



Photo by Jon Moore on Unsplash

SharePoint permissions are a common source of confusion and frustration.  This isn't because adding permissions for a new user is particularly difficult for an admin (although I'll cover one way to do that below), and nor is it because sharing a document with someone is particularly difficult for a user (although I'll cover that in a future article).  It's because it's very common to find yourself in a situation where you've given the correct permissions to a user, but they still can't see what you expect them to see.

Fear not though, because once you understand how permissions work you'll be able to fix your problems and prevent them happening in the future.  (Note: we'll be going through permissions for team sites - sites with lists and libraries - not Communications sites or the recently introduced Hub sites.  That's for a different time.)

To understand how SharePoint permissions work, you need to understand the hierarchy of objects, as well as inheritance and cascading.  

The hierarchy of objects in SharePoint is the equivalent of a family tree.  You have a node at the top (the parents), with nodes underneath (the children), nodes underneath them (the grandchildren), and so on. In SharePoint the hierarchy is:



The permissions for each of these nodes are inherited from the node above (the parent).  The Document node inherits permissions from the Folder node, which inherits from the Library node, and so on up to the Site Collection node. (If you're not using Folders then the Document node will inherit from the Library node.)

The converse of inheritance is cascading, that is, the permissions cascade down from the node above to the node below.  When you give a user permission to view a site, that permission cascades down to the library, then cascades down to the folder, then down to the individual documents.

Ok, so far so good: You create a site collection, give permission to people to view it, and they'll be able to view every site, list, library, folder and document underneath that site collection.

But that is the simplest possible option, and assumes a) that you don't need to give specific permissions to any particular object, b) that you won't give anyone else permissions to a specific object in the future and c) that no user will share a folder or document with anyone.  If any of those things happen then you'll find that the permissions aren't doing what you expected.

The reason for this is quite simple, and is at the heart of understanding SharePoint permissions: Giving unique permissions to an object breaks the inheritance.  

This means that if you, for example, give permissions to a user to see a specific library, the inheritance is broken.  So when you change the permissions in the site or the site collection, those changes won't cascade down to the library that has unique permissions.  Let's work through an example.

You create a site collection with yourself as Primary Site Collection Administrator.  Your site collection has one site, and 3 libraries called TestLib1, TestLib2, and TestLib3.  Each library has a folder called TestFolder1, TestFolder2, and TestFolder3 respectively, and each folder has a document called TestDoc1, TestDoc2 and TestDoc3 respectively.  Diagrammatically:



You give Alice and Bob edit permissions at the site level.  This cascades down to the nodes below, shown here as green nodes:



Alice and Bob have edit permissions to all of the green nodes.  If they - or you - add additional libraries, folders or documents then all 3 of you will be able to see the new objects, because the permissions will cascade down to those objects from the site.  

Now you decide to allow Charlotte to have access, but only to TestLib3.  This permission cascades down to the folder and document.  Charlotte's permissions are shown here as orange nodes:



Now Alice, Bob and Charlotte can all see TestLib3 and the folder and document underneath it, but only Alice and Bob can see TestLib1 and TestLib2.  

Now you give permission to Dave to the whole site - in other words, you want him to have the same access as Alice and Bob.  So you give him permission to see the site, and.....he can only see TestLib1 and TestLib2, and the folders and documents contained within them, shown in red below:



Why?  

Because by giving TestLib3 unique permissions - for Charlotte - you broke the inheritance, so permission changes at the site level will not cascade down to TestLib3.

Now imagine that Dave shared TestFolder1 with someone else in the organisation.  You give Ellie permission to the site, and her permissions are shown in purple:



Because Dave shared a folder (a very common action for users to perform), the inheritance for that folder is broken, and permission to it (and the document it contains) no longer cascades down.

To make matters more confusing, the inheritance that is working means that if Dave adds TestFolder1a to TestLib1, Ellie will be able to see it, because TestFolder1a will inherit permissions from its parent, TestLib1:



The situation now is that:

  • Alice and Bob can see the site, all 3 TestLibs and the folders and documents contained in them.
  • Charlotte can only see TestLib3 and the folder and document within it.
  • Dave can only see TestLib1 and TestLib2, and the folders and documents within them.
  • Ellie can see TestLib2, along with the folder and document in it, as well as TestLib1 and TestFolder1a, but not TestFolder1 and the document in it. 

Oh, and if you remove Alice's permissions by mistake, then give her those exact same permissions back....she'll have the same permissions as Ellie, because of all the breaks in inheritance.

It should be easy to see how complicated this can get.  At this stage you're already in a mess, and if you have an organisation with hundreds of users and a few sites, it's almost impossible not to get in this mess.  

However, there is a simple solution to stop this mess happening: Groups

If you give access to a group, then you can add and remove users from that group without breaking inheritance because the group always has permissions.  

To take a simple example, you might create a group that has Admin rights to the site and a group that has Edit rights to the site.  These permissions will cascade, and all lists, libraries, folders and documents will inherit those rights.  

In the example shown in the diagrams, you would be in the Admin group and Alice and Bob would be in the Edit group.  If you give Charlotte edit rights to just TestLib3, and then add Dave to the Edit group, he will now have access to all 3 libraries because he is a member of a group that already has access to them.  After Dave shares TestFolder 1, you add Ellie to the Edit group, and again she has access to all 3 libraries and all of the folders and documents in them because she is a member of a group that already has access to them.  

But if you then gave Frank edit permissions to the site as an individual, rather than adding him to the Edit group, he wouldn't be able to see TestLib3 (because you broke the inheritance when you gave Charlotte edit rights to it), nor would he be able to see TestFolder1 or the document in it (because Dave broke the inheritance when he shared TestFolder1).

So groups allow you to maintain your intended permissions no matter which user you add to them or in what order the users are added.  To add a group, go to Site Settings > Site Permissions and click Create Group in the ribbon.  However, you'll find that there are already a number of default groups there, as per this list from Microsoft, and you may find the the ones you want are already there.  You can delete any you don't need, or create any that you do.

It's common to just use the Owners, Members and Visitors groups, with Full Control, Edit and Read rights respectively.  This is something that Microsoft suggests, but it's by no means required.  Set up whatever groups you need!  If you want to know more about each of the default groups and what permissions they provide, there is a full list here, under the Default Permission Levels dropdown.

Next time we'll talk about using security groups to make your security both more robust and more manageable.