SharePoint Online & OneDrive External Sharing

I would like to start this post by saying every organisation is different. Everything written here is based on my experience, and the challenges that I have faced with external sharing within my organisation. It is somewhat likely that some of what I mention here may apply to your external sharing needs, but your circumstances will likely have many avenues that differ, and I do not advocate for the same approach to external sharing in all situations.

The challenge:

In my organisation, the business structure is very complex. There is a small Group function, overseeing the wider business, which is split into several different global divisions, each in turn having their own legal entities, sites and employees around the world. At a Group level, we take care of a single Microsoft 365 tenant however, there are IT departments for each division and in some cases, regional IT departments within those divisions. Totalling around 13,000 users across all divisions of varying sizes and complexities.

Managing a single tenant in these circumstances can be tricky. Divisions want to do different things at different times often requiring configuration that impacts other divisions and the way they work. This also means that our divisional IT teams cannot have admin level access to the tenant, to prevent unforeseen business impact to other divisions. I will not go into fine detail here but the main take-away is that as a business we strike a balance between divisional administration autonomy (managing users, hardware, on-prem applications etc) and Group IT governance and control over shared services, such as Exchange, AzureAD, SharePoint, PowerPlatform etc.

When it comes to SharePoint this is a particular challenge. Each division operates independently and some are large entities in their own right. They each produce different products, sell to different jurisdictions, and have their own set of standards and policies, although there are also Group level requirements that all businesses within the Group must comply with. This ultimately means that we require independent divisional "Intranets" that all share the same tenant, and also, link back to the primary Group Intranet.

This structure provides a concern when it comes to governing external sharing within the organisation. Some divisions will share with external parties heavily, whilst others will be minimal. Some will require very tight control over external sharing, whilst others will be more flexible. This is our ultimate challenge here. How do we maintain control and balance useability?

The Microsoft Defaults:

Microsoft defaults are very open. On a new tenant, external sharing settings as seen in the SharePoint Admin Center are the most permissive. The standard settings are:

- Anyone can share files and folders using links that don't require sign-in
- The default sharing link type is "Anyone with the link"
- The default permission for sharing links is "Edit"
- "Anyone" links do not expire
- Guests are permitted to share items they don't own
- Guest access expires after 100 days
- People using a verification code must reauthenticate after 30 days
- All SharePoint sites, upon creation, allow external sharing from that site

Of course, these defaults can be changed, and there is a large amount of choice amongst these settings to tweak the overall experience with external sharing to meet your needs.

Anyone Links:

The first thing that we changed was the complete removal of "Anyone" links. Allowing our users to create a link to SharePoint or OneDrive content, that anyone can click on and access, without sign in, perpetually (as the links do not expire) was not acceptable to us. At the very least, where a sharing link is used, we wanted to ensure that when a link is created, only those users who are listed against the link could access it. I know this is not perfect, as the use of generic emails such as "sales@somecompany.com" could be used etc. The main aim here was to at least target external access rather than leave the gates completely open. We also required that guest access automatically expired after 21 days, ensuring that access was for a reasonable yet limited period, and that guests using a verification code needed to reauthenticate after 7 days. This also means that the default sharing link type is automatically changed from "Anyone with the link" to "Only people in your organisation" and it can be restricted further to "Specific People".

The principle of least privilege:

In order to, at the very minimum, provide an environment where the Principle of least privilege could be followed, even by those end users who did not know of its existence, We decided that it was important to change the default link type to "View". This does not prevent the usage of "Edit" rights with sharing links but at least provides a more secure default. We also removed the ability for guests to share content that they do not own. In my opinion, this setting should not even exist as allowing this removes almost all control over the content.

We also decided that not everyone in the business needs to share externally, and those that do, should have a valid business case for doing so. This was tricky. As the Group IT function is very small and does not have the capacity to manage this for 13,000 users. This required devolving the administration of this to the individual divisions. We achieved this by using a setting in the SharePoint Admin Center that allows you to restrict the ability to share with external users to particular AD groups. As our divisional IT teams already manage their own AD structure through child domains in the domain tree, we could utilise individual AD Security Groups for each division to manage those users that can share externally. It is worth noting here that this also restricts which users can share externally from OneDrive (there is currently no ability to separate this between SharePoint and OneDrive) which for us was a bonus but may provide a different issue for other organisations.

The SharePoint Problem:

This left us with the final hurdle. SharePoint. With all the above completed, we were left with a few key questions on how to apply some standards and defaults to SharePoint, without restricting the divisions:

1. How can we set the default external sharing setting on all newly created SharePoint sites to "Off", regardless of how those sites were created?
2. How can we allow divisional IT teams to turn external sharing for a SharePoint site back "On", easily, with limited SharePoint knowledge and limited administrative access?
3. How can we prevent end users from changing the external sharing settings for their SharePoint sites, without first engaging with IT?
4. What do we do about all the legacy SharePoint sites, that were created before these changes?

Here is what we did. For point 1 above, we created a new Site Template (previously called site designs) and applied a Site Script which turned off external sharing. We then made this new site design the default site design for all new SharePoint sites. Microsoft has good documentation on these and how they work, please see the link HERE for more information.

For point 2, we then created a second Site Template with a different Site Script which enabled external sharing. This Site Template was set so that only those users in an AD Security Group could apply it. This AD Security Group was at the root of the domain (controlled by Group IT) and contained nested groups from each division, meaning that each divisional IT department could define who was able to apply this template. The IT team then need only visit the SharePoint site that required external sharing to be enabled, and apply this Site Template. As users would not be included in the AD Group that allows them to apply the template, they could not turn on external sharing by themselves, thus meaning they would need to engage with their divisional IT team, covering point 3.

Point 3 is a bit of a monster. There are thousands of SharePoint sites in our tenant created before these changes were made. However, with the creation of the new Site Template it is relatively easy for divisional IT teams to switch off external sharing by simply applying the template. With the added security that users were no longer allowed to share externally (unless they were placed in a particular AD Group), we asked the divisions to audit their own SharePoint sites and asked them to apply the new "External Sharing Off" template to those sites which did not require it.

Conclusion:

This is not a perfect solution. Personally, I do not believe that there is one. Either you can restrict external sharing so much that external collaboration is difficult to impossible or open it up so it is a potential security risk. Striking a balance here is difficult for any organisation and your requirements will dictate how far you go. I believe that for us, what we have done strikes the right balance and allows for easier administration for all our IT teams, as well as providing them the ability to self-report, audit, and review. Our changes provide a massive improvement over the Microsoft defaults. There are many more things that Microsoft could do to help us manage this better. Such as, the ability to manage a single tenant more like AD with SharePoint "child domains", and the ability to segregate some of the OneDrive settings from the SharePoint ones. Just because someone can share externally from OneDrive does not mean they should be able to do the same from SharePoint. I have not touched on the sharing settings within the SharePoint sites themselves here. In our organisation, SharePoint sites have business owners who can manage these settings themselves, and these settings apply to both internal and external sharing settings. If you would like to know more about these settings, Microsoft has good documentation about it HERE.

I hope you found this article useful, or at least interesting. I welcome any constructive feedback and comments about this, our approach and the information provided. If you have anything you would like to add or ask about, please feel free to leave me a comment below.