MS365 – Troubleshooting Encrypted Email Failures to Remote Tenants

emailencryptionmicrosoft-office-365

We are attempting to replace a secure email gateway solution with MS365's inbuilt email message encryption.

We have a mail flow rule set up to force encryption from a specific sending address to any recipient, as follows:

CONDITIONS:
Apply rule if:
Sender is '[email protected]'

Do the following:
Modify message security – Apply Office 365 Message Encryption and rights protection

  • Rights protect message with 'Encrypt' (default Encrypt policy)

Now, when we send from alwaysencrypt – which is a Business Basic licensed account in this tenant – we have odd results.

  1. When sending to a non-MS365 account/tenant/domain, email messages are property delivered and require an OTP code to be sent to validate access. This works fine.
  2. For some MS365 tenant recipients but NOT part of the origin tenant, rights management works properly and properly identifies this external tenant as a recipient and the user is allowed access.
  3. For other MS365 tenant recipients who are NOT part of the origin tenant, the system does not allow their user to login and use MS365 tenant auth to access the document and fails with a message akin to Selected user account does not exist in tenant 'Example Tenant' and cannot access the application 'UUID' in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account.

It's very new that we have this third option happen, and MS365 does NOT offer external tenants the OTP code option.

I don't see a way to address this and permit access to the rights system to external tenants without adding them manually to our origin tenant, and this is a problem because this is an automated system sending encrypted message data as part of alerting systems to external recipients.

Has anyone seen this and does anyone have any idea how we can resolve this to force it to NOT use MS365 tenant authentication for access to encrypted messages and be only OTP-code verification if they are outside the organization?

I should note that MS365 is now forcing the use of Microsoft Purview so the legacy OME solutions will not function, and there's zero documentation on how to alter this or make these revisions as needed.

Note that I have access to a Global Admin on the origin tenant so I SHOULD have access to all the Powershell options if needed.

Best Answer

So, in fact, it turns out this isn't a "tenant" issue at all, but a licensing one. Which is not straight-forward to find in the documentation, because the basic Purview pages don't even reference this, it's only in the FAQ which you don't see when you try and debug encryption stuff.

Buried here in the Microsoft Purview OME documentation in the FAQ (but NOT anywhere else on the Purview documentation), it indicates what plans Purview is automatically supported in:

To use Microsoft Purview Message Encryption, you need one of the following plans:

  • 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 to receive the new protection capabilities powered by Azure Information Protection.

  • 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.

  • Each user benefiting from Microsoft Purview Message Encryption needs a license to use message encryption.

Unfortunately, this is NOT listed on the MS365 plans pages, and not detailed in any of the other documentation about MS365 plans - at least, not anywhere obvious.

We obtained a license for Azure Information Protection Plan 1 as indicated and attached it to the alwaysencrypt user in the origin tenant. After giving Microsoft time to apply this change and the AIP service to the origin tenant, it works as expected and external tenants can now view the messages, as can non-MS365 recipients as well.

Microsoft has scored a -1 on their documentation today, but at least we resolved this with a simple solution: throwing more money at Microsoft.

Related Topic