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.
Update Entra ID Device Extension Attributes via PowerShell & Create Dynamic Security Groups.
2) Overview of Extension Attributes and Updating via PowerShell What Are Extension Attributes? Extension attributes (1–15) are predefined string fields available on Entra ID device objects. They are exposed to Microsoft Graph as the extensionAttributes property. These attributes can store custom values like department, environment tags (e.g., Prod, Dev), or ownership details. Why Use Them? Dynamic Group Membership: Use extension attributes in membership rules for security or Microsoft 365 groups. Policy Targeting: Apply Defender for Endpoint (MDE) policies, Conditional Access or Intune policies to devices based on custom tags. For details on configuration of the policies refer below documentation links. https://learn.microsoft.com/en-us/defender-endpoint/manage-security-policies https://learn.microsoft.com/en-us/intune/intune-service/ https://learn.microsoft.com/en-us/entra/identity/conditional-access/ Updating Extension Attributes via PowerShell and Graph API Use Microsoft Graph PowerShell to authenticate and update device properties. Required permission: “Device.ReadWrite.All”. 3) Using PowerShell to Update Extension Attributes create app registration in Entra ID with permissions Device.ReadWriteall and Grant admin Consent. Register an app How to register an app in Microsoft Entra ID - Microsoft identity platform | Microsoft Learn Graph API permissions Reference. For updating Entra ID device properties you need “Device.ReadWrite.all” permission and Intune administrator role to run the script. Microsoft Graph permissions reference - Microsoft Graph | Microsoft Learn Below is the script Important things to note and update the script with your custom values. a) update the path of the excel file in the script. column header is 'DeviceName' Note: You may want to use CSV instead of excel file if Excel is not available on the admin workstation running this process. b) update the credential details - tenantId,clientId & clientSecret in the script. Client id and client secret are created as a part of app registration. c) update the Externsionattribute and value in the script. This is the value of the extension attribute you want to use in dynamic membership rule creation. ___________________________________________________________________________ #Acquire token $tenantId = "xxxxxxxxxxxxxxxxxxxxx" $clientId = "xxxxxxxxxxxxxxxx" $clientSecret = "xxxxxxxxxxxxxxxxxxxx" $excelFilePath = "C:\Temp\devices.xlsx" # Update with actual path $tokenResponse = Invoke-RestMethod -Uri "https://login.microsoftonline.com/ $tenantId/oauth2/v2.0/token" -Method POST -Body $tokenBody $accessToken = $tokenResponse.access_token # Import Excel module and read device names Import-Module ImportExcel $deviceList = Import-Excel -Path $excelFilePath foreach ($device in $deviceList) { $deviceName = $device.DeviceName # Assumes column header is 'DeviceName' Get device ID by name $headers = @{ "Authorization" = "Bearer $accessToken"} $deviceLookupUri = "https://graph.microsoft.com/beta/devices?`$filter=displayName eq '$deviceName'" try { $deviceResponse = Invoke-RestMethod -Uri $deviceLookupUri -Headers $headers -Method GET } catch { Write-Host "Error querying device: $deviceName - $_" continue } if ($null -eq $deviceResponse.value -or $deviceResponse.value.Count -eq 0) { Write-Host "Device not found: $deviceName" continue } $deviceId = $deviceResponse.value[0].id # Prepare PATCH request $uri = "https://graph.microsoft.com/beta/devices/$deviceId" $headers["Content-Type"] = "application/json" $body = @{ extensionAttributes = @{ extensionAttribute6 = "MDE" } } | ConvertTo-Json -Depth 3 try { $response = Invoke-RestMethod -Uri $uri -Method Patch -Headers $headers -Body $body Write-Host "Updated device: $deviceName"} catch { Write-Host "Failed to update device: $deviceName - $_" } } Write-Host "Script execution completed." ________________________________________________________________________________________________________________________ Here’s a simple summary of what the script does: Gets an access token from Microsoft Entra ID using the app’s tenant ID, client ID, and client secret (OAuth 2.0 client credentials flow). Reads an Excel file (update the path in $excelFilePath, and ensure the column header is DeviceName) to get a list of device names. Loops through each device name from the Excel file: Calls Microsoft Graph API to find the device ID by its display name. If the device is found, sends a PATCH request to Microsoft Graph to update extensionAttribute6 with the value "MDE". Logs the result for each device (success or failure) and prints messages to the console. 4) Using Extension Attributes in Dynamic Device Groups Once extension attributes are set, you can create a dynamic security group in Entra ID: Go to Microsoft Entra admin center → Groups → New group. Select Security as the group type and choose Dynamic Device membership. Add a membership rule, for example: (device.extensionAttributes.extensionAttribute6 -eq "MDE") 4. Save the group. Devices with extensionAttribute6 = MDE will automatically join. 5) Summary Extension attributes in Entra ID allow custom tagging of devices for automation and policy targeting. You can update these attributes using Microsoft Graph PowerShell. These attributes can be used in dynamic device group rules, enabling granular MDE policies, Conditional Access and Intune deployments. Disclaimer This script is provided "as-is" without any warranties or guarantees. It is intended for educational and informational purposes only. Microsoft and the author assume no responsibility for any issues that may arise from the use or misuse of this script. Before deploying in a production environment, thoroughly test the script in a controlled setting and review it for compliance with your organization's security and operational policies.Using Entra ID Authentication with Arc-Enabled SQL Server in a .NET Windows Forms Application
Introduction: This guide demonstrates how to securely connect a .NET Framework Windows Forms application to an Arc-enabled SQL Server 2022 instance using Entra ID (Azure AD) authentication. It covers user authentication, token management, and secure connection practices, with code samples and screenshots. In many modern applications, it is common practice to use an application web service to mediate access to SQL Server. This approach can offer several advantages, such as improved security, scalability, and centralized management of database connections. However, there are scenarios where directly connecting to SQL Server is more appropriate. This guide focuses on such scenarios, providing a solution for applications that need direct access to SQL Server. This model is particularly useful for applications like SQL Server Management Studio (SSMS), which require direct database connections to perform their functions. By using Entra ID authentication, we can ensure that these direct connections are secure and that user credentials are managed efficiently. By following the steps outlined in this guide, developers can ensure secure and efficient connections between their .NET Windows Forms applications and Arc-enabled SQL Server instances using Entra ID authentication. This approach not only enhances security but also simplifies the management of user credentials and access tokens, providing a robust solution for modern application development. SAMPLE CODE: GitHub Repository Prerequisites Arc-enabled SQL Server 2022/2025 configured for Entra ID authentication Entra ID (Azure AD) tenant and app registration .NET Framework 4.6.2 Windows Forms application (Not required .NET version, only what the solution is based on) Microsoft.Identity.Client, Microsoft.Data.SqlClient NuGet packages Application Overview User authenticates with Entra ID Token is acquired and used to connect to SQL Server Option to persist token cache or keep it in memory Data is retrieved and displayed in a DataGridView Similar setup to use SSMS with Entra ID in articles below. Windows Form Sample Check User Button shows the current user The Connect to Entra ID at Login button will verify if you are logged in and try to connect to SQL Server. If the user is not logged in, an Entra ID authentication window will be displayed or ask you to log in. Once logged in it shows a Connection successful message box stating the connection to the database was completed. The Load Data button queries the Adventure Works database Person table and loads the names into the datagridview. The Cache Token to Disk checkbox option either caches to memory when unchecked and would require reauthentication after the application closes, or the option to cache to disk the token to be read on future application usage. If the file is cached to disk, the location of the cached file is (C:\Users\[useraccount]\AppData\Local). This sample does not encrypt the file which is something that would be recommended for production use. This code uses MSAL (Microsoft Authentication Library) to authenticate users in a .NET application using their Microsoft Entra ID (Azure AD) credentials. It configures the app with its client ID, tenant ID, redirect URI, and logging settings to enable secure token-based authentication. //Application registration ClientID, and TenantID are required for MSAL authentication private static IPublicClientApplication app = PublicClientApplicationBuilder.Create("YourApplicationClientID") .WithAuthority(AzureCloudInstance.AzurePublic, "YourTenantID") .WithRedirectUri("http://localhost") .WithLogging((level, message, containsPii) => Debug.WriteLine($"MSAL: {message}"), LogLevel.Verbose, true, true) .Build(); This method handles user login by either enabling persistent token caching or setting up temporary in-memory caching, depending on the input. It then attempts to silently acquire an access token for Azure SQL Database using cached credentials, falling back to interactive login if no account is found. private async Task<AuthenticationResult> LoginAsync(bool persistCache) { if (persistCache) TokenCacheHelper.EnablePersistence(app.UserTokenCache); else { app.UserTokenCache.SetBeforeAccess(args => { }); app.UserTokenCache.SetAfterAccess(args => { }); } string[] scopes = new[] { "https://database.windows.net//.default" }; var accounts = await app.GetAccountsAsync(); if (accounts == null || !accounts.Any()) return await app.AcquireTokenInteractive(scopes).ExecuteAsync(); var account = accounts.FirstOrDefault(); return await app.AcquireTokenSilent(scopes, account).ExecuteAsync(); } Connecting to SQL Server with Access Token This code connects to an Azure SQL Database using a connection string and an access token obtained through MSAL authentication. It securely opens the database connection by assigning the token to the SqlConnection object, enabling authenticated access without storing credentials in the connection string. This sample uses a self-signed certificate, in production always configure SQL Server protocols with a certificate issued by a trusted Certificate Authority (CA). TrustServerCertificate=True bypasses certificate validation and can allow MITM attacks. For production, use a trusted Certificate Authority and change TrustServerCertificate=True to TrustServerCertificate=False. Configure Client Computer and Application for Encryption - SQL Server | Microsoft Learn string connectionString = $"Server={txtSqlServer.Text};Database=AdventureWorks2019;Encrypt=True;TrustServerCertificate=True;"; var result = await LoginAsync(checkBox1.Checked); using (var conn = new SqlConnection(connectionString)) { conn.AccessToken = result.AccessToken; conn.Open(); // ... use connection ... } Fetching Data into DataGridView This method authenticates the user and connects to an Azure SQL Database using an access token, and runs a SQL query to retrieve the top 1,000 names from the Person table. It loads the results into a DataTable, which can then be used for display or further processing in the application. private async Task<DataTable> FetchDataAsync() { var dataTable = new DataTable(); var result = await LoginAsync(checkBox1.Checked); using (var conn = new SqlConnection(connectionString)) { conn.AccessToken = result.AccessToken; await conn.OpenAsync(); using (var cmd = new SqlCommand("SELECT TOP (1000) [FirstName], [MiddleName], [LastName] FROM [AdventureWorks2019].[Person].[Person]", conn)) using (var reader = await cmd.ExecuteReaderAsync()) { dataTable.Load(reader); } } return dataTable; } Configure Azure Arc SQL Server to use Entra ID authentication Using SQL Server 2022 follow the instructions here to setup the key vault and certificate when configuring. This article can also be used to configure SSMS to use Entra ID authentication. Detailed steps located here: Set up Microsoft Entra authentication for SQL Server - SQL Server | Microsoft Learn Using SQL Server 2025 the setup is much easier as you do not need to configure a Key Vault, or certificates as it is relying on using the managed identity for the authentication. Entra ID App Registration Steps Register a new app in Azure AD Add a redirect URI (http://localhost) Add API permissions for https://database.windows.net/.default On the Entra ID app registration, click on API Permissions. Add the API’s for Microsoft Graph: User.Read.All Application.Read.All Group.Read.All Add a permission for Azure SQL Database. If Azure SQL database is not shown in the list ensure that the Resource Provider is registered for Microsoft.Sql. Choose Delegated permissions and select user_impersonation, Click Add permission for the Azure SQL Database. NOTE: Once the permissions are added ensure that you grant admin consent on the items. Security Considerations Never store client secrets in client apps Use in-memory token cache for higher security, or encrypted disk cache for convenience Use user tokens for auditing and least privilege References Microsoft Docs: Azure AD Authentication for SQL Server MSAL.NET Documentation Arc-enabled SQL Server Documentation Conclusion: By following the steps outlined in this guide, developers can ensure secure and efficient connections between their .NET Windows Forms applications and Arc-enabled SQL Server instances using Entra ID authentication. This approach not only enhances security but also simplifies the management of user credentials and access tokens, providing a robust solution for modern application development. *** Disclaimer *** The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
