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

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

By Devjani Roy  |  Published on September 7, 2020

AIP Error: 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.

2 comments

  1. Great Article!
    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!
    – James

    1. Hi James,

       

      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

      References

      Work or school account (another Azure AD tenant)

      Microsoft Account (MSA) (live.com, outlook.com, hotmail.com)

      • Recipients can create a new Microsoft account with the email address that was granted permissions in the sensitivity label

      Federated social providers (gmail.com, yahoo.com) OR Other public identity providers (e.g. mail.com)

      • Recipients will need to create a Microsoft Account using their Gmail/Yahoo email address
      • Google Federation: If federation with Google is set up in Azure AD, invited users can sign in to your shared apps and resources with their own Gmail accounts, without having to create Microsoft accounts (MSAs).
      • Facebook Federation: To allow users to sign in using Facebook, you'll first need to enable self-service sign-up for your tenant. After you add Facebook as an identity provider, set up a user flow for the application and select Facebook as one of the sign-in options

      One Time Passcode (OTP) authentication

      • The email one-time passcode feature can be a fallback method to authenticate B2B guest users when they can't be authenticated through other means like Azure AD, a Microsoft account (MSA), or Google federation. 
      • At the time of invitation, there's no indication that the user you're inviting will use one-time passcode authentication. When the guest user redeems an invitation or accesses a shared resource, they can request a temporary code, which is sent to their email address. You can view guest users who authenticate with one-time passcodes in the Azure portal
      • https://docs.microsoft.com/en-us/azure/active-directory/external-identities/one-time-passcode

       

      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

       

      Direct Federation

      ·         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

Leave a comment

Your email address will not be published. Required fields are marked *

Unravel The Complex
Stay Connected

Subscribe and receive the latest insights

Netwoven Inc. - Microsoft Solutions Partner

Get involved by tagging Netwoven experiences using our official hashtag #UnravelTheComplex