RMS, Azure RMS, and IRM, are playing a critical role on the DLP front and are securing content inside and outside of organizations across the globe. The main purpose of these solutions are to ensure the recipient of content is the only individual who can access that content and they can only do so according to permissions set by the content creatorsender.
For instance, if I send the HR manager an email with my personal information in it and attached, I can apply an RMS template to that email. I can do that so I know only the HR manager can open it, view its contents, cannot print, cannot screen capture, and cannot forward it. When the HR manager goes to access that email, they are required to authenticate their identity and once verified, they can interact with the email but only based on the rules applied by my template. The rules, permissions, and encryption also stay with the content, so if the HR manager was to download the email or attachments to another device, and tried accessing the content from outside the corporate network, the same authentication verification process would take place, or I could even restrict all outside access entirely. I could even view a report of who open the email, when and from where.
That is a very powerful story around security and data loss prevention, and describes a scenario that ensures content is only being viewed by the intended set of eyes…….. and their assistant.
That’s right. Assistants or anyone who has delegated email access to a person’s mail box also has access to their RMS encrypted content. Using the same above scenario, if the HR manager has an HR assistant with delegated email access for scheduling or other assistant based tasks, if I send an RMS protected email to the HR manager, the assistant can still access and interact with that email from their Outlook client just as the manager can. The delegate will have the same level of control as the Manager, so if the applied permissions are “cannot forward and cannot print”, the delegate will be unable to forward and print. But by design, they shouldn’t be able to view the content, they shouldn’t be able to access the content at all because they were not recipients of it. This is most certainly not the intended behavior of the product.
This unfortunate loophole is present in all RMS templates, Azure RMS templates, Custom RMS templates, automatically applied templates, Transport rule templates and all IRM settings.
There is however a single exception; there is one template that is different than the rest, and behaves as expected, the default “Do Not Forward” permissions template that is loaded automatically in Office applications when RMS or IRM is turned on.
The default “Do Not Forward” template will behave exactly how you’d expect it should. Only recipients of the content can access it and their delegates cannot.
That sounds great and very promising, but what if you don’t like the “Do Not Forward” wording and want to change it, or you don’t like all of the permissions it applies (Cannot forward, Print, or Copy) and want to edit it. You cannot. There is no way to edit this template.
The next logical thought would be to identify some way to then copy this template and just adjust it to fit the rest of your needs, and have the rest of your RMS templates be variations of those one. This unfortunately cannot be done either. There is no way to copy this template. Not with any GUI, PowerShell, script, registry keys, XML files, Azure RMS settings, on-premises RMS, Exchange rules, consoles or otherwise. It is a dynamically generated set of rules that is built into the Office applications themselves and it cannot be replicated.
So if you are truly looking for secured content with absolute certainty that only the recipient of your sensitive information is the person reading or accessing it, you have to use the default “Do Not Forward” template and absolutely nothing else.