Microsoft Entra Suite Tech Accelerator
Aug 14 2024, 07:00 AM - 09:30 AM (PDT)
Microsoft Tech Community

External Sharing with Sensitivity Labels

Copper Contributor


Can someone confirm that the only way to share a document externally that has a sensitivity label applied, is to invite the recipient as a guest into our AD Tenant? 


Say I have a partner company, and I wish only all of my users, and all of theirs to have access to particular documents.  Do I have to add them in as a cross tenant organization, and then create guest accounts for all of their users? This would seem a little unwieldly 


Additionally if I wish as an end user to apply a confidential label with just the email address of a 3rd party company having access (they that configure at the time).  Would that 3rd party user then also have to already have a guest account in our tenant? 


Seemingly without a guest account, in both scenarios, they just receive an error that no Azure AD account exists for them in our tenant

6 Replies
No. Only if the external permissions aren’t set in the label.



Hi Christian,
Thanks for the reply.
This was my understanding. However if I configure either a direct mail account or a domain within the label. Send that document to the external party. They receive the message that there is no account for them in our Azure AD

I imagine you have some conditional access policies set up. And I think this could be a case of the Microsoft Azure Information Protection app not being allowed/selected for them. Try excluding that app from CA or exclude the externals from the CA. When they are using an AAD tenant you can configure the Cross-tenant access settings under External Identities in Azure AD allowing the MAIP app (but only necessary when allowing some apps) and if not specified just check the box where you trust their MFA claims.


Been some edits now so I’ll just add this for assitance instead


*edit @Whiteb02 Did this get sorted?




Having mixed results with this at the moment.

Having turned on B2B collaboration with partner organizations, we now have some users that can successfully open the document once they provide the credentials from their own tenant (and without the need for us to create guest accounts).


We have other users from the same organization that receive the error  “Sorry, another account from your organization is already signed in on this computer”  Also a working user, from a personal device, receives the same error above.


Is it necessary for all account info in Credential Manager to be cleared out? 


Finally, on an individual user level.   If user A in my organization wants to specify the permissions themselves, before sending a document externally to 1 or more people.  Is the only way for the recipient(s) to be able to open the document, to be added as a guest within our tenant? (as we'll likely have no B2B setup for whoever it has been sent to.


Without a guest account, we again get the error above, and the recipient receives no notification inviting them to create a guest account (if required), so we'd have to pre-stage an account for them? 


It can be tricky as you’ve noticed. And the business requirement should be the baseline for how the label config is done. I think it’s better if I simply add some links as there’s too much info on the topic.

First, did you read the FAQ above?

Read this

And this

Hope that helps.

@Whiteb02 Wrote a post on LinkedIn about this. Bear in mind guest accounts could be necessary sometimes, hence read the link


External sharing of protected content. What gives?

To follow up from a question in #TechCommunity I thought I should provide my take on it.

For email content and attachments you can use #MicrosoftPurviewMessageEncryption (OME) with 'Encrypt only' and 'Do not Forward' templates. The options are available in the desktop and web client. You can also choose to exclude them from one of those clients if you'd like, using regedit/GPO or PowerShell for the web interface.

There are some config that can be made such as if the recipients should use one-time passcodes and/or social sign-in for authentication. You can use some design parts too, such as informational text and a company logo and color. Here you need to use PowerShell. For more advanced features you can include mail flow rules in #EXO with Message encryption or #DataLossPrevention (DLP) as well.

The nice thing about Message encryption is that it's very easy for end-users to understand. There are only two alternatives and both encrypt the content and the attachment. The 'Do not Forward' is encryption too, just adding some more restrictions to the recipient.

As long as the recipient is using a Microsoft identity the process is really seamless and no need to use any portal or software to view the message. If using Gmail for example they will receive a wrapper in the message directing them to the Purview Message encryption portal (OME portal) where the above options will display for authentication.

The more advanced way of working with protection are #SensitivityLabels and I'm certain many of you are either using them or have seen them. They offer super granularity when it comes to permissions and configurations and can be used all over the #M365 suite, as opposed to Message encryption which is for email messages only.

This is the part when considerations and planning are introduced and must be involved with stakeholders/business representatives as it's about #classification and data knowledge. One cannot establish permission levels in sensitivity labels and publish them to users without analyzing the business requirements.

So what are the primary considerations for external sharing of protected content? From my perspective.

- The permissions granting access in the sensitivity labels.
- Any #ConditionalAccess policies that includes the #MicrosoftAzureInformationProtection app and #MFA

When it comes to #B2B collaboration there are no extra configurations to be made from a fundamental point of view but as soon as you're securing your environment and most likely are using "all apps/users" requiring MFA you have to use Azure AD #CrossTenantAccessSettings trusting those external MFA claims. If you don't do that they will need a guest account in your tenant. And if that for some reason isn't applicable you have to either exclude the app or the external users from the conditional access policy.

There's more to the topic but LinkedIn says I've reached the character limit.