Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The super user feature of the Azure Rights Management service from Microsoft Purview Information Protection ensures that authorized people and services can always read and inspect the data that Azure Rights Management encrypts for your organization. If necessary, the encryption protection can then be removed or changed.
A super user always has the Rights Management Full Control usage right for documents and emails that have been encrypted by your organization’s tenant. This ability is sometimes referred to as "reasoning over data" and is a crucial element in maintaining control of your organization’s data. For example, you would use this feature for any of the following scenarios:
An employee leaves the organization and you need to read the files that they encrypted.
An IT administrator needs to remove the current encryption settings that were configured for files and apply new encryption settings.
Exchange Server needs to index mailboxes for search operations.
You have existing IT services for data loss prevention (DLP) solutions, content encryption gateways (CEG), and anti-malware products that need to inspect files that are already encrypted.
You need to bulk decrypt files for auditing, legal, or other compliance reasons.
Configuration for the super user feature
By default, the super user feature isn't enabled, and no users are assigned to this role. It's enabled for you automatically if you configure the Rights Management connector for Exchange, and it's not required for standard services that run Exchange Online, Microsoft SharePoint Server, or SharePoint in Microsoft 365.
If you need to manually enable the super user feature, use the PowerShell cmdlet Enable-AipServiceSuperUserFeature, and then assign users (or service accounts) as needed by using the Add-AipServiceSuperUser cmdlet or the Set-AipServiceSuperUserGroup cmdlet and add users (or other groups) as needed to this group.
Although using a group for your super users is easier to manage, for performance reasons, the Azure Rights Management service caches the group membership. So if you need to assign a new user to be a super user to decrypt content immediately, add that user by using Add-AipServiceSuperUser, rather than adding the user to an existing group that you configured by using Set-AipServiceSuperUserGroup.
Note
When adding a user with the Add-AipServiceSuperUser cmdlet, you must also add the primary mail address or user principal name to the group. Email aliases aren't evaluated.
If you haven't yet installed the Windows PowerShell module for Azure Rights Management, see Install the AIPService PowerShell module for the Azure Right Management service.
It doesn't matter when you enable the super user feature or when you add users as super users. For example, if you enable the feature on Thursday and then add a user on Friday, that user can immediately open content that was protected at the very beginning of the week.
Security best practices for the super user feature
Restrict and monitor the administrators who are assigned a global administrator for your tenant, or who are assigned the GlobalAdministrator role by using the Add-AipServiceRoleBasedAdministrator cmdlet. These users can enable the super user feature and assign users (and themselves) as super users, and potentially decrypt all files that your organization encrypts.
To see which users and service accounts are individually assigned as super users, use the Get-AipServiceSuperUser cmdlet.
To see whether a super user group is configured, use the Get-AipServiceSuperUserGroup cmdlet and your standard user management tools to check which users are a member of this group.
Like all administration actions, enabling or disabling the super feature, and adding or removing super users are logged and can be audited by using the Get-AipServiceAdminLog command. For example, see Example auditing for the super user feature.
When super users decrypt files, this action is logged and can be audited with usage logging.
Note
While the logs include details about the decryption, including the user who decrypted the file, they don't detail when the user is a super user.
Use the logs together with the cmdlets listed previously to first collect a list of super users that you can identify in the logs.
If you don't need the super user feature for everyday services, enable the feature only when you need it, and disable it again by using the Disable-AipServiceSuperUserFeature cmdlet.
Example auditing for the super user feature
The following log extract shows some example entries from using the Get-AipServiceAdminLog cmdlet.
In this example, the administrator for Contoso Ltd confirms that the super user feature is disabled, adds Richard Simone as a super user, checks that Richard is the only super user configured for the Azure Rights Management service, and then enables the super user feature so that Richard can now decrypt some files that were protected by an employee who has now left the company.
2015-08-01T18:58:20 admin@contoso.com GetSuperUserFeatureState Passed Disabled
2015-08-01T18:59:44 admin@contoso.com AddSuperUser -id rsimone@contoso.com Passed True
2015-08-01T19:00:51 admin@contoso.com GetSuperUser Passed rsimone@contoso.com
2015-08-01T19:01:45 admin@contoso.com SetSuperUserFeatureState -state Enabled Passed True
Scripting options for super users
Often, somebody who is assigned a super user for Azure Rights Management needs to remove encryption from multiple files, in multiple locations. While it’s possible to do this task manually, it’s more efficient (and often more reliable) to script this using the Set-FileLabel cmdlet.
You can also use this cmdlet to apply a new label that doesn't apply encryption, or remove the label that applied encryption.
For more information about these cmdlets, see Use PowerShell with the Microsoft Purview Information Protection client from the PurviewInformationProtection PowerShell documentation.
Note
The PurviewInformationProtection module is different from and supplements the AIPService PowerShell module that manages the Azure Rights Management service for Microsoft Purview Information Protection.
Removing encryption from PST files
To remove encryption from PST files, we recommend that you use eDiscovery from Microsoft Purview to search and extract encrypted emails and encrypted attachments in emails.
The super user ability is automatically integrated with Exchange Online so that eDiscovery in the Microsoft Purview portal can search for encrypted items prior to export, or decrypt encrypted email on export.
If you can't use Microsoft Purview eDiscovery, you might have another eDiscovery solution that integrates with the Azure Rights Management service to similarly reason over data.
Or, if your eDiscovery solution can't automatically read and decrypt protected content, you can still use this solution in a multi-step process together with the Set-FileLabel cmdlet:
Export the email in question to a PST file from Exchange Online or Exchange Server, or from the workstation where the user stored their email.
Import the PST file into your eDiscovery tool. Because the tool can't read encrypted content, expect these items to generate errors.
From all the items that the tool couldn't open, generate a new PST file that this time, contains just encrypted items. This second PST file will likely be much smaller than the original PST file.
Run Set-FileLabel on this second PST file to decrypt the contents of this much smaller file. From the output, import the now-decrypted PST file into your discovery tool.
For more detailed information and guidance for performing eDiscovery across mailboxes and PST files, see the following blog post: Azure Information Protection and eDiscovery Processes.