Ken Muse

Using OnMicrosoft.com Azure Active Directory Accounts


When you create an Azure account, a unique domain name will be automatically assigned to you. This unique name has several advantages which can make it very helpful for managing your Azure account.

If you open your Azure Active Directory, you’ll be presented with the Overview blade. This blade displays your unique directory name and domain name.

In this example, you can see I have a custom domain name assigned called yoursitehere.onmicrosoft.com. This detail is also provided in the Custom domain names blade.

Like any domain associated with you tenant, this allows you to create users with an email address in that domain. If I click the Users blade and then New User, I can create a user account that relies on this custom domain name. For example, [email protected]:

This creates a user called “B2C Tenant Owner” using our onmicrosoft.com domain.

Why would we want to do this? By using an account that doesn’t represent a particular individual in our organization, we have an inherent ability to limit who can access the account to make changes. You can assign this account the Owner role for critical resources. Let’s dive a bit deeper into that.

The Owner role in Azure is a role with elevated permissions. The main difference from the Contributor role is that the Owner role can assign or alter permissions. In a centrally managed IT organization, you will typically want users to have access to discrete sets of resources — especially in the production environment. To this end, you assign the Owner role to an onmicrosoft.com account and make the administrator for the resources a Contributor. If additional permissions are required, additional roles or custom roles can be used to grant those specific permissions.

There are two common use cases for this. The first and most common involves Microsoft Enterprise Agreement (EA) subscriptions. Rather than making a single individual the Owner of the subscription, we use an onmicrosoft.com account. We then assign our administrative users Contributor rights to the overall subscription. This user can now perform all of the actions available to the Owner except altering the permissions on the subscription. Ideally, we will assign the permissions to an AAD Security Group, and then apply the security group to appropriate resources. With EA accounts, this has the advantage of ensuring that the Owner role is using a valid user account which is not also part of a different Azure tenant.

It’s very common for IT to use this approach to limit access to certain shared resources. Enterprises using an ExpressRoute or VPN to connect the on-premise environments to Azure will commonly employ a hub and spoke topology to connect the networks. In this configuration, the subscription users are typically restricted using RBAC from altering the main network resources (typically, placed in a resource group with read-only access). By avoiding the use of the Owner role, these restrictions can be enforced across all users in the subscription.

Similarly, when we create a new B2C tenant, we require a Global Administrator. By making this account an onmicrosoft.com account, we can reserve the Global Administration rights. We can still grant appropriate users Limited Administration rights. This allows us to restrict who has access to alter permissions or add administrative users to a production B2C tenant.

Using an onmicrosoft.com account has several advantages over the standard domain accounts for these particular use cases. It makes it clear that this is a restricted-access special account and it allows us to maintain control over the administrative rights of key production resources.