Retirement of RBAC Application Impersonation Role in Exchange Online

Microsoft’s announcement about the retirement of the application impersonation role in Exchange Online is the response to the Midnight Blizzard attack. Initially, the attackers got in using a password spray attack in a legacy test non-production system that lacks MFA configuration. Then, they compromised a test OAuth app with elevated access in the non-production tenant. Adding to the breach, they created a malicious app and a fake user to gain unauthorized access to Microsoft Corporate email accounts. This led the attackers to read a few confidential company emails.

As this incident highlighted the need for faster response and stronger security measures, Microsoft decided to remove RBAC application impersonation in Exchange Online to prevent similar breaches in the future.

Application impersonation role in Exchange Online is used to grant service applications access to multiple mailboxes. Impersonation is a good choice to enable users to access other users’ mailboxes. Because you can easily grant a single service account access to every mailbox in the database that acts as a mailbox owner. Please note that only accounts assigned with the ApplicationImpersonation role by Exchange server admin can use ‘Impersonation’.

To assign an application impersonation role, you can either use Exchange Admin Center or PowerShell.

Retirement of application impersonation will apply only to Microsoft 365 apps and Exchange Online environment. EWS in Exchange Server will not be affected. Additionally, the changes will not affect Outlook for Windows or Mac, Teams, or any other MS product, as this change applies to web apps alone.

Starting in May 2024, Microsoft will begin to block the ApplicationImpersonation role assignment, and from February 2025, this role and its feature set will be completely removed.

From October 1, 2026, Microsoft will block allowing non-Microsoft apps to use EWS to connect to Exchange Online. The most challenging thing about EWS is that it lacks granularity and gives unwanted high-privileged access. If an app uses EWS to access a user’s mailbox, it can see almost everything, like contacts, emails, calendar events, notes, and even Teams & Viva Engage compliance records. This is why Microsoft is making changes.

• Microsoft strongly recommends users migrate applications to Microsoft Graph to access Exchange Online data as EWS is in its retiring stage.
• Also, granting access using Graph API is more granular and you can easily track them using audit logs.
• As an option, you can also consider using Role-Based Access Control for apps accessing mailboxes.

If you are using EWS for applications to access mailboxes, always keep a check on the following key solutions. Mitigate risks associated with EWS protocol and step up your security. If you want to find out the apps having application impersonation roles in your tenant, run the below cmdlet.

First, make sure your application is registered with Microsoft Entra ID. Especially to use OAuth, an application ID is a necessity. You can register your application either by using Entra ID or Microsoft Graph. Follow the steps below to register your application.

• Log in to the Microsoft Entra admin center.
• Select Identity in the left menu, then select App Registrations under Applications.
• Select New registration. On the ‘Register an application’ flyout, set a Name, Supported account types, and Redirect URI (optional), respectively.
• Select Register. Then, you can find the Application (client) ID and Directory (tenant) ID on the next. Copy and save them for later use.

If you want to use EWS apps to access multiple mailboxes, you can configure OAuth for apps to grant app-only access instead of granting full access. Look at the steps below to use application permissions.

• Select an application to which you are going to configure app-only access.
• Select Manifest in the left menu under Manage.
• Locate the requiredResourceAccess property to add the JSON code containing app ID, access type, etc., and select Save.

• Select API permissions in the left menu. Ensure that full_access_as_app permission is listed.
• Select Grant admin consent for org and select Yes on the dialog.

• Select Certificates & Secrets –> New client secret–> Enter a description and click Add.
• Copy the secret ID and save it for future requirements.

Then, you can get a token and add the authentication token to EWS requests.

If your organization uses EWS applications with an impersonation role, consider implementing resource-scoped access using the Role-Based Access Control for applications to have controlled access to mailboxes as per your needs.

To assign permissions for a service principal performing actions across a scope, you can use management role assignments in Exchange Online. Let’s see how to create and modify management role assignments with custom resource scope access.

• To create a new management role assignment, use the cmdlet below.

• To modify an existing management role assignment, use the cmdlet below.

• If you want to test your Service Principal access, run the cmdlet below.

Though Microsoft strongly suggests users migrate to Microsoft Graph, still many developers are using EWS as MS Graph has a few feature gaps listed below.

• Access to archive mailboxes
• Folder information/user configuration
• Exchange Online management
• Access to public folders

You don’t need to worry about it! Microsoft continues to improve the Microsoft Graph features and plans to fill these gaps efficiently.

As attackers always come up with new strategies and techniques, we always need to be super secure to prevent such malicious threats. Maintaining essential Microsoft 365 security checklists is the key measure to mitigate attacks and periodically audit crucial actions to identify & close the loopholes. Look at the security measures below to avoid password spray attacks and the usage of malicious OAuth applications.

• Identify and avoid weak & guessable passwords. Ensure that you have a strong password policy in the organization.
• Audit risky user sign-ins and restrict them if required.
• Detect password change activity and ensure it has not been changed by unauthorized persons.
• Monitor the highly privileged identities, users, service principals, and applications frequently.
• Pay attention to apps having app-only access as they might have over-privileged access, and remove unused apps, if any.
• Identify applications that hold ApplicationImpersonation permissions in Exchange Online.
• Spot any sensitive EXO admin actions by malicious OAuth apps via App governance.
• Implement conditional access app control for users to prevent unmanaged devices.
• Review applications that hold EWS.AccessAsUser.All and EWS.full_access_as_app privileges. If they are no longer required, consider removing them.

I believe this blog will help you understand the need to configure essential security measures in the organization and the reason behind this retirement. If you are using EWS, take the necessary steps and stay free from data abuse in the organization.