Marcus from Contoso Ltd is collaborating on a project for Fabrikam Inc. In order to facilitate the collaboration, the Project Manager for Fabrikam, Denise, invites Mark to a SharePoint Online Team site using the external sharing features. She looks up Marcus’ email and adds him to the SharePoint Site, using his email address email@example.com. Marcus receives the invitation, clicks on the link, and instead of being presented with the SharePoint Online site he was expecting, instead gets the following error:
Confused, Marcus reaches out to Denise, and through her, they open a case from Microsoft Support. Unfortunately, the response from Microsoft Support is that there is nothing wrong with their tenant that Microsoft Support can fix. Unfortunately, this is a situation where two competing and completely valid IT security decisions are conflicting.
When a user is invited to collaborate with SharePoint Online, the user or administrator will designate an email address. An invitation email is sent to that email address that contains a link to AcceptInvite.aspx. When the user clicks the accept invite link, they are then authenticated to their service either using an Organizational Account – that is, an account issued by a tenant in the O365 service (also referred to as ‘Your Work or School ID’) – or using a Microsoft Account (also called MSA, or Live.com accounts). By default, a user who is invited using an email can choose to accept using an account with a different email, such as using their Microsoft Account.
For some customers, however, particularly those with stringent data protection policies, such a situation was far from ideal. In order to conform to such policy requirements, SharePoint Online Tenant Administrators can configure their tenants to require external users to accept their invitations using the same email that was initially invited. This way, they can have additional assurances that the user who was viewing the data was the user who was authorized to do so.
However, some institutions take a different approach to their account naming conventions, choosing to keep their Email Addresses separate from their User Principal Names. This allows another layer of obfuscation, requiring malicious attackers to guess the user name as opposed to simply entering the email address that is displayed across the internet and on every business card that gets passed out.
When these two configurations meet, however, we find ourselves in one of the most frustrating situations in Support. When everything is working exactly as intended, and exactly as the individual administrators want it to, but it prevents users from doing their work. In these situations, the only way forward is to revisit certain decisions and look at the options available. We should be careful to point out that since nothing is technically broken, there is naught that Microsoft Support can do to remediate this issue, short of facilitating the conversation between partner organizations who wish to collaborate using the External User feature of SharePoint online.
If you find yourself in this situation, either trying to invite an external user to collaborate, or as an external user being invited to another tenant, the best way forward is to have your IT team reach out to your partner organization’s IT team, and reference this article. There are several ways to work around this problem, none of which are perfect, but will allow partnered organizations to make the decision that works best for everyone.
Whatever collaborating partner organizations choose to do, it should be done after careful thought as to the original needs that caused the organization to choose their current configuration, and in open dialogue between partner organizations.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.