Back in the days with the old Azure Rights Management Services solution Microsoft introduced the functionality to both track usage and the possibility revoke access to RMS encrypted information.

This function was not initially added to the new Unified Labeling client because of the low usage frequency, which led to a low prioritization of the function.

There were also some privacy concerns for some organizations regarding tracking of encrypted documents since the end user easily could track who had opened a document and from where. As a result, these organizations disabled the track and revoke -feature.

In the public preview version of the current AIP Client Microsoft have now reintroduced a track and revoke feature. This enables users to revoke their protected documents. The tracking function is also in public preview for documents protected with this preview client. Tracking is only available for administrators and administrators can also revoke documents protected with this version of AIP client.

There are currently some limitations with the revocation functionality. To be able to explain this in the best way I prefer (as always) to do a deep dive and illustrate what happens in the background during both tracking and revocation. I will also give some workarounds for the current limitations. Let’s kick off and test the new Track and Revoke -feature.

To be able to test this you need to have the AIP client version 2.9 or later

To be able to revoke a file you need to be the one who applied the protection.

If you want to test this with a new document:

1. Create a new document and apply any label with encryption/protection.
2. Then you need to close the file and reopen it again.
   After this you will have a new option Revoke Access under the Sensitivity Button
   

If you get annoyed that you needed to close and reopen the document, I will now try to explain the reason for this.

First of all, we are able to encrypt files when we are offline. This is done with help of the public organization key and the users certificate keys. These keys are cached on the device when the end-user connect to the AIP service the first time (this is called the bootstrap process).
This means that Microsoft are not aware of the files that we have encrypted.

But when we decrypt a document there will be an authentication and authorization by the MIP service and during this process the unique ContentId will be created and registered. The ContentID is the unique value that Microsoft need for both the track and revoke-functionality.

By running the PS-command for tracking, Get-AipServiceDocumentLog we can see that this ContentID is registered (after the document have been decrypted/opened for the first time)Since the contentID doesn’t change if someone make copies of the original document all copies of a sensitive document (even outside the organization) will be revoked. The exception is the one who applied the protection that still have access to all copies of the document.

Let’s test this scenario as well!

We take the original encrypted document and make a couple copies of this document and then open this with other accounts that have permissions to the document.

All access, both successful and denied access will be logged and visible with the
Get-AipServiceTrackingLog command:

Let’s go back to the original document with the user account who applied the protection and revoke access:

When this is done the end-user can easily see that the document has been revoked

Also an administrator can revoke access to the specific document with the PS command: Set-AipServiceDocumentRevoked

When I try to open the document with one of the other users, I do get a denied access which is showed with this message (after Word had tried to access the document with the logged in account):

Notice that if offline access is allowed for specific label, users will continue to be able to access the documents that have been revoked until the offline policy period expires.

If we run the same PS commands once again, we will now see that this document has been revokedAnd the central tracking log shows that we got an attempt to open this document after its revocation

Limitations and workarounds

One limitation in the current preview is that documents that have been uploaded to SharePoint Online cannot be revoked by the owner. This applies to SharePoints tenants where AIP integrations have been enabled. The reason is simply that SharePoint then decrypts the RMS protection for the document during upload/storage and contentID is then removed from the document. If a user downloads the file from SharePoint and accesses it from their local machine, a new ContentID is applied with the RMS protection to the document. In that case an administrator needs to identify the new contentID and assist the user to revoke access.

There is a couple of other workarounds to prevent the above (current) limitation:

1. If end user revocation is a business requirement for all protected documents don’t enable AIP integration with SharePoint Online
2. To be sure that you can revoke a certain information class/label. You can prevent uploading to SharePoint with this label by using EndPoint DLP or MCAS
3. If there is a business requirement to be able to revoke files stored at a certain SharePoint site/library there is a work around to enable IRM for this library. In that case protected files that are uploaded to this library won’t be decrypted.

For more details around the new Track and Revoke feature go to Microsoft docs