AIP Error Part I: Sensitivity labels having user defined permission does not display in SharePoint Online & OneDrive

Introduction

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.

1. 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.
2. 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.

1. Sensitivity Label name is not reflected in “Sensitivity” column.
2. Office Document cannot be opened on web
3. Co-Authoring feature will not work
4. Document will not be displayed in search result
5. 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.

Some Workarounds

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.

Takeaways

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.