How to deal with the “Migrate Service Principals from the retiring Azure AD Graph APIs to Microsoft Graph” recommendation

Over the past few weeks, Microsoft started rolling out a new Entra ID recommendation, with the goal of helping customers prepare for the upcoming deprecation of the Azure AD Graph API. While the intentions were indeed good, and the Entra ID recommendations feature itself is quite a useful one, this new Migrate Service Principals from the retiring Azure AD Graph APIs to Microsoft Graph recommendation caused some stir on the various Microsoft-focused communities, as the data exposed therein raises some concerns.

Let me be very clear, none of this is actually new. The initial announcement about the Azure AD Graph API retirement dates back to 2020 (as usual Microsoft postponed it few times). A plethora of blog posts around the upcoming deprecation have since been posted, the most recent one from this month. The recommendation itself has been around in various shapes and forms for few months. But as Microsoft is well aware that not many people read those blogs, and even fewer are paying attention to the Entra ID recommendations, they went ahead and send an email notification to tenant admins.

Nothing wrong thus far, we’ve seen more aggressive campaigns for much less important milestones, and we certainly cannot blame Microsoft for trying to keep their customers informed. What caught many customers unprepared however is the data exposed in the Migrate Service Principals from the retiring Azure AD Graph APIs to Microsoft Graph recommendation and the call to action. For some reason, the recommendation can potentially surface a bunch of first-party (i.e. Microsoft owned) service principals. While there is nothing wrong in knowing which of the apps leveraged by users in your tenant are still relying on the soon to be deprecated Azure AD Graph API, the “action plan” for this recommendation raised some questions, and rightly so.

On the screenshot below, you can see an example for this recommendations’ impacted resources in one of my tenants. In most Microsoft 365 tenants, you can expect to see at least one of these entries, namely the Microsoft Office application (ID of d3590ed6-52b3-4102-aeff-aad2292ab01c). The Azure Active Directory PowerShell entry (ID of 1b730954-1685-4b74-9bfd-dac224a7b894) should also be a fairly common one, for organizations where admins are still using the Azure AD PowerShell module (which you should not be doing anymore).

AADGraphDeprecation

Clicking the More details link should bring up a pane with breakdown of all the operations performed against the Azure AD Graph API via the corresponding service principal for the past 30 days. This is a great piece of insight you can otherwise only get if you have configured the Graph activity logs export. Here, you get it for free, and in an easily digestible form, which is great. What is not great is the Resource link on top, which seems to lead nowhere, and further confuses customers.

AADGraphDeprecation1

Along with this data, each Recommendation entity will surface an Action plan, outlining the steps you can use to remediate it. Here’s a direct copy paste for the Action plan on the Migrate Service Principals from the retiring Azure AD Graph APIs to Microsoft Graph recommendation:

Action plan
1. Review the list of Service Principals calling Azure AD Graph under Impacted Resources.
2. Working with the owner or publisher of the corresponding application, identify steps required to update the application to a version that is using Microsoft Graph APIs instead of Azure AD Graph APIs.
3. Learn more about Azure AD Graph retirement. Azure AD Graph Retirement
4. Learn more about Microsoft Graph. Microsoft Graph

This is the part that causes the biggest confusion. While the steps above certainly make sense for some scenarios, they fail to address the most common one – service principals owned by Microsoft appearing in the recommendation. Specifically, those that are hidden from plain view and do not surface in any of the admin tools. There are many examples of service principals that fail under this category, some of which have been documented by Microsoft or customers. Such lists are far from being exhaustive however, and given the sheer number of such service principals, it’s perhaps unsurprising that some of them will appear under this recommendations’ Impacted resources list.

The reasons for that can vary. In some cases, such as the Azure AD PowerShell module, Microsoft might have deprecated the corresponding tool/feature/service, and is still in the process of cleaning up any related resources. In others, we are seeing the not-so-uncommon scenario of Microsoft releasing a feature, then having the PM and engineering team move to the next big thing, and just leave the code in limbo. Some of my favorite M365 features fall into this category, but I digress. And, there is of course the outlier scenario, with Microsoft simply ignoring their own recommendations. We got enough evidence of this from all the high-profile “security incidents” over the past few years 🙂

Whatever the reason, the fact remains that you will likely encounter such “first-party” service principal entries when working with the Migrate Service Principals from the retiring Azure AD Graph APIs to Microsoft Graph recommendation. So what can you do about them? Here are my recommendations (pun intended):

  • First, copy the ID of the resource, which is effectively the appID (client id) value of the corresponding service principal (or application).
  • The next step is to figure out what the ID corresponds to. There are several methods you can use for that:
    • Navigate to the Enterprise applications page. Then, hit the Add filters button and select Application ID for the filter and paste the ID value in the Application ID field. Do make sure to remove the Application type filter, as by default it will remove most of the first-party entries.
    • Use the Graph SDK for PowerShell, Graph explorer or any other Graph-based tool. Make sure to filter by the appId property, not by objectID. Here is an example via the Get-MgServicePrincipal cmdlet:
      Get-MgServicePrincipal -Filter "appId eq '1b730954-1685-4b74-9bfd-dac224a7b894'"
      
      Get-MgServicePrincipalByAppId -AppId '1b730954-1685-4b74-9bfd-dac224a7b894'
      

      For additional examples, consult the Graph API documentation on the GET service principal method.

    • Do not be surprised if no entries are returned from the above, as mentioned few times already there are many hidden ones. As you cannot use any of the admin tools to surface information on such service principals, using your favorite search engine is the next best option. You can also consult this list, but again, far from exhaustive source.
    • Make sure to also check the App registrations page. Generally speaking, you should rarely be in situation where this is necessary, as usage of the app in any given tenant is only possible after its service principal has been provisioned (i.e. consent has been granted), and we already checked for matching service principals via the above steps. But you might run into a scenario where the SP has been removed for some reason, etc. Anyway, you can directly paste the ID in the search box on this page, but do make sure to switch to the All applications view first. The corresponding PowerShell cmdlet is:
      Get-MgApplicationByAppId -AppId ae23ad05-9b02-4946-a906-78b7a0757f5f
  • If you did manage to find a matching object within your organization, explore its properties to gather some additional details. Note any information about the Publisher of the app, but be aware that some of it might only be exposed via the Graph API or corresponding PowerShell cmdlets. Also, take a note of any Owners configured, as those should be the people in your organization most familiar with the app in question.
    If you are having trouble gathering this information on your own, consider leveraging my PowerShell script that does it all for you.
  • Depending on the result of the above steps, we might end up in one of several scenarios:
    • No matching service principal was found. The most likely explanation here is that you have run into a hidden service principal, owned by Microsoft. In which case feel free to give Microsoft your honest thoughts about this by either hitting the Got feedback? button on top, or via your preferred method of harassing them.
      Another possibility is that the service principal was removed sometime in the past 30 days.
    • A service principal owned by Microsoft or third-party vendor was found. Congratulations! You run into the prime use case for the Migrate Service Principals from the retiring Azure AD Graph APIs to Microsoft Graph recommendation. Follow the action plan above, and ask the owner of the app to contact the vendor in order to understand their plans for updating the application. If no owners are configured, you as the administrator will have to take on this task. And, you might also take this opportunity to evaluate the need for this application. Given the fact that the vendor neglected to update it for several years, perhaps consider switching to an alternative vendor, or removing the app altogether.
      And if the service principal belongs to Microsoft, just ignore it. They will update it, eventually. Or you can harass them, not only they are causing confusion, but ignoring their own best practices and recommendations!
    • A service principal corresponding to an application developed by your organization was found. Note that this doesn’t necessarily mean the application resides in the same tenant where you run into the infraction, but any tenant owned by your organization (or parent company, etc). In this case, it will be up to you, or someone within your organization to ensure that the application has been updated to leverage the Microsoft Graph instead. Or, as in the case with third-party apps, you might want to reevaluate the need for this application, given the lack of updates.
      If for some reason you have an application that you cannot update before the February 2025 deadline, you can extend access to the Azure AD Graph API for said app by following the method outlined in this article.
  • If you are having trouble locating the owner of a given application, there are few things you can try. Start by reviewing the sign-in and audit logs, where available. Those should give you an idea about the users leveraging said app, and perhaps a hint as to which department(s) or business unit(s) “own” it. Or, you can try the “brute force” approach – disable the app temporarily and follow the screams. Once you know who the app owner is, work with them, or the vendor, to make sure a new version will become available before the deadline.
  • Rinse and repeat for any other impacted resources listed under the recommendation. You should hopefully have just a handful of these. If not, reevaluate the process you are using to add and monitor usage of Entra ID integrated apps.

Before closing the article, there is one additional thing you should take into consideration. The recommendation we discuss in this article is based on actual usage, thus it is possible that you have applications that leverage the Azure AD Graph within your tenant that will not appear in the list because of lack of usage in the past 30 days. If you want to be more thorough, you can run my service principals report script and filter out any entry that has “Windows Azure Active Directory” listed in the permissions fields. For its report on app registrations sibling, I even added a field to signal Azure AD Graph usage.

And that’s it. Some additional information can be found in the official documentation on the recommendation. There is nothing that scary or complicated going on here, but Microsoft could have handled this things better, IMO. Especially when it comes to applications owned by them, which should have been hidden from view, or maybe even updated on their end, instead of showing up in what’s a purely informational message.

P.S. While I do not have an exhaustive list of applications that can potentially appear under this recommendations’ impacted resources, here are some of the common ones:

  • d3590ed6-52b3-4102-aeff-aad2292ab01c – Microsoft Office (ignore it)
  • 1b730954-1685-4b74-9bfd-dac224a7b894 – Azure Active Directory PowerShell (update to Graph SDK for PowerShell/Entra PowerShell)
  • 04f0c124-f2bc-4f59-8241-bf6df9866bbd – Visual Studio (ignore it)
  • 04b07795-8ddb-461a-bbee-02f9e1bf7b46 – Azure CLI (update to the MSAL-based Azure CLI)
  • 1950a258-227b-4e31-a9cf-717495945fc2 – Azure PowerShell (update to the Az module)
  • fe6aa35b-7da8-44fd-a44e-e2d4bafbdab5 – Modern Workplace Tools (ignore it)
  • cdb1c100-cbe5-4a62-acb0-0a2ad77f698e – Modern Workplace Tools (Service) (ignore it)

If you use my service principal reporting script, you can potentially uncover few more. I do not have sufficient usage data for them in my tenant, so I cannot guarantee any of the below is still relevant:

ApplicationId			SP name				Publisher
0473c7eb-66c6-4c65-82b4-c6400ea3fb78	Office 365 Training		Microsoft Learning
33486655-4d68-4145-bd5d-f245af637cf8	PowerShell Gallery		PowerShell Gallery
3556adcf-f332-4d63-b677-ef1fcb328095	O365 Secure Score		trustportal
2e5a173e-72b1-452e-867e-f84c70eb7bf5	Office 365 Service Trust Portal	trustportal
264fc698-9d94-486a-9159-436ab673c76c	FastTrack Production		Valorem Consulting Group
ccc737ba-4bcc-4a71-8e38-f0e86310d5e8	FlowRPCustomConnector		Microsoft
31359c7f-bd7e-475c-86db-fdb8c937548e	PnP Management Shell		Microsoft 365 PnP
b257e672-b9d0-496c-80b6-14bed02c944e	Modern Learning Experiences	Microsoft Learning
e462442e-6682-465b-a31f-652a88bfbe51	Microsoft events		Microsoft
5a0aa725-4958-4b0c-80a9-34562e23f3b7	Windows Virtual Desktop AME	MS Azure Cloud
fa4345a4-a730-4230-84a8-7d9651b86739	Windows Virtual Desktop Client	MS Azure Cloud
41b23e61-6c1e-4545-b367-cd054e0ed4b4	Azure VPN			Microsoft

The PnP module for one is now deprecated.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.