Estimated reading time: 10 minutes
When people leave the organization, we mostly focus on their user account in (Azure)Active Directory, information stored in OneDrive, and Exchange Online. But what if the user has been labeling and/or protecting documents using user-defined permissions?
Let’s start with the basics. User-defined permissions or custom permissions can be set by a user if these have been defined in the label settings and label policies. These permissions allow the user to select which users, groups, or organizations will be able to open the document using a set of pre-defined permission levels.
In addition, the user can set an expiration date and is also able to track & trace the document using the Azure RMS portal. In most use cases, the permissions for a document will be defined within the label itself, and the user will not be able to modify this. Using these user-defined permissions, we can allow our users to have more flexibility.
User-defined permissions can be added to a label. In which case, the user will need to add the permissions when that label is selected. Another option is Windows Explorer. Normally, the user-defined permissions are there as well, as the “Protect with custom permissions” option.
Some thoughts on this
Working with user-defined permissions allows the user more leeway. And information is protected in a fit-for-purpose fashion: specifically aimed at the intended recipient. But there are some thoughts on this.
First off: the document that is protected (using these kinds of permissions) will be uniquely protected. Only the users (or groups/organizations) that have been added to the permissions and the owner of the document will have access to the document.
When the document is stored/shared in SharePoint Online or OneDrive for Business, it is accessible to anyone that has access. Either by being part of the site, Team or by having shared access. But this is just access to the container. When the document has user-defined permissions that don’t match the ones on the container, then the document will become inaccessible to anyone else. Keep this in mind!
At the time of writing this blog, I did come across this Microsoft roadmap item. But if my thoughts are correct, this will still not solve the issue above.
The third important aspect to take into account when using user-defined permissions; As with any Microsoft Information Protection encryption functionality (which the setting of permissions is part of), users will need to be able to decrypt the document. And for this, you will still need a Microsoft (Azure AD) account. Just sharing a document using user-defined permissions and any e-mail address simply will not work.
And lastly: user-defined permissions allow the user to set an expiration date. Which makes sense, so use this 🙂 But if not set, then the document will always be accessible. Even when offline. And this is problematic (see below).
But one of the aspects I think deserves some more attention is offboarding employees. Normally, when employees leave the organization, IT will take care of their mailbox, OneDrive for Business, and other information locations. But what if this employee has documents that have these user-defined permissions? These need to be found and the permissions need to be changed.
First things first; for these kinds of scenarios, we will need the so-called SuperUser group in Azure AD and active within Azure Information Protection. This group allows you to decrypt information when this is required. And this is the case in these offboarding scenarios.
Finding those documents can be a challenge. Especially if these documents are not stored in Office 365 and only have the user-defined permissions attached (so: no label). In my opinion, but I can be mistaken, these are some of the options:
- Don’t do anything. When someone reports that a document cannot be opened because of permissions, let the members of the SuperUser group handle this;
- Use PowerShell to get a list of documents with user-defined permissions for the user or use the Azure RMS portal to do the same;
- Find the documents (if possible) in Office 365 or on the file shares and let the SuperUser group handle this;
- If a label was used: search for the label id and the “last modified” or “created” metadata.
I must confess, these aren’t the easiest options. But still, these need to be part of your offboarding processes. Let’s take a look.
Finding the documents
1 – Search
Trying to find documents with user-defined permissions can be difficult. The most simple scenario is one where the user-defined permissions are part of a label and the documents are stored in Office 365. In this case, you can use Search to find the specific label and the owner. For example:
2 – Content/Activity explorer
Another option is to simply use Content Explorer in the Microsoft Purview Data Classification section. Although this only shows you the label and the location where documents/emails are stored. And not who applied the label. So this is somewhat limited. And it’s an E5 add-on.
The activity explorer does provide user information and labeling information. So this might be helpful. Unfortunately, this information only goes back for one month. And this is also an E5 add-on.
3 – Classic Azure Information Protection portal
Granted – I’m not sure when this portal is going to be deprecated. But in the meantime, you can still find information on (historic) labeling activity. Although this is limited, you could look for documents labeled by the leaving employee and select the specific label. These logs go back three months. But these logs do provide additional information on the device and app used.
4 – AzureRMS
It’s another thing altogether when the documents have been protected using user-defined permissions, without the use of a label. And even more so, when these documents are not stored in Office 365. But Let’s focus for now on finding these documents.
Thankfully there are two options for this. And both are related. First of all, you can use the Azure RMS tracking portal for this. The big pre-requisite for this is (of-course) that document tracking has been enabled in the tenant. This is on by default, but you might want to check if the AIP policy is set up correctly (Get-AIPServiceDocumentTrackingFeature).
If set up correctly, then this feature will help us find documents that have user-defined permissions. Option 1 is to go to https://portal.azurerms.com. After login, you’ll see any documents you’ve protected and shared. And this even includes the option to revoke access to these documents.
When an administrator logs in, he/she will be presented with the administrator mode. And this is the one we need. Here you can find the documents that were left by the departing employee. In this case, I will use my co-worker Connie and my own documents. As you can see, Conny did not leave any protected documents.
So, let’s take a look at my account.
And here are the documents that have specific user-defined permissions. If I wanted to, I could open the specifics of the documents and see when these were accessed and by whom. But for now, this is ok.
The other option to find these documents relies on PowerShell. But in the end, it will show the same information. Using the Azure Information Protection PowerShell environment, we can use this cmdlet:
Get-AIPServiceDocumentLog -Owner <leaving employee> | Format-list
This will present me with an overview of all documents with user-defined permissions. If I want to go a bit deeper, I can use this cmdlet:
Get-AipServiceTrackingLog -ContentId <contentid>
And use the content-id I got from the previous cmdlet. This one will present me with information on accessing the document (location, date/time, user). By the way: this ContentID is used specifically for protected documents in Azure RMS. It does not show up in the search schema for SharePoint Online, for example!
Using either the portal or the PowerShell cmdlets we can get an overview of documents that might cause some problems due to the user-defined permissions. One of the options we now have is to revoke any access granted using the permissions. For this, we can use PowerShell:
Set-AipServiceDocumentRevoked -ContentId <contentid> -IssuerName <userid>
You will get to see a nice warning though 😉
But in the end, this works. Do note the notice on the offline access option! If the user has set the expiration to “never”, the document can be accessed even if the user is offline. And this is a problem because then revocation will not work. Another reason why I don’t particularly like these user-defined permissions.
Do we have other options?
As described above, these are the options till now:
- Find labeled documents when stored in Office 365 either by search, content explorer or activity explorer;
- List documents with user-defined permissions and revoke access;
- Use the SuperUser group to remove any customer permissions.
And to be honest, that’s kinda it. You cannot use the ContentID to find documents in Office 365. And both explorer functions only go back for a certain time. So my advice would be to set up a process to check for these kinds of documents (if you are using these kinds of permissions). And to have the SuperUser group ready if any documents cannot be accessed anymore.