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:

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:

Migrate from EWS Application Access Policy to RBAC for Applications
Figure 1: All supported permissions with granted 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:

Migrate from EWS Application Access Policy to RBAC for Applications
Figure 2: Properties of an Application Access policy

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:

Migrate from EWS Application Access Policy to RBAC for Applications
Figure 3: Creation of service principal in Exchange Online

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:

Migrate from EWS Application Access Policy to RBAC for Applications
Figure 4: Details of 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
Migrate from EWS Application Access Policy to RBAC for Applications
Figure 5: Details of ManagementRoleAssignment

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:

Migrate from EWS Application Access Policy to RBAC for Applications
Figure 6: Two examples for app access and one without access

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:

Migrate from EWS Application Access Policy to RBAC for Applications
Figure 7: admin consent and permissions have been removed

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.

About the Author

Ingo Gegenwarth

Ingo Gegenwarth is a Technical Consultant at a market-leading organization for enterprise application software. In his role, he is responsible for the Exchange infrastructure as well as Office 365. In 2003, he earned his first MCSE 2000, and since then he's earned Microsoft Certified Master (MCM) and Microsoft Certified Solutions Master (MCSM).

Comments

  1. Chandan

    Hello @ingo – In your article you have mentioned to “Create a replacement app in Entra ID”. Do we have to do this for all impacted apps ? is there any way we can create service principal for existing apps ?
    Also could you please confirm why app owners have to change authentication to client credentials flow ?

    1. Ingo

      Hi Chandan,
      sorry for the delay!
      Of course you can use your existing ServicePrincipals in EXO. Just create your desired RoleAssignment.
      Ciao,
      Ingo

  2. Ingo

    Hi Bryan,
    this is only supported for IMAP/POP and SMTP as outlined here:
    https://learn.microsoft.com/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth?WT.mc_id=M365-MVP-5001727
    I get your point for a single or few mailboxes. However, think about it: you can’t do a reverse search like “EXO, please give me all mailboxes this specific SPN has access to.” With role assignments and scopes you’re better in terms of governance and insights.
    Ciao,
    Ingo

  3. Bryan

    Is it possible to utilize the Add-MailboxPermission cmdlet to leverage access to the mailbox for the Service Principal?

    That is, rather than going through with utilizing management scopes and management roles, would assigning mailbox delegated permissions be enough to grant access? Or would that still expose the rest of the mailboxes in the org to the app? Given that the biggest reason to utilize Application Access Policies was to reduce the access from all mailboxes in Exchange Online to the Graph App Registration.

Leave a Reply