This post has been republished via RSS; it originally appeared at: SharePoint Support Blog articles.

The Scenario

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 marcus.jones@contoso.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.

It’s about Control

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.

Your Options

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.

• Option 1: Remove the requirement that accepting users must match invited users. This is something that the inviting organization must do. To disable this feature, you may choose between the option "External users must accept sharing invitations using the same account that the invitations were sent to" check box under Additional Settings on the Sharing configuration page of your SharePoint Online tenant admin portal; or you can use the Microsoft SharePoint Online Management Console and run the following command after connecting to your tenant (using the Connect-SPOService cmdlet): Set-SPOTenant -RequireAcceptingAccountMatchInvitedAccount $false
• Option 2: The Invited Organization can add the upn of the user as an smtp-proxy address to the user object in Active Directory and sync it up to the cloud. This means that the upn of the user is a valid email address.  While this somewhat defeats the purpose of having separate email addresses and UPNs, not advertising the email address except in special circumstances, such as this, still maintains some of the original difficulty in discovering the person’s username.
• Option 3: Users who are invited to tenants that are configured in this scenario, where neither organization wants to pursue Option 1 or 2, can still create a separate Microsoft Account and log in to the partner tenant using those credentials. The easiest way to do that is to create an Outlook.Com email address and invite that address to the tenant.

Final Thoughts

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.