Saturday, 2 June 2018

SharePoint Permissions Part 4 - Creating a Permissions Strategy and Design Guide

Photo by rawpixel 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. In part 3 we looked at reducing your maintenance burden by using dynamic security group membership.

These 3 articles covered the technical side of setting up permissions that don't break the permission inheritance rules, adding a user to a single security group so they automatically get permissions to many sites at once, and how to add users to security groups automatically by setting up dynamic group membership in AAD.

This is the how of setting up permissions, but it's also important to understand the why of setting up permissions. If you don't understand why you're setting your permissions up the way you are, you'll just be providing permissions on an ad hoc basis without any structure. This will store up problems for the future because your permissions scheme won't be consistent, and the rationale for any given permissions can only be explained by the person who set them up. Why is Joe Bloggs in this security group when he's not a member of that department? Why does Jane Bloggs have Edit rights to this library when everyone else has Contribute rights? What's this security group used for? Why does every site have different permission levels to all the other sites? These kind of questions should not come up - and if they do come up, they should be easy to answer - if you have a permissions strategy.

As always when creating a strategy, the first question to ask is "What do we want to achieve?" Are you looking for minimal admin burden? The removal of data silos? Highly restrictive permissions to protect sensitive information? The chances are you want all of these things, but in different areas. So your strategy should lay down some general principles that guide you towards the most important goal for a particular site, but also ensure a consistent, structured approach to permissions.

Some useful principles:

  • Only restrict a site if necessary.  Most of your sites can be open, that is, everyone in your organisation has read access to the site.  You might have a library restricted to a particular team, but otherwise the site is readable (and importantly, searchable) to the whole organisation.  This helps breakdown data silos and reduces the admin burden.  A few sites will be closed, that is, only those people who need access will be given it, and this is done where there is sensitive data.
  • The higher the permission level, the less people should have it.  This means the group with the highest permission level - Full Control - should also be the group with the fewest members.  Normally this is your System Admin group, commonly the people responsible for maintaining the structure and security of your SharePoint instance.  Conversely, the group with Read access will be the group with the largest membership (normally the built-in "Everyone except external users" group).
  • Minimal complexity for maximum performance.  The more unique permissions you have in a library, the lower the performance.  This is not such a big deal for small libraries, but in larger libraries where each individual document could have unique permissions provided by users sharing things, it can cause a drop off in performance.  There's a good discussion of this problem here, and although the article is talking about SharePoint 2010 on-premise, the basic elements of load-balancers, web servers, databases and CPUs haven't changed significantly.  The performance can depreciate on both the indexing crawl and the site performance itself.
  • Breaking inheritance is the last resort, not the first.  If you have sensitive information in several folders across different libraries and you need to restrict access to these, but the rest of your libraries and documents can be read by anyone, you'll have to break inheritance for all of those folders.  That's the easy way to "fix" the access immediately, but in the long run it's just more maintenance complication and potential access problems to troubleshoot.  When you're designing the site take these issues in mind and create a single library for sensitive information.  This will make the permissions much simpler and correspondingly easier to maintain.
  • Security by design, not by accident.  Your organisation has to comply with a regulatory framework, whether that be industry- specific (e.g. Sarbanes-Oxley) country-specific (e.g. local data protection laws) or trading-bloc specific (e.g. GDPR).  A logical, well thought out permissions strategy can help prevent breaches, and, in case of a breach, also demonstrate that you incorporated sensible security measures into your design from the outset, which can help lower penalties and maintain your organisation's reputation.
  • All permissions are documented. Out of all the principles, this is probably the most important.  It's certainly the most useful, because even if you have no other principles to follow then at least you've got information about what permissions have been applied and why.  In the design document for each site - you've got a design document for each site, right? - set aside a standard section explaining what SharePoint groups you've used with what permission level you've applied, which security groups are in each SharePoint group, and an explanation of any unusual or unique permissions, and any deviations from your standards.  This information will be invaluable in a whole host of different future scenarios.
A permissions strategy is part of the governance of your SharePoint implementation.  It should be written down and accessible to the whole organisation.  All administrators who are able to add or amend permissions from the library level up should be familiar with it, and no site collection or site design should be applied to a site unless it meets the requirements of the strategy.

But whilst writing it and making it accessible is important, it's not enough.  What doesn't often get talked about is the need to convert your strategy into practical actions.  It can be difficult to understand how the strategy should be applied in day-to-day work, especially for people more used to solving technical problems than creating and interpreting policy.

So the strategy document should also have an accompanying permissions design guide that translates the strategy into concrete actions and requirements.  The guide should include what default SharePoint groups are in your site template and why, under what circumstances it's acceptable to deviate from these groups, naming conventions for security groups, and so on.  

The contents of your permissions design guide will vary according to your strategy (e.g. you may prioritise accessibility over security, or vice versa) and the overarching design decisions you've made (e.g. what your naming conventions will be, what default SharePoint groups you use, etc), so just as there is no "correct" strategy, there is no "correct" design guide.  The design guide is there to provide your designers with the practical information they need to implement your strategy.  Think of it as a tactical handbook which, if followed by everyone, will allow you to realise your strategy successfully.

A design guide takes a long time to write and is a living document.  As new functionality is added to SharePoint, the design guide will change and grow.  It would be nice to say "don't build anything until your design guide is finished!" but that's unrealistic in a production environment.  Instead, start by working out your strategic principles and getting all of the stakeholders on board.  Then at least you're all working from the same starting point.  This is doubly important if you're well into a SharePoint implementation or you've got a mature implementation you want to improve (and realistically most people reading this will be in these positions).  

The further into your implementation you are, the more potential work there will be to implement a strategy and corresponding design guide on your pre-existing sites, so don't expect to make sweeping changes.  An incremental approach that gradually improves things has a better chance of success than a radical redrawing of your permissions to fit a new strategy.  Start by creating a strategy and corresponding design guide that can be used for any new sites from now on, and when it's stable and well-understood you can look to implement it in existing sites over time.

The technical work of creating and implementing the permissions strategy is part of the admin's role.  In the next article we'll take a look at user sharing, how to modify the out of the box settings (both at tenant and site level) and what you can and can't stop your users doing.


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 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.