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 outlook.com.  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.]

Something-As-A-Service in the Cloud

Source: Pexels

I'm going to be writing quite a bit about Azure, Office 365 and SharePoint over the next few months.  The initialisms IAAS, PAAS and SAAS will come up from time to time, so it would be helpful to explain these terms in advance:

• IAAS - Infrastructure As A Service
• PAAS - Platform As A Service
• SAAS - Software As A Service

Before we talk about the Infrastructure, Platform, and Software parts, let's talk about the as-a-service part.  What does this mean?

To understand as-a-service, you need to know what cloud computing is.  This has been a buzzword for a good few years now, and it's the backbone of as-a-service.  Wikipedia provides a good definition:

"Cloud computing is an information technology paradigm that enables ubiquitous access to shared pools of configurable system resources and higher-level services that can be rapidly provisioned with minimal management effort, often over the Internet. Cloud computing relies on sharing of resources to achieve coherence and economies of scale, similar to a public utility."

In less technical terms, cloud computing providers have huge racks of servers loaded with useful tools like databases, storage, load-balancers, web servers, and software.  They then lease space on these servers to remote users, along with access to the (usually pre-configured) tools.  This is referred to as AAS, or As A Service.  It's important to understand that cloud computing is a service provision model, not a generic term to refer to remote computers, which it's often misunderstood to mean.  Cloud computing is what's used to deliver AAS.

AAS is in contrast to "on-premise" where the servers, databases, storage, etc are all physically located within a company.  It's much cheaper to lease space on a server with access to the tools you need than it is to buy, configure and mantain all the servers and tools yourself, especially if you only need access for a short or ill-defined period of time.  Think of AAS as the digital equivalent of hiring a van - they buy the van, service it, clean it and repair it, and different people hire the van as and when they need it, then return it.  The van leasing company has the costs but makes a profit once the hiring fees have covered those costs, and you get the van you need for a relatively small outlay without any of the hassle and cost of having to actually buy a van.     

So, cloud computing providers lease space and tools as a service, but different users want different services.  Therefore there are different service models of AAS, of which the 3 standard ones are IAAS, PAAS and SAAS.  These service models are defined by the National Institute of Standards and Technology (an agency of the American Department of Commerce) in their NIST Definition of Cloud Computing (link to PDF).  This is a surprisingly readable 7-page document which is a model of economy and information, and if you're at all interested in cloud computing or AAS then I encourage you to spend a few minutes reading it.

In short, the service models explain which parts of the tech stack the vendor is responsible for, with the obvious correlation that the customer is responsible for the other parts.  Here's a diagram showing how IAAS, PAAS and SAAS divide up the responsibilities between the vendor and the customer, with On-Premise included for comparison:

Reproduced from Kevin Remde's Technet blog

With On-Premise, you manage all of the hardware and all of the software in the tech stack.

With IAAS, the vendor manages the hardware, but you choose the operating system and everything above it.  This is typically used for things like web hosting and data centres.

With PAAS, the vendor manages everything except the application and the data.  This is commonly used by software companies as a base for developing an application.

With SAAS the vendor manages everything.  A good example of this would be GMail, where every part of the tech stack is managed by Google. 

With both IAAS and PAAS the customer can choose how many resources to use as and when they need them (this is why cloud computing is often called "computing on demand").  The billing is usually dynamic and depends on the resources that have been consumed during the billing period.  It's typical to buy IAAS/PAAS capabilities and spin up additional virtual servers as required (a virtual server is a software representation of a real server), then apply a template that provides standard O/S, Middleware and Runtime.  With IAAS the customer maintains the template and with PAAS the vendor provides one or more templates to choose from.  The customer pays for every server they use.  With SAAS you're getting access to a piece of software and usually the price is determined by the number of user licences you buy.

As an example of how this works, consider the following scenario:

• Vendor A buys, configures and maintains networking, storage, servers and virtualisation to sell as IAAS.
• Web hosting company B buys IAAS from vendor A, then configures several templates for O/S, Middleware and Runtime that will appeal to different customers.  They then sell this as PAAS.
• Software development company C buys PAAS from company B, picks a template and a number of servers, then develops a piece of software on it.  
• Finally, company C sells their software as a SAAS offering to customers around the world, running on company B's PAAS, which runs on company A's IAAS.

It's not uncommon for a vendor to offer at least 2 of the 3 service models, although normally this would be IAAS/PAAS or PAAS/SAAS.  It wouldn't make a lot of sense to offer IAAS and SAAS without PAAS, because if the vendor has the capability to offer both infrastructure and software services then they've got the capability to offer a platform service.  

That covers cloud computing and as-a-service to the level that I'll be using it over the new few months.  There might be cause to look into deployment models (also covered in the NIST Definition of Cloud Computing), in which case there'll be a separate article, but that can wait until it's needed...