Subscription Governance: The Relationships and Dependencies Involved with Managing Subscriptions
In this article Introduction Relationships and dependencies between Entra ID, Billing Accounts and Subscriptions Identity and Roles Billing Account and Subscription Creation Summary Introduction In cloud governance, the relationships between Entra ID, Billing Accounts, Subscriptions, and User Permissions are frequently misunderstood even by experienced practitioners. Many organizations assume these components form a simple hierarchy or that permissions and associations are inherited in certain ways. In reality, these elements are loosely associated, and their dependencies are far more nuanced. Misunderstanding these relationships and dependencies poses a challenge to governance and can allow subscription sprawl. For example, assuming that billing accounts and subscriptions are always tied to the same Entra ID tenant, or that user roles in Entra ID automatically confer billing permissions, can result in misconfigured access controls and the creation of subscriptions outside of your corporate procurement and deployment processes. There can also be confusion about where to go to manage permissions. Is it Entra ID, is it in the resource RBAC, is it in the billing account? Effective governance requires clarity on: How Entra ID tenants, billing accounts, and subscriptions are associated and how these associations can be changed. Which roles have the authority to create or manage subscriptions and billing accounts, and where those roles are found. How the type of billing account (EA, MCA, MOSP, Partner) determines who can create subscriptions and what controls are available. By understanding these foundational relationships and the specific permissions required, organizations can avoid common pitfalls and build a governance model that is both secure and flexible. Relationships and dependencies between Entra ID, Billing Accounts and Subscriptions In order to manage subscriptions, it is key to understand the components and dependencies related to subscriptions. Let’s first understand the relationship between subscriptions, billing accounts and Entra ID tenants. Do not think of the tenant as a container for billing accounts which are containers for subscriptions. Think of the relationship between these components as “associations” rather than a hierarchy. A billing account is typically associated with a single Entra ID tenant. However, with MCA billing accounts you can configure Associated Billing Tenants which allow users from multiple tenants to have billing permissions on a single billing account. Entra ID can have many different billing accounts of different types. A billing account can be associated with many subscriptions, but a subscription can only be associated with a single billing account. An Entra ID tenant can be associated with many subscriptions, but a subscription can only be associated with a single tenant. A subscription is first associated with the tenant in which the user is logged in, which isn’t always the same tenant for which the associated billing account belongs to. These relationships or associations can also be changed later. For example, Subscription Owners can change the association of the subscription’s Entra ID tenant to ANY other Entra ID tenant in which they have access. They don’t need elevated permissions in the target tenant. One of the most important things to know is that the billing account that is associated with a subscription does not need to be associated with the same Entra ID tenant for which the subscription is associated with. See the following example associations: Identity and Roles Entra ID is a directory of user identities and other objects. A user identity can be associated with many Entra ID tenants. While the primary account belongs to a single tenant, users can be invited as guest users to any number of Entra ID tenants using B2B collaboration. There are three places that house roles/permissions that are mapped to those user identities: Entra ID roles, Azure Resource Manager (ARM) Role Based Access Control (RBAC), and Billing Accounts. Entra ID Roles Entra ID roles manage directory level objects such as user identities. The Global Administrator is the most well-known role within Entra ID. Entra ID roles are typically limited to managing the directory, however there is the ability to elevate access so that the Global Administrator can access and assign RBAC and Billing roles to themselves or others (two exceptions are that the Global Admin cannot elevate billing permissions for EA or MOSP billing accounts). Entra ID roles assigned to a user in one tenant do not follow them when they gain access to another tenant. ARM RBAC RBAC is a function of the ARM and is scoped to either management groups, subscriptions, resource groups or resources. RBAC is inherited from parent scopes. The RBAC assigned for a user in one tenant, is not shared with any another tenant as the mappings are maintained by ARM for each resource in the tenant. As each tenant has unique resources, the RBAC mapping the user has for resources in one tenant logically cannot exist in another tenant. While user identity is handled by Entra ID, the RBAC is handled at the resource level. Billing Roles Billing roles are a part of the billing/commerce engine and depend on the billing account type. For example, with an MCA billing account you manage them in Cost Management + Billing instead and not in Entra ID. These billing roles are different depending on the billing account type. While billing roles manage access to billing details, they also control the creation of subscriptions. If you have the correct billing role, you can create subscriptions under that billing account. Subscription creation is not managed by Entra ID roles nor RBAC. Billing Accounts There are 4 main billing account types: Enterprise Agreements (EA): Legacy contractual model for large enterprises. Provides volume licensing discounts, centralized invoicing, and long-term pricing commitments but is gradually being replaced by MCA. Billing roles to create subscriptions: Enterprise Administrator, Account Owner Microsoft Customer Agreements (MCA) The modern default billing model for enterprise customers. Free trial and pay-go subscriptions are supported. Invoice-based or credit card billing, supports multiple billing profiles and invoice sections. Billing roles to create subscriptions: Billing Account Owner/Contributor, Billing Profile Owner/Contributor, Billing Invoice Owner/Contributor, Subscription Creator Microsoft Online Services Program (MOSP) Agreements Tied to a single user, lacks enterprise governance features, and is the most common source of subscription sprawl. Typically used by individuals or small businesses and supports free trial, pay-go and Visual Studio subscriptions. Billing role to create subscriptions: Account Administrator Microsoft Partner Agreements (MPA) A billing account owned and managed by a Microsoft partner. Subscriptions billed under CSP appear in your tenant but financially roll up under the partner’s agreement. Control over invoicing and some subscription-level actions is delegated to the CSP, not directly to corporate IT. Billing role to create subscriptions: Admin agent role in the CSP partner organization Billing Account and Subscription Creation As the roles within the billing account provide the permissions to create subscriptions it is important to understand who can create these billing accounts. Because whoever can create a billing account, is also able to create a subscription. And remember, subscriptions do not need to be associated with the same Entra ID tenant as the billing account. Billing accounts are created in the following ways: Enterprise Agreements (EA) An individual at your company works with Microsoft to set up an EA contract. An EA billing account is created for them, and they become the Enterprise Administrator for that billing account. Microsoft Customer Agreements (MCA) An individual at your company works with Microsoft to set up an MCA contract. An MCA billing account is created for them, and they become the Billing Account Owner for that billing account. Microsoft Online Services Program (MOSP) Agreements Any individual can perform a self-signup for a pay-go or free-trial subscription. When they do this, a billing account is created for them, and they become the Account Administrator for that billing account. This can be done in any Entra ID tenant for which they have an identity (including guest accounts). Microsoft Partner Agreements A Microsoft Partner registers and manages the CSP billing account on behalf of a customer. They become the Admin agent. Summary Understanding the associations between Entra ID tenants, identity, permissions, billing accounts, and subscriptions is foundational for effective governance. With these building blocks in place, you can design for and establish governance that will ensure your environment aligns with your corporate strategy and reduce opportunity for subscription sprawl.
Managing Multi-Tenant Azure/365: Workarounds for Cross-Tenant Limitations in Purview and Fabric
I am working in a Microsoft Azure/365 multi-tenant setting due to some constraints. I am using Purview (Tenant1) and Fabric (Tenant2), M365 in (Tenant 2). I'm facing issues with various solutions due to cross tenant limitation for eg: Data Quality Connection, Metadata ingestion, lineage, etc. To overcome this I am exploring various workarounds. Key Question: 1. Are there proven workarounds or solutions to manage data estate in this scenario? (Can't merge /migrate tenants)
Migrated users in a new MS Tenant have old calendar invites from previous tenant users
Good afternoon. We recently moved a group of users to a new Microsoft tenant. Before the migration, some users had sent out meeting invitations while using the old tenant. Now that they’ve transitioned to the new tenant, they were able to remove those meetings from their Outlook client. However, the attendees who received those invitations still see the meetings in their calendars I have tried to use the command "Remove-CalendarEvents" but because the original account was used to create the invites under the old tenant, the command cannot find that email address in the new tenant. Any help would be greatly appreciated.
Unable to delete tenant
I want to delete a single tenant I've created some time ago using my personal MS account (@outlook.com). The goal is to start fresh. In the Manage tenants page I see this 'All initial checks passed. Click 'Delete' to Delete tenant 'Default Directory'', meaning all the checks are passed. However, when I try to delete 'Default Directory' I am getting below error: 'Unable to delete tenant Default Directory. Known issues exist where some enterprise applications are not capable to delete within the portal. Click the notification title for more information and manual troubleshooting steps.' But I don't have any enterprise applications left in my tenant. Is it even possible to delete only tenant?Migration Data Factory pipelines between tenants
Hi everybody. I need your help please. I'm trying to migrate several Data Factory pipelines between 2 diferent fabric tenants. I'm using Azure DevOps to move all the workspaces, I created the connections with the same name but when I try to restore the data factory pipelines it return an error than datafactory pipielines can't be created because doesn't find the connections. I was trying to update the connection ID but I don't find them into the json file. How can I migrate these data factories and reconnect to the new connections?Azure Devops Pipeline for Power Platform solution : Tenant to Tenant
I have a query related to Azure Devops Pipeline. Is it possible to move form one tenant to another tenant. Is it possible to move canvas app solution using Azure Devop Pipelines. If yes, I am using Sharepoint lists. Can this be moved, as it wont be the part of solution, should it be done manually? I am also using environment variables, How will this be mapped in the receiver tenant using pipelines. I have few solutions that i need to move from one solution to another every sprint. So what will be the suitable plan/license for it. Can you please share relevant documents or steps or related videos if any regarding this.
Is it possible to connect 2 carrier Teams Tenants with 1 supported SBC?
Hi Everyone, Good day! Recently I'm testing SBC for multiple tenants. I found the below article. It seems to be a method to connect 1 carrier tenant with multiple customer tenants through base domain and sub domain matching. But our situation is a bit different, we have 2 carrier tenants and want to connect to the same SBC. Is it possible? If yes, any reference materials? https://docs.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants#deploy-and-configure-the-sbcHow to integrate Microsoft User Authentication using Microsoft Entra ID: A Step-by-Step Guide to Use
Microsoft Entra ID, also known as Azure AD (Active Directory), offers numerous advantages. Whether you're prioritizing security or seeking a well-organized and automated User Management system, this tool is your go-to for building a secure authentication system, be it for a web app, mobile app, or any other application.Teams Activity Feed Notifications / Multi-Tenant
Hello! I have some questions about Teams activity feed notifications and how they work in conjunction with tenants. What I currently have is: * In AAD registered an application in a tenant with permissions + admin consent to send activity notifications - the application was registered with signInAudience "AzureADMultipleOrgs" * Set the ID of that application as "webApplicationInfo" in the manifest of the teams application developed by us * Get an application token with a secret configured with this application from login.microsoft.com * Send an activity notification with that application token to a user by it's ID (the notifications are sent by our application) via graph.microsoft.com With this an activity notification can be sent to all users which have installed the teams application. But that only works if the user which the notification should be sent is also in the same tenant than the application was registered. If the user has the application installed but is from an other tenant, an error message like "the user cannot be found in the tenant" occurs. As the ID of the registered application is also part of the manifest I don't understand how it would be possible for an other organisation to install our teams application and we can send activity notifications to their users in their tenant. The other organisation could themselves register an application in their ADD with appropriate access rights and configure access to it so that our application could send notifications to their users, but as the ID is in the manifest this would not be possible as that ID always points to our tenant. I tried removing the "webApplicationInfo" entry from the manifest, but without it sending notification does not work at all. What I am missing here? My main questions: * How would it be possible to send activity notifications to users in different tenants for a Teams application in the store (so no manifest change is possible)? * Why is sending notifications restricted to only the tenant the application was registered in? Should a limitation to users which have the application installed not be enough restriction? Thank you and regards, Dominik
