Office 365 & SharePoint Online - Control sharing with External Users, uggly but effective workaround
At the time of writing, Office 365 is a great solution that is ready to use and usually a perfect platform for small to mid-sized enterprises having not too many constraints regarding data confidentiality, data sharing etc..For larger enterprises or "sector senstiive" (bank, pharma...), things can be a little more challenging when it comes to collaboration with external partners.
As of now, the only way to collaborate with partners in 365 is to enable external sharing. However, external sharing is often seen as a problem by sensitive companies because:
- It allows people to share a site/document with ANYONE in the world
- There is no garantee that the person who receives the invitation link is well the one who will accept it. If the mail gets intercepted or forwarded to anyone else, anyone with either a Microsoft account, either an Organizational account can accept the invitation and have access to potentially sensitive documents
In other words, you cannot restrict external sharing to specific partners only. It would be great if Microsoft could come with the following extra options:
- Offer an option to limit sharing with Organizational accounts only. This would not protect against the mail issue but would at least ensure that people you invite have at least a tenant and not anyone in the world with a Microsoft Account (or who could create one on the fly). It'd be better than nothing
- A better option would be : limit the domains users are allowed to send invitations to. This is the workaround I'll explain a bit later. That would still not protect against the mail issue but would at least prevent users from sharing with anyone.
Before jumping into that workaround, let's see what else me and others have tried
- http://blog.atwork.at/post/2014/12/06/How-to-use-external-users-in-Share.... Here the key is to use another AAD to create external users. The problems I see with this approach : 1) people can still invite anyone, they're not restricted to sharing only with users from that AD. 2) Invited people have another set of credentials to remember and cannot use their own credentials (either Organizational, either Microsoft account)
- I tried to dig the GRAPH API to add external users to the Office 365 AAD. It works but...it seems that external users created by SharePoint Online are flagged differently. When a person accepts an invitation, SharePoint Online creates a new user (if necessary) in the Office 365 AAD. You can easily recognize them if you go to 365's admin portal and list users. You'll recognize external users because they have a "#-EXT-#" in their UPN. If you click one of those, you won't be able to change anything, options are grayed out and 365 tells you explicitely that you can't change them. When an external user is created in the 365 AAD with the GRAPH API or with the Management Portal, you also see the "-#ext#-" thing in the UPN but you are allowed to assign them licenses etc..This clearly means that they are not truely considered external...altough it i's indicated in their UPN.
The interesting bits I found out is that if you add a Microsofft Account in the 365 AAD via the Azure Management Portal, a corresponding #ext# user shows up in the 365 admin portal but if you then grant that account to access a SharePoint site, the owner of the Microsoft account cannot log in using his credentials. The management portal (as well as the graph API) actually creates another user and you can only login using 365 credentials...although the account shows up as "Microsoft Account" in Azure. This is quite funny to see! So, what's the point of adding Microsoft Accounts to 365 AAD if they cannot login using with their account? Well, I found out that if you bind an Azure web site (or onprem web site) with the 365 AAD for authentication, people will be able to login with their Microsoft Account to your web site but not to SharePoint Online. This clearly means that the only way to have a true external user is SharePoint Online is to let it send an invite and go through its special way of adding users.
I thought : ok no problem, let's see if CSOM allows to share programmatically...no luck! That's where you start thinking workarounds.
That workaround isn't dirty but can be tedious for end users. A way to mitigate the "share with anyone issue" could be to create a custom permission level you'd call "Business Owners" that doesn't include the "Manage Permissions" permission. That will prevent people from sharing with external users. So, sharing would be made possible only for allowed users (full control/site col admins). This is absolutely clean but it means that you need to put a "request process" in place so that whenever users want to share with external users, they need to ask it to someone with the proper permissions. It works but can be tedious and slow down (if not kill) the user adoption.
Here comes the dirty workaround. I tested it and it works fine! If you provision your 365 collaboration sites automatically (which is our case), you could provision this:
- A list with unique permissions (read for everyone), write only for site collection administrators providing you don't set business users site collection administrators
- That list would contain the allowed domains users could send invitations to
This per site collection approach allows you to envision a "one collaobration site per partner" strategy and have a more granular way of allowing domains. If on the contrary, you want to allow all your collaboration sites to invite the same domains, you could provision this list in the root site collection of the collaboration web application.
- Disable the Share button
- Add a FocusOut event to the People Picker control
- Check the resolved entities and see if their domain matches any of the allowed domain list
- Adjust the Share button availability accordingly
This is what it looks like in pictures:
Last but not least, you'll need to provision a custom action of type scriptlink at site collection level to inject your script in every page.