We have been working to develop custom utilities using Microsoft Information Protection SDK for protection of shared content for a large enterprise.
As is normal with any large and involved platform dealing with enterprise information security, we found certain errors or inadequacies that can only be realized when one does it hands on. I intend to post a series of articles about our experience in this area, each trying to mention some specific issues and some ways of addressing at least some of those.
Hope you will enjoy!
Let’s begin with a quick background.
We were building some utilities which can be used to apply/remove sensitivity labels or to change the RMS owner for the documents lying in different sources like SharePoint Online, OneDrive or File Share leveraging MIP SDK. During implementation, we have uncovered some hidden or not so documented limitations. As I said, I plan to share some of them in few separate short bubbles.
In case you need it, here is a background reference about sensitivity labels and their usage.
Limitations around Dynamic Permission Sensitivity Labels
A quick recapitulation of the types of permission associated with AIP sensitivity labels here, since the topic revolves around the same.
- Static Permission Labels: These are the sensitivity labels where Admin would define the permission set while defining the labels in Office 365 security and Compliance Centre. I might sometime refer to this type of label as templated based label.
- Dynamic Permission Labels: These are the sensitivity labels where Admin would allow the user to set the permission when user chooses to apply the sensitivity label. I might alternately refer to this type of label as specified person’s label.
We found that static permission labels can be seamlessly integrated with SharePoint with the help of AIP integration feature. However, problem arises when we try to use dynamic permission label on the document uploaded to SharePoint.
Our experience says that one might face the following issues when one deals with dynamic permission labels. Let me describe the specific use case where we ran into issues while building our solution. We have a situation where user would protect a document using a label that has dynamic permission associated with it. User does it by using AIP Unified Labelling Client in his desktop. At SPO we needed to identify the label of the document and take further business actions depending on the label. We got stuck here. Usually, the default “Sensitivity” column would get populated once the SPO is integrated with AIP. But in case of dynamic permission label, this column would not get populated. We consulted Microsoft but they said it is still not there.
As a result, the following issues surfaced.
- Sensitivity Label name is not reflected in “Sensitivity” column.
- Office Document cannot be opened on web
- Co-Authoring feature will not work
- Document will not be displayed in search result
- No easy way to identify the sensitivity label of the document
So, what do we do!
Let’s look at the workarounds that I think might be helpful given the scenario.
Issue 1 – Sensitivity Label name is not reflected in “Sensitivity” column:
I felt most of the issues mentioned above are actually linked to this issue. Out of the box “Sensitivity” column is read only and cannot be updated even programmatically. We thought and had to take a circuitous route to evolve a workaround. We added a custom multiline text column – “CustomSensitivity” in the SPO library. We downloaded the document to local drive, read the label using MIP SDK and uploaded the document back again. While uploading the event handler would populate the custom column with the label of the document.
Volia! we took it from there.
You may also like: Learn how to proactively identify and protect your sensitive information
Issue 2 – Office Document cannot be opened on web
Though we cannot open the file in web, Microsoft is providing an option to open the same document in office app. If users have the office installed in local system, they should be able to open and edit the document.
Issue 3 – Co-Authoring feature will not work
This is linked to Issue 2. As per the limitations mentioned in the article.
“Office desktop apps and mobile apps don’t support co-authoring for files that are labelled with encryption. These apps continue to open labelled and encrypted files in exclusive editing mode.”
Since document cannot be opened from web when dynamic permission label is applied, we are losing out the feature of co-authoring as well. We have not found any work around for this issue.
Issue 4 – Document will not be displayed in search result
Once we have the new custom column with required information available, we can create our custom search webparts which can query the new column and present the result to the user.
Issue 5 – No Easy way to identify the sensitivity label of a document
Our new custom column became savior for this case as well.
I think these limitations exist as we speak today. Having said that, the basic protection and classification feature with respect to Dynamic Permission label works fine with the document. This means even if the label is not visible, the said protection does get applied. Any user won’t be able to open the document if the user is not assigned to the permission set defined.
We have provided the feedback to Microsoft through various channels with an aim to make the product richer since we believe we have a great platform with AIP. However, an integrated solution for this issue is yet to come from Microsoft.
I also hope that you would share your experience about this and add value to this discussion.
Download the Datasheet to learn more about Netwoven’s Information Protection and Compliance service.
Download the Solution Brief to learn how Netwoven’s solution proactively identifies and protects your sensitive data.
Looking forward to hearing from you.
More on the next post.
We have just recently stumbled upon this exact same issue with dynamic-permission encryption labels wherein the labels cannot be chosen via office web clients, and documents with these labels applied cannot be opened with office web clients (word online, excel online, etc).
It was only after considerable head-banging and inquiries with partners that we discovered the issue was specific to dynamic labels, while static labels do seem to function correctly for the most part.
I say “for the most part” because I am finding that even with static-permission encryption labels, there are still some unexpected errors. It seems that documents stored in SPO with static-permission encryption labels which are shared to external email addresses via SPO ad-hoc link sharing will only open for certain recipients, while others receive the message “The document is protected by a rights management service, such as Azure Information Protection” (which is what led me to your page as it appears you have written the only article on the web referencing that error presently). My best guess right now is that the issue may be related to whether or not the recipient has an actual office work or school license. Curious if you have encountered this phenomenon?
Thanks for your feedback on the blog!
The problem you mentioned seems to be the authentication issue. We faced similar issue for one of our external user where user account was not managed in azure active directory and user chose "One Time Passcode (OTP) authentication" mechanism to authenticate himself. Again, once a user is registered with OTP, you can't switch them to MS Authentication without deleting their registration. So, as a solution we deleted user's existing guest registration and recommended the user to use the "RMS for Individuals approach". Here are some reference and study our team did during the investigation:
Authentication Options for External Users
Work or school account (another Azure AD tenant)
Microsoft Account (MSA) (live.com, outlook.com, hotmail.com)
Federated social providers (gmail.com, yahoo.com) OR Other public identity providers (e.g. mail.com)
One Time Passcode (OTP) authentication
Other identity and email providers (e.g. corporate on-premises infrastructure)
Recipients will need to sign up for RMS for Individuals using their company email address
· You can set up direct federation with a partner organization whose identity provider (IdP) supports the SAML 2.0 or WS-Fed protocol. New guest users from that domain can use their own IdP-managed organizational account to sign in to your Azure AD tenant and start collaborating with you. There's no need for a guest user account in your Azure AD.
Example Active Directory Federation Services (AD FS) as either a SAML 2.0 or WS-Fed identity provider: described here