Link to home
Start Free TrialLog in
Avatar of J.D. Payne
J.D. PayneFlag for United States of America

asked on

OME Encrypted Emails Error When Opening in Outlook Desktop Client

Hello Experts,

We are using Microsoft 365 E5, and have Office 365 Message Encryption enabled and it is working as expected for the most part, as long as the recipient (external, not a member of our source domain) opens the message in a browser.
However, when we send an encrypted message and the same external recipient attempts to open it from their desktop Outlook client, an error occurs:

"Something went wrong
Unfortunately we're having trouble signing you in. Try again in a few minutes. If this doesn't work, contact your support person and report this error.
AADSTS90072: User account 'user.name@receiving.domain.org' from identity provider 'https://sts.windows.net/f46xx8xx-7900-4x10-8xxx-xxxxxxxx/' does not exist in tenant 'Our Source Domain' and cannot access the application 'dxxxxx6-52xx-4102-xxxx-aad2292xxx01x'(Microsoft Office) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account."

Again, if the recipient uses Outlook online through a web browser, this error does not occur and the encrypted message opens up fine.
Could this be caused by the Outlook desktop client blocking links and other fucntionality because it is from an external user that is not added as a Trusted Sender?
I checked the backend settings for IRMconfiguration and OMEconfiguration, and everything looks to be set to default following the Microsoft OME documentation, so nothing has been changed on the backend by one of our admins.
Any ideas how to fix this issue, or even what could be the cause?

Thanks in advance for any insight!

Avatar of Saif Shaikh
Saif Shaikh
Flag of India image


This issue is discussed in 

Office Message Encryption - Recipient not able to open office attachments.

https://docs.microsoft.com/en-us/answers/questions/95843/office-message-encryption-recipient-not-able-to-op.html

This is by design, as protection is embedded in the file itself. If you want them to be able to download attachments in unencrypted form, use the configuration detailed here: https://techcommunity.microsoft.com/t5/microsoft-security-and/admin-control-for-attachments-now-available-in-office-365/ba-p/204007 

By default the attachments in an encrypted message remain protected when downloaded. To allow recipients to download Encrypt-only attachments without encryption, please refer to the article shared by michev:
  1.  Set-IRMConfiguration - DecryptAttachmentForEncryptOnly $true

Open in new window



Also refer additional article and see if you have 1. any conditional access policy configured to enable Multi-Factor Authentication for guest accounts and/or 2. another policy to restrict access to all unauthenticated users.

Microsoft’s understanding is that each external user we want to share data with AIP (Azure Information Protection) with should be added as a guest account.

https://www.cloudsecuritea.com/2020/01/caa20004-aadsts90072-user-account-from-identity-provider-does-not-exist-in-tenant/

Avatar of J.D. Payne

ASKER

The issue is not with an attachment, it is with opening the actual encrypted email itself from the Outlook desktop client.
I am very intimate with the OME document you linked, and completely understand the reasoning behind all of it.
I never said anything about an attachment in my original post.
However, I do appreciate your response.

I was able to fix the issue myself, I just hadn't had time to post the fix here.

After researching the actual error message code "AADSTS90072" on this AAD error codes site:
Azure AD authentication & authorization error codes | Microsoft Docs 

AADSTS90072PassThroughUserMfaError - The external account that the user signs in with doesn't exist on the tenant that they signed into; so the user can't satisfy the MFA requirements for the tenant. This error also might occur if the users are synced, but there is a mismatch in the ImmutableID (sourceAnchor) attribute between Active Directory and Azure AD. The account must be added as an external user in the tenant first. Sign out and sign in with a different Azure AD user account.

That definitely points to a MFA Conditional Access policy, which we do have in place for all users.
In that MFA Conditional Access policy, under the 'Assignments > Cloud apps or actions' section, we are targeting 'All cloud apps'.
I added an 'excluded cloud app' exclusion for the "Azure Information Protection" app. Tested, Problem solved.

Again, thanks for your response.

ASKER CERTIFIED SOLUTION
Avatar of J.D. Payne
J.D. Payne
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
yes, glad to here your issue was resolved, however if you look at the second solution which I posted is the same for your resolution. My be I was a little late in posting it before you managed to resolve on your own.

Thanks again.


Yes I did recognize you as being helpful. Thanks again!
welcome.