Azure Subscription Management – Beyond the 101… aka The Advanced Topics

Introduction

Today’s post will cover three more advanced topics that I’ve seen surfacing on a regular basis ;

• Transferring a Subscription versus Changing the Directory of a Subscription
• Moving resources between subscriptions with different AAD (Azure Active Directory tenants
• Understanding the relationships between components when leveraging an Enterprise Agreement (EA)
• Various advanced scenarios on how AAD in intertwined between subscriptions & the EA

Transfer vs Change Directory

Apparently there is a bit of confusion between the “Transfer” and the “Change Directory” buttons for a subscription ;

In essence ;

Transfer Subscription = Change the Owner AND Change the Directory

What does that mean?

• If you want to transfer the billing of a subscription, you do a “Transfer“.
  (Do note: Transferring a subscription will also change the directory to the one linked to the new owner. If this is a different one, then you’ll be linked to a new AAD Tenant.)
• If you do not want to transfer the billing, and just change the directory, you do a “Change directory“.
  (Do note: Changing a directory will not remove the account owner. And (s)he’ll still have owner rights on it! Also be aware that all rights set linked to the previous tenant will disappear. So you’ll have to reinstate IAM. For which you can easily leverage management groups...)

Moving resources between tenants

Moving resources between resources groups & subscriptions is possible. There are a few exceptions to the rule… But in general all services can be moved “freely” (whilst adhering to their dependencies). That being said, when moving to another subscription, you can only do this to subscriptions linked to the same Directory / AAD Tenant.

You can work yourself around this by leveraging (let’s call it…) a “transit subscription” ;

Subscription X currently contains all your resources. And you want them to be transferred to Subscription Z. As X is linked to the AAD of Organization A, you won’t be able to move it directly to Z. This as Z is linked to the AAD of Organization B. So how do we work around this? We use an intermediate subscription (Y) that is in the first leg of the operation linked to source AAD (A). Then we move all the resources from X to Y. Once done, we switch the directory of Y to the AAD of Organization B. Once that has completed, we then move all the resources from Y to Z.

Is that complex? Sadly… yes. Does it get the job done? Hell yeah! 😉 I’ve personally done this numerous of times to move things from my personal sandbox to a shared team subscription.

Understanding the link to an Enterprise Agreement

Many organizations are leveraging an “Enterprise Agreement” (contract with Microsoft) to consume Azure services. Within such an Enterprise Agreements, the following components exist ;

• Administrative (https://ea.azure.com/)
  • Enrollment : Basically this is the “billing address”.
  • Department : A logical grouping to provide a hierarchy. It also has the ability to configure a spending limit (notification only, no hard limit).
  • Accounts : The accounts that can create Azure subscriptions. This can be linked to a department.
• Technical (https://portal.azure.com)
  • Subscription
  • Resource Group
  • Resources

So in terms of relationships :

Enterprise Agreement (contract terms) => Enrollment (billing address) (=> Department) => Account Owner => Subscription => Resource Group => Resource

Be aware of this structure, as it will be your guidance when designing a governance structure. What are “common” questions in the advanced space ;

• Can I have separate billing addresses for Organization X & Y within our group? Yes. Though this will be via separate enrolments. Thus having an impact on the dependencies underneath. As an alternative, consider internal chargebacks.
• Can I have multiple AADs linked to multiple subscriptions? Yes. From a contract level, billing is linked to the account owner. So as long as the account owner is linked to your enrollment, then the Azure subscription will consume from that contractual agreement. An AAD is linked on two levels… One on the contractual part as the account owner, and a subscription will also be linked to one AAD. On both levels you can have different (or a single) AAD if you want.

I would also like to recommend checking the “Azure Enterprise Scaffold“. If you are looking to govern your Azure agreement/subscriptions, then this is a very valuable asset!

What the … AAD?!?

AAD (Azure Active Directory) is often thought of as “Office 365”. Where there is a very clear 1:1 relationship with Office 365, in reality AAD is a standalone service that can be used as a kick ass identity directory for a lot of applications. And with the latter being said, consider the “EA Portal” (used for the administration of the Enterprise Agreement) and the Azure Portal as applications…

Now let’s take a look at the possibilities that we could setup ;

When looking at the “Enterprise Agreement (“EA Portal”-application), the application allows us to use multiple identity providers ;

• MSA Account Only : Only Microsoft Accounts (“LiveID”)
• Single AAD Tenant : You can only use AAD accounts from a single tenant.
• Multiple AAD Tenants : You can only use AAD accounts. There is no way to select which… It is “one” or “all in the world”.
• Mixed : A combination of the above.

Next to that, we saw earlier on in this blog post that we can change the directory of a subscription. So we could have an account owner that is linked to AAD B and the subscription is linked to AAD A (example: Subscription Y). In addition, we can also do “B2B“-invites, where a placeholder/stub of the account from a different directory is imported into an AAD. You can then grant rights to this “stub”, where the user will still authenticate versus their own AAD. Thus removing the complexity (and risks!) of having multiple identities.

(Update : From the old “ASM” portal days, there is sometimes also mention of a “Service Administrator”. Be aware that this is a different user than the account owner.)

 

Closing Thoughts

Enterprise scenarios are typically quite complex by nature… As Azure is accustomed with able to deal with these scenarios, I must admit that the complexity to understand the above isn’t always a gift. Though I do hope that this blog post was insightful and cleared things up for you!