Sunday 24 June 2018

SharePoint Permissions Part 5 - External Sharing

Photo by bruce mars 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. Part 3 focused on reducing your maintenance burden by using dynamic security group membership, and part 4 was all about the creation of a permissions strategy and accompanying design guide.

This has all been very internal user-focused.  What if you want to allow external users to access your site?  Or, perhaps more importantly, what if you want to make sure that only some things (or even nothing) can be shared with external users?  It's time to talk about external access.

External access is controlled at 2 levels: the tenant, and the site collection

Unlike site permissions, which cascade down and can be changed to be less or more restrictive at each of the site collection, site, library/list, folder and document levels, external sharing cannot be made less restrictive at the site collection level.  So your site collections cannot allow more external sharing rights than the tenant allows.  On the other hand, you can make your site collections more restrictive than the tenant, so if external access is allowed at the tenant level, you can prevent it at the site collection level if you want. (For reasons which will become obvious quite soon, this is probably the setup you'll want to use.)  But these are the only 2 levels at which you can change the external access settings - all of the sites, libraries/lists, folders and documents under a site collection will get their external permission settings from the site collection.

Let's start with preventing any external access to your SharePoint instance, because this is the easy part.  

To do this, you just need to turn off external access in the tenant settings by going to O365 Admin > SharePoint > Sharing and selecting the Don't allow sharing outside your organisation radio button.

If you do this then no-one will be able to share a document from a SharePoint site, nor will adding an external user to a site give them access (because when you add a user to a site, even as an administrator, you are actually sharing the site with them).  But there is a big caveat:

Turning off external sharing at the tenant level stops users sharing externally from OneDrive as well.

Now, that might be fine for you, in which case congratulations, you're done here, don't bother reading the rest of this article.

But if you want your users to be able to share externally from OneDrive, or need to allow one or more teams to share externally from SharePoint, then this won't work for you.  If you're wondering why this affects OneDrive, it's because OneDrive is a series of SharePoint sites, one for each of your users.  If you go to O365 Admin > OneDrive > Sharing, you'll see a note under External sharing that says "Your sharing settings for OneDrive can't be more permissive than your setting for SharePoint".  Hence, if you turn off external sharing for SharePoint, you're also turning it off for OneDrive.

In a scenario where even a single user needs to be able to share externally from OneDrive or SharePoint, you'll need to turn external sharing on at the tenant level.  Your options are as follows:

The options are described in detail by Microsoft here, where you'll also find an explanation of the other parameters that limit which external users can be shared with, and what those external users can do with their shared files.

One section of the parameters not covered by that Microsoft page is the sharing by security groups section:

This is known more formally - and unintuitively - as "per-group sharing".  It allows you to chose which security groups are allowed to share externally (the second option will only appear if you've chosen to allow users to share anonymous links) and you can find out more about it from Microsoft here.  Note that it also affects OneDrive, so it gives you a little more control there too.

But whatever parameters you've set, once you've allowed external sharing at the tenant level you now need to set up your site collections appropriately as well.

First things first, lets look at how you allow or not allow external sharing in a site collection.  Go to O365 Admin SharePoint > and the SharePoint admin portal will open in the Site Collections option.  Select the site using the checkbox next to it on the left hand side and click Sharing from the toolbar at the top:

If you don't want your site collection to allow external sharing, select the Don't allow sharing outside your organization radio button, click Save, and you're done: 

If your permissions strategy doesn't generally allow external sharing, set this in your template site and it will be copied through to any sites that use that template.  

If you do want to allow external sharing the full explanation of what each of these options will and will not allow can be found on this Microsoft page.  The first thing to note is that the Sharing outside your company options are missing some options that are in the tenant level options.  At the tenant level you could decide if anonymous links expire, and if so after how long, and also whether anonymous links allow anonymous users to view or edit.  You can't change this at the site collection level.  These are tenant-wide settings that every site collection will inherit.  

You can then choose the Default link type and Default link permission, both of which by default will inherit from the default organisation setting, but can be changed.

You've then got the ability to whitelist, or blacklist, domains which people can share with:

You can either whitelist certain domains (users can only share externally with users who have an email address in a whitelisted domain) or blacklist certain domains (users can share with any external users except those with an email address in a blacklisted domain).  You can't do both at the site collection level, although you can have a blacklist at tenant level and a whitelist at the site collection level.

The blacklisting is a rather odd option, in that a user from a blacklisted domain could simply create a free email address from a service that isn't blacklisted, and use that. So there would be no point blacklisting a competitor service when a user who really wanted to share with a competitor could just tell the competitor to create a new email address from a common service like gmail or  This is especially true when the blacklist must be filled in by hand, rather than syncing automatically with, for example, the untrusted site list used by a security program.  The use case for blacklisting therefore seems a bit lacking at the moment.

The whitelisting make perfect sense, however.  One site collection can only share with your external regulator, for example, while another site collection can only share with your parent company, and so on.  This gives the administrators a way to allow sharing with trusted organisations without worrying about people sharing things with whomever they want.

These lists can also be setup at the tenant level as part of the additional settings I mentioned.  If you've set this up at the tenant level, then this Microsoft page details the priorities, which I'll list here for ease:
  • In the case of conflicts, the tenant-level configuration takes precedence over the site collection configuration.
  • If a tenant-level allow list is configured, then you can only configure an allow list at the site collection level. The site collection allow list must be a subset of the tenant allow list.
  • If a tenant-level deny list is configured, then you can configure either an allow list or a deny list at the site collection level.
  • For individual OneDrive for Business site collections, you can only configure this setting by using the Set-SPOSiteWindows PowerShell cmdlet.
Note that the logic outlined above means that if a domain is blacklisted at the tenant level, this will overrule that same domain being whitelisted at the site collection level. You can list up to 1000 domains at the tenant level, but only 60 at the site collection level.  

Following on from this, you've also go the option to prevent users from sharing with external users without owner approval:

You'll have to decide if you want to change the default from allowing users to share freely, to requiring site owner approval to share.  This applies to ALL sites in the site collection and ALL sharing, whether it's internal or external.  If your permissions strategy has the administrators as site owners, this will create a lot of work, and you'd need to consider giving an information owner enhanced rights to handle this workload.

Once you've set the permissions for your site collection appropriate, click Save.

If you want to know what's being shared externally (which can often be a good way to tell if your permissions are correct) you can search for content that's been shared externally in the Security & Compliance Centre.

And that's the mechanics of external sharing.  Hopefully this series on SharePoint Permissions has been useful for you.  If there's a permissions issue you want to me to cover, drop a comment below and I'll do my best to oblige.

[Update: I was planning to write a 6th installment on SharePoint and AIP (Azure Information Protection) but there's a lot of new work going on there at the moment.  Luckily the World Cup was on, so I could spend a month watching that, but we're still waiting for some new SharePoint-related AIP functions, so I'll come back to this topic another time.]

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.