Blog Post

Exchange Team Blog

3 MIN READ

Critical Update: ApplicationImpersonation RBAC Role Deprecation in Exchange Online

Microsoft

Nov 13, 2024

Update 11/20/2024: We added a new Graph-FindImpersonation script as a way of finding the applications using the role.

In our previous announcement, we detailed the upcoming deprecation of the ApplicationImpersonation role in Exchange Online. As the deprecation date of February 2025 approaches, it is vital for administrators and developers to take immediate action to ensure a smooth transition. This follow-up article aims to reinforce the urgency and provide clear guidance on the necessary steps.

Unchanged Timeline

We want to emphasize that the timeline for the complete removal of the ApplicationImpersonation role remains unchanged. The deprecation will occur starting February 2025, and it is crucial that all necessary preparations are made well in advance of this date.

You should be receiving Message Center post MC724116 if we have detected usage in your tenant. However, it’s possible for there to be usage outside of our reporting range, so we advise our customers that they must exercise their own due diligence to ensure that this feature is no longer being used in their tenant.

The Security Imperative for This Change

The decision to deprecate the ApplicationImpersonation role is rooted in our commitment to enhancing security within Exchange Online. Historically, the role served as a broad-access solution, but it poses several security risks due to its extensive permissions and potential for abuse. Leaving such wide-ranging access enabled compromises your organization’s security posture.

Immediate Steps for Administrators and Developers

To avoid disruptions, it is imperative that administrators and developers begin transitioning their applications immediately. Here are your options:

Transition to Microsoft Graph: If possible, migrate to Microsoft Graph as EWS is being phased out.
Implement App-only authentication and RBAC for Applications: Make the necessary code and configuration updates for EWS applications requiring 1-to-many mailbox access to use App-only access (uses EWS.AccessAsApp OAuth Application permission) along with implementing resource-scoped access using Role-Based Access Control (RBAC) for Applications in Exchange Online.

Identifying and Addressing Affected Accounts

To identify accounts using the ApplicationImpersonation role, you can use the following tools:

Exchange Online PowerShell: Check for accounts with the ApplicationImpersonation role using the command:

Get-ManagementRoleAssignment -Role ApplicationImpersonation -GetEffectiveUsers -Delegating:$false

Graph-FindImpersonation Script on GitHub. This is the most comprehensive and scalable solution to get a report of users leveraging the ApplicationImpersonation RBAC role with third party EWS applications. Please note that the script requires an application registration in Entra ID, so that is a prerequisite for it to run. Credit to Jim Martin for creation of this solution!
Sample reporting Script on GitHub: Utilize the ApplicationImpersonation reporting script available on GitHub. This script generates a report of Microsoft 365 third-party EWS applications using accounts assigned the ApplicationImpersonation RBAC role. Use this information to find the applications in Entra and identify the application owners. Work with application owners (both within your organization and vendors outside your organization for 3^rd-party apps) to transition.

Please note that the above two scripts are not supported by Microsoft support teams. If you have issues, please file them through their respective GitHub repos.

If you have impacted applications, the script will provide you with the Application ID. To translate this Application ID to something you can identify as a specific application, you will have to go to the Entra portal for your tenant. Please see the article Application and service principal objects in Microsoft Entra ID to find the name of the application based on the ID that the script provided. If the ID identifies an application created by an independent software vendor, you will have to contact them to get an updated application that does not rely on ApplicationImpersonation role. If the application is something that your tenant has built in-house, you will need to work with application developers to update the application.

Conclusion

As the February 2025 deprecation date approaches, it is crucial to act now. Engage with your application owners and utilize the guidance provided to ensure a seamless transition. Applications that are not updated will no longer work after this date.

The Exchange Online Team

Updated Feb 14, 2025

Version 7.0

Microsoft

Joined April 19, 2019

View Profile

Exchange Team Blog

You Had Me at EHLO.

windach
Copper Contributor
Feb 27, 2025
What a **** ... System Center Service Manager stopped working because the only way here is using some 3rd party management packs. There is no other way to grab mails.
Migrating back to OnPrem ... and getting rid of System Center.
markdevr
Copper Contributor
Feb 25, 2025
We were watching for this this go down on Monday, but ApplicationImpersonation seems to be working still in our environment. When should we expect this to actually stop working?
XL2020
Copper Contributor
Feb 13, 2025
Hi MS Experts,
We are diligently working to update our applications that currently utilize the RBAC Application Impersonation in Exchange Online. However, transitioning to the new Microsoft mode requires extensive testing and collaboration with various vendors and teams. Additionally, our security team frequently raises questions about the necessary steps to move forward.
Given these challenges, we are seeking an extension of the retirement date by more than three months. This additional time would allow us to thoroughly upgrade our current applications and ensure a smooth transition.
Thank you for your understanding and consideration.
- markdevr
  Copper Contributor
  Feb 25, 2025
  Going to be difficult to get MS to extend this. They gave ample notice and already significantly extended it once.
Scootsie2
Copper Contributor
Feb 04, 2025
Is there any cleanup effort required after our affected applications have been upgraded?
Our current goal is to identify what service accounts were previously utilizing the role and address the necessity of these to continue existing. But is there any reason to remove the role itself from the account for clerical purposes -or- is that the action that Microsoft will be taking come the switch?
- _cparker
  Microsoft
  Feb 04, 2025
  It's not required, as the role will eventually be removed by Microsoft.
Maluks
Iron Contributor
Jan 31, 2025
I get few impersonation attempts, that all them seem to be by a single user or app principal. What I get is userID starting with "S-1-5-80" and all logon types are "1", UserKey is all zeros. How do I find what kind of account is that? I have no values in the report, that I could just simply copy paste into Entra ID for search?
- thejimmartin
  Microsoft
  Jan 31, 2025
  You can use EXO shell and run Get-User "S-1-5-80..." to see the user
- Pagliacci
  Copper Contributor
  Jan 31, 2025
  The script outputs an "ID" in column B which is the App ID of the application performing the impersonation (to my understanding). However, I seem to be getting IDs that don't correspond to any Apps. The events listed correspond to what appear to be Microsoft Teams Services impersonation events when users create groups.
  - thejimmartin
    Microsoft
    Jan 31, 2025
    The audit query does not include ExchangeAdmin events so it should not capture group creation. You should be able to use the Graph module to see the application if you can't in Entra center.
    
    Import-Module Microsoft.Graph.Applications
    
    Get-MgApplication -ApplicationId <AppId>
Pagliacci
Copper Contributor
Jan 29, 2025
I've run the FindImpersonation script, and received the output with 9 entries in it, however, none of the IDs in column B seem to match up with with any of our applications. I tried to find one by connecting to graph with "Application.Read.All" permission, then running:
Get-MgServicePrincipal -filter "appId eq 'ID-From-CSV'"
Trying each of the ID's from column B returned nothing. Am I missing something or using this information incorrectly?
- thejimmartin
  Microsoft
  Jan 29, 2025
  Take the application ID and search against your enterprise applications within the Entra ID admin portal.
  - Pagliacci
    Copper Contributor
    Jan 29, 2025
    I've tried that as well, I cleared all filters and tried using the ID in the search field, and also setting only 1 filter with "Application ID starts with {App-ID}", but I'm still not seeing any hits for any of the App ID's found from the script. I verified I am in the correct tenant, given the Organization ID. Not sure what I'm missing.
AllanCooper
Copper Contributor
Dec 05, 2024
Hi Nino

1.
Is below is not an Oauth Permission Case Scenario:

Why Microsoft is only suggesting this - "Implement App-only authentication and RBAC for Applications: Make the necessary code and configuration updates for EWS applications requiring 1-to-many mailbox access to use App-only access (uses EWS.AccessAsApp OAuth Application permission)"

2. What string or inf can tenant admins can look into SignIn Logs to confirm that Apps are using OAUTH?
- thejimmartin
  Microsoft
  Jan 29, 2025
  
  RBAC allows you to scope the mailboxes the application can access just like you could do with impersonation.
  
  Sign-ins should be using OAuth as legacy auth has been disabled. You can filter by AppId if needed.
- thejimmartin
  Microsoft
  Dec 05, 2024
  Exchange Online doesn't support basic authentication. All sign-ins are using OAuth. The delegated permission type is how EWS application impersonation role can be leveraged. The switch to application permission type removes the use of this role which is being retired.
  - Kevin Mychal Ong
    Copper Contributor
    Dec 05, 2024
    If an app uses the EWS.AccessAsUser.All delegated permission, that doesn't necessarily mean the ApplicationImpersonation RBAC role in EXO is being utilized (even if it is assigned to a service account that the app is using), correct?
theovski
Copper Contributor
Dec 05, 2024
Yes we have the same issue as Ken... message centre update on Dec 3rd advising our tenant has applications using impersonation but both methods have provided zero result. How accurate is the information being given in message centre?
- _cparker
  Microsoft
  Dec 05, 2024
  It's possible that your tenant may no longer have apps running that use ApplicationImpersonation, which is why you may have received the targeted MC post but are not seeing any usage via the reports at this point due to the cutoff date for the analysis that informed the MC post.
Ken_Harrell1145
Brass Contributor
Dec 04, 2024
I have used both methods to try and figure out what is using the ApplicationImpersonation RBAC with no luck. The message center article states we have accounts using ApplicationImpersonation RBAC but does not state which ones. I wish there was a report to help out. The date is closing and I'm trying to comply but have not been able to get the results. I have opened a second support case, the first one was using the ApplicationImpersonation reporting script and we thought we were good but looks like that report didn't scale well and may have been misleading. The current case is for the Graph-FindImpersonation Script on GitHub which ran but provided no results.
- _cparker
  Microsoft
  Dec 05, 2024
  It's possible that your tenant may no longer have apps running that use ApplicationImpersonation, which is why you may have received the targeted MC post but are not seeing any usage via the reports at this point due to the cutoff date for the analysis that informed the MC post.
  - Ken_Harrell1145
    Brass Contributor
    Jan 21, 2025
    After a support case and lots of digging we figured out which accounts had and were using Application Impersonation and have corrected the accounts.
Ken_Harrell1145
Brass Contributor
Dec 03, 2024
I ran Step 1 of the .\Graph-FindImpersonation.ps1
When I run Step 2 it is asking me for a name. I assume I use the Query ID from Step 1 for the name? Confused since the -AuditQueryId is specified in the command.
- thejimmartin
  Microsoft
  Dec 03, 2024
  Name is just a value you specify that will be used for the query and the csv file output. the audit query id is required for the graph call.