-
Título
How to configure RBAC for mail migration -
Descrição
This guide will provide users with steps to enable RBAC for mail migration in ODM.
-
Resolução
Granting ODM Consents
- Check if an ODM mail migration related Azure application already exists on the tenants and delete the application if it exists (check both source and target tenants):
Quest On Demand - Migration - Mailbox Migration
Quest On Demand - Migration - Mailbox Migration - Minimal
Quest On Demand - Migration - Mailbox Migration - Full - From the ODM UI, Grant consents for the Mailbox Migration - Custom RBAC application. Perform this for both source and target tenants for the least privilege scenario. This will add an Enterprise application in Azure for each tenant and will act as a placeholder for RBAC.
Note: the Quest On Demand - Migration - Mailbox Migration - Custom RBAC application contains a single consent that is already granted by the Quest On Demand - Migration – Basic application (Directory.Read.All)
Understanding minimum permissions used for mail migration
Below are the mailbox permissions used in a least privilege scenario when migrating from a source tenant to a target tenant. These permissions are referenced later in the section titled “Ready to use PowerShell cmdlets”.
Consents used to migrate from source
Graph - Calendars.Read - Application
Office 365 Exchange Online - full_access_as_app - ApplicationConsents used to migrate to target
Graph - Calendars.ReadWrite - Application
Graph - Calendars.Read.Shared – Delegated*
Office 365 Exchange Online - full_access_as_app – Application*RBAC for Applications does not support delegated permissions, so Calendars.Read.Shared - Delegated access will not be assigned.
This consent is used during the mailbox activation process and does not impact mailbox migration activities.
Configuring RBAC for Applications in the Tenant
- To use RBAC for Applications, Exchange Online requires a service principal object that knows about the Azure application. You will need to create this using PowerShell.
New-ServicePrincipal -AppId $AppId -ServiceId $ServicePrincipalId -DisplayName "ODM"
To run the New-ServicePrincipal cmdlet, collect the Application ID and the Object ID for the Quest On Demand – Migration – Mailbox Migration – Custom RBAC application in Azure so you can specify them for $AppId and $ServicePrincipalId in the cmdlet respectively.
- Next, you need to create a management role scope to tell Exchange Online what mailboxes the Quest application can access. You can use any of the filterable mailbox properties to create a scope. Below is an example that filters on the Office property.
New-ManagementScope -Name "America Employees" -RecipientRestrictionFilter "Office -like 'Chicago*'"
To validate that the scope finds the expected set of mailboxes, you can use the same filter with the Get-EXOMailbox cmdlet:
Get-EXOMailbox -Filter {Office -like 'Chicago*'} | Format-Table DisplayName -
Next, you need to create a management role assignment that will connect the management scope to the service principal and apply an access role.
In the example below, we are assigning the role “Application EWS.AccessAsApp,” which corresponds to the Office 365 Exchange Online - full_access_as_app permission required to access the contents of user mailboxes.
New-ManagementRoleAssignment -App $AppId -Role "Application EWS.AccessAsApp" -CustomResourceScope "America Employees" - Continue creating management role assignments to grant additional role access to meet the requirements referenced later in the section titled “Ready to use PowerShell cmdlets”.
- Use the Test-ServicePrincipalAuthorization cmdlet to test that an app can access a target mailbox. For example, the following test returns a False result, meaning that the selected mailbox is outside the management scope.
Test-ServicePrincipalAuthorization -Identity $AppId -Resource Garry.Smith
Known issues and Limitations
- After creating a migration project that uses RBAC consents, you will need to open the project and manually specify the EWS URL in the Dashboard tab under Configure Connections. ODM normally uses the Autodiscovery service to obtain this value, but this service cannot be accessed when RBAC is configured.
Commercial tenant URL: https://outlook.office365.com/EWS/Exchange.asmx
GCC High tenant URL: https://outlook.office365.us/EWS/Exchange.asmx- Mailbox provisioning may fail in some cases. This may occur when Exchange Online does not have updated information, so it blocks attempted access (403 forbidden error) when the ODM app tries to access the specified mailbox. This will result in a mailbox migration task failure. If this happens, please wait for some time and re-run the task.
- Since delegated permissions are not supported for RBAC, you will not be able to grant consent for Calendars.Read.Shared permissions. This can impact Teams meeting link migration since the calendar is not available for new target mailbox. The solution is to activate the target mailbox manually by logging in or use PowerShell to activate prior to running Teams meeting link migration.
- ODM EXO RBAC support does not apply to Public Folders. Public folder migrations will not work under RBAC setup and will require you to grant one of the other ODM mail migration consents.
Additional considerations
- When migrating an Archive mailbox – On Demand may report the below 401 unauthorized errors and warnings. However, these do not seem to impact content migration.
- All other operations will still work as a part of mail migration task, regardless of RBAC is setup or not, including:
Auto reply
X500 address migration
Mailbox switch operation (Mail forwarding)
Safe senders list
Delegates
Litigation hold settings - When attempting to migrate a mailbox not in scope of the RBAC config, you will see the below 403 forbidden error.
Ready to use PowerShell cmdlets
- You will have to connect to Exchange Online PowerShell using Connect-ExchangeOnline cmdlet before running any of the commands listed below.
- You will need to run both sets of commands to configure RBAC on both source and target tenants. Alternatively, you can configure RBAC on one tenant and use one of the other ODM mail migration Azure applications on the other tenant.
- In the examples below, the Office location property is used to set the scope for the Azure app, meaning that mailbox migration would work for any user who has the Office location set as Chicago in Azure and would fail for anyone else.
Minimal consents – (Source tenant)
New-ServicePrincipal -appid 8de29203-c58a-45e2-ac4f-7a3784b66933 -objectid fa4f5229-0bc5-435a-80c6-0ca7e122c050 -displayname "Quest migration mailbox"
New-ManagementScope -Name "ODM test" -RecipientRestrictionFilter "Office -like 'Chicago*'"
New-ManagementRoleAssignment -App 8de29203-c58a-45e2-ac4f-7a3784b66933 -Role "Application Calendars.Read" -CustomResourceScope "ODM test"
New-ManagementRoleAssignment -App 8de29203-c58a-45e2-ac4f-7a3784b66933 -Role "Application EWS.AccessAsApp" -CustomResourceScope "ODM test"
Full consents – (Target tenant)
New-ServicePrincipal -appid 8de29203-c58a-45e2-ac4f-7a3784b66933 -objectid fa4f5229-0bc5-435a-80c6-0ca7e122c050 -displayname "Quest migration mailbox"
New-ManagementScope -Name "ODM test" -RecipientRestrictionFilter "Office -like 'Chicago*'"
New-ManagementRoleAssignment -App 8de29203-c58a-45e2-ac4f-7a3784b66933 -Role "Application Calendars.ReadWrite" -CustomResourceScope "ODM test"
New-ManagementRoleAssignment -App 8de29203-c58a-45e2-ac4f-7a3784b66933 -Role "Application EWS.AccessAsApp" -CustomResourceScope "ODM test"
Please note that we skipped Calendars.Read.Shared - Delegated permissions here for target tenant since it is not supported for RBAC.
- Check if an ODM mail migration related Azure application already exists on the tenants and delete the application if it exists (check both source and target tenants):
