Revoke Access to Office Files with Sensitivity Labels and Azure Information Protection

Most of us have had that “oh <blank>” moment where we have given someone access to someone only to immediately or later need to undo that access.  Azure Information Protection has historically been able to help us there.  AIP allowed us to create protected (encrypted) documents and also let us remove access.  However, in the move from ‘classic’ AIP to the new unified labelling with sensitivity labels, the ability to revoke was lost in the transition.  Now it’s back in preview, but unlike the classic version, it’s managed on the client and not a web portal.

Revoking means we can block access to a file even after it’s been sent, even if the label applied to it gave the user permission.  For example, you have a label in your organisation named Confidential.  That label allows anyone in your company, but not outside it, permission to view the file.  You, the owner, made a mistake emailing a file with that label to someone within your company. Revocation lets you block access even after they’ve received and downloaded the file.  Note that the file must be protected – a file with a label with no protection cannot be revoked.

The prerequisite is to use the revoke files is the Azure Information Protection unified labelling client version 2.9.111.0, which must be installed for users we want to give this ability to.  Both end-users and administrators can revoke access, the latter being most likely in circumstances where the user no longer has the original file or the recipient changed the permissions to the file.  This is because revoking access is dependent on the file’s content ID and this value changes whenever permission changes; for example, if a user downgrades the sensitivity label.  Administrators are able to query the AIP service document log to find that changed content ID.  The content ID is key to making revocation work and I’ll explain some significant gotchas later on in this article.

User Experience

Without the AIP client above (or later), this is the end-user experience clicking the sensitivity button:

In this example, I’m the owner of a file with a label called custom protection (which was set up to allow the end-user to specify named user access rights – see here for that!).  You’ll note I can change the label, but that’s about it.  The label itself has no limitations on how long access is allowed.

After installing the AIP client, the file now presents a revoke access option.  An important note I found in my testing of this is that the file had to be saved and locally available on my PC.  If I accessed a SharePoint Online or OneDrive for Business file via the cloud only, it wasn’t available.

The revoke access option asks the end-user to confirm they want to proceed.

A ribbon bar confirms the action was successful.  If users who have this file are offline and offline access has been allowed, this obviously won’t take effect until they are forced to check-in (or go online with the file before that mandatory check-in).

When a user I emailed the file as an attachment to now tries to open the file, they receive the generic message that they don’t have permission.

Admin Experience

Ok, back to content ID, and some gotchas for the preview release.  This is an ID that is registered in the AIP service when a sensitivity label protected file is opened for the first time on a device with the AIP unified labelling client that supports revocation (i.e. 2.9.111.0+).  When you revoke, you revoke against the content ID, so it’s important it doesn’t change.  But it does change – a lot!

At the moment, a significant drawback is that when a file is uploaded to SharePoint Online or OneDrive for Business (or Teams… it’s all SharePoint, really!), the content ID is lost.  Take the scenario where you protect a file locally, then share it using SPO, and the recipient downloads it to their local device.  Your end-user cannot revoke this file, because the content ID was lost.

What if we need to revoke a file that has since been lost by the owner?  An administrator can use the AIPService module for PowerShell to find the content ID of files, and then revoke access.

A host of information is presented to the admin for all matching results, including the owner, created time, and existing revocation status if any.  The administrator can then take the content ID, and revoke access.

Lastly, be very careful if the document has EDITRIGHTSDATA as permission.  This will allow a recipient to remove the label, which if they do so means you can’t revoke it.  This also applies to copies of files: if a file is copied and the label changed, you won’t be revoking that copy.

Because of the above gotchas, you may, for now at least, until things improve, want to disable this feature entirely in your tenant.  This can be achieved by an administrator using PowerShell.

And to remove the choice from clients, run the following from the Exchange Online V2 PowerShell module.