New OME Encryption Template, Criticism Revisited…Alex Fields
Spooky. Lately it’s like Microsoft is following this blog or something. I have been working on a number of posts that I’m rather excited about.
First, I had one of my biggest wishes come true, with the release of Files On-Demand for OneDrive (included in Fall Creator’s update).
Additionally, I’ve been piloting Microsoft 365 (not Office 365), and find that it is indeed answering some of my long-standing requests for simplified security & cloud-based device management, to help us wean off on-premises AD solutions of old (new post coming soon on that).
And now, just a week or two after I openly complained about the new Office Message Encryption (OME) features, I find that they are making strides toward fixing those, too.
New template: Encrypt
The major issue with the new release, version 2.0 as they call it, is that the only option for applying message encryption was Do Not Forward. It was either that, or one of the Confidential templates. The latter were only good for sharing content internally. The former was fairly limited, as it forced you to apply the permissions for Do Not Forward, meaning that the messages and their attachments were fairly… how do I put this nicely??
Enter the new “Encrypt” template. I hope they make this the default for the “Protect” button in OWA too (it is still set to Do Not Forward). With the new Encrypt template, you can apply just message encryption, which the users cannot remove. However, they can still forward, print, copy and edit any attached document. If they forward the message, it will remain encrypted on down the line, to the next recipients, etc.
If you are already using the new message encryption, you can see this feature from OWA immediately; just choose Protect on a new message, then Change Permissions.
From the drop-down menu, select Encrypt rather than Do Not Forward.
If you have any transport rules setup that apply Do Not Forward for encryption, I’d recommend updating them to Encrypt (unless you really like the DNF template).
In Outlook, I note that the content does not open directly in the application, like it does with Do Not Forward. Instead, Outlook will have you sign-in to view the message via a web link, but the link is presented right in the message, similar to how a Gmail or other external user would see it. I really like the consistency of experience here actually. One of the more frustrating parts about the way it used to work was that it would be different depending on who was receiving the message. This makes it difficult for companies to provide recipients with instruction. So kudos, MS. This is definitely a step in the right direction.
Click to sign-in to the message, and you will have an OWA-like web page, from which you can reply OR forward. WHAT?!!
The attachments also will have a different set of permissions, much preferable to the Do Not Forward variety:
UPDATE 06/18/2018: One of our community members found an excellent article to supplement this piece–thanks Jacob! It is also possible to “disable” the IRM permissions which get applied to attachments entirely, when using the Encrypt template. The cmdlet for doing so (when you are connected to Exchange Online via PowerShell), is:
Set-IRMConfiguration -DecryptAttachmentFromPortal $true
For more details on how this changes attachments when using the “Encrypt” template, see this article.
In short, it’s basically exactly what we’ve been asking for. Thank you, Microsoft, for listening to your customers (I’m positive I could not have been the only person asking about this, either–I’m sure it wasn’t because of this blog, but the timing for this was just funny).
Excellent write-up! I’ve been wondering about that. Thanks for sharing!
Have you any information on why the “Encrypt” only template is not accessible within the Outlook client yet? I also like your Essentials solution to removing Hybrid and retaining sync, looking to implement that for a customer shortly.
That is a good question, Matt! I wish I knew, and I hope it shows up soon too.
Excellent Article. I have been struggling with the changes that have been made to the original RMS to facilitate AIP, and now we have OME which will do what I want. I wonder when will the protect button appear in outlook?
Right?! We’re waiting for that… In the mean time, on a new message you can go to Options > Permission. Or File > Set Permissions.
What about fixed the 2 month expiry of the link?
These are all very cool and practical updating by the product group at Microsoft. These posts are great observations and extremely useful pointers by you, Alex.
I have a question that you or one of your followers here might be able to answer ; if the OWA ‘Protect’ button is available to a tenant’s clients – where they have enabled the ‘new’ message encryption for Office 365 built on top of AIP – but they have no option at all to select, “Change permissions | Remove” beneath that ‘Protect’ button, is that visibility for the template permissions still controlled by the OME v.1 “Set-IRMConfiguration – ClientAccessServerEnabled” command being set to $true (visible IRM tempaltes) or $false ( hidden tempaltes) ?
I appreciate any feedback or ideas.
any update on the 2 month expiry ? also can you edit the logo and text on this template? I assuming its via powershell
It is possible to add branding, but not sure about the expiry piece.
Is it possible to stop the new OME just using encrypt mode from adding permissions/restriction to attachments? When we send an encrypted email to several people, not all of them get permission to view the attachment for some reason.
Do you know if it is possible to disable the rights management/permissions and just have it use encryption in transit and at rest? We have to revert to the old encryption sometimes when the recipients cannot view the attachment because of permission.
The templates which apply rights management are default templates, but it is possible to create your own, as well. The “encrypt” template should be already fairly permissive (document is not locked from edits or prevented from forwarding). However, depending on the requirements, you might just need to setup a TLS connection to another organization–that would not apply any rights management to the message at all, and this ensures that messages are encrypted in transit at least. At rest would have to be handled by the recipient organization in that case (you can’t control what happens on their servers).
I talked to Microsoft for about an hour and I told them we have been using the new MOE for about 2 months and this rights management only started recently. If we encrypt an email with an attachment and send to several recipients , not all of them are getting the permissions to open the attachment. I dont know if their Outlook is outdated or OME is just messing up and not giving all of them rights. They said the new OME is always being updated and for us to ensure our Outlook is updated. MY response is do you want me to tell a 1000 partners to update their Outlook. This is going to be a big problem if they do not fix this or make it easy to disable adding rights management to the attachment and just encrypt.
I am going to attempt to make my own template right now in Azure and test it out.
UPDATE: Microsoft support failed me again. They told me you cannot remove rights management but after some more research I did….it is possible. It is possible to disable rights management to attachments when encrypting an email with the new OME. Its a little trickier when an O365 user gets it but other wise works great.
This link is a valuable contribution, thank you Jacob. In case others weren’t following this conversation–I will update the article with this description.
I have played with the new settings and it still seems to apply to recipients who use Office 365. However, those should be well verified since they should be logged into their O365 account. Non-O365 users, no rights will be applied to thee attachment….which is a majority of people.
I know this is an old thread but I got a question. SO we have been using Microsoft OME v2 for awhile now and for the most part I got everything down and “usually” don’t have problems with it. Once in awhile a customer/partner cannot open or even see the encrypted email and the problem can be fixed usually using one of 2 methods.
Most problems are due to the partner having a Microsoft O365/Outlook email and using Outlook (desktop). It seems the decryption is stuck in the middle somewhere due to them using O365 email. Sometimes it can be fixed by double-clicking the message preview which kicks in downloading encryption/IRM rights to their computer.
The other cause is that the user is not signed into Outlook by going to File -> Account (Office Account)-> User Information, so they need to sign in with the Microsoft email account that the encrypted email was sent to.
That is not my question but I thought I would share that since I am sure people are still having issues with OME v2. My question is do you know if it is possible to send an encrypted email to a non-Microsoft distribution list? I have tested it with a Microsoft account to a Microsoft account distribution list and it works ok but apparently it is not working for other email providers.
I am sure it is because encryption relies on being signed into the email address the encrypted email was sent to and this is not the case with a distribution list.
Yes, thanks for this. Right–you would not send to a distro list but rather to intended recipients. They might be missing the point if they are trying to send OME to a distro list. It’s purpose is to ensure that only the intended recipient can sign into the message. There are other forms of encryption such as TLS, S/MIME, etc. that provide a different kind of encryption and experience, but they are different from OME.
Thank you for this post. Has anyone discovered a way to completely disable the (Forward) option to the recipient within OME. The reply is handy to send back encrypted messages but I cannot find a a way to disable.
I ok disabling all reply/forward if necessary.
The “Do Not Forward” option does disable forward option but maintains reply.