Migrate from EWS Application Access Policy to RBAC for Applications

Increasing Tenant Security By Removing EWS Application Impersonation

On February 20, Microsoft announced their intention to remove Application Impersonation for Exchange Web Services from Exchange Online. In the beginning, no new assignments will be possible and later, existing ones will be removed:

This step is to increase tenant security in response to the lessons learned from the Midnight Blizzard attack. There is no reason for panic. However, you should check your environment to make sure that it will not be affected. For this purpose, Microsoft provided a script, which can be downloaded from GitHub

If you have existing management role assignments, this article explains how to make the transition to RBAC-based assignments.

To start, let me give you some background on how things work and the differences between the old and new approach.

Microsoft’s first mechanism to control access to applications, using OAuth2 application permissions, was the implementation of the Application Access Policy. You can read more about OAuth2 permissions here:

• Delegated Access
• App-only access

The documentation for these policies still be found in the Microsoft Graph documentation.

You would have used the cmdlet New-ApplicationAccessPolicy to create and Test-ApplicationAccessPolicy for testing policies. In the beginning, this was limited to Exchange specific permissions like Mail.*, MailboxSettings.*, Calendars.* and Contacts.*.

As customers and the community complained about no support for an equivalent to the full_access_as_app permission, representing Exchange Web Services, this was introduced later.

The implementation was great, but it came with some limitations:

• Only a limited number of policies were supported (250 and maybe more if you opened a support case)
• Shared mailboxes were not supported because these policies target mailboxes with IsSecurityPrincipal set to true
• A highly privileged account is needed to grant admin consent on the registered app for the permissions

As the ability to scope application access is now moved to RBAC, we are now only limited to 10.000 applications per tenant. The statement can be found here. There requirement for the attribute IsSecurityPrincipal and the admin consent is not necessary (the beauty of RBAC!).

One of the biggest advantages is the fact that you can reuse all your custom Management Scopes. If the tenant has deployed Administrative units in Microsoft Entra ID, you can use them as well.

Migration Steps

As we are migrating apps that use application impersonation, I assume there are already registered apps with admin consent to permissions. Figure 1 shows all supported permission with type Application and admin consent:

In Exchange Online, I have an Application Access Policy to scope the app to members of a specific group. The policy is shown in Figure 2:

As of now, the app is restricted to members of this group.

The first step in the migration is to create a corresponding object in Exchange Online: A Service Principal representing the app. For this, the cmdlet New-ServicePrincipal is used. The Application and Object ID is necessary and can be found in Microsoft Entra ID as described in this article.

In my case, I run the following command:

New-ServicePrincipal -AppId 4258e832-c307-48df-93e9-cb0905232c57 -ObjectId 3a89d415-0d60-42f1-8175-56906e364be5 -DisplayName 'SPN for App Policy to RBAC'

Figure 3 shows the command and the created object:

The next step is to create a custom Management Scope to restrict access only to members of this group using the New-ManagementScope cmdlet. First, I store the existing group in a variable and create the scope using the DistinguishedName of the group:

scopedGroup = Get-Group 'Practical365 App Users'
New-ManagementScope "Practical365 Scope" -RecipientRestrictionFilter "MemberOfGroup -eq '$($scopedGroup.DistinguishedName)'"

Figure 4 shows the commands and the created scope:

The last step is to combine the existing service principal with a role and the scope. Microsoft did a great job and provided a list of different roles, which allows you to grant gradual permissions. In our case, we grant read/write access to the calendar and use “Application Calendars.ReadWrite” (Figure 5):

New-ManagementRoleAssignment -App 4258e832-c307-48df-93e9-cb0905232c57  -CustomResourceScope 'Practical365 Scope' -Role 'Application Calendars.ReadWrite'
Get-ManagementRoleAssignment -Role 'Application Calendars.ReadWrite' | fl

Testing Permissions

You can check whether an application was granted access to a mailbox by using cmdlet Test-ServicePrincipalAuthorization:

Test-ServicePrincipalAuthorization -Identity 3a89d415-0d60-42f1-8175-56906e364be5 -Resource AlexW@M365x16362668.OnMicrosoft.com

Figure 6 shows two examples and the details:

Cleanup

Now that we have created a new ManagementRoleAssignment, we need to do some housekeeping.

To avoid overprivileged apps, we should remove admin consent and all permissions from our app. Figure 7 shows the app after cleanup:

Migrating from EWS ApplicationImpersonation

Many third-party applications use EWS to access mailboxes. In most cases, the apps run in the context of a specific user, which has already a ManagementRoleAssignment with the role ApplicationImpersonation. As this role is now deprecated, the steps for administrators are straightforward:

• Create a replacement app in Entra ID
• Create in Exchange Online the corresponding ServicePrincipal (New-ServicePrincipal)
• Optional: create a new (New-ManagementScope) or reuse existing ManagementScope
• Create a new ManagementRoleAssignment (New-ManagementRoleAssignment)

That’s all you need to do. The major work needs to be done by the vendors as they have to change their authentication process to OAuth2.0 client credentials flow, which is used when it comes to application permissions.

Don’t forget to remind the vendors to switch their code to use the Microsoft Graph APIs because Microsoft will retire Exchange Web Services in Exchange Online from October 2026.

Summary

I hope this article shows that it’s not difficult to migrate existing application access policies to RBAC in Exchange Online. The retirement of EWS ApplicationImpersonation will start soon (May 2024!), but don’t panic because existing assignments will not be removed before February 2025!

However, if you are using a third-party product, you should contact the product vendor and ensure they are aware of the need for migration and are prepared to deliver updated code.