Edit

Preparing users and groups for Azure Information Protection

  • Article

Note

Are you looking for Microsoft Purview Information Protection, formerly Microsoft Information Protection (MIP)?

The Azure Information Protection add-in is retired and replaced with labels that are built in to your Microsoft 365 apps and services. Learn more about the support status of other Azure Information Protection components.

The new Microsoft Information Protection client (without the add-in) is currently in preview and scheduled for general availability.

Before you deploy Azure Information Protection for your organization, make sure that you have accounts for users and groups in Microsoft Entra ID for your organization's tenant.

There are different ways to create these accounts for users and groups, which include:

  • You create the users in the Microsoft 365 admin center, and the groups in the Exchange Online admin center.

  • You create the users and groups in the Azure portal.

  • You create the users and group by using Azure AD PowerShell and Exchange Online cmdlets.

  • You create the users and groups in your on-premises Active Directory and synchronize them to Microsoft Entra ID.

  • You create the users and groups in another directory and synchronize them to Microsoft Entra ID.

When you create users and groups by using the first three methods from this list, with one exception, they are automatically created in Microsoft Entra ID, and Azure Information Protection can use these accounts directly. However, many enterprise networks use an on-premises directory to create and manage users and groups. Azure Information Protection cannot use these accounts directly; you must synchronize them to Microsoft Entra ID.

The exception referred to in the previous paragraph is dynamic distribution lists that you can create for Exchange Online. Unlike static distribution lists, these groups are not replicated to Microsoft Entra ID and so cannot be used by Azure Information Protection.

How users and groups are used by Azure Information Protection

There are three scenarios for using users and groups with Azure Information Protection:

For assigning labels to users when you configure the Azure Information Protection policy so that labels can be applied to documents and emails. Only administrators can select these users and groups:

  • The default Azure Information Protection policy is automatically assigned to all users in your tenant's Microsoft Entra ID. However, you can also assign additional labels to specified users or groups by using scoped policies.

For assigning usage rights and access controls when you use the Azure Rights Management service to protect documents and emails. Administrators and users can select these users and groups:

  • Usage rights determine whether a user can open a document or email and how they can use it. For example, whether they can only read it, or read and print it, or read and edit it.

  • Access controls include an expiry date and whether a connection to the internet is required for access.

For configuring the Azure Rights Management service to support specific scenarios, and therefore only administrators select these groups. Examples include configuring the following:

  • Super users, so that designated services or people can open encrypted content if required for eDiscovery or data recovery.

  • Delegated administration of the Azure Rights Management service.

  • Onboarding controls to support a phased deployment.

Azure Information Protection requirements for user accounts

For assigning labels:

  • All user accounts in Microsoft Entra ID can be used to configure scoped policies that assign additional labels to users.

For assigning usage rights and access controls, and configuring the Azure Rights Management service:

  • To authorize users, two attributes in Microsoft Entra ID are used: proxyAddresses and userPrincipalName.

  • The Microsoft Entra proxyAddresses attribute stores all email addresses for an account and can be populated in different ways. For example, a user in Microsoft 365 that has an Exchange Online mailbox automatically has an email address that is stored in this attribute. If you assign an alternative email address for a Microsoft 365 user, it is also saved in this attribute. It can also be populated by the email addresses that are synchronized from on-premises accounts.

    Azure Information Protection can use any value in this Microsoft Entra proxyAddresses attribute, providing the domain has been added to your tenant (a "verified domain"). For more information about verifying domains:

  • The Microsoft Entra userPrincipalName attribute is used only when an account in your tenant doesn't have values in the Microsoft Entra proxyAddresses attribute. For example, you create a user in the Azure portal, or create a user for Microsoft 365 that doesn't have a mailbox.

Assigning usage rights and access controls to external users

In addition to using the Microsoft Entra proxyAddresses and Microsoft Entra userPrincipalName for users in your tenant, Azure Information Protection also uses these attributes in the same way to authorize users from another tenant.

Other authorization methods:

  • For email addresses that are not in Microsoft Entra ID, Azure Information Protection can authorize these when they are authenticated with a Microsoft account. However, not all applications can open protected content when a Microsoft account is used for authentication. More information

  • When an email is sent by using Office 365 Message Encryption with new capabilities to a user who doesn't have an account in Microsoft Entra ID, the user is first authenticated by using federation with a social identity provider or by using a one-time passcode. Then the email address specified in the protected email is used to authorize the user.

Azure Information Protection requirements for group accounts

For assigning labels:

  • To configure scoped policies that assign additional labels to group members, you can use any type of group in Microsoft Entra ID that has an email address that contains a verified domain for the user's tenant. A group that has an email address is often referred to as a mail-enabled group.

    For example, you can use a mail-enabled security group, a static distribution group, and a Microsoft 365 group. You cannot use a security group (dynamic or static) because this group type doesn't have an email address. You also cannot use a dynamic distribution list from Exchange Online because this group isn't replicated to Microsoft Entra ID.

For assigning usage rights and access controls:

  • You can use any type of group in Microsoft Entra ID that has an email address that contains a verified domain for the user's tenant. A group that has an email address is often referred to as a mail-enabled group.

For configuring the Azure Rights Management service:

  • You can use any type of group in Microsoft Entra ID that has an email address from a verified domain in your tenant, with one exception. That exception is when you configure onboarding controls to use a group, which must be a security group in Microsoft Entra ID for your tenant.

  • You can use any group in Microsoft Entra ID (with or without an email address) from a verified domain in your tenant for delegated administration of the Azure Rights Management service.

Assigning usage rights and access controls to external groups

In addition to using the Microsoft Entra proxyAddresses for groups in your tenant, Azure Information Protection also uses this attribute in the same way to authorize groups from another tenant.

Using accounts from Active Directory on-premises for Azure Information Protection

If you have accounts that are managed on-premises that you want to use with Azure Information Protection, you must synchronize these to Microsoft Entra ID. For ease of deployment, we recommend that you use Microsoft Entra Connect. However, you can use any directory synchronization method that achieves the same result.

When you synchronize your accounts, you do not need to synchronize all attributes. For a list of the attributes that must be synchronized, see the Azure RMS section from the Microsoft Entra documentation.

From the attributes list for Azure Rights Management, you see that for users, the on-premises AD attributes of mail, proxyAddresses, and userPrincipalName are required for synchronization. Values for mail and proxyAddresses are synchronized to the Microsoft Entra proxyAddresses attribute. For more information, see How the proxyAddresses attribute is populated in Microsoft Entra ID

Confirming your users and groups are prepared for Azure Information Protection

You can use Azure AD PowerShell to confirm that users and groups can be used with Azure Information Protection. You can also use PowerShell to confirm the values that can be used to authorize them.

Note

Azure AD and MSOnline PowerShell modules are deprecated as of March 30, 2024. To learn more, read the deprecation update. After this date, support for these modules are limited to migration assistance to Microsoft Graph PowerShell SDK and security fixes. The deprecated modules will continue to function through March, 30 2025.

We recommend migrating to Microsoft Graph PowerShell to interact with Microsoft Entra ID (formerly Azure AD). For common migration questions, refer to the Migration FAQ. Note: Versions 1.0.x of MSOnline may experience disruption after June 30, 2024.

For example, using the V1 PowerShell module for Microsoft Entra ID, MSOnline, in a PowerShell session, first connect to the service and supply your global admin credentials:

Connect-MsolService

Note: If this command doesn't work, you can run Install-Module MSOnline to install the MSOnline module.

Next, configure your PowerShell session so that it doesn't truncate the values:

$Formatenumerationlimit =-1

Confirm user accounts are ready for Azure Information Protection

To confirm the user accounts, run the following command:

Get-Msoluser | select DisplayName, UserPrincipalName, ProxyAddresses

Your first check is to make sure that the users you want to use with Azure Information Protection are displayed.

Then check whether the ProxyAddresses column is populated. If it is, the email values in this column can be used to authorize the user for Azure Information Protection.

If the ProxyAddresses column is not populated, the value in the UserPrincipalName is used to authorize the user for the Azure Rights Management service.

For example:

Display Name UserPrincipalName ProxyAddresses
Jagannath Reddy jagannathreddy@contoso.com {}
Ankur Roy ankurroy@contoso.com {SMTP:ankur.roy@contoso.com, smtp: ankur.roy@onmicrosoft.contoso.com}

In this example:

  • The user account for Jagannath Reddy will be authorized by jagannathreddy@contoso.com.

  • The user account for Ankur Roy can be authorized by using ankur.roy@contoso.com and ankur.roy@onmicrosoft.contoso.com, but not ankurroy@contoso.com.

In most cases, the value for UserPrincipalName matches one of the values in the ProxyAddresses field. This is the recommended configuration but if you cannot change your UPN to match the email address, you must take the following steps:

  1. If the domain name in the UPN value is a verified domain for your Microsoft Entra tenant, add the UPN value as another email address in Microsoft Entra ID so that the UPN value can now be used to authorize the user account for Azure Information Protection.

    If the domain name in the UPN value is not a verified domain for your tenant, it cannot be used with Azure Information Protection. However, the user can still be authorized as a member of a group when the group email address uses a verified domain name.

  2. If the UPN is not routable (for example, ankurroy@contoso.local), configure alternate login ID for users and instruct them how to sign in to Office by using this alternate login. You must also set a registry key for Office.

    With UPN changes for users, there will be a loss of business continuity for at least 24 hours or until the UPN changes are properly reflected in the system.

    For more information, see Configuring Alternate Login ID and Office applications periodically prompt for credentials to SharePoint, OneDrive, and Lync Online.

Tip

You can use the Export-Csv cmdlet to export the results to a spreadsheet for easier management, such as searching and bulk-editing for import.

For example: Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csv

Note

With UPN changes for users, there will be a loss of business continuity for at least 24 hours or until the UPN changes are properly reflected in the system.

Confirm group accounts are ready for Azure Information Protection

To confirm group accounts, use the following command:

Get-MsolGroup | select DisplayName, ProxyAddresses

Make sure that the groups you want to use with Azure Information Protection are displayed. For the groups displayed, the email addresses in the ProxyAddresses column can be used to authorize the group members for the Azure Rights Management service.

Then check that the groups contain the users (or other groups) that you want to use for Azure Information Protection. You can use PowerShell to do this (for example, Get-MsolGroupMember), or use your management portal.

For the two Azure Rights Management service configuration scenarios that use security groups, you can use the following PowerShell command to find the object ID and display name that can be used to identify these groups. You can also use the Azure portal to find these groups and copy the values for the object ID and the display name:

Get-MsolGroup | where {$_.GroupType -eq "Security"}

Considerations for Azure Information Protection if email addresses change

If you change the email address of a user or group, we recommend that you add the old email address as a second email address (also known as a proxy address, alias, or alternate email address) to the user or group. When you do this, the old email address is added to the Microsoft Entra proxyAddresses attribute. This account administration ensures business continuity for any usage rights or other configurations there were saved when the old email address was in use.

If you cannot do this, the user or group with the new email address risks being denied access to documents and emails that were previously protected with the old email address. In this case, you must repeat the protection configuration to save the new email address. For example, if the user or group was granted usage rights in templates or labels, edit those templates or labels and specify the new email address with same usage rights as you granted to the old email address.

Note that it's rare for a group to change its email address and if you assign usage rights to a group rather to than individual users, it doesn't matter if the user's email address changes. In this scenario, the usage rights are assigned to the group email address and not individual user email addresses. This is the most likely (and recommended) method for an administrator to configure usage rights that protect documents and emails. However, users might more typically assign custom permissions for individual users. Because you cannot always know whether a user account or group has been used to grant access, it's safest to always add the old email address as a second email address.

Group membership caching by Azure Information Protection

For performance reasons, Azure Information Protection caches group membership. This means that any changes to group membership in Microsoft Entra ID can take up to three hours to take effect when these groups are used by Azure Information Protection and this time period is subject to change.

Remember to factor this delay into any changes or testing that you do when you use groups for granting usage rights or configuring the Azure Rights Management service, or when you configure scoped policies.

Next steps

When you have confirmed that your users and groups can be used with Azure Information Protection and you are ready to start protecting documents and emails, check whether you need to activate the Azure Rights Management service. This service must be activated before you can protect your organization's documents and emails:

  • Beginning with February 2018: If your subscription that includes Azure Rights Management or Azure Information Protection was obtained during or after this month, the service is automatically activated for you.

  • If your subscription was obtained before February 2018: You must activate the service yourself.

For more information, which includes checking the activation status, see Activating the protection service from Azure Information Protection.