Estimated reading time: 5 minutes
Using OLE in Office apps combined with user permissions provided by Microsoft Purview Information Protection might not work as expected. Let’s take a look…
The ability to add or embed other objects into an Office document has been around for quite some time. According to Wikipedia, the first 1.0 version of Object Linking & Embedding (OLE) was released by Microsoft in the 1990s….. And you can still use this functionality in Office (or Microsoft 365 Apps for Business) today.
But one of our clients discovered an unexpected result when working with OLE embedded PDFs and Microsoft Purview Information Protection. In this blog, I want to document this and provide some insights. My conclusion at this time: the restriction to copy/extract information from Office documents also encompasses embedded OLE objects.
Embedding a document
If you are not familiar with this functionality, let’s take a quick look. When you insert an object in an Office document, it stays embedded in the document. A use-case might be that you have one overall Word document and you want to add some PDFs as attachments to the document. You can either create a new document and embed this, add the object from a file, and/or link to a document.
In any Office application, you can find the option Insert | Object. And that’s where you’ll find these options. When embedding a PDF, for example, you can choose to display this as an icon. If you don’t use this option, then the contents of the PDF will be displayed in your Office document. In this scenario, I’m using the icon option.
In this blog I use the example of a PDF-document embedded into an Office document as an icon. Just to be sure, I tested this scenario as well with a protected Excel-document, with another Excel-document and JPG-file embedded. The results were exactly the same. Although Excel did provide more feedback "Permissions to this workbook are restricted". I also tried embedding the PDF without using the icon, or using the link option. Again - the same results.
This business use-case or scenario is relatively simple. An Office document (either Word, Excel, or PowerPoint) is protected by Microsoft Purview Information Protection [MPIP] by using the so-called User Defined Permissions (UDP). A PDF document was embedded using an icon. When the receiving party opened the document, the permissions were granted. However, the PDF could not be opened and the relevant options were either greyed-out (Reader) or did not work (Reviewer).
Why the black screen you might wonder? That’s because the UDP does not allow me to take a screenshot of the contents. Still pretty cool stuff 🙂
User Defined Permissions
This scenario is related to these UDPs. So before continuing with the scenario, let’s take a closer look at this option. UDP can be set when using the Unified Labeling client and Windows Explorer or by setting this option in a label. When used in this last scenario, the permissions can only be set in Word, Excel or PowerPoint.
UDP comes with five specific permissions levels. And for this article, these need to be explained. Why? Because these are part of the problem. I’ve included the four main levels. The fifth level is the “Only me” level, which is not relevant for this scenario.
You might notice that the Reviewer and Co-Author are nearly the same. And keep that in mind.
When testing out the scenario, I used all permission levels. The scenario itself stayed the same. A Word, Excel, and PowerPoint document, with a PDF embedded as an icon. Without protection, this PDF could be opened by simply double-clicking or using the relevant menu option.
So what happened?
To summarize; Both the Reader and Reviewer permission levels did not allow me to open the embedded PDF document. Even when Office displayed the “Open” option, this did not work. When upgrading the permission level to either Co-Author or Co-Owner, the problem was solved.
So this made me wonder: as the Reviewer and Co-Author roles are only slightly different, might that be the cause of this problem? The difference between the two is the option to either print the content or copy/extract the content. So I tested this out.
In order to test this out, I created two different sensitivity labels based on the Reviewer role. I added the specific additional permissions to the label. One label is called EXTRACT (no printing) and the other is called PRINT (no extraction). And now, let’s test this out.
When using the EXTRACT label, the embedded PDF could be opened.
And as you might have guessed, the document labeled PRINT did not offer this function.
My conclusion, for now, is that the copy/extract permission (in either the Reader or Reviewer permission) on Office documents disallows OLE-embedded (PDF) documents from being opened. Which somewhat makes sense, but somewhat does not. It’s at least not expected by end-users.
But what now? Is there some solution for this?
There are many search references on either Google or Bing for Word embedded PDFs not opening. And it’s not my ambition to try and solve any of this 🙂 I tried to delve into the technical details for the Azure RMS EXTRACT permission. But I could not find any reference to OLE embedded documents.
From a usage perspective, you are stuck with this. UDP only allows for the build-in permission levels and these cannot be changed. So you cannot have real custom permissions which might solve this issue. One solution is to use a defined label with custom permissions. And, for example, use the “Authenticated users” option.
You could also use Office 365 Message Encryption and remove the encryption to the document when downloading. However – this doesn’t do justice to the use case for using UDP.
Another approach is to look at alternatives for embedding documents into other documents when using classification and encryption technologies. You could store all the documents in a SharePoint Online library and folder and share this folder. With a limitation on downloading documents and expiring the sharing link.
I don’t have an easy solution for this. But please leave a note in the comments if you do 🙂