OWA Gets Remove External Access Feature
Office 365 notification MC216367 (updated August 27) announced that end users would be able to revoke messages protected by Office 365 Message Encryption (OME) if they are eligible for the advanced form of OME, licensed through Office 365 E5 or other licenses (like Microsoft 365 E5 compliance). OME allows users to encrypt or mark messages with Do Not Forward using OWA and Outlook desktop. Microsoft automatically enables OME for all Office 365 tenants with E3 or above licenses.
The new feature means that after you send a revocable message, you can use the Remove external access option to revoke access to the message (Figure 1). This feature is only available in OWA and only works for some external recipients (see below), but it’s still a nice option to have if you suddenly need to withdraw access to sensitive content that’s been distributed outside your tenant.
In addition to being able to revoke messages sent with the standard OME Encrypt-Only or Do Not Forward protection, the Remove external access feature also works for messages with an Office 365 sensitivity label, which can use rights management based encryption to secure access to content. Figure 2 shows a message protected by the Financial Data sensitivity label. Revoking access for external recipients works in the same way.
After the message is revoked, the OWA message header is changed to confirm that external access has been removed. At this point, any attempt by the recipient to open the content will be declined because “this message has been revoked by the sender.”
What Messages Can be Revoked
Revocation only works for external recipients. You can’t revoke a message delivered to recipients in your tenant. OME divides external recipients into two categories:
- Accounts in Office 365 domains and Outlook.com: You can’t revoke messages delivered to these recipients.
- Accounts in any other domain: Messages sent to these recipients can be revoked because the actual message is not delivered to their mailboxes. Instead, they receive a notification directing them to the OME portal. These notifications are called link-based messages. Recipients must authenticate with the OME portal by signing in or using a one-time passcode to access the protected content.
Revocation is possible for link-based messages because you can guarantee to block access at the OME portal. Revocation of messages delivered to other Office 365 domains or Outlook.com would require the ability to interfere with mail flow in those domains, and that’s not possible today.
Administrator Revocation
Prior to this development, protected messages could only be revoked by administrators using PowerShell or the Message encryption report in the compliance center. As the message encryption report is usually a few days behind real time and the need to retrieve sensitive information often makes revocation something that happens “now,” the best approach is to run a message trace in the new Exchange admin center (EAC) or the old Security and compliance center to find the message identifier and then revoke it with PowerShell.
Figure 3 shows the results of a message trace in the new EAC. After finding the message we want to revoke, we can check its properties to find the message identifier.
After saving the message identifier, we can use it with the Get-OMEMessageStatus cmdlet to check if it can be revoked (see below).
$msgId = "DB7PR04MB44108EE5BE4CD44B7452E20A8B050@DB7PR04MB4410.eurprd04.prod.outlook.com"
Get-OMEMessageStatus -MessageId $MsgId
ObjectState : New
Container : SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}@office365itpros.onmicrosoft.com
Subject : Project Quarterdeck
ReceivedTime : 01/01/0001 00:00:00
Revoked : False
IsRevocable : True
In this case, the IsRevocable flag is True, so we can go ahead and revoke using the Set-OMEMessageRevocation cmdlet:
Set-OMEMessageRevocation -Revoke $True -MessageId $MsgId The encrypted email with subject "Project Quarterdeck" and Message ID "DB7PR04MB44108EE5BE4CD44B7452E20A8B050@DB7PR04MB4410.eurprd04.prod.outlook.com" was successfully revoked.
Running Get-OMEMessageStatus for the message will now show that the Revoked property has changed from False to True and the recipient will no longer have access to the content.
One irritation is that Get-OMEMessageStatus shows that these messages can be revoked and you can try to revoke them with Set-OMEMessageRevocation (which tells you that the revocation is successful), but recipients will still have access to the messages. I guess the cmdlet can’t tell the difference between messages sent by link and those which go direct
Detail like this leads to a couple of lines in the Office 365 for IT Pros eBook. Even a book spanning 615,000 words can’t cover everything in depth, which is why we have this web site. But that’s no reason to not subscribe to the book.
Hi Tony,
I know we can only revoke an email that has been sent as a link-based email (wrapper email) via OWA to a single recipient by selecting the email in sent items and select “remove external access” next to where it says encrypted, but instead, for me it just says “This message is encrypted. What’s encryption?”.
But it should say “remove external access” where it says “What’s encryption?”
I’m able to revoke the email using PowerShell and that way works fine so I know the email is revokable, but end users should be able to do it via the sent items.
Licensing is not an issue we have Microsoft E5 licensing, IRM is set up as it should be but still end users in my tenant cannot revoke encrypted (wrapper) emails.
I’ve created a custom OME template, and used that via transport rules, still no “remove external access” for my users when in the sent items in OWA.
I’ve used the “encrypt” and “do not forward” options in Outlook and also via information protection labels that have been configured in Purview with encryption.
All the encryption works fine, and wrapper emails are sent to gmail/yahoo etc and I know they are revokable because Powershell says so, and I can revoke them as an admin in PowerShell, just my end users cannot do it themselves.
Any ideas Tony?
This is one of those situations where I have no idea what’s going on and can’t see the settings that might be causing the issue. Your best idea is to file a support case with Microsoft and have them check everything out. They can see the settings in the tenant and should be able to verify where things are right (or wrong). And if they find a problem, they can escalate to engineering.