Microsoft 365 Purview Message Encryption, previously known as OME (Office Message Encryption) and before that Microsoft Rights Management, allows you to share protected email with anyone on any device. Users can exchange protected messages with other Microsoft 365 organizations, as well as third-parties using Outlook.com, Gmail, and other email services.
The feature is part of Azure Rights Management, but does not require that you set up any other Purview Information Protection such as labels or rules for auto-label or encryption. Therefore, as long as Azure Rights Management is enabled in your tenant and the user holds the correct licence, Purview Message Encryption is automatically turned on for your tenant.
Microsoft Purview Message Encryption is offered as part of Office 365 Enterprise E3 and E5, Microsoft 365 Enterprise E3 and E5, Microsoft 365 Business Premium, Office 365 A1, A3, and A5, and Office 365 Government G3 and G5. You don’t need additional licenses. You can also add Azure Information Protection Plan 1 to the following plans to receive Microsoft Purview Message Encryption: Exchange Online Plan 1, Exchange Online Plan 2, Office 365 F3, Microsoft 365 Business Basic, Microsoft 365 Business Standard, or Office 365 Enterprise E1.
To send an encrypted message so that only the recipient can open it (and allow it to be forwarded to other recipients can also open it) or to send a message (also encrypted) so that it cannot be forwarded on, you choose the Encrypt or the Do Not Forward option in Outlook when composing a message. The below picture shows Encrypting an email in Outlook:
To restrict a message so it cannot be forwarded, choose the drop-down menu below the Encrypt button, select your organization name (you might have more than one organization here if you work for multiple companies) and select Do Not Forward as shown:
You continue to compose your email and send it. This is all easy and is just like sending any other email. But when the message arrives with an external recipient there are scenarios where it should just open without additional steps but it does not. This is not easy to fix, and this is the purpose of this blog post.
When the Encrypt or Do Not Forward email arrives at the recipient, if the recipient is an Outlook user and logged into a mailbox in their Microsoft 365 Entra ID tenant then the email should just open in a new message window and look like the following:
In Outlook you need to open the message once, as its not visible in the preview pane on first viewing. Once you open the message you are authenticated and the message is now visible in the preview pane. in Outlook in the browser (OWA) you do not need to double-click the message the first time and the same is true in Outlook Mobile.
Non-Outlook clients and recipients not in Exchange Online, Yahoo or Gmail will not get this experience. Instead they will see a message telling them they have an encrypted message to read and to open that message via a web browser. This non-seamless experience looks like this:
So the problem is, what if you see the “read the message” in the portal view and you are an Exchange Online mailbox holding recipient? There are two reasons for this. They are:
- The sender’s tenant has Conditional Access rules impacting external or guest users
- The sender’s administrator has customised the Purview Message Encryption template and used a transport rule to ensure that the senders messages always use the template.
The second above is the easiest to fix – becuase you cannot! If the sending admin adds additional templates (via the New-OMEConfiguration PowerShell cmdlet) and requires that template is used via Exchange Online Mail Flow rules, the recipient will always see the template and never the seamless experience of opening the encrypted message without prompts. For example, a custom template could look like this:
The first type of error above exists when you have no custom templates enforced via mail flow rules, but does exist when your sending tenant requires Multi-Factor Authentication to access resources in the sending tenant. The problem here is that you are just a recipient of an email from the sending tenant and do not have any means of authentication into that tenant (an external recipient as far as the tenant is concerned) or you might have a guest account, but Encrypt or Do Not Forward ad-hoc Purview templates do not invoke the prompt to register or confirm that MFA request. Note that the Conditional Access rules that enforce MFA might also be a rule for IP restriction (only login via a known network) or device restriction (login with compliant device only) and these will have the same effect.
So how do you fix this one, as this first issue can be fixed. To start you need to be the sending tenant admin. If you are just the recipient, you cannot fix this unless the sending tenant admin is involved. The fix is that MFA or other restrictions on login to the tenant need to be exempted for either the Azure Information Protection app across the board, or exempted only for external users. Note that the Azure Information Protection app can also be called the Microsoft Rights Management Services app. They are both the same app and which one you have depends upon when your tenant was created (they are both 00000012-0000-0000-c000-000000000000 as the app ID).
The first of these fixes is the easiest – ensure that any Conditional Access rule that mentioned “All Cloud Apps” has an exclusion for the Azure Information Protection app:
You might need to do this on more than on Conditional Access rule depending upon your configuration, but it is only needed where “All Cloud Apps” is used. For example, if you have a rule to enforce MFA for admins to the Microsoft Admin Portals then you do not need to exempt the Enterprise app as it is not included in this rule in the first place.
This gives you a problem though – what happens if you want some of your Purview MIP labels to only work if MFA is provided, or only open “Confidential” labeled documents on compliant devices? Those conditions are enforced via the same app in Conditional Access.
To work around this requirement you need to exempt the Azure Information Protection app from any rule that involves external or “All” users and have additional rules that only apply to the internal members or guests who will open MIP labeled documents under those conditions.
This combination of two (or more) rules that say the “Azure Information Protection” app is exempt from any “All Cloud Apps” rule, but specfically included on any “internal member” rule ensures that Purview Message Encryption keeps working seamlessly.
Note: If you enable “seamless” OME and remove the portal, OME auditing and the ability to revoke emails (Advanced OME features) are no longer available.
Photo by cottonbro studio: https://www.pexels.com/photo/photo-of-cryptic-character-codes-and-magnifying-glass-on-table-top-7319068/
Leave a Reply