Retirement of RBAC Application Impersonation in Exchange Online

[The_Exchange_Team]

Update 4/3/2024: We added information about the sample ApplicationImpersonation reporting script.

Today we are announcing that we will begin blocking the assignment of the ApplicationImpersonation role in Exchange Online to accounts starting in May 2024, and that in February 2025, we will completely remove this role and its feature set from Exchange Online.

Modernizing Application Access

Historically, when you needed to grant an application access to more than its own mailbox in your Exchange organization using Exchange Web Services (EWS), you had limited options.

Simple delegation worked for one-to-one and even some one-to-few scenarios, but when you needed to grant access to many mailboxes, Impersonation was the way to go. Impersonation provided easy and broad access to many mailboxes, but limited options for scoping resources for access, and limited visibility outside of Exchange.

Today, the Microsoft identity platform / application model is the standard way to build apps that integrate with your data in the Microsoft cloud. Registering your app in Microsoft Entra simplifies deployment and adoption, makes permissions clearly visible, and helps to standardize your integrated applications.

How Does This Affect Me?

All apps must have an App Registration, and when using Application permissions (not Delegated), the app must use a secure credential for access.

When using EWS, grant scoped access using RBAC for Apps.

Better yet, use Graph, as EWS is going away!

How Do I Find Accounts Using This Type of Access and What Actions Should I Take?

Use Exchange Online PowerShell to check for accounts that have been assigned the ApplicationImpersonation role:

Get-ManagementRoleAssignment -Role ApplicationImpersonation -GetEffectiveUsers

Update:

You can also use the sample ApplicationImpersonation reporting script that is posted on GitHub here.

This script produces a report of Microsoft 365 3rd party EWS applications using accounts that have the ApplicationImpersonation RBAC role assigned. This script will help provide you with the impacted App Ids and the accounts in use by these applications that are performing EWS Impersonation. You can then use this information to approach your application owners and work with them to migrate to using RBAC for Applications.

For EWS applications requiring 1 to many mailbox access, ensure the application is configured properly with OAuth to use App-only access.

Implement resource-scoped access using Role Based Access Control for Applications in Exchange Online to control mailbox access as needed for your scenario.

The Exchange Online Team

[Vasil Michev]

It's a bit unclear what this announcement is about. So you are going to be deprecating the built-in ApplicationImpersonation role, correct? And the recommendation is to use the "full_access_as_app" permissions, which covers the application permissions model? Then what about the delegate permissions model, will the "EWS.AccessAsUser.All" permissions continue to be supported or?

And the recommendation to use Graph makes no sense, as there is no impersonation permission therein (for the application permissions model). Both examples from the documentation still use the Exchange Online API resource ("00000002-0000-0ff1-ce00-000000000000"), not Graph.

[Thomas Stensitzki]

Again, it looks like the deprecation is underway while not having a replacement option available providing the very same feature set.

[Mike Crowley]

Further reading, and no doubt the inspiration for this change:

https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-o...

[_cparker]

Vasil: Yes, all correct in your first paragraph. Regarding the recommendation to use Microsoft Graph, this is due to the fact that EWS will be retired in Exchange Online in October 2026, and migrating to Microsoft Graph is strongly encouraged.

[_cparker]

Thomas: Regarding the deprecation of the ApplicationImpersonation RBAC role, you can use RBAC for Apps.

[PankajNTT]

@The_Exchange_Team This will impact all the O365 Tenant or the one starting from May 24.?

I dont see specific solution to remediate.

[_cparker]

Pankaj: This announcement applies to all tenants. The solution for enabling one-to-many mailbox access in Exchange Online going forward is shared in the "How Does This Affect Me?" section of the article.

[hansj21]

@The_Exchange_Team 

Can we make use of Delegated Type permission when using app registration with secured access or it is mandate to use Application Type API permission only.

[PankajNTT]

@The_Exchange_Team @_cparker impact may start from May 2024 or Feb 2025? it will still continue to work till Feb 2025. right?

[_cparker]

Hans: You can use the Delegated permissions model and associated OAuth flows when appropriate (e.g.: one-to-one, one-to-few mailbox access). One-to-many/app-only scenarios should use RBAC for Applications to scope access.

[_cparker]

Pankaj: In May 2024, we will begin blocking new assignments of the ApplicationImpersonation RBAC role. Existing assignments will continue to work until February 2025 when the role will be removed. 

[kousuke]

@_cparker 

Most of the reasons for using ApplicationImpersonation are related to throttling. 

In a one-to-many scenario, what does RBAC for Applications do for throttling?

Does RBAC for Applications increase the EWSMaxSubscriptions or EWSMaxConcurrency?

Or can RBAC for Applications be used to obtain consent and access tokens from each resource mailbox? (application accesses many resource mailboxes)

[_cparker]

kousuke: RBAC for Applications does not impact throttling.

[gsinghlive]

I have tried using App Only permission but the scope the very wide and unable to use Delegated permission. I have to use Impersonation with 100s of mailboxes and resources but should be able to limit access based on scope.

What is the best path forward for using EWS Impersonation while using delegated permission? Do I need to use RBAC then what are the steps?

[Subham_Saurabh]

Hello guys,

I have a disjoint (not hybrid) exchange server 2016 cu 23  and AD server environment. How could I enforce or configure secure ldap in exchange server. As I can see in netstat and TCP connection in process monitoring (of exchange server) that normal ldap 389 port is being used by various exchange services.

If anyone knows kindly guide.

[mfmadsen]

@The_Exchange_Teamfollowing up on @kousuke 's comment/question re. impersonation: ApplicationImpersonation is currently used to handle/prevent throttling when having a service scenario where a single service account is used to access many mailboxes. When ApplicationImpersonation now goes away, what are the recommendations to handle/prevent throttling issues in such a scenario?

[mfmadsen]

@The_Exchange_Team, another question: will this change impact on-premise Exchange Server?

[_cparker]

gsinghlive: RBAC for Applications allows you to scope access for App-only scenarios. This is the recommended path as a replacement for the use of the ApplicationImpersonation role assignment. Please see https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac for details.

[_cparker]

mfmadsen: When using RBAC for Applications, access is performed by the application security principal. RBAC for Applications does not impact throttling.

[_cparker]

mfmadsen: This deprecation is regarding Exchange Online, not Exchange On-prem.

[gsinghlive]

@_cparker I tried doing app only permission with RBAC but there is no documentation with EWS, when I used `https://outlook.office365.com/.default` scope with client_credential grant but I cannot impersonate any user or resource in scope. Always get the error - `2000008;reason="The token contains not enough scope to make this call.";error_category="invalid_grant"` that gives impression that either the scope is incorrect or there is something missing in steps.

[Kboentkuri2620]

BRAC can migrate to all policy under Microsoft policy for modern technology :victory_hand:

[hiep_tran]

@_cparker At the moment our application is using the delegated permission model with the "EWS.AccessAsUser.All" scope on Graph to get the access token and use it in each EWS request. Does this retirement affect how our app works?

[Xavier_P1150]

Hi,

If I understand correctly, RBAC For Apps will eventually replace application access policies?

In this context, is it also advisable to take the necessary steps to migrate our application access policies?

[Yenna900]

Hi @_cparker ,

Same like @hiep_tran , we utilizing the same and require direction if it's impacting our process of new onboard setup after May 2024. Delegated permission with EWS.AccessAsUser.All and scoping thru New-ManagementRoleAssignment -role ApplicationImpersonation -CustomRecipientWriteScope

What Im understood is just impacting Application type not delegate, but somehow when review our current setup seems like it's will impacting as well as Role = ApplicationImpersonation?

[arconicajanes]

I think it is important to note that EWS is going away as well. The retirement of this feature seems to be related with the retirement of EWS as well. Anyone looking for guidance on what permissions to use with EWS now should stop and look at Graph going forward.

If your application doesn't support Graph, contact the vendors/developers and tell them to start catching up. :p

[mfmadsen]

@arconicajanes, not helpful as EWS is not going away until at least 2026 and the retirement of RBAC Application Impersonation is going to happen way sooner. Therefore it is extremely relevant to know how to handle this in the meantime. Also, Graph is currently not in a state where it can replace EWS in all scenarios (see comments on https://techcommunity.microsoft.com/t5/exchange-team-blog/ews-exchange-web-services-to-microsoft-gra... and https://techcommunity.microsoft.com/t5/exchange-team-blog/retirement-of-exchange-web-services-in-exc...)...

[_cparker]

Hiep_tran: If you are using the Delegated permission with an account that has the ApplicationImpersonation role assignment to perform 1:many mailbox access, yes. Applications that are using this permissions model with an account that was assigned the ApplicationImpersonation role are affected and must follow the guidance in the article.

[_cparker]

Xavier: Yes and yes.

[_cparker]

Yenna: Please see my response to hiep_tran above. You will need to follow the guidance in the article.

[_cparker]

@gsinghlive The steps in the article https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac provide what you need to migrate. Please follow those steps and if you are running into issues, and if you have a Unified Support agreement, please open a support ticket for additional assistance.

[gsinghlive]

@_cparker I have followed what is in the article you mentioned. I have no unified support agreement. I maintain this library for nodejs https://github.com/gautamsi/ews-javascript-api and I am unable to migrate due to lack of proper documentation. 

if anyone has tried this with ews-managed-api in C#, let me know.

[Forrest Hoffman]

Does anyone know if this is also going to affect ResourceImpersonation? I am also trying to determine in the Unified Audit Log how to search the account usages.

According to the Unified Audit Logging article for Mailbox Auditing

You cannot Search for Activity on a Resource mailbox. 
Unfortunately, this is exactly what I am trying to investigate.

We use a service to synchronize Rooms Reservations to Android tablets mounted on the walls.
If the change does not impact ResourceImpersonation and is ONLY applicable to ApplicationIMpersonation then I may have wasted half my day.

[RichardAtRiva]

This is a major deprecation to have such a short notification period of only 2 months. It will require significant changes to adjust the way our customers configure and setup our application to adapt to this change. These types of infrastructure and application changes need time to develop, test and deploy, and this notification period is simply not sufficient.

And I'll reiterate, as I have on the previous EWS deprecation notices, that the Graph API simply is not production ready to replace EWS. It is fraught with performance and functional issues, and Microsoft does not appear to be making any progress on solving them.

[MSFT-Saurabh]

Application Impersonation Role Retirement: Below are the latest recommendation from Microsoft.

EWS impersonation provides a mechanism for EWS applications that run as a service account to act as a user, whereas With Microsoft Graph there are no service accounts.

Instead, permissions are granted to applications directly, the way to achieve Impersonation in Microsoft Graph is by making use of app-access policy and application permissions.

You can learn more about this from the Microsoft Document here:  
https://learn.microsoft.com/en-us/graph/migrate-exchange-web-services-authentication#impersonation 

• consider using the Microsoft identity platform / application model for building apps that integrate with Microsoft cloud data.
• Register your app in Microsoft Azure, utilize OAuth for secure access, and follow best practices for permissions and visibility.
• If you have EWS applications requiring access to multiple mailboxes, ensure they are configured properly with OAuth for App-only access.

Exchange Web Service Mapping with MS Graph APIs: You can find the Graph API's mapping in the Microsoft article below.
Exchange Web Services (EWS) to Microsoft Graph API mappings - Microsoft Graph | Microsoft Learn 

[hiep_tran]

@_cparker "If you are using the Delegated permission with an account that has the ApplicationImpersonation role assignment to perform 1:many mailbox access, yes. Applications that are using this permissions model with an account that was assigned the ApplicationImpersonation role are affected and must follow the guidance in the article."

Does this mean that somehow if we manage to make our app work without the ApplicationImpersonation role assigned to the account (using Delegated permission "EWS.AccessAsUser.All"), our app will not be affected anymore?

Many thanks

[gsinghlive]

@MSFT-Saurabh @_cparker 
I know you guys are good at pointing to documentation but there is no way they work. One article talks about RBAC for APPS and other talks about how to use oAuth with EWS. Both do not reference each other and the combination does not work. it is easy ask for getting Unified Support contract which usually very big companies have and not an open source library maintainer like me.

Are you guys able to do it yourself? it hardly takes few hours to set it up and test this for any non-MSFT developer, I guess it will be much less time for people like yourself.

many would appreciate if you confirm that you followed the article yourself (fresh created apps and permission as per article) and you had success without applying any extra step or code or permission to do this.

I bet that would not work that is why we have so many people asking the question and all we get a pointer to a document. 

[Forrest Hoffman]

@RichardAtRiva   I received MC718754 on Feb 25 as part of the Weekly Digest.

However, it was vague to the point where I thought I wouldn't have to take action until much later.

[RichardAtRiva]

@Forrest Hoffman Yeah, I didn't see any such announcement in Oct. 23. If I search now for it using MC718754, I still can't seem to find that. Do you have a link?

Either way, if it was too vague for most people to properly understand the impact, I would still suggest that this deprecation should be postponed to give users, and partners a sufficient amount of time to adapt.

[Forrest Hoffman]

Sure, this is from our tenant but should still work   MC718754.

My statement about Oct 23 may be wrong and referred to another change.  
I'll amend what I wrote earlier.

[_cparker]

@hiep_tran In that hypothetical scenario, yes, as the application's account would not be making use of the ApplicationImpersonation role that is the subject of this retirement.

[_cparker]

@gsinghlive We've tested this, and it works. You need to make sure that you are creating the service principal using the values from the Enterprise App page, not the App Registration page. The object id's differ between these locations, and the values from the Enterprise App page for your application must be used. When using the App Registration values, you will encounter the error you mentioned. No extra steps are required.

[gsinghlive]

Thanks @_cparker I have verified that I have used correct ID by using ` Get-MgServicePrincipal` due to the disconnect in id on both pages and the note in guide asking to verify the id with this cmdlet. 

I did not have to do anything to make it work today, what changed ? 

I redid everything and it took several hours to get this permission working in a very small developer tenant. My bad I was hoping it will be good in 30min to 2 hours. but it took more than that

[gbsridhar81]

Does it affect the delegated access model? We have currently granted the application access to EWS API through the delegated access model and the user access is granted through management role assignment in Exchange. 

[cmixSol]

Grateful for the helpful conversation here. I'm also curious if we need to move away from any custom application impersonation roles.

Additionally, should we expect this deprecation to impact the delegating role assignments inherited from a role group?

[_cparker]

@gbsridhar81 If you are using the Delegated permission with an account that has the ApplicationImpersonation role assignment to perform 1:many mailbox access, yes. Applications that are using this permissions model with an account that was assigned the ApplicationImpersonation role are affected and must follow the guidance in the article.

[_cparker]

@cmixSol We will be removing the ApplicationImpersonation role and its feature set. This will impact functionality making use of this role, inherited or otherwise.

[gbsridhar81]

@_cparker: I appreciate your response to my query. So, in short if we want to have 1 to many mailboxes access, then the only option is to go with application permission model (not delegated) and then control the target mailbox access through RBAC for apps? Please confirm.  

[_cparker]

Correct, you should use RBAC for Applications to configure 1:many mailbox access for your application(s).

[cdelorey]

@_cparker  This is unclear. Does this mean that new assignments will no longer be allowed, or does this mean that both new assignments and existing assignments will stop working starting in May?