What’s the right way to update Entra apps that connect to on-prem services? Should we be leaning on the vendor’s latest guidance?
Having worked with several organizations and vendors, I see this as one of the major issues in Entra application lifecycle management. As Entra applications are the new frontier for non-human interaction towards Entra, and vendors learn how to wield the platform, they inevitably update their solutions to make better use of the platform features and/or use lesser privileges.
Vendors may update the code in their installation/upgrade process, but typically, because the (enterprise application and) app registration already exist, these steps may be skipped. That way, rolling back the upgrade on-premises or restoring from backup remains possible…
Vendors of multi-tenant apps - where the application registration lives in the tenant of the vendor and instances of Enterprise applications are hosted in clients’ tenants, based on the blueprint in that one application registration - may apply lesser privileges or branding changes, but these don’t make it to their clients’ tenants, because the blueprint is only applied upon creation of the Enterprise application…
I’ve been working with a particular vendor on solving this, and we’ve been testing a procedure where we delete the (enterprise application and) application registration before an upgrade, to have a solution recreate its Entra artifacts.
You know what… let me write a blogpost on it, so that everyone can benefit!
1 Like