This article is contributed. See the original author and article here.
In this article we are going to clarify a topic which has been causing a lot of confusion and questions among our customers: “How do we securely share emails and documents with someone outside of our organization using sensitivity labels?”
Disclaimer: Considering diversity of operating systems and productivity applications used these days and vast amount
of possible combinations of identities and software used, we will not be able to cover all possible scenarios in this
article but will focus on the most common ones instead.
We assume that the reader has some basic knowledge about sensitivity labels, their purpose, how to create, apply, and manage them. If you are new to this field, a good place to start is here. We also highly recommend to spend fair amount of time reviewing documentation on Azure Right Management Service (RMS), which is a critical component of all our Information Protection solutions, responsible for encryption and access control management.
Before we jump into it, let’s set the stage by clarifying a few things first. Everything we are going to cover in this article is applicable to both the client-based solution a.k.a. Azure Information Protection (AIP) as well as the modern built-in labeling capability in Office 365 applications which is part of a broader Microsoft Information Protection (MIP) framework. Both solutions use the same unified sensitivity labels.
Note: If you for some reason have not migrated your existing sensitivity labels to the Unified Labeling yet, it is
about time to do that as the AIP classic client and label management in the Azure portal will be deprecated on
March 31, 2020. Please find more info on deprecation notice here.
We are also going to be focusing on Microsoft Office and Adobe PDF as the most used file types and that have full classification and protection support.
Alright, let’s say you need to implement a solution that will allow your users to securely share emails and documents with people outside of your organization (consumers, partners, auditors, etc.). In other words, share it with someone whose identity and device is out of your control.
When you create a sensitivity label, you can either determine which users get which permissions to content that has the label applied, or you can allow your users make this decision when they apply the label (also commonly known as user-defined permissions or UDPs).
When it comes to the predefined permissions (Assign permissions now), we have four options as shown below.
“Add all users and groups in you organization” is pretty much self-explanatory, all existing and future users and groups from your Azure Active Directory (AAD) tenant will be able to access and consume the protected content (emails and documents). This is a great option for secure internal collaboration, therefore, we are not going to spend a lot of time here.
“Add any authenticated users”, with this option we can encrypt content and limit what users can do with protected emails or documents, but can’t limit those who should be able to access this protected content – any authenticated user will be able to do so.
An example scenario might be when you need to share certain information (e.g. financial reports) with your customers or partners. Even if it’s overshared, it won’t cause any issues to your business, but you want prevent this information from being copied and re-used outside of your documents. In addition to that, it is possible to make the protected content time-bound as well as control whether users can access it offline and for how long. In this case your label may look like this:
“Add users and groups”, this option allows you to provide a list of AAD users and groups and specify what permissions that user or group will have for the protected content.
Note: There are several identity and software requirements and limitations that we are going to cover in detail
later in this article.
For example, you can create a label for a team working on a specific project and allow them to use that label to securely collaborate with an approved list of external partners.
You can invite anyone to collaborate with your organization by adding them to your directory as a guest user. Guest users can sign in with their own work, school, or social identities.
Note: Please take a moment to review current Azure Active Directory limitation and restrictions.
This is a very granular and flexible way of managing who will be able to access your protected content but it does add additional work to your AAD administrators.
“Add specific email addresses or domains”, with this option you can specify a list of specific emails or the whole domains.
For instance, if you are a group of companies, each one with its own AAD tenant, you can list all domain names so that every user of those orgs will be able to access content protected by this label.
If you have very complex requirements for your label you can mix and match any of those four options.
Last option that we have is “Let users assign permissions when they apply the label” a.k.a. the user-defined permissions, that lets users specify who should be granted permissions and what those permissions are.
This is a good option when you do not know upfront who your users will be sharing the protected content with and you feel comfortable with transferring responsibility of making an appropriate security decision to the end users.
Note: As of this writing (9/15/2020) not all platforms support the user-defined permissions yet. Please keep an eye
on our documentation to track our progress.
Now, let’s switch sides and talk about what kind of identity and software your partners/recipients would need to have in order to successfully consume the protected content (emails and documents) you would like to share with them.
When it comes to identity, we can determine five main categories: Work or school accounts (AAD), Microsoft Accounts, Federated social providers, Public email providers, and everything else.
Protected emails.
|
Identity type |
OS |
Email clients to open protected emails |
|
Work or school account (Azure Active Directory)
|
Windows |
|
|
MacOS |
|
|
|
Android |
|
|
|
iOS |
|
|
|
Microsoft Account (live.com, outlook.com, hotmail.com) |
Windows |
|
|
MacOS |
|
|
|
Android |
|
|
|
iOS |
|
|
|
Federated social providers (gmail.com, yahoo.com) |
Windows |
|
|
MacOS |
||
|
Android |
||
|
iOS |
||
|
Other public email providers (e.g. mail.com) |
Windows |
|
|
MacOS |
||
|
Android |
||
|
iOS |
||
|
Other identity and email providers (e.g. corporate on-premises infrastructure) |
Windows |
|
|
MacOS |
||
|
Android |
||
|
iOS |
Here are a few examples of what user experience depending on a platform and type of identity used would be.
Protected documents.
|
Identity type |
OS |
Applications to open protected documents |
|
Work or school account (Azure Active Directory)
|
Windows |
For Office documents:
For PDF documents:
|
|
MacOS |
For Office documents:
For PDF documents:
|
|
|
Android |
For Office documents:
For PDF documents:
|
|
|
iOS |
For Office documents:
For PDF documents:
|
|
|
Microsoft Account (live.com, outlook.com, hotmail.com) |
Windows |
For Office documents:
For PDF documents:
|
|
MacOS |
Not supported. Please keep an eye on our documentation for updates. |
|
|
Android |
For Office documents:
For PDF documents:
|
|
|
iOS |
Not supported. Please keep an eye on our documentation for updates. |
|
|
Federated social providers (gmail.com, yahoo.com)
Recipients would have to create a Microsoft Account using their Gmail/Yahoo email address. |
Windows |
For Office documents:
For PDF documents:
|
|
MacOS |
Not supported. Please keep an eye on our documentation for updates. |
|
|
Android |
For Office documents:
|
|
|
iOS |
Not supported. Please keep an eye on our documentation for updates. |
|
|
Other public identity providers (e.g. mail.com)
Recipients would have to create a Microsoft Account using their public email address. |
Windows |
For Office documents:
For PDF documents:
|
|
MacOS |
Not supported. Please keep an eye on our documentation for updates. |
|
|
Android |
For Office documents:
|
|
|
iOS |
Not supported. Please keep an eye on our documentation for updates. |
|
|
Other identity and email providers (e.g. corporate on-premises infrastructure) |
Windows |
Recipients would need to sign up for RMS for Individuals using their company email address |
|
MacOS |
||
|
Android |
||
|
iOS |
Here are a few examples of what user experience of accessing a protected document depending on a platform and type of identity used would be.
Now you are probably wondering what’s about SharePoint Online, OneDrive and Teams? There is a lot of work is being done to enable different B2B and B2C scenarios for secure information sharing there and it is a subject for its own blog post. So, stay tuned…
References:
Configuring usage rights for Azure Information Protection
Applications that support Azure Rights Management data protection
Revoke email encrypted by Advanced Message Encryption
Automatically encrypt PDF documents with Exchange Online
Configuring secure document collaboration by using Azure Information Protection
Sharing encrypted documents with external users
RMS for individuals and Azure Information Protection
Which PDF readers are supported for protected PDFs?
Update history for Microsoft 365 Apps
Known issues with sensitivity labels in Office
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments