AIP Error Part III – Issues with Relabelling of Documents in SharePoint/ OneDrive using App Authentication

Introduction

Remember we spoke about the incompleteness of the “Sensitivity” column while dealing with labelling of files in an MIP integrated SPO/OneDrive document library? Here are the links to my earlier articles in case you want to refer to it.

If you are dealing with relabeling of documents programmatically, you might face some issues as we experienced and here is a discussion about that along with suggestions to work around it.

Background

It is always possible for a user to change the label applied to a document by opening it in web app and relabel it.

The difficulty arises when it needs to be done from an administrative perspective. Consider a security implementation across the organization which requires standardization or alteration of the existing labels for a large number of documents lying at various online storage e.g. SPO or OneDrive. This may also be necessitated for sharing a document with external entity since the document label needs to change in most cases requiring specific permission. In all such cases, one would need an automated process to label the documents correctly.

Unfortunately, there is no support available in MIP SDK to relabel an online document directly through CSOM or using other APIs programmatically. So, we tried the following in an effort to relabel the document.

• Download the document
• Remove protection and/or label
• Apply protection and/or label
• Upload the document

Our use cases demanded that we need to be able to relabel documents lying in multiple site collections and all users’ OneDrive. We also decided to make SPO/OneDrive RMS authenticated and the activity was driven through an app having all required permissions. Everything was fine, we could download, remove the existing protection and also successfully relabel. The trouble began when it came to putting it back to the repository. It will report an unacceptable label and would error out disallowing the upload.

Diagnosis

So, what’s wrong here? We started the investigation by looking at permissions of the application trying to upload the document. We did provide almost all the conceivable permissions required. You can check at the Azure portal and by looking at Azure AD App API permissions. We checked all – Azure Rights Management, Microsoft Graph, Microsoft Information Protection and SharePoint. Unfortunately, we didn’t find anything missing.

Now back to the basics again. Let’s look at the error that is actually thrown. Here is the exception thrown from code when we try to programmatically upload the protected document using APP authentication:

“The label that’s applied to this item prevents it from being edited or deleted. Check the item’s label for more details.”

When we dug deeper and actually worked with Microsoft Support team to get to the bottom of it. We unearthed the following in the error log of Fidler Trace.

•	- Failed to get rights for labelId (mip_cc_result = 5)
•	protection\rest_clients\rest_client_error_handling.cpp.::mip::HandleRestClientError - Service error. Response code:  Message: app@sharepoint is not a valid email address.  Parameter name: delegatedUserEmail
•	XXXXXXX::HrGetRightsFromLabelId: Failed calling GetRightsFromLabelId (VmipResult = 9)

src\protection\rest_clients\protection_http_provider.cpp.80::mipns::ProtectionHttpProvider::CreateFailureException - Http request failed. Status code: 400 Response: {"Message":"app@sharepoint is not a valid email address.\r\nParameter name: delegatedUserEmail"}            432c749f-c0f1-b000-d3a0-b96b51d31f93

You may also like: Learn how to proactively identify and protect your sensitive information

Finally, it was concluded that the app’s permission is getting validated onto the sensitivity label applied to the uploaded document with some invalid email id like app@sharepoint. While the app authentication would never have any email id associated with it, still it is looking for some email id to determine whether it is a valid user or not. The trace clearly indicates that. It looks like you can only use an eligible user credential and app based authentication would not work in this case. You cannot possibly do the final upload after relabeling. Something Microsoft would look at in future, hopefully.

You may also like : AIP Erro Part I

See it for yourself

Here are few steps that you can use to verify it for yourself. To avoid any additional programming issue and to isolate the problem, we did the download, manually relabeled using AIP client. We created a stub console app only for uploading and overwriting the labelled document in the repository.

Here are the steps which can be followed using the sample stub code:

1. Make sure SharePoint site collection is AIP integrated.
2. Create an azure AD app, configure client secret, and provide all required permission to SharePoint, RMS or wherever it is needed.
3. Label a document with encryption enabled template-based label.
4. Upload the document to a SharePoint document library. Label would be reflected to Sensitivity column:

5. Change some content of the local file which you uploaded – optional
6. Open console application code from “NW.MsTickets.UploadFileError.7z” attached along with the post
7. Update TenantId, ClientId, ClientSecret in app.config
8. Open Program.cs file
9. Set SharePoint document url in variable: spFilePath(fully qualified path)
10. Set local document path in variable: localFilePath(fully qualified path)
11. Execute the code hitting F5. You should be able to get the error from line no: 78 in SPODataAccess.cs file

Possible Workaround and its flip side

As was indicated, it looked like an authentication issue. To verify, we used user-credential based authentication instead of APP based authentication to connect to SharePoint Online programmatically. And it worked!

Therefore, as a deliverable, we needed to bypass the issue somehow and create some alternative. We chose to go with mixed mode of authentication. Let me elaborate on this. We did other SPO activities like download, reading metadata of the file through APP authentication but used USER credential-based authentication (Service accounts) for the upload activity.

As we need our custom solution to work on multiple site collections and OneDrive, a major disadvantage of this approach is that we need to provide service account access to all site collections as well as users’ OneDrive which is not obviously a preferred choice to the client. We had to live with it again.

We also face the risk of crossing the threshold for number of requests since this threshold limit is considerably lower when we use user credential-based authentication as compared to APP authenticated SP calls. We tried to avoid this issue by using multiple service accounts in a round robin fashion so that requests are made from different accounts.

Takeaways

As per Microsoft recommendation in general, modern app-based authentication should be our preferred choice, but these kinds of issues force us to use the legacy way of querying SharePoint.

Like other issues mentioned in this series, Microsoft support has been appraised of this issue. Microsoft team confirmed that this behavior is “by design” and document should be uploaded by the user who has permission to read and overwrite the content to avoid this issue. As of now, our work around works great. Many a times, life is a matter of work arounds only!

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.

Let me know if you ever face the same issue and come up with some other innovative trick to circumvent this issue.

Looking forward to hearing from you.

More on the next post.